Portál AbcLinuxu, 17. května 2024 00:53
V prvním díle jsme si řekli, jak nakonfigurovat Kerberos klienta a PAM na linuxovém serveru. Také jsme si uvedli, které instalační balíčky budeme potřebovat. Teď popíšeme změny konfigurace doménového kontroleru (PDC) a konfiguraci LDAP klienta.
Při větším počtu linuxových stanic není výhodné, aby údaje o uživateli
obsahovala každá zvlášť. Proto k centralizaci hesel přidáme i centralizaci
údajů, které jsou obvykle uloženy v /etc/passwd, NIS nebo na
LDAP serveru. Jedná se o login, uživatelské číslo, číslo jeho primární
grupy, domovský adresář, shell.
MS Windows server ukládá (nejen) uživatelské údaje do LDAP databáze, která je základem AD. Pro popis databáze se používá schema (terminus technicus). Schema použité Microsoftem není kompatibilní s normou POSIX používanou ve světě UNIXu. Naštěstí lze toto schema rozšířit do dobře použitelné podoby. Rozšíření schematu je zdarma dodáváno přímo Microsoftem jako součást Services for Unix (SFU). Při instalaci SFU se nám toho nainstaluje ovšem víc, než bychom si přáli, a proto zde existuje alternativa v podobě balíčku AD4UNIX) a jeho binární podoby MKSADPlugins.msi, kterou je potřeba na MS Windows PDC nainstalovat. Plugin obsahuje kromě rozšíření schematu i doinstalování záložky Unix Settings do menu Active Directory Users and Computers, kterým v MS Windows editujeme údaje o uživateli.
Ve firmě jsme si rozšíření nechali v rámci migrace z Windows NT na 2003 udělat našim dodavatelem MS Windows 2003 řešení a při tom jsem se dozvěděl, že toto rozšíření schematu je krok nevratný. Doporučuji při této operaci postupovat s rozmyslem a dělat ji teprve v okamžiku, kdy víme, co děláme. Pro milovníky novinek od Microsoftu uveďme, že rozšíření schematu je součástí nového vydání Windows Server, 2003 R2.
Moje vlastní zkušenost s pluginem je taková, že spolehlivě nainstaluje rozšíření schematu, což jsem si vyzkoušel na dvou testovacích čerstvě nainstalovaných Windows 2003 PDC na VMware. Zkušební instalace serverů neobsahovala žádný update. Plugin obvykle první nainstaluje administrátorskou záložku pro editaci Unix Settings a pak se každém případě zeptá před nainstalováním rozšíření schematu, zda to opravdu chceme. Bohužel v případě našeho PDC, BDC a Exchange serveru záložku Unix Settings do menu nenainstaloval. Nainstalovat funkční záložku se mi povedlo pouze na samostatném serveru v doméně a na Win XP s administrátorskými nástroji. Na druhou stranu na zkušebním PDC serveru se záložka bez nejmenších problémů nainstalovala, ale dokud jsem nezadal alespoň nějaké relevantní UNIXové uživatelské ůdaje do AD jinou cestou, způsobovala chybu aplikace Active Directory Users and Computers. Naštěstí odinstalace pluginu nemá žádný vliv na již rozšířené schéma a díky volitelnosti rozšíření schematu se lze později pokusit o přeinstalaci.
V případě, že se nám nepovede záložku Unix Settings nainstalovat,
nezbývá nám nic jiného, než údaje doplnit z Linuxu pomocí utility
ldapmodify. Jak na to, si ukážeme později.
Linuxový server musí mít někde nastaveno, že se má do AD (LDAP databáze)
dívat, a musí vědět, kde LDAP server najde, a jak se jej má zeptat. První
údaje se dozví ze souboru /etc/nsswitch.conf, druhé ze souboru
/etc/ldap.conf. Samozřejmě předpokládáme, že LDAP klienta máme
nainstalovaného.
Během konfigurace budeme mít na paměti, že lokální uživatel root v Linuxu a uživatel administrator ve Windows jsou dva zcela nezávislí uživatelé a pro jistotu nebudeme konfigurovat žádnou korespondenci mezi nimi.
NSS je mechanismus, který umožňuje různým funkcím systému hledat jména
a jim příslušející údaje v různých zdrojích, které jsou vyjmenovány, včetně
pořadí právě v souboru /etc/nsswitch.conf. Většinu údajů
necháme nezměněnu, pouze změníme položky passwd a
group tak, že k nim přidáme ldap. Tady je příklad
mého nsswitch.conf:
# passwd: files nis # shadow: files nis # group: files nis passwd: compat ldap group: compat ldap # zbytek je sice nutny, ale nas uz nezajima hosts: files lwres dns networks: files dns services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files nis aliases: files
V příkladu jsme záměrně ponechali i zapoznámkované položky. Pokud ve
vašem původním nsswitch.conf bude compat místo
files, ponechte tam původní hodnotu a pouze přidejte
ldap. Kvůli lokálním uživatelům nemusíme zapoznámkovávat
shadow (jak bylo zmíněno v minulém dílu (Integrace linuxového serveru do domény Windows 2003), příkaz
passwd se nemusí chovat podle očekávání).
Než se pustíme do konfigurace LDAP klienta, vyzkoušíme přístup k LDAP
databázi na Windows serveru. Použijeme k tomu příkaz
ldapsearch s parametry tak, že nebudeme potřebovat
konfigurační soubor. Zadejte (vše na jeden řádek)
ldapsearch -x -W -h 10.8.8.1 -b
"cn=users,dc=windom,dc=diiradu,dc=cz"
-D "cn=Kucera Jaromir,cn=users,dc=windom,dc=diiradu,dc=cz"
"sAMAccountName=*" sAMAccountName
Parametry najdete v man ldapsearch. Za přepínačem
-D si všimněte cn=Kucera Jaromir,cn=users, ke
kterému se váže heslo a nevyskytuje se tam login (ten si necháváme vypsat).
První výskyt cn=users nemusíte měnit, druhý výskyt je
závislý na vaší implementaci a může vypadat třeba takto:
ou=admini. Paranoiky upozorňuji na fakt, že komunikace není
šifrovaná. Proto jsme raději nepoužili v téměř každé instalaci přítomný
záznam "cn=Administrator". Výstup vede na zhruba něco takového
(v prvním řádku zadáváme heslo):
Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope sub # filter: sAMAccountName=* # requesting: sAMAccountName # # AD Reader, Users, windom.diiradu.cz dn: CN=AD Reader,CN=Users,DC=windom,DC=diiradu,DC=cz sAMAccountName: adreader # Administrator, Users, windom.diiradu.cz dn: CN=Administrator,CN=Users,DC=windom,DC=diiradu,DC=cz sAMAccountName: Administrator . . . # Zak Ivan, Users, windom.diiradu.cz dn: CN=Zak Ivan,CN=Users,DC=windom,DC=diiradu,DC=cz sAMAccountName: izak # search result search: 2 result: 0 Success # numResponses: 395 # numEntries: 394
Přirozeně můžete dostat nejrůznější chybové hlášky. Invalid
credentials znamená, že je něco špatně v řetězci za parametrem
-D nebo heslo. Taky může být problém ve firewallu, který
neotevře ldap port na Windows serveru. V každém případě, dokud chybu
nenajdete, nemá smysl pokračovat dál.
Ted se vrátíme ke zmíněnému doplnění údajů uživatele pomocí
ldapmodify. Předpokládejme, že již máme v AD zavedeného
uživatele "Kucera Jaromir". Údaje ekvivalentní řádku v
/etc/passwd vyžadované UNIXem doplníme tak, že vytvoříme
soubor jkucera.ldif (na jméně nezáleží) s následujícím
obsahem:
dn: cn=Kucera Jaromir,cn=users,dc=windom,dc=diiradu,dc=cz changetype: modify add: uidNumber uidNumber: 1152 - add: gidNumber gidNumber: 100 - add: msSFUName msSFUName: jkucera - add: gecos gecos: Kucera Jaromir - add: msSFUHomeDirectory msSFUHomeDirectory: /home/jkucera - add: loginShell loginShell: /bin/bash -
a jeho obsah přidáme do databáze AD příkazem (vše na jednom řádku)
ldapmodify -x -W -h 10.8.8.1 -D
"cn=Administrator,cn=users,dc=windom,dc=diiradu,dc=cz" -f
jkucera.ldif
Uživatel zapisující do AD musí mít práva administrátora, proto použijeme
"cn=Administrator" za přepínačem -D. Pokud si
znovu vypíšeme pomocí ldapsearch uživatelské údaje, měli
bychom mezi nimi najít i právě zadané.
Všechno funguje skvěle 
a můžeme editovat
/etc/ldap.conf. Soubor ldap.conf najdete na svém
počítači pravděpodobně i v adresáři /etc/openldap/, tento
soubor není pro účely NSS a PAM používán. Konfigurační údaje v něm uvedené
používají LDAP utility jako již dříve zmíněná ldapsearch.
Debian používá dva různé soubory - /etc/libnss-ldap.conf pro
NSS a /etc/pam_ldap.conf pro PAM. V našem případě budou oba
stejné a dokonce budou stejné jako ldap.conf v SUSE. Konečně
se dostáváme ke komentovanému souboru:
# /etc/ldap.conf # ldap servery PDC a BDC (staci jeden) host 10.8.8.1 10.8.8.3 base dc=windom,dc=diiradu,dc=cz ldap_version 3 # k bezpecnosti prihlasovacich informaci (2 radky) se vratime binddn cn=AD Reader,cn=users,dc=windom,dc=diiradu,dc=cz bindpw "heslo_v_citelne_podobe" scope sub # ssl proti windows AD se mi nepovedlo rozbehnout ssl no pam_filter objectclass=user pam_login_attribute sAMAccountName pam_password ad # Nasledujici tri radky hodne zavisi na cleneni uzivatelu # do ruznych organizacnich jednotek (OU) v ramci AD. # Mozna budete muset vsude dat DC=windom,DC=diiradu,DC=cz # coz povede k hledani v ramci cele databaze. nss_base_passwd DC=windom,DC=diiradu,DC=cz # když pouzivame Kerberos nepotrebujeme shadow # nss_base_shadow CN=Users,DC=windom,DC=diiradu,DC=cz nss_base_group CN=Users,DC=windom,DC=diiradu,DC=cz # Na zbyvajicich radcich prirazujete POSIX parametrum pouzivanym # v UNIXu parametry pouzivane v AD ve Windows nss_map_objectclass posixAccount User # MS SFU definuji pro uid msSFUName, nicmene nasledujici volbu # povazuji za stastnejsi. nss_map_attribute uid sAMAccountName nss_map_attribute uniqueMember Member nss_map_attribute userPassword msSFUPassword nss_map_attribute homeDirectory msSFUHomeDirectory nss_map_objectclass posixGroup Group nss_map_attribute cn sAMAccountName
Přihlašovací informace na řádcích s binddn a
bindpw jsou v ldap.conf veřejné a ani zprovoznění
SSL nás od jejich zveřejnění neuchrání, protože ldap.conf
musí být podobně jako /etc/passwd čitelné pro všechny. Do LDAP
databáze AD máme možnost dát anonymní přístup nebo podobně jako v našem
příkladě vytvořit uživatele, který má ve Windows minimální práva. V našem
případě je to AD Reader ve skupině Domain Guests.
Pro otevření anonymního přístupu nebo pro zajištění přístupu do AD pouze
pro čtení použijeme na Windows 2003 serveru administrátorskou aplikaci
Active Directory Users and Computers a pravým tlačítkem myši na
doméně vyberte Delegate Control. V otevřeném wizardu si vybereme to,
co nám nejlépe vyhovuje.
Pokud se nám povedlo nainstalovat výše zmíněný plugin AD4UNIX, můžeme na
Windows serveru doeditovat UNIXové údaje uživatelů nebo, pokud si dobře
rozumíme s LDAP utilitami, nebude nám určitě dělat problém napsat si skript
pro zápis unixových uživatelských údajů do AD. Uživatelé se pak budou moci
přihlástit k našemu linuxovému serveru. Chybí nám ovšem ještě způsob, jak
vytvořit domovský adresář uživatele na serveru. Bohužel to asi budeme muset
udělat nezávisle na vytvoření uživatele v AD. Pokud vše, co bylo popsáno
výše, aplikujeme na pracovní stanici, máme k dispozici možnost, jak
domovský adresář vytvořit při prvním přihlášení uživatele (nejen) na
lokální textové konzole. V souboru /etc/pam.d/login, to
zajistí řádek:
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
Pokud chceme neexistující domovský adresář vytvořit i při jiném způsobu
přihlášení, musíme uvedený řádek přidat do všech odpovídajícíh souborů nebo
jej dát do společného souboru, jak je to uvedeno v příkladu
/etc/pam.d/common-session pro Debian. V adresáři
/etc/skel/ musí být umístěna šablona domovského adresáře (a
téměř jistě ji tam najdeme). Pokud vytvoření domovského adresáře
nezajistíme, uživatel bez domovského adresáře se může přihlásit s omezenými
právy třeba do adresáře hlavního / (např. při použití ssh),
což asi není žádoucí. Je to problém, kterému budeme muset přizpůsobit
konfiguraci, abychom dostali uspokojivý výsledek pro každou možnost
vzdáleného přístupu na server, která s domovským adresářem počítá.
Než přistoupíme k testování, doporučuji pro ladění systému vypnout
nscd démon (/etc/init.d/nscd stop), protože jinak
mohou být získávány z jeho cache neaktuální údaje. Nemusíme pak démon po
každé změně restartovat. Dokumentace od Samby obecně doporučuje při použití
winbind nepoužívat nscd vůbec.
Konečně vše, co potřebujeme pro přihlášení uživatele definovaného pouze
v AD na Windows serveru, máme připraveno a můžeme jej zkusit přihlásit z
lokální textové konzole. Správnou funkci NSS a ldap lze ověřit i tak, že
vytvoříme pod rootem třeba soubor pokus a přiřadíme jej
vlastníkovi testuser definovanému pouze v AD s id
(uidNumber) např. 54321 (touch pokus;
chown 54321 pokus). ls -l by pak mělo správně
vypsat
-rw-r--r-- 1 testuser root 0 2005-06-18 21:59 pokus
K ladění nefungujícího PAM použijeme obsah souborů ve
/var/log/ a možnosti dopsat parametr debug za
odpovídající pam modul do konfiguračního souboru. Např.
auth required pam_krb5.so use_first_pass debug
případně použijeme Ethereal pro sledování packetů na síťové kartě a grafickou utilitu GQ pro přístup k LDAP. I když vývoj GQ ještě neopustil testovací fázi (určitě si toho všimnete), utilita umožní přehledné prohlížení LDAP databáze na PDC včetně schematu.
V okamžiku, kdy se uživatel definovaný pouze v AD může přihlásit k linuxovému serveru, nám zbývá pouze konfigurace Samby.
Dovoluji si upozornit na programek Luma, umi toho cca stejne jako GQ. Jeho vyvoj neustrnul v roce 2003 a podle meho nazoru ma i prijemnejsi ovladani a skvelou lokalizaci. Dle cerveneho trpaslika davam tomuto programu pet a pul pracky Whirpool.
Ohledně Win 2003 RC2 nemůžu napsat vůbec nic, protože jsem se s ním nesetkal. Informaci uvedenou v článku jsem v podstatě náhodou našel na Internetu v jakési důvěryhodně vypadající recenzi.
Můj osobní dojem je, že MS si s RFC2307 moc hlavu nelámal a pro ekvivalentní ůdaje použil své pojmenování. Proto asi nemá moc smysl pokoušet se jejich schema rozšiřovat podle RFC. Asi je lepší přijmout "MS SFU standard".
Nevím jak odpovědět na otázku jakým způsobem rozšíří schema AD4Unix. Před několika měsíci jsem to schema měl ve svém počítači a bylo k dispozici na Internetu, jak už jsem psal ve svém prvním diskusním příspěvku, na Inetu schema zmizelo a já jej taky nemůžu najít. Ze zdrojáků od AD4Unix se přímočaře dostat nedá, ale určitě v nich je. Fakt mě mrzí, že jsem vám předložil černou skříňku místo solidního popisu. Jediné co vím, je to, že rozšíření pomocí AD4Unix je totožné s SFU rozšířením, ale ani tady nevím jistě, zda dokonale. Taky je postačující pro získání ůdajů, které jsou standardně v /etc/passwd a /etc/group. Pokud si AD4Unix nainstalujete na nějaký zkušební server, velkou část atributů a "Object Classes" poznáte podle prefixu "msSFU". V reálném čase bohužel přesnější odpověď dát nedokážu.
Souhlasím, že by bylo super, kdyby RC2 zahrnovalo RFC2307. Jen si nedokážu představit, jak to udělají při zachování zpětné kompatibility?
Taky se mi ten plaintext nelíbí, ale nedokázal jsem se přes to dostat. Pokud se to někomu povedlo a bude ochoten se o zkušenosti alespoň rámcově podělit, jsem ochoten vše vyzkoušet a pak se o tom rozepsat v nějakém NEpřímém pokračování.
msSFU30, kdežto AD4Unix pouze kratší msSFU.
Každé rozšíření schematu obsahuje prvky, které nejsou obsaženy v tom druhém. Jinými slovy: Odlišnost není nepodstatná, ale zároveň není problém upravit naši konfiguraci podle použitého schematu.
[ondrejv@hercules ~]$ /usr/kerberos/bin/kinit
Password for ondrejv@PRAGUE.AD.S3GROUP.COM:
[ondrejv@hercules ~]$ /usr/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_2527
Default principal: ondrejv@PRAGUE.AD.S3GROUP.COM
Valid starting Expires Service principal
12/28/05 10:44:10 12/28/05 20:44:16 krbtgt/PRAGUE.AD.S3GROUP.COM@PRAGUE.AD.S3GROUP.COM
renew until 12/29/05 10:44:10
Kerberos 4 ticket cache: /tmp/tkt2527
klist: You have no tickets cached
[ondrejv@hercules ~]$ ldapsearch -h polaris -b "" -s base -Y GSSAPI
SASL/GSSAPI authentication started
(tady cekam hoodne dlouho)
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI
Error: Miscellaneous failure (Cannot contact any KDC for
requested realm)
Zajimave je, že ve skutečnosti to KDC (řadič AD domény) najde a chvilku si to s ním i povídá (asi tak 4 pakety...)
Fungovat by to ale mělo - nevím co se děje - zkusíte to taky?
3.5.2006 16:57
houska | skóre: 41
| blog: HW
LDAP passwordje heslo toho uzivatele na domenovem radici/to ktere pouziva pro prihlasovani do windows?
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.