Integrace linuxového serveru do domény Windows 2003

7. 12. 2005 | Jaromír Kučera | Sítě | 15100×

Miniseriál pojednává o integraci linuxového serveru do domény Windows 2003 tak, aby sloužil jako NFS souborový server pro stanice s UNIXem a zároveň jako souborový server se Sambou a ověřováním přístupu z Active Directory (AD) s PDC na Windows 2003.

Úvod, distribuce, prostředí

Přístupová práva k souborům požadujeme podle normy POSIX. Vedlejším cílem bude přiblížení se k Single Sign-On mezi Linuxem a MS Windows. Ač předpokládáme, že server bude sloužit i pro NFS, nebudeme se jeho konfigurací zabývat.

Popisovaný server je postaven na SUSE LINUX Professional 9.2. Pro server byla vybrána distribuce SUSE Professional 9.2 především z toho důvodu, že stanice jsou na SUSE provozovány také, mám s ní největší zkušenosti, je docela slušně připravená na použití autentizace přes Kerberos, má dostatečně aktuální Sambu a je možné ji dobře updatovat z Internetu. Pokud si budete chtít zvolit jinou distribuci, doporučuji použít nějakou nepříliš starou. (Článek jsem napsal před pár měsíci a před publikací na abclinuxu.cz jsem jej nechal uležet v naivní víře, že uzraje. Neuzrálo však ani písmenko, ale protože si redakce přála rozdělení článku na části, tak jsem jej přece jen mírně doplnil. Není o posledních dostupných distribucích. Naštěstí SUSE 10.0 se konfiguračně přiblížila níže popsanému Debianu.)

Články zaměřené pouze na jednu distribuci (zvláště pokud to není ta moje :-)) mívají občas tu chybu, že se tváří, že všechno funguje právě tak, jak je v nich napsáno. Jenže vy potřebujete spravovat zrovna jinou distribuci a obvykle vám trvá i několik hodin, než najdete ekvivalentní konfigurační soubory mezi popisovanou a vaší distribucí. Dobré je, že si tím rozšíříte znalosti o obecných principech. Rozhodně vás odlišnosti nepotěší, když chcete někomu rychle ukázat, že řešení na Linuxu je jednoduché a výhodnější než řešení na systémech s méně distribucemi.

Zabrousím proto i do konfigurace v Debianu 3.1 Sarge a jiných distribucí, které moc neznám, ale nainstaloval jsem si je pro srovnání. I když jsem server postavil na SUSE, Debian se mi ve výsledku jevil jako lepší volba. Uvidíte, že především konfigurace PAM má do jednotnosti dost daleko. Nebudeme se zabývat žádným překladem použitého software, použijeme pouze balíčky z distribucí nebo jejich aktualizace. To bohužel vyloučí například Mandrivu Limited Edition 2005 z plnohodnotného použití Samby včetně rozšířených přístupových práv k souborům (Access Control List - ACL).

V konstrukční kanceláři, která má více než sto PC s operačními systémy (OS) od Microsoftu, několik desítek stanic s OS Irix a Solaris a okolo deseti PC s OS SUSE Linux, jsme se rozhodli postavit fileserver s Linuxem sloužící pro všechny operační systémy. Možností, jak zkonfigurovat služby je značné množství. Tady se budeme věnovat popisu konfigurace, nasazené do reálného provozu.

Na konec úvodu ještě poznámka o bezpečnosti: pokud jste paranoidní administrátor se slabší povahou, pak tento článek není pro vás. Popisovanou konfiguraci doporučuji nasadit pouze na serveru ve vnitřní firemní síti, která je od Internetu oddělena firewallem (stejně by asi málokoho napadlo Sambu vystavit do Internetu). Pokusím se upozornit na bezpečnostní problémy tam, kde na ně téměř jistě narazíte, a budu vám vděčný za jakoukoliv radu, jak je řešit (s výjimkou vytažení síťového kabelu z počítače). Řešení klade větší důraz na sjednocení databáze uživatelů než na bezpečnost.

Základní instalace serveru

Server budeme instalovat minimalisticky tak, aby uměl právě to, co od něj vyžadujeme. Jakýkoliv další balíček přidáváme teprve v okamžiku, kdy zjistíme, že nám na serveru chybí. Filesystém volíme tak, aby umožňoval rozšíření přístupových práv podle POSIX (XFS, ReiserFS, Ext3). Jak bylo řečeno v úvodu, server se nachází ve vnitřní firemní síti za firewallem a popis možného zabezpečení proti "vnitřnímu" nepříteli je mimo záměr tohoto článku (kdybych se k tomu někdy odhodlal, určitě by to vydalo na další článek). K základním instalačním balíčkům musíme přidat další tak, abychom měli k dispozici:

• Kerberos klient a utility
• Open LDAP
• PAM
• NSS
• Sambu
• ACL utility (pro rozšířená přístupová práva)
• NTP klient (nebo jinak zajistit synchronizaci hodin)

Při vyhledávání balíčků v naší distribuci se nám budou hodit následující klíčová slova: kerberos, krb5, ldap, nss, pam, nfs, acl, samba, ntp. Konkrétně v SUSE 9.2 se jedná o balíčky heimdal-lib, heimdal-tools, ldapcpplib, openldap2-client, nss_ldap, pam-modules, pam, pam_krb5, samba-client, samba, (samba-winbind), acl, xntp, pam_ldap (poslední není v SUSE nezbytný). Pokud si budete překládat některou část softwaru sami, právě tato kouzelná slovíčka budete muset předkládat příkazu configure obvykle s prefixem with.

Server bude nakonfigurován jako mujlinux.windom.diiradu.cz, ověřování bude zajišťovat Windows 2003 PDC server mujw2k3pdc.windom.diiradu.cz s IP adresou 10.8.8.1, jméno domény je zřejmě windom.diiradu.cz a jméno windows domény je windom. (Pro testování s oblibou používám VMware. Proto jména počítačů, ze kterých kopíruji příklady, mohou začínat vmw...)

Větami v první osobě jednotného čísla se snažím oddělit subjektivní zkušenosti a názory od obecných pravidel.

Další popis bude veden maximální snahou o dodržení správného pořadí konfigurace potřebných služeb. Synchronizaci času mezi počítači budeme předpokládat, ale popisovat ji nebudeme. Proto začínáme konfigurací Kerberos klienta.

Ověřování přes Kerberos

Kerberos je síťový autentizační protokol, který umožňuje ověření totožnosti přes nedůvěryhodnou síť na vzdáleném serveru. Protokol vznikl na MIT a jeho mírně přepracovanou verzi (jak jinak :-)) používá Microsoft v AD. Současné unixové implementace jsou naštěstí s tou od MS kompatibilní.

Nainstalujeme si Kerberos klienta a Kerberos utility. Konfigurace Kerberos klienta je uložena v souboru /etc/krb5.conf, do kterého je nutné zadat především kerberos realm, kerberos server a povolený časový rozdíl mezi systémovými hodinami serveru a klienta (clockskew). Ostatní položky, které bude náš konfigurační soubor obsahovat, se budou lišit podle distribuce. Odlišnost je způsobena především tím, že k dispozici jsou dvě různé implementace - Heimdal nebo MIT Kerberos. Náš Heimdal Kerberos v SUSE 9.2 používá následující konfiguraci:

[libdefaults]
        clockskew = 600
        default_realm = WINDOM.DIIRADU.CZ

[realms]
WINDOM.DIIRADU.CZ = {
        kdc = mujw2k3pdc.windom.diiradu.cz
        default_domain = WINDOM.DIIRADU.CZ
        kpasswd_server = mujw2k3pdc.windom.diiradu.cz
}

[domain_realm]
        .WINDOM.DIIRADU.CZ = WINDOM.DIIRADU.CZ


[logging]
        default = SYSLOG:NOTICE:DAEMON
        kdc = FILE:/var/log/kdc.log
        kadmind = FILE:/var/log/kadmind.log

[appdefaults]
pam = {
        ticket_lifetime = 1d
        renew_lifetime = 1d
        forwardable = true
        proxiable = false
        retain_after_close = false
        minimum_uid = 0
        debug = false
}

Všechny názvy zapsané v konfiguračním souboru velkými písmeny musí být napsány opravdu velkými písmeny! SUSE, Debian, Mandrake i Aurox bez problémů vytvoří tento soubor konfiguračními utilitami (a někdy nám tam nechají i konfigurace realmů, které nepotřebujeme).

V tomto okamžiku provedeme test správné funkce Kerberos klienta pomocí příkazu kinit případně kinit mujlogin. U Debianu, který používá primárně MIT Kerberos, doporučuji použít i parametr -V, který učiní kinit mírně upovídaným. Budeme dotázáni na heslo a po jeho zadání nám počítač s Heimdal klientem potvrdí přijetí ticketu:

jkucera@mujlinux:~> kinit
jkucera@WINDOM.DIIRADU.CZ's Password:
kinit: NOTICE: ticket renewable lifetime is 1 week

U Debianu bez parametru -V mlčení znamená souhlas. Pokud vše proběhlo tak, jak je výše popsáno, můžeme pokračovat v další konfiguraci.

PAM

Kerberos nám funguje, ale do systému se obecně ještě nepřihlásíme. K tomu potřebujeme patřičnému PAM modulu říct, že má Kerberos pro přihlášení použít. PAM je obecným rozhraním mezi různými autentizačními mechanismy a službami systému, které autentizaci vyžadují. PAM se obvykle instaluje z několika balíčků. Kromě základu budeme potřebovat modul pro spolupráci s Kerberem pam_krb5 a možná pam_ldap modul. Konfiguraci PAM provádíme v adresáři /etc/pam.d a /etc/security. Ve způsobu konfigurování se různé distribuce liší.

Obecně platí, že přihlašování a s ním spojené zjišťování potřebných uživatelských údajů se konfiguruje v adresáři /etc/pam.d zvlášť pro každou službu, která přihlašování vyžaduje. Například soubor login je používán při přihlašování se z lokální konzole a soubor sshd je používán při vzdáleném přihlašování se přes ssh. Protože část mechanismu přihlašování pro většinu služeb obsahuje stejné kroky, používají distribuce Linuxu způsob, jak společnou část konfigurovat pouze jednou v jednom souboru. Bohužel právě tady se distribuce značně liší. PAM modul je důležitou bezpečnostní součástí instalace a měli bychom mu věnovat dost velkou pozornost. V testovací fázi stačí s pomocí příkladů dosáhnout nějaké funkční konfigurace. V případě ostrého nasazení si určitě pročtěte manuály k jednotlivým modulům a konfiguraci dolaďte. (Bližší vysvětlení k PAM najdete např. v Linux-PAM-html a pam_unix2.)

V SUSE je používán pam modul pam_unix2.so, který umí zprostředkovat práci s modulem Kerberosu. V Debianu (a většině dalších) má podobnou funkci pam_unix.so, který s Kerberosem nepracuje, a je proto potřeba doplnit další modul pam_krb5.so. V SUSE editujeme pouze soubor /etc/security/pam_unix2.conf do následující podoby:

auth:           use_krb5 nullok
account:        use_krb5
password:       use_krb5 nullok
session:        none

V Debianu (a SUSE 9.3) měníme čtyři začleňované soubory /etc/pam.d/common-.... (viz poznámka na prvním řádku každého souboru):

# /etc/pam.d/common-account
# autorizacni nastaveni spolecne vsem sluzbam

account sufficient      pam_ldap.so
account required        pam_unix.so

Bez pam_ldap.so mě nechtěl (s použitím údajů z AD) Debian přihlásit.

# /etc/pam.d/common-auth
# autentifikacni nastaveni spolecne vsem sluzbam
# pam_unix je tradicni Unix mechanismus.
#
auth    sufficient      pam_unix.so nullok_secure
auth    required        pam_krb5.so use_first_pass

# /etc/pam.d/common-password
# zachazeni s hesly - nastaveni spolecne vsem sluzbam
#
password   required   pam_unix.so nullok obscure min=4 max=8 md5
password   required   pam_krb5.so try_first_pass

# /etc/pam.d/common-session - session
# - nastaveni spolecne vsem sluzbam
#
session required     pam_unix.so
session required     pam_mkhomedir.so skel=/etc/skel/umask=0022auth

V Mandrake, Aurox a Fedora hraje podobnou roli jako začleňované soubory v Debianu soubor /etc/pam.d/system-auth. I když jsem zmíněné tři distribuce testoval, s laděním jsem se moc nenamáhal.

#%PAM-1.0

auth      required    pam_env.so
auth      sufficient  pam_unix.so likeauth nullok
auth      required    pam_krb5.so use_first_pass
auth      required    pam_deny.so dump

account   sufficient  pam_unix.so
account   required    pam_deny.so dump

password  required    pam_cracklib.so retry=3 minlen=4  dcredit=0 ucredit=0
password  sufficient  pam_unix.so nullok use_authtok md5 shadow
password  required    pam_deny.so # i tady by mel byt pam_krb5.so

session   required    pam_limits.so
session   required    pam_unix.so
# pokud chcete, doplnte sem pam_mkhomedir.so

Rozdílné proti standardní konfiguraci jsou pouze řádky s krb5, ldap u Debianu a pam_mkhomedir (poslední dva nás budou zajímat až v příští části). Proti konfiguracím, které nám distribuce vytvoří hned po instalaci, ještě přepíšeme v místech, kam přidáme Kerberos modul, původní required pam_unix.so na sufficient pam_unix.so a ostatní asi budete moct ponechat nezměněné.

Pouze pro úplnost si ukažme ještě příklad souboru /etc/pam.d/login ze SUSE, který se od základní konfigurace liší jen přidaným pam_mkhomedir.

#%PAM-1.0
auth     requisite  pam_unix2.so     nullok #set_secrpc
auth     required   pam_securetty.so
auth     required   pam_nologin.so
# auth   required   pam_homecheck.so
auth     required   pam_env.so
auth     required   pam_mail.so
account  required   pam_unix2.so
password required   pam_pwcheck.so   nullok
password required   pam_unix2.so     nullok use_first_pass use_authtok
session  required   pam_unix2.so     none # debug or trace
session  required   pam_mkhomedir.so skel=/etc/skel/ umask=0022
session  required   pam_limits.so
session  required   pam_resmgr.so

Pokud by naše nároky na Active Directory končily u společného hesla v MS a Unix síti, mohli bychom tady skončit. Za předpokladu, že dobře funguje standardní lokální přihlašování, si to můžeme vyzkoušet tak, že vytvoříme např. uživatele jkucera v Active Directory (zatím bez podpory unixových položek) a uživatele se stejným loginem v Linuxu. V /etc/shadow vyblokujeme jeho účet vložením * místo zašifrovaného hesla do druhého pole a zkusíme se přihlásit. Místo /etc/shadow by měl být použit Kerberos z PDC a přihlášení by se mělo zdařit (v opačném případě musíme nahlédnout do /var/log/messages, /var/log/?dledistribuce? a problém řešit).

Příště se podrobněji zmíníme o položce pam_mkhomedir.so. Pokud ji v konfiguraci PAM máme, nemusíme pro uvedený test v Linuxu plnohodnotně vytvářet uživatele, stačí nám dopsat jeho záznam do /etc/passwd.

jkucera:x:1152:100:Kucera Jaromir:/home/jkucera:/bin/bash

Při uvedeném testu se pokusný uživatel nejen přihlásí, ale automaticky se mu vytvoří i domovský adresář. K ladění nefungujícího PAM použijeme také 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

Nakonec ještě poznámka ke změně hesla. Heslo bychom měli měnit příkazem kpasswd. Jde sice použít i klasické passwd, ale chce si to vyzkoušet. V SUSE se mi passwd chovalo normálně tak, že změnilo heslo na Kerberos serveru, ale při nevhodném nastavení systému ořezalo jeho délku. V Mandrake šlo passwd do chyby, kterou jsem nezkoušel řešit. Domnívám se, že ne vše se vždy podaří vyřešit dobrým nastavením PAM sekce password, která změnu hesla řídí.

Příště

V další části miniseriálu si popíšeme dokonfigurování Windows PDC serveru tak, aby nám poskytoval údaje o uživatelích a konfiguraci LDAP klienta, a aby tyto údaje dokázal ze serveru přečíst.

       

Komentáře

[diverman]

Super! Nezbývá mi nic jiného, než pochválit.

[Tomáš Šimek]

Ani mě ne, pěkný propracovaný článek, jen tak dál

[Marek]

Paradny clanok, tesim sa na pokracovanie.

[davadu]

Skvělé. :) Jsem rád, že to vyjde v podobě článku. Něco jsem měl už v blogu, ale nebylo to tak rozsáhlé a ani nebyl čas článek vytvořit.

Jsem rád, že si někdo takovýto čas udělal, protože Windows Server je dobrý kus software a ve spoustě firem se využívá. Tak proč na něco nevyužít i Linux, když také udělá svou práci dobře a za rozumnou cenu.

[Martin Lebeda]

Windows Server je dobrý kus software

Kacířský názor na zdejším serveru - pozor aby tě neupálili...

[davadu]

Neboj. :) Už jsem přežil horší diskuse. :) Řídím se heslem "Používat věc ke určenému účelu." A když práci líp odvede Windows, tak na serveru bude Windows, když Linux, tak Linux, a tak dále. :)

A zatím, že je to dobrý kus software si stojím. Prozatím, co jsem si všiml, spousta lidí, co nadávají na Windows zamrzla s administračními znalostmi u Win9x, maximálně WinNT. To nemyslím všeobecně na všechny, alespoň co vidím podle diskusí. Obzvláště to platí u porovnávání Windows Server 2003 a Samba 3.x. :)

[benzin]

No pozor. Samba je na neco jineho nez cely Windows 2003. Kdyz ale spojite sambu s LDAP serverem do ktereho nasadite nejake to schema pro AD, tak vam udela tu samou praci co Windows 2003. Je ale pravda ze MsSQL na nem nerozbehate.

Takze rekl bych to takhle. Existuje alternativa zadarmo. Coz samo o sobe neznamena, ze je Windows 2003 spatny.

Protoze AD neni vlstne nic jineho nez LDAP s pekymi GUI konfiguracnimi nastroji.

[Ondar]

Take se musim pridat ke chvale - jen tak dal. Vlastne jsem se chystal napsat podobny clanek, ale autor me predbehnul . Jen slovo ke Kerberosu: Omezeni USA ohledně exportu nastroju uzivajicich velkych delek šifrovacích klíču nedávno padlo, takže nový Suse by měl také užívat MIT kerberos - možná by mělo smysl se v dalších článcích zaměřit právě na tento balík.

Dlouhou dobu jsem si s Kerberosem a AD hrál a dospěl jsem bohužel k závěru, že to není dost stabilní na to, aby to člověk užil naostro ve firmě. Kupříkladu ten PAM - na RedHat 8.0 vše funguje tak jak má, ale na RHEL 4.0 kinit projde, ale přes PAM se nepřihlásím ani za boha.

Bylo by to moc krásné, kdyby to tak fungovalo....

Ondra

[davadu]

Potvrzuji, že na OpenSUSE 10.0 je již MIT Kerberos. Při nedávné integraci OpenSUSE do domény s Win2k3 jsem na něj narazil.

[Arno3t]

MIT Kerberos je už v SUSE 9.3. Já jsem SUSE 9.2 zvolil proto, že jej momentálně používám a taky proto, abych upozornil na existenci obou možností. Konfigurační utility většiny distribucí zvládnou nakonfigurovat Kerberos poměrně dobře. Minimálně vám dají k dispozici šablonu, do které pouze doplníte vaše názvy domén, realmů a serverů.

[Dýka]

Používám u nás ve firmě OpenSuSE 10 jako domain member servery (Samba 3.0.20), uživatelé se autorizují proti DC W2K3. Je to super, ušetříme spoustu peněž za M$ licence (stačí 1 device CAL pro každý server). SuSE 10 je první verze SuSE, u které jsem rozchodil jak autorizaci pomocí Kerberosu, tak ACL. U SuSE 9.2 mi nefungovala ani autorizace (uživatel musel být na Linux serveru založen - klidně i bez hesla a bez přítupu do Samby), ani ACL (access denied i pro roota). Tedy, fungovalo set/getfacl, ale ne Exploder. A na FC4 to po instalaci updatů do gcc fungovalo bez problémů taky hned. Na obou distribucích stačilo upravit /etc/smb.conf, /etc/krb5.conf a etc/pam.d/login.

[Arno3t]

Tak to jsi úspěšnější než já. Říkal jsem si, že bych do posledního dílu rád napsal i zkušenosti se SUSE 10.0, ale bohužel nejsem při stejné konfiguraci jako pro SUSE 9.2 nebo Debian Sarge schopen rozchodit korektní fungování ACL. Docela by mě zajímal Tvůj smb.conf. Pokud to budeš číst, pošli mi ho prosím.

[Karel Novak]

Nemohl bys me prosim te poslat nejaky navod nabo vzorove configuraky moc by me to pomohlo predem dik

karel.novak@aucz.cz

[Martin Job]

Zdravim, neporadi mi nekdo kde sezenu pam moduly na solaris 10 ???? Diky