Samba DC

A lap 2007. december 27., 23:48-kori változata

A Samba egy az SMB\CIFS protokollt megvalósító kiszolgáló illetve kliens szoftver Unix platformokra.

Az alábbiakban a Samba tartományvezérlő (Domain Controller - DC) képességeiről lesz szó.

1 Miért jó a tartományi rendszer?

• Központi adminisztráció - központi adatbázisban tárolódnak a felhasználók és a csoportok - ebből Unix kliensek esetén is profitálunk
• Windows tartományi tagok számára ezen felül:
  • Egyszeri bejelentkezés (Single Sign-On) - A munkamenet időtartama alatt a felhasználó újbóli autentikáció nélkül fér hozzá az erőforrásokhoz
  • Mozgó profilok - A felhasználó a tartomány bármely számítógépén a saját munkakörnyezetét használhatja
  • Házirendek - Beállítások központi kezelésére
  • Bejelentkezési parancsfájlok - Az alkalmazások számára egységes környezet (pl. elérési út) biztosítható vele, de ezen felül természetesen szinte bármire használható, ami szkriptelhető

2 A Samba e téren mire képes?

• Samba >= 2.2
  • NT4 típusú elsődleges tartományvezérlő (Primary Domain Controller - PDC)
  • NT4 típusú tagszerver, vagy kliens - akár Active Directory (AD) domainben is, ha az NT4 hitelesítési protokoll engedélyezett (alapértelmezésként még natív módban is az!)

• Samba >= 3.0
  • Támogatja a Kerberos hitelesítést és az LDAP címtárprotokollt, ezért már részt vehet minden AD domainben
  • Az LDAP támogatásnak köszönhetően tartalék tartományvezérlő (Backup Domain Controller - BDC) lehet egy Samba PDC mellet, Windows PDC mellett azonban nem! Az LDAP azért ajánlott a BDC szerephez mert ez az egyetlen Samba felhasználói adatbázis háttér, amely konkurens elérést és replikációt támogat.

• Samba >= 4.0 alpha
  • AD DC, beépített LDAP és Kerberos szerverrel. Az Active Directory esetében már nincs megkülönböztetve PDC és BDC, a tartományvezérlők között Multi-Master replikáció van, s az egyes speciális funkciók szerepekhez (FSMO Role) kötődnek.

• A Samba stabil verzióit elterjedten alkalmazzák DC szerepben, a témáról részletes dokumentáció áll rendelkezésre:
  • Samba-Guide
  • Samba-HOWTO-Collection
  • Különböző hálózatok összekapcsolása, Samba, az előadáson vetített fóliák
  • Samba alapú tartományvezérlők

3 DC szempontból lényeges konfigurációs paraméterek

3.1 passdb backend (felhasználói adatbázis hátterek)

Ebben tárolódnak a jelszavak, illetve további attribútumok. 3 típus közül választhatunk:

smbpasswd

• Előnyök:
  • nem igényel külön konfigurációt, automatikusan kezeli a rendszer

• Hátrányok:
  • egyszerű szöveges fájl alapú, nagy méret esetén lassú
  • a tárolható paramétrek száma szűkös
  • nem támogat replikációt

tdbsam

• Előnyök:
  • nem igényel külön konfigurációt, automatikusan kezeli a rendszer
  • bináris adatbázis, nagy méret esetén jobb teljesítményt nyújt, mint az smbpasswd

• Hátrányok:
  • a tárolható paramétrek száma több, mint az smbpasswd esetén, de még mindig szűkös
  • nem támogat replikációt

ldapsam - LDAP címtár

• Előnyök:
  • jó teljesítmény
  • replikáció támogatása
  • szerkezete sémák segítségével tetszőlegesen bővíthető

• Hátrányok:
  • konfigurálni kell

3.2 security

Az SMB/CIFS protokoll kétféle biztonsági szintet definiál:

• Share level - az egyes megosztásokhoz tartoznak jelszavak
• User level - felhasználók vannak s nekik vannak jelszavaik, ezt a szintet a Samba négy különböző módon valósíthatja meg: user, domain, ads és server módban.

Összesen tehát öt Samba security mód létezik:

• share - A fenti 'Share level' megvalósítása, használata nem ajánlott!

• user - Az alapértelmezett, s a legtöbb esetben ajánlott mód. A kapcsolat kiépítésekor (session setup) a kliens felhasználónév/jelszó párossal azonosítja magát, de a szerver ekkor még nem tudja, hogy a kliens mely erőforrásokhoz szeretne hozzáférni, tehát a felhasználónév/jelszó páros és a kliensgép neve alapján kell hogy eldöntse engedélyezi-e a hozzáférést. Amennyiben igen a kliens ezután elvárja, hogy újbóli autentikáció nélkül csatlakozhasson a megosztásokhoz.

• domain - Ebben a módban a Samba tartományi tag, rendelkezik domain security trust account-tal amivel autentikálni tud a tartományhoz; a szerver maga nem bírál el autentikációs kérelmeket, az a tartományvezérlők feladata. Természetesen az adott szerver egyúttal lehet tartományvezérlő is, de ezt nem ez a paraméter határozza meg, hanem a #domain_logons !

• ads - Olyan Active Directory tartományban, ahol NT4 tag nem vehet részt (Natív AD módban ez nem igaz!) a Samba ezáltal tag lehet, mivel ebben a módban képes Kerberos ticketek fogadására. Használata esetén a password server és a realm használata szükséges.

• server - A Samba korábbi változataiból örökölt üzemmód, használata nem ajánlott mivel számos problémát okozhat (pl. felhasználó kizárása MS password server esetén)! Fontos tudni, hogy eredményeképpen a Samba az autentikációt továbbítja egy másik SMB szerverhez - azaz nem ettől lesz "szerver" maga a Samba! Használata esetén a password server és az encrypt passwords használata szükséges.

3.3 LDAP paraméterek:

• ldap admin dn
• ldap group suffix
• ldap machine suffix
• ldap user suffix
• ldap suffix
• ldap ssl

3.4 További paraméterek

• local master - Arra utasítja az nmbd-t, hogy vegyen részt a helyi főtallózó szerepkörért folyó választásban.

• os level - Meghatározza, hogy mekkora eséllyel nyeri el a helyi főtallózó szerepet az nmbd. Ha a 20-as alapértéken hagyjuk akkor Windows szerverek és kliensek nyernek, 34-es érték már biztosítja, hogy minden Windows rendszer fölött a Samba nyerjen

• domain master - Az opció hatására az nmbd a munkacsoport tartományi főtallózójaként hirdeti magát, ezért kizárólag a PDC-n szabad beállítani a BDC-n nem!

• preferred master - Hatásra az nmbd szavazást kezdeményez induláskor. A domain master = yes opcióval együtt használva garantáltan ez a szerver lesz a tartomány főtallózója.

• domain logons - A tartományi bejelentkezések kiszolgálására utasítja a szervert, gyakorlatilag ettől lesz DC Samba.

• logon drive - A kliensek számára adja meg, hogy melyik meghajtóként csatlakoztassa a felhasználó saját könyvtárát.

• logon path - A kliensek számára adja meg, hogy a mozgó profilt hol tárolják. A UNC szintaxis használható (pl. \\%L\Profiles\%U -ahol %L a szerver NetBIOS nevét, %U a felhasználónevet jelenti).

• logon home - A felhasználó saját könyvtárának elérési útvonala a szerveren (pl. \\%L\%U ).

• logon script - A Logon szkript NETLOGON megosztáson belüli elérési útja. A %U paraméterrel ez egyes felhasználóknak külön szkript adható meg.

• add user script
• unix password sync
• passwd program
• passwd chat
• realm
• password server
• encrypt passwords

4 Jogosultságkezelés

Hogyan rendeli egymáshoz a Samba a Windows SID-eket és a POSIX azonosítókat?

• Amennyiben a kiszolgálón csak helyi fiókok vannak akkor minden felhasználó esetén szükség van Unix fiókra és a hozzárendelt Windows accountra is (utóbbi tárolódik a Security Accounts Manager - SAM adatbázisban), s az ezek közötti összerendelés segítségével jutnak érvényre a jogosultságok.
• Nagy számú felhasználó esetén ez körülményes, ezért ajánlott a Unix fiókokat is LDAP címtárban tárolni, így nincs szükség két adatbázis szinkronban tartására. Ehhez természetesn a Unix névfeloldást és authentikációt is illeszteni kell (nss_ldap, pam_ldap).
• A rendszer felépítése, illetve a felhasználók kezelésének módja szükségessé teheti a Winbind szerver használatát, amely minden esetben biztosítja a Samba számára a POSIX azonosítók és Windows SID-ek kölcsönös megfeleltetését.

5 Mire van szükség ahhoz, hogy tartományvezérlőt készítsünk a Samba-val?

• Önálló PDC-hez elégséges egyetlen Samba (>=2.2) szerver, smbpasswd, vagy tdbsam adatbázis háttérrel.
• Amennyiben BDC-t is szeretnénk alkalmazni:
  • Kell egy Samba PDC :)
  • LDAP címtár megfelelő sémával
  • IDX-smbldap-tools
  • nss_ldap és pam_ldap
  • Szükség lehet a Winbind használatára (pl: tartományon kívüli Windows kliensek esetén)

6 Samba 4 alpha1 teszt

6.1 Telepítés

A Samba Wiki-n található leírás alapján egyszerűen és gyorsan összeállítható egy teszt Samba 4 AD Domain Controller:

• A Samba 4 fordítása és telepítése után a mellékelt "provision" szkript segítségével egy teljesen működő Samba 4 Active Directory Servert kapunk, ezen felül csak egy DNS szerverre van szükség mivel maga a Samba a Kerberos és az LDAP kiszolgáló is. (Sőt a korábban az NMBD által végzett WINS és NetBIOS névkiszolgáló funkciókat is az SMBD démon látja már el)

• A "provision" szkript használata:

./setup/provision --realm=SMB4TEST.ORG --domain=SMB4TEST --adminpass=egyjelszo

• A kapott alap smb.conf fájl:

[globals]
        netbios name    = samserv
        workgroup       = SMB4TEST
        realm           = SMB4TEST.ORG
        server role     = domain controller
        log level       = 4

[netlogon]
        path = /usr/local/samba/var/locks/sysvol/smb4test.org/scripts
        read only = no

[sysvol]
        path = /usr/local/samba/var/locks/sysvol
        read only = no

• A szkript ezen felül elkészíti nekünk a létrehozott domain zónafájlját, s a BIND konfigurációs állományaiban elvégzendő változtatásokhoz is ad mintát. Mindkét fájl a private könyvtárban található, a zónafájl ez esetben: smb4test.org.zone, a DNS módosítási sablon pedig named.conf néven.

• Az alábbiakban látható a nem éppen triviális felépítésű zónafájl:

; -*- zone -*-
; generated by provision.pl
$ORIGIN smb4test.org.
$TTL 1W
@               IN SOA  @   hostmaster (
                                2007120210   ; serial
                                2D              ; refresh
                                4H              ; retry
                                6W              ; expiry
                                1W )            ; minimum
                        IN NS   samserv
                        IN A    192.168.1.9
;
samserv         IN A    192.168.1.9
eac6ba95-9801-4fdb-a489-420ba6078e76._msdcs     IN CNAME samserv
;
; global catalog servers
_gc._tcp                IN SRV 0 100 3268       samserv
_ldap._tcp.gc._msdcs    IN SRV 0 100 389        samserv
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs     IN SRV 0 100 389 samserv
;
; ldap servers
_ldap._tcp              IN SRV 0 100 389        samserv
_ldap._tcp.dc._msdcs    IN SRV 0 100 389        samserv
_ldap._tcp.pdc._msdcs   IN SRV 0 100 389        samserv
_ldap._tcp.c9638a22-98d8-4f71-80d5-4b65481892a9.domains._msdcs          IN SRV 0 100 389 samserv
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs     IN SRV 0 100 389 samserv
;
; krb5 servers
_kerberos._tcp          IN SRV 0 100 88         samserv
_kerberos._tcp.dc._msdcs        IN SRV 0 100 88 samserv
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 88 samserv
_kerberos._udp          IN SRV 0 100 88         samserv
; MIT kpasswd likes to lookup this name on password change
_kerberos-master._tcp           IN SRV 0 100 88         samserv
_kerberos-master._udp           IN SRV 0 100 88         samserv
;
; kpasswd
_kpasswd._tcp           IN SRV 0 100 464        samserv
_kpasswd._udp           IN SRV 0 100 464        samserv
;
; heimdal 'find realm for host' hack
_kerberos               IN TXT  SMB4TEST.ORG

• A szerverünkön és a tartományba léptetni kívánt többi hoston állítsuk be, hogy ezt a DNS szervert használják, a Kerberos miatt ezen felül fontos, hogy az időzónáik is megegyezzenek.
• Ezután már indíthatjuk a Sambát, először célszerű interktív, debug módban megtenni:

 /usr/local/sbin/smbd -i -d 5 

• Első induláskor a Samba kulcspárt generál a SWAT számára, amihez természetesen szüksége van entrópiára, így ha a Samba már fut, de a SWAT még nem elérhető, azonban hibaüzenetet nem kaptunk akkor vélehetően ezzel a problémával szembesültünk. (Úgy tűnik sikerült találni példát arra, amikor hasznos lett volna, ha egy felügyelő rendszer riaszt, hogy a random pool kifogyott :) )

• A SWAT továbbra is a 901-es porton hallgat alapértelmezetten, de a kapcsolat már HTTPS, s nyújt néhány teljesen új funkciót nyújt pl. a címtár kezeléséhez. A Samba-val ellentétben a SWAT-on érződik, hogy jelenleg még alpha státuszban van: számos funkció hibásan, vagy egyáltalán nem működik - pl. nincs még webes szerver konfiguráció.

6.2 Windows kliens beléptetése a tartományba

• Windows 2000 vagy XP operációs rendszer esetén a Vezérlőpult -> Rendszer -> Számítógépnév -> Módosítás menü választásával adható meg a tartomány neve amelybe az adott gépet be szeretnénk léptetni. A jelszó megadása után az 'Üdvözöljük a tartományban – Tartománynév' üzenetet kell kapnunk. Újraindítás után a helyi gép mellett immár a tartományt is választhatjuk bejelentkezési helyként, ahová azonban csak egy tartományi felhasználó léphet be, helyi nem.

6.3 Felhasználók és csoportok kezelése

A Windows Server 2003 SP1 Administration Tools Pack részeként elérhető Active Directory Users and Computers nevű snap-in-nel tudunk felhasználókat és csoportokat felvenni a tartományba:

6.4 A Csoportházirend használata

A Csoportházirend (Group policy) kezelésére a Group Policy Management Console használható.

• Indítsuk el az Administration Tools Pack részeként elérhető Group Policy Management snap-in-t:

Fájl:domain policy.jpg

Itt a Default Domain Policy-t választva szerkeszthetjük az alapértelmezett tartományi házirendet (Default Domain Policy). A Settings fül segítségével lekérdezhető, hogy az aktuális házirend milyen beállításokat tartalmaz.

• Ha a házirendet módosítottuk, akkor a klienseken a gpupdate parancs segítségével kényszeríthetünk ki egy azonnali házirend frissítést; magával a házirenddel ugyanakkor a frissítés gyakorisága is szabályozható.
• A képen látható példában kikényszerjük, hogy az energiatakarékos módból történő visszalépéskor a számítógép jelszót kérjen a felhasználótól.

A Csoportházirend lényege azonban az, hogy az alapértelmezett tartományi házirenden felül használhatunk továbbiakat, amelyeket szervezeti alegységekhez köthetünk, ezáltal rugalmasan határozhatjuk meg, hogy az egyes felhasználókra, csoportokra illetve számítógépre milyen házirend jut érvényre. A tesztelés során azonban a Group Policy Management Console használatával nem sikerült létrehozni új csoportházirend objektumot (GPO-t), s habár a Group Policy Object Editor segítségével ez a probléma áthidalható volt az így létrehozott házirendek nem jutottak érvényre.

6.5 Tapasztalatok

A tesztelés eredményeképpen megállapítható, hogy a Samba 4 első alpha kiadása - mint az várható volt- tartalmaz még hibákat, azonban ezek elhárítása után várhatóan hasonlóan jól fog működni, mint a korábbi verziók. A fájlmegosztás, s az alkalmazott belső Kerberos szerver működése már most is megfelelő - pl. az időszinkronból kiesett gépet nem engedi hozzáférni az erőforrásokhoz - de a belső LDAP és a SWAT még láthatóan fejlesztésre szorul, pl. a fenti két menedzsment eszközzel végrehajtott bizonyos műveletek esetén előfordult, hogy az LDAP szerver leállt.