Integrace linuxového serveru do domény Windows 2003 - 2

20. 12. 2005 | Jaromír Kučera | Sítě | 11507×

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.

Konfigurace společné uživatelské databáze v AD

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.

Konfigurace LDAP klienta

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.

       

Komentáře

[Arno3t]

Využívám autorského privilegia vidět článek dřív než ostatní čtenáři k vložení krátké poznámky. V době, kdy jsem ladil konfiguraci linuxového serveru ve firmě, byl na Internetu k dispozici článek s odkazem na soubor pro rozšíření schematu AD. Bohužel před publikací se na svém původním místě již nevyskytoval a ani jsem jej nikde "nevyGooglil". Proto jsem ruční rozšíření schematu vynechal. Velmi podrobný popis jak to udělat najdete u MS.

[Karel Benák]

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.

[Ondar]

Poznámka - jakkoli je SFU pěkný, tek AD schema nerozšíří tak, aby bylo kompatibilní s RFC2307:. Tady bych si dovolil dotaz na autora : Jakým způsobem rozšíří schema utilita AD4unix nebo Win 2003 RC2? Jinak pekny clanek....

[Arno3t]

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.

[Ondar]

škoda, že nevíte víc - taky jsem slyšel jakési nadějné skazky ohledně RC2 a doufal jsem že se MS pochlapí a neco s tou kompatibilitou schemat udělá (konkrétně jsem slyšel, že MS půjdou právě cestou RFC2307 - což by bylo super).

Další věc - pokud AD4Unix rozšiřuje schema stejně jako SFU, pak nechápu, jaký má tato utilita smysl. SFU rozšíří schema sakumprásk i s AD for Users and Computers utilitou bez problémů a taky zadarmo - a navíc máte jistotu, že to ADC nezboří, protože je to produkt MS.

Poslední věc: koukám, že k AD přistupujete přes plaintext - což je sice nejjednodušší, ale zároveň nejnebezpečnější záležitost. Napadlo mě - LDAP tu máme, Kerberos taky -> proč tedy nezkusit GSSAPI+SASL? Teoreticky by to mělo zafungovat a bylo by bylo naprosto super! Plánujete zmínku o tomto v dalším dílu?

Dík

[Arno3t]

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í.

[Arno3t]

MS SFU používá u atributů a "Object Classes" prefix 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.

[Ondar]

Zajimavy, tak jsem to zkusil:

[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?

[houska]

LDAP password 

je heslo toho uzivatele na domenovem radici/to ktere pouziva pro prihlasovani do windows?

[Arno3t]

Ano, je to heslo pouzivane ve Windows uzivatelem, ktery posila dotaz do LDAP (vztahuje se knemu prihlasovaci retezec za -D v ldapsearch).