[megoldva]Centos 6.4 windows domainba léptetés

UNIX kezdő

Sziasztok!

Valaki csinált már ilyet?
Centos 6.4 windows 2008 domainba léptetése. Találtam több leírást is, de nagyon kínainak hangzik, mert még soha nem csináltam.
Fordítva már igen, de így még nem.
Valakinek van valami tapasztalata? ( karakteresen kellene leginkább.)

( mr shadow v | 2013. 10. 22., k – 16:59 )

sub
--
>'The time has come,' the Walrus said<

Winbind-el próbálok csatlakozni. Ezt kapom vissza amikor csatlakozok. A 2008-ban meg is jelenik a linux gépem ( CENTOS ), illetve a centos.test.hu-ra tudok ssh-zni de a tartományi felhasználóval nem tudok bejelentkezni.

[/usr/bin/net join -w DC -S test.test.hu -U Rendszergazda]
Ignoring unknown parameter "mangle case"
Enter Rendszergazda's password:<...>

Using short domain name -- DC
Joined 'CENTOS' to dns domain 'test.hu'
No DNS domain configured for centos. Unable to perform DNS Update.
DNS update failed!

( traktor | 2013. 10. 22., k – 18:09 )

Par honapja inditottam en is itt egy szalat a temaban: hup.hu: LDAP vs AD, arra eleg sok valasz jott, az alapjan en meg is csinaltam, igaz nem CentOS-sel, hanem Ubuntuval, de nagy kulonbseg nincs. Igertem, hogy irok egy howto-t is... azzal meg nem vegeztem, de ahogy te fent irod valojaban tobb jo megoldas is van mar a neten.

Sziasztok!

Köszönöm a válaszokat. Traktor olvastam a te elindított kérdésed. Nekem ebből a szempontból szerencsés helyzetem van, a felhasználókat nem én kezelem sőt abszolút semmit. A lényeg hogy a linux szerver be legyen csatlakoztatva a domainba.
Hogy a rajta használt szoftver ami tőlünk származik az a ad-s felhasználókkal legyen hitelesítve. Mivel erre nem került még sor hogy így legyen megoldva a hitelesítést csak ennél az egy cégnél így nincs túl sok infóm erről. Annyit találtam hogy egy domainba kell hogy legyen a linux szerver az ad-val. A szoftverünkbe pedig meg kell adni a felhasználót és az uid-ját. Ezután elvileg már az ad-s felhasználókkal fognak tudni bejelentkezni. Legegyszerűbb megoldásnak a PowerBrokert találom első ránézésre, de a te topicodban is nagyon sok hasznos dolog van.
Leginkább nekem csak annyi lenne a lényeg, hogy karakteresen hogyan tudnám beléptetni domainba a linuxot.

Ez a "domainba leptetni" ez nagyon ködös dolog. Szerintem te csak siman onnan akarsz autentikalni, nem? Nem akarod majd AD-bol manage-elni a gepedet, azt sem akarod, hogy szepn update-elje a DNS-t AD oldalon.... meg nem is tudom miket tudna meg az AD, amiket te szeritnem nem biztos, hogy akarsz. Ugye?

Ha igy van, akkor egyszeruen egy LDAP+kerberos autentikaciot kell beallitanod Linuxon, ennek annyi feltetele van, hogy elerd az ehhez szukseges portokat az AD szerver(ek)en, es legyen valami accaountod ami ozza fer az LDAP-hoz. Ugyhogy nem kell 'egy domainban lenniuk'... barmit is jelentsen ez.

Nos én nem akarok semmilyen domainos felhasználóval bejelentkezni a linux szerverre. Nekem a lényeg csak annyi hogy a linuxon futó erp rendszer a domain felhasználókkal tudjon autentikálni. Ehhez azt írták hogy szükséges az hogy egy domainba legyenek.
Nekem annyi a lényeg, hogy az erp-rendszerben lévő felhasználóhoz megadom az ad-s felhasználó uid számát és felhasználó nevét, majd az ini fálj-ba megadom hogy felhasznál+jelszót kérjen bejelentkezésnél és ezután már az ad-s felhasználóval tudjak belépni. Illetve ha lejár a jelszó az ad-ban akkor az erp-ben is. Ezt egy bejelentkezésnél megváltoztatva az erp rendszer kiértékeli és ott is az új jelszó élne.

Na, akkor szerintem ennek kicsit kerdezz jobban utana, mielott a Linux "domainba leptetes"-ebe nagyon beleasod magad. Lehet, hogy neked egyaltalan nem ez kell. Lehet, hogy az ERP rendszernek meg lehet adni kulso autentikacios forraskent az Active Direcotory-t. Ha igy van, akkor Linuxon (marmint magan az OS-en) semmit nem kell csinalnod.

Ennyi + infót sikerült ezzel kapcsolatban szereznem

Windows szerver: a jelszó beállítása GUI (grafikus kezelőfelület) felhasználók számára
A munkaállomás PC-nek és a szervernek ugyanabban a domain-ben kell lennie. Ekkor a ++-en keresztül beállítható a domain jelszó, ami a GUI-ban (grafikus kezelőfelületen) való bejelentkezéskor is kiértékelésre kerül.

Figyelem!

A loginnevet ne törölje ki az operációs rendszerből! Különben fennáll annak a veszélye, hogy a felvitt felhasználók szándéka ellenére bejuthatnak az ERP-be.
Csak olyan loginneveket adjon meg, amik jelszóval védve vannak! Máskülönben az ERP-t teljesen jelszóvédelem nélkül lehet működtetni.
Nem írhat be különböző login neveket ugyanazzal az UID-vel (User Identifikation) különböző jelszó meghatározásokban.

A felhasználók minden egyes kezelésénél, akkor is, ha LDAP-n vagy Active Directory-n alapul, biztosítani kell, hogy az ERP-hez engedélyezett felhasználók azoknak a UNIX felhasználói csoportoknak is a tagjai legyenek, amikhez a megfelelő ERP adatbázisok tartoznak.

Egy új számítógépre való áthelyezés során az UID-nek az új számítógépen minden egyes felhasználó számára ugyanannak kell lennie, mint a régi számítógépen.
Az UID az abas ERP-ben elmentésre kerül és új UID-k kiadásánál az áthelyezés után már nem található meg.

Ez továbbra sem tiszta. Szét kell választani a dolgokat.

Hol vannak nyilvántartva a felhasználók, az AD-ben, vagy az ERP-ben?

- Ha az előbbi (AD), akkor az ERP-ben csak azt kell beállítani, hogy honnan authentikáljon, a lehetőségek pl.:

- melyik domainből/realmből (pl. kerberos auth esetén) - ehhez fog kelleni, hogy az ERP-nek legyen egy SPN-je (service principal name) és egy keytab fájlja, amihez viszont tényleg léteznie kell machine accountként az AD-ben a linuxos gépnek - javasolt tool a msktutil, howto pedig pl. itt: http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos

- melyik LDAP-ból (pl. LDAP auth esetén) - ezt megint lehet kétféleképpen is csinálni:

- lehet szükség arra, hogy legyen egy olyan felhasználó az AD-ben, amivel hozzáfér az ERP rendszer az AD-hez, ekkor az ERP ezzel a felhasználóval csatlakozik az AD-hez és ott lekérdezéseket csinál, pl. megkérdezni, hogy az ERP-be belépni szándékozó felhasználó létezik-e az AD-ben, oké-e a jelszava, megfelelő csoportnak tagja-e stb. (ez nagyon kevéssé valószínű eset, de láttam már olyan rendszert, ami LDAP-pal így működött együtt az authorizációs rész kapcsán)

- lehet, hogy a belépni kívánó felhasználó nevében próbál az ERP kapcsolódni az LDAP-hoz, ha sikerül, akkor authentikáltnak tekinti a felhasználót, ha nem sikerül, akkor meg nem - ebben az esetben nem kell az AD-be semmi

- Ha az utóbbi, akkor van egy felhasználói adatbázis az ERP-ben is, amit valamilyen módon karban kell tartani. A felhasználónevek kapcsán lehet:

- kézzel,

- az AD felé indított periodikus/triggerelt LDAP lekérdezésekkel (amely lekérdezésekhez legalább kétféleképpen (kerberos, LDAP bind külön userrel) lehet authentikálni)

A jelszavak kapcsán már kicsit keményebb dió a dolog - az AD-ben tudtommal nincs olyan mechanizmus, amivel ha az AD-ben megváltozik egy felhasználó jelszava, akkor az AD szól erről egy másik rendszernek (ha valaki tud ilyet, szóljon). Ugyanez a fordított irányban az ERP-től függően megoldható is lehet - beauthentikál a felhasználó, jelszót változtat, majd ugyanezt megteszi az AD-ben is.

Sokkal többet segíteni csak akkor tudunk szerintem, ha ezeket kideríted az ERP-d kapcsán...

A jelszavak kapcsán már kicsit keményebb dió a dolog - az AD-ben tudtommal nincs olyan mechanizmus, amivel ha az AD-ben megváltozik egy felhasználó jelszava, akkor az AD szól erről egy másik rendszernek (ha valaki tud ilyet, szóljon). Ugyanez a fordított irányban az ERP-től függően megoldható is lehet - beauthentikál a felhasználó, jelszót változtat, majd ugyanezt megteszi az AD-ben is.

Nincs ezzel semmi baj, az AD-nek nem kell ertesitenie senkit. Az ERP az AD-bol autentikal, ha az AD-ben lejar a jelszo, akkor a user kovetkezo belepesenel (az ERP-re) ez ki fog derulni, es ha az ERP eleg okos, akkor felajanlja, hogy valtoztasd meg a lejart jelszot. (Ha nem, akkor incs nagy baj, a userek AD oldalon is megvaltoztathatjak a jelszavukat.) De ha a gepek ahonnan auserek jonnek eleve domainban vannak (gyanitom ezert van egyaltalan AD), akkor a lejaro jelszavukat ugyis a sajat gepukre belepeskor valtoztatjak meg.

Na ez van akkor, amikor a kerdezo nem azt mondja el, hogy mit szeretne elerni, hanem azt kerdi, hogy a kivant celhoz szerinte szukseges feladat hogyan oldhato meg.

Most te pont nem jo helyen keresgelsz.

A legtobb ertelmes rendszer tud LDAP auth-ot, mivel ez total alap. Pont ez a szepsege az LDAP-nak, hogy total szabvanyos dolog, es rengeteg dolog tamogatja. Meg a Cisco ASA tuzfal is tudja a VPN-t LDAP-pal autentikalni, a tartalmazo OU-n kivul akar csoporttagsag fuggvenyeben is. De pl. tamogatja a Gitblit, Redmine, Jenkins, OTRS is, hogy par egzotikusabbat is mondjak.

Ehhez marhara nem kell a futtato OS-nek a tartomanyban lennie. Kell egy darab mezei Domain User az ldap query-khez, beallitod a base dn-t, meg par egyeb aprosagot, es megy, mint a kisangyal.

Ha az ERP rendszeretek (amirol nem artana a semminel tobbet mondani) nem tudja ezt, akkor az szivas. Ez esetben marad az, hogy a rendszer hasznaljon OS auth-ot, az OS pedig legyen osszelove LDAP-pal PAM-en vagy barmi mason keresztul. De ez szerintem elegge kellemetlen megoldas, mert akkor lehet kuzdeni azon is, hogy a t. user-ek ne tudjanak hozzaferni a shell-hez, stb. Ha a rendszer OS auth-ot sem tud, akkor pedig monnyonle IMHO.

Köszönöm a választ a kapcsolat már okés.
Most már csak az lenne a lényeg, hogy azok a felhasználók amik ad-ban vannak linuxon is legyenek meg. Ehhez gondoltam a trustolást, de nem tudom hogy kellene megoldani.

[global]
<------>allow trusted domains = yes
<------>socket options = TCP_NODELAY
<------>map to guest = Bad User
<------>winbind use default domain = yes
<------>realm = TEST.HU
<------>logon home = \\%L\%U\.9xprofile
<------>passdb backend = tdbsam
<------>template shell = /bin/bash
<------>printcap cache time = 750
<------>cups options = raw
<------>server string = ABAS Server Centos
<------>printing = cups
<------>idmap uid = 10000-20000
<------>template homedir = /home/windows/profil
<------>logon path = \\%L\profiles\.msprofiles
<------>workgroup = DC
<------>winbind enum groups = yes
<------>winbind refresh tickets = yes
<------>printcap name = cups
<------>security = ADS
<------>usershare allow guests = yes

A samba konfigom így néz ki jelenleg.

A kinit működött illetve a klist is. Ezeket próbáltam akkor. a wbinfo-ra kaptam mindig hogy nem fálj vagy könyvtár, mire rájöttem hogy a winbdindek hiányzott egy csomagja... Feltelepítettem, azután a wbifnora is megkaptam szépen minden eredményt.
Ssh-n is betudok már lépni. Most lépek az ERP-re tovább. :)

Van olyan pam modul, ami automatikusan kreál a usernek a skel alapján $HOME-ot a megfelelő helyen - ha akarsz a usereknek saját meghajtót, ez jól jöhet, mert winbind auth-tal is működik szépen: az első szerverre tallózáskot már lesz is neki \\szerver\username megosztása.
A modul neve talán mkhomedir - nem eml. feljből -, de talán azon a wiki oldalon is ott van...
--
PtY - www.onlinedemo.hu

Ebben már nem tudok segíteni - gondolom, az appnak kell megtanítani, hogy pam-ból vagy kerberosból authentikáljon, a userek láthatósága csak egy dolog...
Ha webes app, és kompatibilis az apache auth-tal, akkor az apache-ot könnyűkerberos authra megtanítani (bár ldap authra is meg lehet, csak attól még helyi user nem lesz).
--
PtY - www.onlinedemo.hu