OpenLDAP 2.4 mit qmail-Schema

In eige­ner Sache: Hm — die Fall­hö­he zum vor­an­ge­hen­den Arti­kel ist schon krass… Erst eher Lyri­sches, dann pro­fan Tech­ni­sches, aber nun denn…

Vor­ge­schich­te

Unser Schul­ser­ver migriert zur Zeit auf leis­tungs­fä­hi­ge­re Hard­ware: Hetz­ner bie­tet die Vor­se­rie zu den aktu­el­len Model­len zur Zeit ohne Ein­rich­tungs­ge­bühr an. Inte­gra­ler Bestand­teil mei­nes Set­ups ist dabei OpenLDAP (Das Pen­dant bei Klein­weich Fens­ter heißt Active­Di­rec­to­ry — ist aber im Prin­zip eine LDAP-Imple­men­tie­rung). So braucht jeder nur ein Pass­wort für alle Diens­te, die die Schu­le zur Zeit anbie­tet. Prin­zi­pi­ell ist das alles mög­lich, was mit LDAP spricht — und etwas ande­res kommt mir eh nicht auf die Plat­te. Mood­le, Maha­ra, Wor­d­Press, Egroup­ware, Elgg, Media­Wi­ki usw. spre­chen zumin­dest alle­samt LDAP wie auch unser Mail­sys­tem.

Es lag nahe, bei dem Umzug gleich auch die Ser­ver­soft­ware auf eine aktu­el­le­ren Stand zu brin­gen: Bis­her nutz­te ich Ubun­tu 8.04 LTS (Har­dy Heron) mit drei von­ein­an­der getrenn­ten vir­tu­el­len Maschi­nen (eine für die Home­page, eine für Mood­le & Co. und eine zum Spie­le für die inter­es­sier­ten Kol­le­gin­nen und Kol­le­gen.

Das Set­up war Mist, weil sich drei (mit der domU sogar vier) unter­schied­li­che Maschi­nen schwer war­ten und sichern las­sen. Außer­dem ver­schluck­te sich der Hyper­vi­sor stets, wenn mehr als zwei CPU-Ker­ne zu vir­tua­li­sie­ren waren, sodass effek­tiv nur ein Kern nutz­bar wur­de.  Daher schwen­ke ich nun um auf Ubun­tu 10.04 LTS (Lucid) und fas­se die vir­tu­el­len Maschi­nen zu einer zusam­men — dann gibt es auch etwas mehr Power, wenn­gleich auch spä­te­re Erzie­hungs­maß­nah­men hin zur Nut­zung von FTPS und eine stren­ge­re Poli­cy für den Zugriff von Kol­le­gen auf den Ser­ver auf Filee­be­ne.

Der Kampf

Lucid kommt mit OpenLDAP 2.4 daher. Neu ist vor allem, dass slapd nun sei­ne sämt­li­chen Kon­fi­gu­ra­ti­ons­da­ten in einem sepa­ra­ten LDAP-Baum spei­chert und neu ist vor allem, dass das ent­spre­chen­de Paket in Lucid nur sehr mager vor­kon­fi­gu­riert ist — z.B. ist ledig­lich das core-Sche­ma inte­griert. Ich brau­che für mei­nen LDAP jedoch zusätz­lich fol­gen­de Sche­men: cosi­ne, inet­or­g­per­son, qmail. Die Sche­men müs­sen in die Daten­bank. Freund­li­cher­wei­se lie­fert Lucid eine Rei­he von Sche­men mit:

lda­padd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif
lda­padd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif

… auf der Kom­man­do­zei­le lösen schon­mal die ers­ten zwei Pro­ble­me. Das qmail-Sche­ma ist ein beson­de­rer Kan­di­dat. Es wird nicht mit­ge­lie­fert und ist auch im Web (noch?) nicht für Debi­an­de­ri­va­te zu fin­den, sodass ich die alte Sche­ma­da­tei  aus Har­dy erst kon­ver­tie­ren muss­te. Da ich so gelit­ten habe — Feh­ler­aus­ga­ben lesen und Intui­ti­on waren hier als Kern­kom­pe­ten­zen gefragt, prä­sen­tie­re ich hier ein­fach das End­ergeb­nis in Form einer impor­tier­ba­ren LDIF- Datei: qmail.ldif. Das Attri­but mail­Host ließ sich jedoch nicht zur Mit­ar­beit mit OpenLDAP 2.4 über­re­den — ich brau­che es nicht und ver­mu­te, dass mit dem Seri­al da etwas nicht stimmt. Ein beherz­tes

lda­padd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/qmail.ldif

füg­te dann das Sche­ma hin­zu. Dann braucht es einen Admi­nac­count für OpenLDAP — also frü­her war das leich­ter, heu­te müs­sen auch die­se Daten in Lucid per LDIF impor­tiert wer­den — der  Lucid-Instal­ler fragt nichts ab, son­dern hin­ter­lässt eine Instal­la­ti­on der 1000 Fra­ge­zei­chen:

# Load dyna­mic backend modu­les
dn: cn=module,cn=config
object­Class: olc­Mo­dule­List
cn: modu­le
olc­Mo­du­le­path: /usr/lib/ldap
olc­Mo­dulel­oad: back_hdb

# Data­ba­se set­tings
dn: olcDatabase=hdb,cn=config
object­Class: olcDa­ta­base­Con­fig
object­Class: olcH­dbCon­fig
olcDa­ta­ba­se: {1}hdb
olcSuf­fix: dc=schule,dc=tld
olcDb­Di­rec­to­ry: /var/lib/ldap
olcRoot­DN: cn=admin,dc=schu­le,dc=tld
olcRoot­PW: secret
olcDbCon­fig: set_cachesize 0 2097152 0
olcDbCon­fig: set_lk_max_objects 1500
olcDbCon­fig: set_lk_max_locks 1500
olcDbCon­fig: set_lk_max_lockers 1500
olcDbIn­dex: object­Class eq
olcLast­Mod: TRUE
olcDbCheck­point: 512 30
olcAc­cess: to attrs=userPassword by dn=„cn=admin,dc=schule,dc=tld” wri­te by anony­mous auth by self wri­te by * none
olcAc­cess: to attrs=shadowLastChange by self wri­te by * read
olcAc­cess: to dn.base=”” by * read
olcAc­cess: to * by dn=„cn=admin,dc=schule,dc=tld” wri­te by * read

schu­le”, „tld” und „secret” sind an die eige­nen Bedürf­nis­se anzu­pas­sen. Die Datei dann als TXT unter dem Namen create_database.ldif spei­chern. Unten wer­den die Berech­ti­gun­gen für den Zugriff „so wie frü­her” gesetzt, d.h. z.B. Mood­le kann die rele­van­ten Daten per Anony­mous Bind (ja, der LDAP-Port ist an local­host gebun­den) aus­le­sen ohne das Pass­wort eines Bin­du­sers im Klar­text durch die Gegend zu pus­ten. Mit

lda­padd -Y EXTERNAL -H ldapi:/// -f create_database.ldif

geht es dann ab in den LDAP-Baum. Im nächs­ten Schritt muss die­se Daten­bank noch initia­li­siert wer­den. Das geht — man erkennt eine gewis­se Kon­se­quenz — wie­der über eine LDIF-Datei:

# Crea­te top-level object in domain
dn: dc=schule,dc=tld
object­Class: top
object­Class: dcOb­ject
object­class: orga­ni­za­ti­on
o: Schu­le Orga­ni­za­ti­on
dc: schu­le
descrip­ti­on: LDAP Examp­le

# Admin user.
dn: cn=admin,dc=schule,dc=tld
object­Class: simp­leSe­cu­ri­ty­Object
object­Class: orga­ni­za­tio­nal­Ro­le
cn: admin
descrip­ti­on: LDAP admi­nis­tra­tor
user­Pass­word: secret

Die­se Datei spei­chert man z.B. unter populate.ldif. Jetzt wird es ein wenig anders, da wir direkt an der Wur­zel­da­ten­bank mit slapd her­ump­fu­schen wol­len und er uns das nur mit einem ech­ten Bind tun lässt — brav:

lda­padd -x -D cn=admin,dc=schule,dc=tld -W -f populate.ldif

Er fragt uns dann nach dem Pass­wort („secret”) aus der create_database.ldif. Wenn wir es im geben, ist danach alles so wie unter frü­he­ren slapd-Ver­sio­nen mit einer schlich­ten Kon­fi­gu­ra­ti­ons­da­tei statt eines con­fig-Bau­mes.

phplda­p­ad­min

phplda­p­ad­min ist zwar fei­ge, aber kann hübsch zur Kon­trol­le dar­über ver­wen­det wer­den, was man wie­der ein­mal mit sei­nen Kom­man­do­zei­len­scrip­ten zum Befül­len des LDAP ver­bockt hat. Das Tool beherrscht noch nicht den Zugriff auf den Kon­fi­gu­ra­ti­ons­baum (was doof ist). Des­we­gen müs­sen wir ihm den ver­meint­li­chen Wur­zel­baum in sei­ner config.php unter­schie­ben:

/*********************************************/
/* Defi­ne your LDAP ser­vers in this sec­tion  */
/*********************************************/

$ser­vers = new Datasto­re();

/* $servers->NewServer(‚ldap_pla’) must be cal­led befo­re each new LDAP ser­ver
decla­ra­ti­on. */
$servers->newServer(‚ldap_pla’);

/* A con­ve­ni­ent name that will appe­ar in the tree view­er and throug­hout
phpLDA­P­ad­min to iden­ti­fy this LDAP ser­ver to users. */
$servers->setValue(‚server’,‚name’,‚Schulname’);

/* Examp­les:
‚ldap.example.com’,
‚ldaps://ldap.example.com/’,
‚ldapi://%2fusr%local%2fvar%2frun%2fldapi’
(Unix socket at /usr/local/var/run/ldap) */
$servers->setValue(‚server’,‚host’,‚127.0.0.1’);

/* The port your LDAP ser­ver lis­tens on (no quo­tes). 389 is stan­dard. */
// $servers->setValue(‚server’,‚port’,389);

/* Array of base DNs of your LDAP ser­ver. Lea­ve this blank to have phpLDA­P­ad­min
auto-detect it for you. */
$servers->setValue(‚server’,‚base’,array(‚dc=schule,dc=tld’));

$servers->setValue(‚login’,‚bind_id’,‚cn=admin,dc=schule,dc=tld’);

Dann ist alles wie frü­her — zumin­dest bei mir. Auf jeden Fall soll­ten Tools wie phplda­p­ad­min und phpmy­ad­min spä­ter immer mit http-auth (z.B. .htac­cess) ver­ram­melt wer­den.

Ich grüb­le jetzt dar­an her­um, die Mai­l­an­ga­ben mit unter den cn’s der Per­so­nen im LDAP zu ver­wal­ten — bis­her lagen die in getrenn­ten Unter­bäu­men. Die qmail-Attri­bu­te sind schließ­lich von inet­or­g­per­son abge­lei­tet. Hübsch wäre ja auch, wenn man sich eige­ne Mai­la­lia­se und -wei­ter­lei­tun­gen set­zen könn­te. Dum­mer­wei­se wird unser Ser­verldap nicht vom Schulldap repli­ziert, son­dern der Daten­aus­tausch erfolgt ein­mal täg­lich via LDIF, weil ich wirk­lich nur not­wen­di­ge Daten unser SuS im Netz sehen woll­te. Die zusätz­li­chen User­da­ten aus dem Web müss­te man also aus z.B. einer sepa­ra­ten Daten­bank gewin­nen oder ich lei­te einen Unter­baum aus dem bestehen­den ab… Mal schau­en — das läuft ja schon alles per Script.

Facebook Like

2 Kommentare

  • Viel zu tech­nisch für mich, ich bin froh, dass ich damit nichts zu tun habe.

    • Einer­seits ver­ste­he ich dich da voll und ganz — ande­rer­seits wer­kelt in einem LDAP unter der Hau­be z.B. auch sowas hier: http://www.herr-rau.de/wordpress/2009/10/einfach-verkettete-liste-rekursion-und-entdeckungen-bei-powerpoint.htm. Außer­dem gibt es da Din­ge wie Klas­sen (Sche­ma), Objek­te (z.B. Benut­zer), Attri­bu­te (z.B. SSHA2-Pass­wort­hash), Metho­den (löschen, modi­fi­zie­ren…).
      Wir Admi­nis­tra­to­ren haben oft den Ein­druck, dass an einem Ende der Ska­la die (theo­re­ti­sche) Infor­ma­tik steht und am ande­ren Ende die touch­ba­re App. Das ist so lan­ge gut, wie alles funk­tio­niert, kei­ne indi­vi­du­el­len Anfor­de­run­gen zu erfül­len sind oder jemand damit streit­ba­re Din­ge macht/zu machen über­legt (Easy­cash: http://www.spiegel.de/netzwelt/web/0,1518,723028,00.html, denn dann braucht man das rie­sen­gro­ße Loch dazwi­schen — das ist die Welt der infor­ma­ti­ons­tech­ni­schen Kom­pe­ten­zen, so wie ich sie defi­nie­re. Ohne LDAP (ein Ver­zeich­nis­dienst) gäbe es Din­ge wie Sin­gle-Sign-On oder Zer­ti­fi­kat-Aut­ho­ri­ties nicht (also kei­ne eID, kein SSL…). Das gin­ge alles auch rela­tio­nal — klar, aber wenn sich Daten nicht sehr oft ändern, ist ein DBMS oft Over­kill.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.