Solaris 10 centralizált authentikáció OpenLDAP által

A következő írásban folytatjuk az alkalmazások beállítását. Bár ez se a tipikus végfelhasználói alkalmazás lesz, adminisztráció szempontjából viszont majdnem elengedhetetlen több server esetén. Én a következőkben a népszerű, és egyszerű OpenLDAP server által felépített centralizált authentikációt fogom szemléltetni.

LDAP

Ez egy rövidítés. Lightweight Directory Access Protocol azaz „pehelykönnyű könyvtár hozzáférés protokoll”. Egyszerűen mondva egy olyan fa struktúrán alapuló adatbázis ahol tipikusan gyorsan kell keresnünk, és sok kis információt akarunk benne elraktározni. Íme egy kis ábra arról a filozófiáról amit az LDAP vall:

Jól látszik a fa struktúra. Fent van a gyökér elem (ahonnan a fa kinő ez a kezdő pont). Minden zöld elemnek kell hogy legyen Distinguished Name-je (rövidítve DN), azaz egyedi megkülönböztető neve, amivel hivatkozhatunk rá.

Ezek a DN-ek tartalmazhatnak minden féle rövidítési tagot. A fenti példában is jól látszik ahogy „dc=”, „cn=” értékekkel nevesítsük a levél elemeket. Ahhoz hogy egy levélelemet meg akarunk hivatkozni, akkor a teljes DN-jét meg kell adnunk. A fenti példában például: „uid=anne, cn=users, dc=example, dc=com” DN-el hivatkozzuk meg Anne Johnson bejegyzését. Lehetőségünk van relative distinguished name (rövidítve RDN) megadására is, amikor nem a gyökérelemhez viszonyítva adjuk meg a helyzét a másik elemnek.

Az LDAP tehát egy gyorsan kereshető címtár. Ahol strukturáltan tudunk információkat tárolni. Itt tárolódnak majd a számítógépeink minden kapcsolódó információval együtt, a felhasználóink csoportjaink. Az LDAP jól ismert a Linux/UNIX világban, és természetesen lehetőség van bármely olyan a külső alkalmazással használni ami a normál LDAP standard kapcsolódást támogat.

Előkészületek

A következő leírásban egy Solaris 10 operációs rendszerre fogok installálni OpenLDAP servert. Felépítek benne egy kis egyszerű struktúrát, egy User csoportal és egy testuser felhasználóval. Ezek után inicializálni fogom a Solaris 10-ben lévő ldap klienst, és ezáltal lehetővé teszem, hogy az LDAP-ban tárolt felhasználó és csoport információk alapján egyszerűen lehessen felhasználókat managelni központosítva. A folyamat közben, az egyszerűbb szemléltés végett egy LDAP klienst is fogok használni. Ez távolról képes csatlakozni az LDAP server-hez, és arról vizuálisabb adatokat képes szolgáltatni. Amennyiben úgy állítottuk be az LDAP serverünket (ACL), akkor LDAP kliensen keresztül lehetőségünk van törölni, létrehozni, módosítani. Bár több ilyen kliens is létezik, én legjobbnak a Softerra LDAP Administrator termékét találtam.

OpenLDAP installáció

Én a következőkben nem fogom forrásból fordítani az OpenLDAP-ot, bár lehetne. A SunFreeware oldaláról szedett csomagokkal fogok dolgozni.

Ha már a gépünkön van, akkor szépen rakjuk fel az összes komponenst.

# cd /tmp/openldap_install
# ls -lah
# gunzip *.gz

# pkgadd -d db-4.7.25.NC-sol10-sparc-local
# pkgadd -d libtool-2.2.6b-sol10-sparc-local
# pkgadd -d sasl-2.1.21-sol10-sparc-local
# pkgadd -d libgcc-3.4.6-sol10-sparc-local
# pkgadd -d openssl-1.0.0a-sol10-sparc-local
# pkgadd -d openldap-2.4.22-sol10-sparc-local

Konfiguráció

A konfigurációs file-t következőképp szerkesszük meg, ehhez a solaris.schema file-ra külön szükségünk lesz. Ezt alapból az OpenLDAP nem fogja tartalmazni.

# mv /export/home/miszterx/solaris.schema /usr/local/etc/openldap/schema/
# ls -lah /usr/local/etc/openldap/schema/

Akkor most nézzük, hogy is néz ki a config:

# cat /usr/local/etc/openldap/slapd.conf

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org

pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args

# ACL’s
access to dn.subtree=”ou=People,dc=test,dc=oss” attrs=userPassword,shadowLastChange
by dn=”cn=proxyagent,ou=profile,dc=test,dc=oss” write
by self write
by anonymous auth
by * read

# Do not allow users so change their uid/gid/groupmembership
access to attrs=uid,uidNumber,gidNumber,memberUid
by * read

access to dn.base=””
by dn=”cn=proxyagent,ou=profile,dc=test,dc=oss” read
by * read

access to dn.base=”cn=Subschema”
by anonymous none
by * read

access to dn.subtree=”ou=People,dc=test,dc=oss”
by self write
by * read

access to dn.subtree=”ou=Group,dc=test,dc=oss”
by * read

access to *
by * read

###############################################
# BDB database definitions
###############################################

database bdb
suffix „dc=test,dc=oss”
rootdn „cn=diradmin,dc=test,dc=oss”
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw osssecret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /usr/local/var/openldap-data
# Indices to maintain
index objectClass eq

Indítsuk el az LDAP servert a következő paranccsal:

# /usr/local/libexec/slapd

Ha nem jelenne meg a process, akkor nem sikerült elindulnia. Ebben az esetben érdemes debug módban elindítani, ahol láthatjuk, hogy mi a baj:

# /usr/local/libexec/slapd -d 500

Első induláskor nekem a következő hibába sikerült rendszeresen belefutnom:

Itt az LDAP által használt gráf típusú BDB adatbázissal van gond. Ezt egy Berkeley DB-t jelent a mi esetünkben. Egyszerűen futtassunk rajta egy visszaállítást, és ez megoldja a gondjainkat.

# cd /usr/local/var/openldap-data/
# /usr/local/BerkeleyDB.4.7/bin/db_recover

Érdemes még ennek a DB_CONFIG-ját is létrehozni. Mostani esetben bőven elég ha a példa file-t átnevezzük:

# mv /usr/local/var/openldap-data/DB_CONFIG.example /usr/local/var/openldap-data/DB_CONFIG

Ezek után már debug módban azt kell látnunk, hogy gond nélkül elindult az LDAP:

# /usr/local/libexec/slapd -d 500

Ha így lenne, akkor már indíthatjuk sima háttérbe futó deamonként így:

# /usr/local/libexec/slapd
# ps -ef | grep slapd

Adatok feltöltése

Most már fut az LDAP server lehetőségünk van csatlakozni hozzá. Nézzünk is egy keresést:

# ldapsearch -x -b ‘dc=test,dc=oss’ -D „cn=diradmin,dc=test,dc=oss” ‘(objectclass=*)’ -W

LDAP Administratorban ugyan ez:

Nem meglepő, hogy azt kapjuk, hogy No such object. Ugyanis az LDAP server fut, de még nem adtunk semmilyen struktúrát, recordot neki.

Én szépen sorjában, külön külön LDIF file-ket fogok csinálni, és ezeket adom hozzá. Így jobban látszik majd, hogy épül fel. Először adjuk hozzá a gyökérelemet:

# cat init.ldif
dn: dc=test,dc=oss
associatedDomain: test.oss
objectClass: top
objectClass: dcObject
objectClass: domain
objectClass: domainRelatedObject
objectClass: nisDomainObject
nisDomain: test.oss
o: Organisation Name

Akkor ezt most adjuk hozzá:
ldapadd -D „cn=diradmin,dc=test,dc=oss” -w osssecret -f /export/home/miszterx/init.ldif

Nézzük ezzel mit értünk:

# ldapsearch -x -b ‘dc=test,dc=oss’ -D „cn=diradmin,dc=test,dc=oss” ‘(objectclass=*)’ -W

LDAP Administratorban ugyan ez:

Most jöjjön a felhasználók csoport eleme a People, és a csoportok eleme a Group létrehozása:

# cat people_groups.ldif
dn: ou=People, dc=test,dc=oss
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group, dc=test,dc=oss
ou: Group
objectClass: top
objectClass: organizationalUnit

Most adjuk hozzá:
# ldapadd -D „cn=diradmin,dc=test,dc=oss” -w osssecret -f /export/home/miszterx/people_groups.ldif

Nézzük akkor most hogy is állunk, ez már kicsit látványosabb lesz:
# ldapsearch -x -b ‘dc=test,dc=oss’ -D „cn=diradmin,dc=test,dc=oss” ‘(objectclass=*)’ -W

LDAP Administratorban ugyan ez:

Most hozzunk létre egy profile elemet, majd ez alá egy proxyagent felhasználót. Őt fogjuk használni a kliensek esetében, ahhoz hogy a megfelelő adatokhoz hozzáférhessünk. Ehhez a felhasználóhoz adtunk a configban speciális ACL-eket.

# cat proxy.ldif
dn: ou=profile, dc=test,dc=oss
ou: profile
objectClass: top
objectClass: organizationalUnit

dn: cn=proxyagent,ou=profile, dc=test,dc=oss
userPassword: ossproxy
objectClass: top
objectClass: person
sn: proxyagent
cn: proxyagent

Most adjuk hozzá:
# ldapadd -D „cn=diradmin,dc=test,dc=oss” -w osssecret -f /export/home/miszterx/proxy.ldif

LDAP Administratorban ugyan ez:

Most pedig hozzuk létre az első felhasználónkat:

# cat testuser.ldif
dn: uid=testuser,ou=People, dc=test,dc=oss
shadowMin: 5
sn: User
userPassword: test
loginShell: /bin/bash
uidNumber: 9999
gidNumber: 1000
shadowFlag: 0
shadowExpire: -1
shadowMax: 99999
uid: testuser
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: shadowAccount
gecos: Test User
shadowLastChange: 0
cn: Test User
homeDirectory: /export/home/testuser
shadowInactive: -1
shadowWarning: 7

Adjuk hozzá:
# ldapadd -D „cn=diradmin,dc=test,dc=oss” -w osssecret -f /export/home/miszterx/testuser.ldif

LDAP Administratorban ugyan ez:

Kliens LDAP inicializálása

Felépítettük a struktúránkat, most már csak a felhasználó adatokat jó lenne ha a kliensek is használnák. Ehhez inicializálnunk kell a beépített Solaris 10 ldap service-t.

Alap esetben:
# svcs ldap/client

Akkor jöjjön a mágikus parancs:
# ldapclient manual -v -a credentialLevel=proxy
-a proxyDN=cn=proxyagent,ou=profile,dc=test,dc=oss
-a proxyPassword=osssecret
-a defaultSearchBase=dc=test,dc=oss
-a defaultSearchScope=sub
-a domainName=test.oss
-a serviceSearchDescriptor=passwd:dc=test,dc=oss?sub
-a serviceSearchDescriptor=shadow:dc=test,dc=oss?sub
-a serviceSearchDescriptor=group:dc=test,dc=oss?sub
-a serviceAuthenticationMethod=pam_ldap:simple
-a authenticationMethod=simple 10.0.0.13

És jobb esetben a serivce is online lesz:
# svcs ldap/client

Nézzük mit értünk el ezzel. Kérjük le gép számára elérhető usereket:

# getent passwd

Szuper megjelent a rendszerünk számára a definiált testuser. Akkor próbáljunk belépni vele.

masik-host# ssh testuser@10.0.0.10

Nem megy. Nem fogadja el a jelszót. Viszont a service online, az inicializálás hiba nélkül ment. Akkor csak egy helyen lehet a probléma. Méghozzá a jelszó értelmezésében. Most plaintext módon tároljuk az UserPassword a értékét. Ezzel nem is lenne gond, mert az LDAP simple bind-el tudja használni, de a Solaris a user password-höz titkosított jelszót használ.

Tehát nekünk titkosítottan kell tárolnunk a jelszót az LDAP-ban az usereinkhez. A Solaris alapból DES alapú crypt algoritmust használ. Több féle módon is kreálhatunk ilyen jelszavakat, én most a legegyszerűbb módszert fogom megmutatni, amit az LDAP Administrator támogat:

Ezek után válogathatunk a titkosító algoritmusok között, viszont nekünk a DES(Crypt) kell.

Ha ez megvan máris hasonló dolgot kell látnunk:

Ezek után pedig már sikeresen beléphetünk a megfelelő LDAP felhasználóval.

Solaris 10 centralizált authentikáció OpenLDAP által

LDAP

Előkészületek

OpenLDAP installáció

Konfiguráció

Adatok feltöltése

Kliens LDAP inicializálása

Published by MiszterX

“Solaris 10 centralizált authentikáció OpenLDAP által” bejegyzéshez 2 hozzászólás

Vélemény, hozzászólás? Válasz megszakítása