Samba DC

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen Mzsolt (vitalap | szerkesztései) 2008. január 6., 23:36-kor történt szerkesztése után volt.

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

Tartalomjegyzék

 [elrejtés] 

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: Irodalom

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 (a Kerberos kötelező) 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, sőt így szükség van egy másik szerverre is a működéséhez! Használata esetén a password server és az encrypt passwords paraméterek megadása szükséges.

3.3 LDAP paraméterek:

  • ldap admin dn - A Samba által használt LDAP user DN-je.
  • ldap suffix - A Samba domain BaseDN-je a címtárban. (pl. dc=peldadomain,dc=com)
  • ldap group suffix - A csoportok ága a címtárban, relatívan az ldap suffix-hoz. (pl. ou=Groups)
  • ldap machine suffix - A gépek ága a címtárban, relatívan az ldap suffix-hoz.
  • ldap user suffix - A felhasználók ága a címtárban, relatívan az ldap suffix-hoz.
  • ldap ssl - Hasznljon-e a Samba SSL-t a címtár eléréséhez, 3 lehetséges értéke van:
    • off - nem
    • start tls - LDAPv3 StartTLS mód (RFC2830)
    • on - LDAPS kapcsolat, csak akkor elérhető, ha a --with-ldapsam opció engedélyezett fordításkor.

3.4 További paraméterek

  • local master - Arra utasítja az nmbd-t, hogy vegyen részt a helyi főtallózó (Local Master Browser) 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 (Domain Master Browser) 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 fiókokat létrehozó szkript, abban az esetben fut le (root-ként), ha egy felhasználó sikeresen autentikált a Samba szerverhez, de még nem létezik hozzátartozó Unix account.
  • unix password sync - Ha engedélyezett (=yes) a Samba az SMB jelszó megváltoztatásakor a Unix jelszót is megváltozatja a megadott értékre. Ehhez a passwd program paraméterben megadott parancsot hívja meg root-ként.
  • passwd program - A parancs amivel a Unix jelszót változtatjuk meg (pl. /bin/passwd %u), amennyiben a végrehajtása sikertelen úgy a Samba az SMB jelszó megváltoztatását is visszautasítja.
  • passwd chat - A passwd program meghívásakor használt kommunikációs forma (pl. *New*password* %n\n *new*password* %n\n *Success*). A %n a jelszót helyettesíti, a /n az újsor karaktert, a * pedig tetszőleges karaktersorozatot. Ha a parancs kimenete nem illeszkedik az utolsó sztringre a jelszó megváltoztatása sikertelennek minősül.
  • realm - A Kerberos tartomány (realm) ahová csatlakozik a Samba.
  • password server - Egy másik SMB szerver vagy AD DC, ahová a Samba továbbítja az autentikációs kérelmeket.
  • encrypt passwords - Ha engedélyezett (=yes) a Samba kiszolgáló csak titkosított jelszavakat fogad el.
  • lanman auth - Ha engedélyezett (=yes) a Samba kiszolgálóhoz kapcsolódhatnak LANMAN protokollal kommunikáló kliensek.
  • ntlm auth - Ha engedélyezett (=yes) a Samba kiszolgálóhoz kapcsolódhatnak NTLMv1 protokollon kommunikáló kliensek. Amennyiben a lanman auth és ez a paraméter is tilva van akkor csak az NTLMv2 protokoll engedélyezett.
  • client plaintext auth - A Samba kliens eszközök küldhetnek-e nyíltan jelszavakat.
  • client lanman auth - A Samba kliens eszközök használhatják-e a LANMAN protokollt, ha letiltjuk (=no) a nyílt jelszavak küldése is tiltva lesz.
  • client ntlmv2 auth - Ha tiltva van (=no) akkor a Samba kliens eszközök használhatják az NTLMv1 protokollt. Ellenkező esetben csak az NTLMv2 protokoll lesz engedélyezett, s egyúttal a LANMAN és a nyílt jelszavak használata tiltódik.

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:

  • LDAP címtár megfelelő sémával - A Samba forráskód részeként elérhető samba.schema kell ahhoz, hogy a DC szerepkörhöz szükséges attribútumokat tárolni tudjuk a címtárban.
  • Samba PDC, amely a címtárat használja backend-ként.
  • nss_ldap és pam_ldap
  • IDX-smbldap-tools - A címtár kezelését az smbldap-tools nevű Perl szkriptgyűjtemény segítségével végzi a Samba.
  • Szükség lehet a Winbind használatára (pl: tartományon kívüli Windows kliensek esetén)

5.1 Az nss_ldap beállítása

A Samba felépítéséből adódóan a POSIX azonosítók feloldásához az NSS-t használja. Ha a címtárban tároljuk a felhasználókat, akkor szükséges, hogy a névfeloldást a címtárból is el tudjuk végezni, erre szolgál az nss_ldap, ami az RFC 2307-nek megfelelő névfeloldásra képes LDAP címtárból. A példa libnss-ldap.conf konfigurációs fájl lényeges paraméterei:

  • host - A szerver neve, TLS esetén fontos, hogy a szerver tanúsítványányában szereplő névvel hivatkozzunk a címtárra.
  • base - Az LDAP baseDN, ahol a fiókok tárolva vannak.
  • rootbinddn - A root által indított lekérdezések melyik LDAP felhasználó nevében fussanak. A root hitelesítéséhez szükséges jelszót a /etc/ldap.secret fájlban kell tárolni, 600-as jogosultsággal. A binddn és bindpw paraméter lehetőséget nyújt arra, hogy minden lekérdezés egy megadott LDAP felhasználó nevében fusson, ha azonban nincs megadva, akkor a többi felhasználó által indított lekérdezések anonymous-ként kerülnek végrehajtásra.
  • nss_base_passwd - Az LDAP hivatkozás az NSS passwd lekérdezésekre base?scope?filter formában - lásd: Mi az LDAP URL.
  • nss_base_shadow - Az LDAP hivatkozás az NSS shadow lekérdezésekre.
  • nss_base_group - Az LDAP hivatkozás az NSS group lekérdezésekre.
  • ssl - SSL használata (on), illetve módja (start_tls, illeve ldaps).
  • tls_cacertfile - Az LDAP szerver tanúsítványát kiadó CA tanúsítványa.

Az nss_ldap működéséhez az NSS konfigurációs állományában a passwd, shadow és group bejegyzéshez fel kell venni az ldap-ot, mint forrást.

5.2 A pam_ldap beállítása

A pam_ldap a címtárban tárolt felhasználók számára nyújt lehetőséget Unix autentikációra és jelszóváltoztatásra. A konfigurációja azonos az nss_ldap-éval, ezért a pam_ldap.conf nyugodtan lehet egy link arra, illetve egyes rendszereken eleve a közös ldap.conf-ban szerepelnek a beállítások.

A pam_ldap működéséhez a PAM konfigurációs állományait is módosítani kell (lásd: példa). Az auth és password modulok esetében a try_first_pass opcióval adható át az előzőleg bekért jelszó, ezzel elkerülhető, hogy kétszer kelljen azt begépelni.

5.3 Az smbldap-tools beállítása

A példa smb.conf konfigurációs fájlban láthatóak a konkrét műveletek amelyeket az smbldap- előtaggal kezdődő szkriptek végeznek.

Az smbldap-tools-t használat előtt konfigurálni kell:

  • Az smbldap_tools.pm fájlban meg kell adni a konfigurációs fájlok elérési útjait, pl.:
    • my $smbldap_conf="/etc/smbldap-tools/smbldap.conf";
    • my $smbldap_bind_conf="/etc/smbldap-tools/smbldap_bind.conf";
    • my $samba_conf="/etc/samba/smb.conf";

A configure.pm szkript készíti el az smbldap.conf nevű állományt, amelynek lényegesebb paraméterei:

  • SID - A szerver SID-je, amelyet a net getlocalsid paranccsal kérdezhetünk le.
  • masterLDAP - Az LDAP szerver címe.
  • masterPort - Az LDAP szerver portja.
  • slaveLDAP - A tartalék LDAP szerver címe (ha nincs, akkor értelemszerűen adjuk meg a master címét).
  • slavePort - A tartalék LDAP szerver portja (ha nincs, akkor értelemszerűen adjuk meg a master portját).
  • ldapTLS - Amennyiben TLS protokollon kapcsolódunk, akkor értéke 1.
  • suffix - A használt gyökér LDAP ág.
  • usersdn - A felhasználók ága a címtárban.
  • computersdn - A gépi fiókok ága a címtárban.
  • groupsdn - A csoportok ága a címtárban.
  • sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}" A következő szabad UID és GID tárhelye.
  • hash_encrypt - A UNIX jelszó tárolására használt algoritmus (pl. MD5).
  • defaultUserGid - A tartományi felhasználók alapértelmezett csoportazonosítója.
  • defaultComputerGid - A tartományi számítógépek alapértelmezett csoportazonosítója.
  • defaultMaxPasswordAge="0" - A jelszavak érvényességi ideje napban megadva. 0 értékkel korlátlan ideig érvényesek a jelszavak.
  • userSmbHome - A felhasználók saját könyvtárának elérési útja.
  • userProfile - A felhasználók profiljának elérési útja.
  • userHomeDrive - A felhasználók saját könyvtárának betűjele.
  • userScript - A felhasználók NETLOGON szkriptjének neve.

A szkripteknek természetesen szükségük van egy LDAP felhasználóra, hogy elérjék a címtárat, ennek paramétereit az smbldap_bind.conf-ban kell megadni.

Először a standard Windows csoportokat kell felvenni a címtárba az alábbi paranccsal: 

smbldap-populate -a root -k 0 -m 0

Ezt követően az smbldap.populate szkript sambaUnixIdPooldn paraméterét meg kell változtatni a Domain neve és az LDAP suffix alapján, pl: sambaUnixIdPooldn="sambaDomainName=TESTDOMAIN,dc=peldadomain,dc=com"

Végül gondoskodni kell arról, hogy a címtárban is megfelelően szerepeljen a root user: 

smbldap-usermod -u 0 -d /root -s /bin/bash root

6 Példák

A következő példa konfigurációs fájlok a 4. számú Irodalom mellékletéből származnak:

6.1 libnss-ldap.conf

host server1.peldadomain.com
base dc=peldadomain,dc=com
ldap_version 3
rootbinddn cn=Admin,dc=peldadomain,dc=com
timelimit 50
bind_timelimit 50
bind_policy hard
idle_timelimit 3600
pam_password exop
nss_base_passwd ou=People,dc=peldadomain,dc=com?one
nss_base_shadow ou=People,dc=peldadomain,dc=com?one
nss_base_group ou=Groups,dc=peldadomain,dc=com?one
ssl start_tls
tls_cacertfile /etc/ldap/cacert.pem

6.2 nsswitch.conf

passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files dns wins
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis

6.3 PAM konfigurációs állományok

  • /etc/pam.d/common-account: 
account sufficient pam_ldap.so
account required pam_unix.so
  • /etc/pam.d/common-auth: 
auth sufficient pam_ldap.so
auth required pam_unix.so try_first_pass nullok_secure
  • /etc/pam.d/common-password: 
password sufficient pam_ldap.so
password required pam_unix.so try_first_pass nullok obscure min=4 max=15 md5
  • /etc/pam.d/common-session: 
session required pam_ldap.so
session required pam_unix.so

6.4 smb.conf

6.4.1 PDC

[global]
workgroup = TESTDOMAIN
server string = Server1
netbios name = SERVER1
passdb backend = ldapsam:ldap://server1.peldadomain.com
log level = 1
log file = /var/log/samba/samba.%m
max log size = 50000
add user script = /opt/IDEALX/sbin/smbldap-useradd -m "%u"
delete user script = /opt/IDEALX/sbin/smbldap-userdel "%u"
add group script = /opt/IDEALX/sbin/smbldap-groupadd -p "%g"
delete group script = /opt/IDEALX/sbin/smbldap-groupdel "%g"
add user to group script = /opt/IDEALX/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /opt/IDEALX/sbin/smbldap-groupmod -x "%u" "%g"
set primary group script = /opt/IDEALX/sbin/smbldap-usermod -g "%g" "%u"
add machine script = /opt/IDEALX/sbin/smbldap-useradd -w "%u"
logon path = \\%L\Profiles\%U
logon drive = S:
logon home = \\%L\%U
logon script = scripts\logon.cmd
domain logons = Yes
os level = 33
preferred master = Yes
domain master = Yes
dns proxy = No
wins support = Yes
ldap admin dn = cn=Admin,dc=peldadomain,dc=com
ldap group suffix = ou=Groups
ldap machine suffix = ou=People
ldap suffix = dc=peldadomain,dc=com
ldap user suffix = ou=People
ldap ssl = start tls
hosts allow = 192.168.1., 127.
unix password sync = yes
passwd program = /etc/samba/jelszovalt %u
passwd chat = *New*password* %n\n *new*password* %n\n *Success*
[homes]
comment = Home Directories
read only = No
browseable = No
[netlogon]
comment = Network Logon Service
path = /adat/netlogon
read only = No
guest ok = Yes
locking = No
[Profiles]
path = /adat/profilok
read only = No
profile acls = Yes
browseable = No
[adat]
comment = Kozos Adatok
path = /adat/kozos
read only = No
force create mode = 0777
force directory mode = 0777
guest ok = Yes

6.4.2 BDC

[global]
workgroup = TESTDOMAIN
server string = Server2
passdb backend = ldapsam:ldap://server1.peldadomain.com
log level = 1
log file = /var/log/samba.%m
max log size = 50000
logon path = \\%L\Profiles\%U
logon drive = S:
logon home = \\%L\%U
logon script = scripts\logon.cmd
domain logons = Yes
os level = 33
preferred master = Yes
domain master = No
dns proxy = No
wins server = 192.168.1.10
ldap admin dn = cn=Admin,dc=peldadomain,dc=com
ldap group suffix = ou=Groups
ldap machine suffix = ou=People
ldap suffix = dc=peldadomain,dc=com
ldap user suffix = ou=People
ldap ssl = start tls
hosts allow = 192.168.1., 127.
unix password sync = yes
passwd program = /etc/samba/jelszovalt %u
passwd chat = *New*password* %n\n *new*password* %n\n *Success*
[homes]
comment = Home Directories
read only = No
browseable = No
[netlogon]
comment = Network Logon Service
path = /adat/netlogon
read only = No
guest ok = Yes
locking = No
[Profiles]
path = /adat/profilok
read only = No
profile acls = Yes
browseable = No
[adat]
comment = Kozos Adatok
path = /adat/kozos
read only = No
force create mode = 0777
force directory mode = 0777
guest ok = Yes

6.5 smbldap.conf

SID="S-1-5-21-348755916-828440091-96241843"
slaveLDAP="server1.peldadomain.com"
slavePort="389"
masterLDAP="server1.peldadomain.com"
masterPort="389"
ldapTLS="1"
verify="require"
cafile="/etc/ldap/cacert.pem"
clientcert="/etc/ldap/szervercert.pem"
clientkey="/etc/ldap/szerverkulcs.pem"
suffix="dc=peldadomain,dc=com"
usersdn="ou=People,${suffix}"
computersdn="ou=People,${suffix}"
groupsdn="ou=Groups,${suffix}"
sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}"
# !!!
#Az smbldap.populate szkript használata után meg kell változtatni az alábbi módon:
#sambaUnixIdPooldn="sambaDomainName=TESTDOMAIN,dc=peldadomain,dc=com"

scope="sub"
hash_encrypt="MD5"
crypt_salt_format="%s"
userLoginShell="/bin/bash"
userHome="/home/%U"
userGecos="System User"
defaultUserGid="513"
defaultComputerGid="515"
skeletonDir="/etc/skel"
defaultMaxPasswordAge="0"
userSmbHome="\\SERVER1\%U"
userProfile="\\SERVER1\Profiles\%U"
userHomeDrive="S:"
userScript="%U.cmd"
mailDomain="peldadomain.com"
with_smbpasswd="0"
smbpasswd="/usr/bin/smbpasswd"
with_slappasswd="0"
slappasswd="/usr/sbin/slappasswd"

6.6 smbldap_bind.conf

slaveDN="cn=Admin,dc=peldadomain,dc=com"
slavePw="***"
masterDN="cn=Admin,dc=peldadomain,dc=com"
masterPw="***"

7 Samba 4 alpha1 teszt

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

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

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

Aduandc.jpg

7.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ényszerítjü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.

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

8 Irodalom

  1. Samba-Guide
  2. Samba-HOWTO-Collection
  3. Különböző hálózatok összekapcsolása, Samba, az előadáson vetített fóliák
  4. Samba alapú tartományvezérlők

Mzsolt 2008. január 2., 00:39 (CET)

A lap eredeti címe: „http://unixlinux.tmit.bme.hu/index.php?title=Samba_DC&oldid=2691”
Személyes eszközök