howto: Linux klines Windows Active Directory domain-ben

A válasz: meglepően egyszerűen, ha az ember ismeri az LDAP használatát Linuxon és az Active Directory-t. Én az előbbit valamelyest, az utóbbit eddig egyáltalán nem, most találkoztam vele igazán először, legalábbis ilyen szinten. Tehát a cél a következő: van egy "csupasz" Linuxunk és azt szeretnénk, ha egy AD-ben tárolt userrel ide be tudnánk lépni (nálam a Linux az Ubuntu 10.04 (bizony!) és 12.04 lesz, de ez nem sokat számít, bármi más disztribúcióval is megoldható)

Elöljáróban el kell mondanom, hogy az általam leírt megoldás csak egy a lehetséges sok közül, és vannak erre a célra összerakott "out of the box" megoldások is.

Aki az AD-vel hasonló szinten van mint én, azoknak annyit, hogy nem kell túlmisztifikálni: az AD egy LDAP és kész (legalábbis amit mi fogunk látni belőle). Ebből fogjuk tudni kiolvasni a usereink tulajdonságát (home dir, stb). A Windows azonban a jelszavak tárolásához nem ezt használja, hanem egy saját kerberos implementációt, ami szerencsére szintén egész jól együtt működik a Linuxos kerberos kliensekkel.

Én itt egy Windows 2012 szervert használok, de elvileg korábbi verziókkal is működnie kell.

Első csatlakozás az AD-hoz Linux alól

Először csak játszunk el kicsit az AD-val, próbáljuk meg elérni Linux alól. Ahogy mondtam az AD is csak egy LDAP, úgyhogy keressünk benne ldapsearch-csel (ldapsearch Ubuntu-n az ldap-utils csomagban van)

Nálam az AD a "mydomain.local" domain-t szolgálja ki, a user-em (amit már persze a Windows szerveren korábban felvettem az AD-be) a "myuser" lesz, a Windows szerver címe pedig 192.168.1.111 a replika pedig a 192.168.1.112 (az én példáimban mindenhol IP-k szerepelnek, de érdemes lehet neveket használni, az én valódi konfigjaimban is nevek vannak):

  ldapsearch -D "cn= Myuser, ou=Mydomain Users, dc=qnective, dc=local" -H ldap://192.168.1.111 -b "dc=mydomain, dc=local" -W

A fenti az ldap-ban megszokott forma, azonban az AD-ben mashogy is megadhatjuk a usernevünket a csatlakozáshoz, ami talán kicsit olvashatóbb is:

  ldapsearch -D "myuser@mydomain.local" -H ldap://192.168.1.111 -b "dc=mydomain, dc=local" -W

Ez nagyából az egész LDAP fát lekéri, ezt persze lehet tovább szűkíteni a base (-b) további szűkítésével.

Ha valaki sokat szeretné böngészni az AD-t, akkor talán valami grafikus LDAP tool-nak jobban örülne. Persze lehet böngészni az AD-t a Windows szerverbe épített eszközökkel is, bár az meglepő módon nem mutat meg minden attribútumot (erről majd később). Linux-on én a luma-t használom (azonos nevű deb csomag), elég egyszerű kis eszköz.

Most próbáljuk meg a kerberos autentikációt is. Ehhez fel kell rakni néhány kerberos csomagot (ubuntun: krb5-user, libpam-krb5, libsasl2-modules-gssapi-mit), és beállítani saját kerberos szerverünket (vagyis a Windows szervert), a /etc/krb5.conf -ban.

cseréljük a default realm-et a sajátunkra:

default_realm = MYDOMAIN.LOCAL

és adjuk hozzá ennek a realm-nek a beállításait a konfigunkhoz ([realms] szekció):

        MYDOMAIN.LOCAL = {
                kdc = 192.168.1.111:88
                kdc = 192.168.1.112:88
                admin_server = 192.168.1.111:88
        }

Ezután már kell tudunk kerberos ticketet kérni a Windows-tól:

  kinit myuser

Nézzük is meg mink van:

  klist

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: myuser@MYDOMAIN.LOCAL

Valid starting    Expires           Service principal
30/07/2013 17:10  31/07/2013 03:10  krbtgt/MYDOMAIN.LOCAL@MYDOMAIN.LOCAL
  renew until 31/07/2013 17:10

Ezzel a ticket-tel elvileg már elérhetünk szolgáltatásokat, pl az LDAP-ot is lekérdezhetnénk (ticket-tel, jelszó megadása nélkül), nekem ez 5 perc alatt nem sikerült, többet meg egyelőre nem foglalkoztam vele, jelenleg úgysem a kerberos használat a cél (legalábbis nem így).

Na, ennyit az AD browse-olásról, most csináljuk meg az autentikációt.

AD beállítása Linux/UNIX kliensekhez

Az első... és tulajdonképpen majdnem az egyetlen, probléma, hogy az AD nem tárol Linux/UNIX specifikus tulajdonságokat, amik az autorizációhoz szükségesek (user home könyvtára, shell-je, stb). Legalábbis alapból nem, de szerencsére erre már az MS-nél is gondoltak, úgyhogy hozzá lehet adni ilyen tulajdonságokat az egyes AD objektumokhoz. Ha ezt megtesszük, akkor onnantól Linux oldalról már úgy használhatjuk az AD-t mintha az csak egy szabályos Linuxon installált LDAP alapú user adatbázis lenne.

Tehát az AD userekhez fel kell vennünk a UNIX (avagy Posix) tulajdonságokat, ehhez viszont az adott user AD objektumához hozzá kell rendelnünk a PosixAccount schema-t. Ez a schema tartalmazza a szükséges attribútumokat, úgy mint:

uid
uidNumber
gidNumber
unixHomeDirectory
loginShell

Meg még sok mást is ha akarjuk, de ezekre lesz mindenképpen szükségünk. (Bővebben: http://msdn.microsoft.com/en-us/library/windows/desktop/ms683907%28v=vs…)

(Ezen a ponton talán számít, hogy nekem egy Windows Server 2012-m van, a legtobb helyen azt olvastam (többnyire más Windows Server verziókhoz), hogy installáljam fel a "Windows Services for Unix" (SFU) komponenst a Windows szerverre, de nekem erre nem volt szükségem (A Server 2012-ben ez a komponens deprikáltá vált), a szükséges PosixAccount schema-t így is megtaláltam az AD-ben.)

Itt érzek egy kis neheztelést az MS részéről, amiért ilyesmire akarom használni az AD-t... ugyanis technikailag mindent lehetővé tettek, de az AD GUI-án én nem találtam nem csak olyan felületet amin ezek a tulajdonságokat fel lehetne vinni, de olyat sem ahol egyáltalán látszanának. így sajnos az egyszeri Windows admin számára -aki csak a GUI-t nyomkodja- láthatatlanok ezek a tulajdonságok is, így az is, hogy mely usereknek van UNIX identitásuk és melyeknek nincs.
(Na jó, Advanced mode-ban, az attribute editor fülön a user összes létező tulajdonsága között végül is ezek is meg vannak... ettől még Windows rendszergazda legyen a talpán aki ezt használja.)

Kicsit kényelmetlen, de cseppet sem megoldhatatlan, miután Linux alól tudunk csatlakozni az LDAP-hoz, onnan is elvégezhetjük a beállítást, de biztos vagyok benne, hogy Windows commandline-ból is meg lehet oldani, különösen powershell-ből. Engem ez kevéssé izgatott, úgyhogy Linux alól csinálom. Adjuk a szükséges tulajdonságokat a már említett 'myuser' user-hez:

Először a schema hozzárendelés (az eddigiekkel szemben, ehhez már szükséges, hogy a Myuser-nek admin jogai legyenek az AD-ben):

cat <<EOF | ldapmodify -D "cn= Myuser, ou=Mydomain Users, dc=mydomain, dc=local" -h 192.168.1.111 -x -W
dn: CN=Myuser,OU=Mydomain Users,DC=mydomain,DC=local
changetype: modify
add: objectClass.
objectClass: PosixAccount
EOF

majd jöhetnek a tulajdonságok:

cat <<EOF | ldapmodify -D "cn= Myuser, ou=Mydomain Users, dc=mydomain, dc=local" -h 192.168.1.111 -x -W
dn: CN=Myuser,OU=Mydomain Users,DC=mydomain,DC=local
changetype: modify
add: uidNumber
uidNumber:10000
-
add: uid
uid: myuser
-
add: gidNumber
gidNumber: 100
-
add: unixHomeDirectory
unixHomeDirectory: /home/myuser
-
add: loginShell
loginShell: /bin/bash
EOF

Az értékeket persze értelemszerűen adjuk meg, az uidNumber legyen egyedi, a loginShell-t pedig /bin/false -ra is állíthatjuk, ha a user nem fog shell-t használni.

(Elvileg megtehetnénk, hogy a Windowsos és a UNIX/Linux-os felhasználó nevek különbözzenek, ha az uid-nak mást állítunk be mint a Windowsos user név, de valójában nem tudom ez működne-e.)

Ezt minden userrel meg kell csinálnunk, akivel szeretnénk Linuxon is belépni,ezért célszerű erre valami scriptet írni. Miután LDAP-ról van szó, ami elég széleskörűen támogatott, szinte bármilyen nyelven megírhatjuk a scriptet, az adatok bevitele úgysem igényel intelligenciát, azt mind más AD tulajdonságokból származtathatjuk, vagy fixek. Egyedül az uidNumber kicsit nehézkesebb, amire még vigyázni is kell, hogy ne ütközzenek, viszont ez is elég egyszerűen számolható... nálam 10000-től indulnak felfelé. (Azért nem 1000-től, hogy a már lokálisan felvett userekkel ne akadjanak össze)

Azt is meg kell jegyeznem, hogy ezeket a paramétereket sem muszáj mind felvennünk, megtehetjük, hogy kliens oldalon 'mappeljük' le őket, pl az 'sAMAccountName' attribútumból képezzük az 'uid'-ot. Én nem ezt az utat választottam, úgyhogy nem is tudom minden megoldható-e mappeléssel (pl uidnumber?). Illetve ebben az esetben a kliens oldali konfiguráció mindenképpen bonyolultabb lesz és kiesnek az olyan lehetőségek is, hogy AD oldalon lehessen egy loginShell-t /bin/false-ra billenteni... Viszont ha az AD-n valamilyen okból semmiféle módosítást nem akarunk (vagy jogosultság hiányában nem tudunk!), akkor ezzel kell próbálkoznunk.

Még egy plusz userre lesz szükségünk (vagy ha paranoiásak vagyunk akkor kliensenként egyre), amivel a Linux kliensek ki tudják olvasni a userek tulajdonságait az LDAP-ból. Ehhez egy közönséges usert kell felvennünk az AD-ba, sem különleges privilégiumokra, sem UNIX tulajdonságokra nem lesz szüksége. Sőt, a privilégiumait csökkenthetjük is, hogy tényleg csak azt olvashassa ki amit kell. Nálam ez a 'linuxlogin' user lesz. (Megjegyzem, hogy elvileg be lehet állítani anonymous hozzáférést az AD-hoz, akkor nem kell ilyen user-t felvenni, ami könyebbé teheti a kliensek integrációját, de nyilván valami security kockázata is van.)

Linux oldali kerberos autentikáció és LDAP autorizáció beállítása
Aki képben van egy kerberos+LDAP alapú autentikáció beállításában, annak innen szinte felesleges is tovább olvasnia: a "varázslat" már megtörtént az előző lépésben AD oldalon, a Linux kliens felől innen úgy használhatjuk az AD-t akár egy Linux alapú LDAP+kerberos szervert.

Először okosítsuk fel a rendszert, hogy ne csak a /etc/passwd file-ból vegye a usereket (meg a csoportokat ne csak a /etc/group-ból), ehhez a nslcd -re (azonos nevű csomag), meg egy kis name service konfigurálásra lesz szükségünk.

Az én /etc/nslcd.conf -om, kicsit lecsupaszítva, kommentek nélkül:

uid nslcd
gid nslcd
uri ldap://192.168.1.111/ ldap://192.168.1.112/
base dc=mydomain, dc=local
base passwd ou=mydomain users, dc=mydomain, dc=local
base group ou=mydomain users, dc=mydomain, dc=local
referrals off
filter passwd (&(objectClass=posixAccount)(uidNumber=*)(unixHomeDirectory=*))
map    passwd homeDirectory    unixHomeDirectory
filter group  (&(objectClass=posixGroup)(!(objectClass=computer)))
binddn linuxlogin@mydomain.local
bindpw csillagcsillagcsillag

Ha valakinek lenne 10.04-es kliense is (mint nekem néhány), akkor még erre szükség lesz, enélkül az AD/LDAP csoportok üresek lesznek (ez a sor viszont nem kompatibilis a későbbi verziókkal pl ami 12.04-ben van, úgyhogy csak akkor használd ha tényleg kell):

map    group  uniqueMember        member

Indítsuk újra az nslcd-t:

service nslcd restart

Most, hogy már vannak usereink az LDAP-ból, mondjuk is meg a name service-nek, hogy használja azokat, az /etc/nsswitch.conf file-nam a passwd és group sorokhoz csapjuk hozzá az ldap-ot is:

passwd:         compat ldap
group:          compat ldap

A felrakott csomagokkal elvileg a PAM konfigurálása is megtörtént, úgyhogy azzal nincs dolgunk. Én egy kicsit módosítottam rajtuk, pl az uid limiteket felvettem 10000-re, mert az én AD usereim onnan indulnak (a leírás végén van pár PAM minta config file), ezek után már be tudnak lépni a userek, csakhogy home könyvtáruk nincs (hacsak nem olyan központi home könyvtárakat használunk, amit minden gépről elérni), így ezt még le kell gyártani, szerencsére nem kézzel, erre is van pam modul, ami user login közben legyártja a home könyvtárat ha még nem létezik (pam_mkhomedir, Ubuntu-n a standard libpam-modules csomag része). Adjuk hozzá a pam confighoz, szúrjuk be az alábbi sort a /etc/pam.d/common-session file elejére:

session required      pam_mkhomedir.so skel=/etc/skel/ umask=0077

Most már be tudnak jelentkezni a user-ek és home könyvtáruk is lesz.

Offline használat

A központi autentikáció problémája, hogy offline nemigen működik. Erre is megoldást kellett találnom, egyrészt mert vannak laptopok, amiktől nem várható el, hogy mindig elérjék az AD-t, másrészt így kicsit hibatűrőbb is a rendszer, elég kellemetlen lenne, hogy egy kis hálózati hiba miatt nem lehetne belépni a gépekre.

Ezen a területen kicsit csalódtam a Linuxban. Igazán szép megoldást nem is találtam, bár működőt azért igen.

Elvileg az nscd pont ilyesmire való (name service caching daemon), csakhogy a cache-eléssel van egy kis gond. Ez a cache ugyanis teljesen függetlenül működik a rendszer többi részéről, úgyhogy akár elérhető az LDAP akár nem, komoly esélyünk van rá, hogy elavult információkat fog visszaadni az nscd. Márpedig az nscd-ben a cache idejét nagyra kell állítanunk, hogy hosszú offline használatot is átvészeljen. Viszont minél magasabbra állítjuk ezt az időt annál hosszabb ideig őrzi meg az elavult adatokat is. Persze időnként (ha az LDAP elérhető) törölhetnénk is a cache-t...

Én végül nem az nscd-re építettem az offline használatot. Van szerencsére egy eszköz ami képes lekérdezni az LDAP-ból az aktuális user/group listát és abból épít egy helyi adatbázist. Ez az nss_updatedb (csomagnév: nss-updatedb). Ezt egyszerűen cron-ból időzíthetjük, így amikor az LDAP elérhető frissülnek a bejegyzések, amikor viszont elérhetetlen akkor a helyi adatbázisból veszi a name service a userek adatait.

# nss_updatedb ldap passwd
passwd... done.
# nss_updatedb ldap group
group... done.

ugyanez cron-ban (file: /etc/cron.d/local-ldap-cache-update)

*/15 * * * * root { nss_updatedb ldap passwd; nss_updatedb ldap group; } 2>&1 > /dev/null

És hogy használjuk is a lokális adatbázist, megint módosítsuk az nsswitch.conf-ot:

passwd:         compat ldap db
group:          compat ldap db

Az autorizációs infók (AD/LDAP) cache-elését az nscd vagy az nss_updatedb elintézi nekünk, viszont a jelszavak nélkül ezekkel nem sokat érünk, mert senki nem fog tudni belépni (vagy akár csak egy lock-olt képernyőt feloldani). Erre használhatjuk a ccreds-t (libpam-ccreds ubuntu csomag), ami minden user belépésénél elmenti a jelszavakat lokálisan (persze csak hash-t), így aki egyszer már belépett egy adott gépre az offline is be fog tudni.

A ccreds-hez sehol nem találtam leírást vagy konfigot, hogy hol lehetne beállítani, hogy mennyi ideig tároljon... de a jelek egyelőre arra utalnak, hogy a jelszavakat "örökre" eltárolja (még egyszer: csak hash-t), file-ba ír az biztos, úgyhogy reboot után is működik. cc_dump paranccsal megnézhetjük mi van éppen a cache-ben. A cache-t biztonsági okokból érdemes lehet időnként törölni (file: /var/cache/.security.db , sajnos egyesével törölni nem lehet, legalábbis nincs hozzá beépített tool). Persze csak okosan, nehogy akkor töröljünk amikor a rendszer offline...

No, hát ennyi volna. :) Észrevételeket, hibajavításokat szívesen látok a kommentekben. Szükség esetén javítok itt is.

Mellékletek

szükséges csomagok (Ubutnu 12.04):

krb5-user
libpam-krb5
libsasl2-modules-gssapi-mit
libnss-ldapd
nslcd
ldap-utils
libpam-ccreds
libpam-ldapd
samba-common-bin

pam config file-ok (kommentek nélkül):

---------- /etc/pam.d/common-auth ----------
auth  [success=3 default=ignore]  pam_krb5.so minimum_uid=10000
auth  [success=2 default=ignore]  pam_unix.so nullok_secure try_first_pass
auth  [success=1 default=ignore]  pam_ccreds.so minimum_uid=10000 action=validate use_first_pass
auth  requisite     pam_deny.so
auth  optional      pam_ccreds.so minimum_uid=10000 action=store
auth  required      pam_permit.so
auth  optional      pam_ecryptfs.so unwrap
auth  optional      pam_cap.so 

---------- /etc/pam.d/common-account ----------
account [success=1 new_authtok_reqd=done default=ignore]  pam_unix.so 
account requisite     pam_deny.so
account required      pam_permit.so
account required      pam_krb5.so minimum_uid=10000
account [success=ok new_authtok_reqd=done ignore=ignore user_unknown=ignore authinfo_unavail=ignore default=bad]  pam_ldap.so minimum_uid=10000

---------- /etc/pam.d/common-password ----------
password  requisite     pam_cracklib.so retry=3 minlen=8 difok=3
password  [success=3 default=ignore]  pam_krb5.so minimum_uid=10000 try_first_pass use_authtok
password  [success=2 default=ignore]  pam_unix.so obscure use_authtok try_first_pass sha512
password  [success=1 default=ignore]  pam_ldap.so minimum_uid=10000 try_first_pass
password  requisite     pam_deny.so
password  required      pam_permit.so
password  optional  pam_gnome_keyring.so 
password  optional  pam_ecryptfs.so 

---------- /etc/pam.d/common-session ----------
session required      pam_mkhomedir.so skel=/etc/skel/ umask=0077
session [default=1]     pam_permit.so
session requisite     pam_deny.so
session required      pam_permit.so
session optional      pam_umask.so
session optional      pam_krb5.so minimum_uid=10000
session required      pam_unix.so 
session [success=ok default=ignore] pam_ldap.so minimum_uid=10000
session optional      pam_ecryptfs.so unwrap
session optional      pam_ck_connector.so nox11