OpenLDAP ab 2.4 installieren und einrichten

Vorweg

Mir ist kei­ne Quel­le im Netz bekannt, die die Ein­rich­tung von OpenLDAP wirk­lich umfas­send dar­stellt – schon gar nicht auf Deutsch. Die­se Infor­ma­tio­nen hier sind aus allen mög­li­chen Ecken zusam­men­ge­klaubt – selbst die meis­ten Bücher zu OpenLDAP emp­fin­de ich als sehr wenig hilfreich.

Grundinstallation

Hin­weis: domain.tld muss man natür­lich immer an den eige­nen openLDAP anpassen.

Zuerst instal­lie­ren wir die Bina­ries, in Debi­an und sei­nen Abkömm­lin­gen (Ubun­tu, Mint etc.) z.B. so:

1

apt-get install slapd ldap-utils

Die Instal­la­ti­ons­rou­ti­ne von Debi­an legt dabei nur eine sehr rudi­men­tä­re Kon­fi­gu­ra­ti­on an, sodass etwas Nach­ar­beit von­nö­ten ist. Bei ande­ren Dis­tri­bu­tio­nen ken­ne ich mich nicht so gut aus. Ein

1

dpkg-reconfigure slapd

ermög­licht uns hier die Ein­ga­be einer kor­rek­ten Basis-DN (auf die muss unser SSL-Zer­ti­fi­kat aus­ge­stellt sein), meist sowas wie

• dc=domain, dc=tld

und zusätz­lich defi­nie­ren wir dabei ein Root­pass­wort für den LDAP-User

• cn=admin,dc=domain,dc=de

.

Handling von OpenLDAP

Ab Debi­an Squeeze spei­chert der OpenLDAP-Ser­ver sei­ne Kon­fi­gu­ra­ti­on in einem inter­nen LDAP-Baum und nicht mehr in einem Kon­fi­gu­ra­ti­ons­file. Das macht die Pfle­ge auf den ers­ten Blick erheb­lich auf­wän­di­ger, weil man an die­sen Baum in der Stan­dard­kon­fi­gu­ra­ti­on nur umständ­lich über Kon­so­len­tools her­an­kommt. Zudem kann eine feh­ler­haf­te Daten­bank dazu füh­ren, dass der OpenLDAP nach einer Kon­fi­gu­ra­ti­ons­än­de­rung gar nicht mehr hochkommt.
Nur der Root­be­nut­zer des Sys­tems kommt immer auch direkt an die Daten. Man kann sich die bestehen­den Inhalt nur als root anzei­gen las­sen mit:

1

ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config"

Neue Ein­trä­ge kön­nen über *.ldif-Files hin­zu­ge­fügt werden:

1

ldapmodify/ldapadd -Y EXTERNAL -H ldapi:/// -f

Hinweis zu Ubuntu 14.04 LTS

Der Instal­ler setzt den Account­na­men für den Benut­zer mit Zugriff auf den cn=config-Baum stan­dard­mä­ßig auf: cn=admin,dc=domain,dc=tld. Dann macht man Befol­gen die­ser Anlei­tung ein lan­ges Gesicht. Um das auf den Stan­dard zu ändern, benö­tigt man nur für Ubun­tu 14.04 LTS noch eine klei­ne Ände­rung (change_admin.ldif):

1
2
3
4

dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=admin,cn=config

Obli­ga­to­risch:

1

ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f change_admin.ldif

Sicherheit

OpenLDAP-Verbindungen per TLS absichern

Vor­weg: Hier kann ganz viel schief­ge­hen, obwohl ich die­ses Kapi­tel mit am wich­tigs­ten fin­de. Wenn OpenLDAP aus irgend­wel­chen Grün­den die Zer­ti­fi­kat­files nicht frisst, kann man mit der Kon­fi­gu­ra­ti­on von vor­ne begin­nen oder man hat vor­her ein Back­up der alten Daten­bank gemacht. Des­we­gen über­sprin­ge ich die­sen Schritt ger­ne und bin­de den OpenLDAP ein­fach nicht an öffent­lich erreich­ba­re Netz­werk­de­vices. Wenn man das machen muss, führt aus Daten­schutz­grün­den aber kein Weg an die­ser Pro­ze­dur hier vor­bei. LDAP ist genau wie FTP ein Klar­text­pro­to­koll, dass ohne Trans­port­ver­schlüs­se­lung auf dem gesam­ten Daten­weg offen­liegt und gera­de in WLAN-Umge­bun­gen sehr leicht belauscht wer­den kann.
Gene­rell gibt es zwei Mög­lich­kei­ten, wie man an kos­ten­lo­se Zer­ti­fi­ka­te kom­men kann. Wosign oder Start­S­SL. Es gibt diver­se Tuto­ri­als im Netz zur Nut­zung die­ser Diens­te. Von Let­sen­crypt wür­de ich im Kon­text von OpenLDAP eher abra­ten. Start­S­SL und WoSign sind mitt­ler­wei­le Geschich­te. Wenn es kos­ten­los sein soll, führt kein Weg an let­sen­crypt vor­bei. Man muss dann dafür sor­gen, dass OpenLDAP nach jedem Cert­up­date neu gestar­tet wird, also alle drei Mona­te mindestens.

Man hat am Ende des Zer­ti­fi­zie­rungs­pro­zes­ses in der Regel drei Datei­en vorliegen:

1. domain.tld-crt.pem (ent­hält das Zertifikat)
2. domain.tld-key.pem (ent­hält den pri­va­ten Schlüssel)
3. ca_chain.pem (ent­hält die Zer­ti­fi­zie­rungs­chain der CA)

domain.tld ist dabei der Wur­zel­baum des openLDAP. Ich habe die Datei­en nach /etc/ldap/ssl gelegt. Bes­ser auf­ho­ben sind sie in /etc/ssl/cert – dann muss slapd Lese­rech­te dort bekommen.

Fol­gen­de Datei (tls_ldap.ldif) anlegen:

1
2
3
4
5
6
7
8
9

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/ssl/ca_chain.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/domain.tld-key.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/domain.tld-crt.pem

… und über die Kon­so­le einspielen:

1

ldapadd -Y EXTERNAL -H ldapi:/// -f tls_ldap.ldif

oder auch

1

ldapmodify -Y EXTERNAL -H ldapi:/// -f tls_ldap.ldif

Ich bin zusätz­lich ein Freund davon, siche­re Ver­bin­dun­gen zu erzwin­gen. Cli­ents, die das nicht wol­len oder kön­nen, sol­len bit­te draußenbleiben.

Fol­gen­de Datei (force_tls.ldif) anlegen:

1
2
3
4

dn: olcDatabase={1}hdb,cn=config
changetype:  modify
add: olcSecurity
olcSecurity: tls=1

Und wie­der einspielen:

1

ldapadd -Y EXTERNAL -H ldapi:/// -f force_tls.ldif

oder auch

1

ldapmodify -Y EXTERNAL -H ldapi:/// -f force_tls.ldif

Jetzt noch in /etc/default/slapd nach­schau­en, ob die Ser­vices stim­men (ldaps über Port 639 gilt als ver­al­tet und soll­te nicht mehr ver­wen­det wer­den). In der Regel steht da so etwas:

1

SLAPD_SERVICES="ldap://0.0.0.0:389/ ldapi:///"

Wenn man meh­re­re NICs besitzt, kann man natür­lich statt 0.0.0.0 auch die IP einer spe­zi­fi­schen Netz­werk­kar­te ange­ben oder den OpenLDAP nur an local­host (127.0.0.1) binden.

Ein

1

service slapd restart

bringt Auf­klä­rung, ob das Gan­ze funk­tio­niert hat. Theo­re­tisch ist das nicht not­wen­dig, da OpenLDAP durch das neue Ver­fah­ren ohne Kon­fi­gu­ra­ti­ons­da­tei qua­si live im Betrieb gepatcht wird. Jetzt soll­te der OpenLDAP Ver­bin­dun­gen von außen nur noch ver­schlüs­selt akzep­tie­ren. Von der Kon­so­le aus ( ldapi:/// ) klappt das nach wie vor auch nor­mal. Wir ver­trau­en uns ja schon selbst.

Bruteforce erschweren

Ein offe­ner LDAP-Ser­ver ist anfäl­lig für bru­te-force Atta­cken – zumal gera­de im Schul­be­reich vie­le unsi­che­re Pass­wör­ter im Umlauf sein dürf­ten. Durch das ppolicy.schema kann man z.B. nach eini­gen fehl­ge­schla­ge­nen Log­ins den Account für eine Wei­le auto­ma­tisch sper­ren. openLDAP bringt das dafür not­wen­di­ge Sche­ma in /etc/ldap/schema/ppolicy.ldif schon mit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

dn: cn=ppolicy,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: ppolicy
olcAttributeTypes: {0}( 1.3.6.1.4.1.42.2.27.8.1.1 NAME 'pwdAttribute' EQUALITY
  objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
olcAttributeTypes: {1}( 1.3.6.1.4.1.42.2.27.8.1.2 NAME 'pwdMinAge' EQUALITY in
 tegerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {2}( 1.3.6.1.4.1.42.2.27.8.1.3 NAME 'pwdMaxAge' EQUALITY in
 tegerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {3}( 1.3.6.1.4.1.42.2.27.8.1.4 NAME 'pwdInHistory' EQUALITY
  integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {4}( 1.3.6.1.4.1.42.2.27.8.1.5 NAME 'pwdCheckQuality' EQUAL
 ITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {5}( 1.3.6.1.4.1.42.2.27.8.1.6 NAME 'pwdMinLength' EQUALITY
  integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {6}( 1.3.6.1.4.1.42.2.27.8.1.7 NAME 'pwdExpireWarning' EQUA
 LITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {7}( 1.3.6.1.4.1.42.2.27.8.1.8 NAME 'pwdGraceAuthNLimit' EQ
 UALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {8}( 1.3.6.1.4.1.42.2.27.8.1.9 NAME 'pwdLockout' EQUALITY b
 ooleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {9}( 1.3.6.1.4.1.42.2.27.8.1.10 NAME 'pwdLockoutDuration' E
 QUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {10}( 1.3.6.1.4.1.42.2.27.8.1.11 NAME 'pwdMaxFailure' EQUAL
 ITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {11}( 1.3.6.1.4.1.42.2.27.8.1.12 NAME 'pwdFailureCountInter
 val' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
 )
olcAttributeTypes: {12}( 1.3.6.1.4.1.42.2.27.8.1.13 NAME 'pwdMustChange' EQUAL
 ITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {13}( 1.3.6.1.4.1.42.2.27.8.1.14 NAME 'pwdAllowUserChange'
 EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {14}( 1.3.6.1.4.1.42.2.27.8.1.15 NAME 'pwdSafeModify' EQUAL
 ITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {15}( 1.3.6.1.4.1.4754.1.99.1 NAME 'pwdCheckModule' DESC 'L
 oadable module that instantiates "check_password() function' EQUALITY caseExa
 ctIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcObjectClasses: {0}( 1.3.6.1.4.1.4754.2.99.1 NAME 'pwdPolicyChecker' SUP top
  AUXILIARY MAY pwdCheckModule )
olcObjectClasses: {1}( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'pwdPolicy' SUP top AUXI
 LIARY MUST pwdAttribute MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheck
 Quality $ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout $
  pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange
  $ pwdAllowUserChange $ pwdSafeModify ) )

Ein­ge­spielt wird das Sche­ma mit:

1

ldapadd -Q -Y EXTERNAL -H ldapi:/// -f ppolicy.ldif

Das Sche­ma ppolicy.ldif selbst defi­niert nur Objek­te für das ent­spre­chen­de Modul, was jetzt noch gela­den wer­den muss, wofür wir eine Datei policy_module.ldif mit fol­gen­dem Inhalt anlegen:

1
2
3
4

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy.la

Und das alte Spiel:

1

ldapadd -Q -Y EXTERNAL -H ldapi:/// -f policy_module.ldif

Jetzt brau­chen wir noch eine Abla­ge (policy_context.ldif) für die ver­schie­de­nen Regelsätze:

1
2
3
4

dn: ou=policies,dc=domain,dc=tld
objectClass: organizationalUnit
objectClass: top
ou: policies

1

ldapadd -Q -Y EXTERNAL -H ldapi:/// -f policy_context.ldif

Und als nächs­tes eine Default-Poli­cy (default_policy.ldif):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

dn: cn=default,ou=policies,dc=domain,dc=tld
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: 2.5.4.35
pwdMaxAge: 15552000
pwdInHistory: 3
pwdMinLength: 6
pwdMaxFailure: 3
pwdLockout: TRUE
pwdLockoutDuration: 1800
pwdGraceAuthNLimit: 3
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: TRUE

In die­sen Bei­spiel wird nach drei fehl­ge­schla­ge­nen Log­in­ver­su­chen ( pwd­Max­Fail­ure: 3 ) das Log­in für 1800 Sekun­den ( pwd­Lock­out­Du­ra­ti­on: 1800 ) gesperrt. Das soll­te kleb­rig genug sein.

Muss ich es noch schreiben?

1

ldapadd -Q -Y EXTERNAL -H ldapi:/// -f default_policy.ldif

Da OpenLDAP ja so fluf­fig und intui­tiv ist, brau­chen wir jetzt noch ein Over­lay (policy_overlay.ldif), dass dem OpenLDAP sagt, dass statt des nor­ma­len Log­in­hand­lings jetzt immer auch die Default-Poli­cy gel­ten soll:

1
2
3
4
5
6
7

dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=domain,dc=tld
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: TRUE

Ihr wisst, was jetzt kommt:

1

ldapadd -Q -Y EXTERNAL -H ldapi:/// -f policy_overlay.ldif

Damit hät­ten wir grund­sätz­lich ver­schlüs­sel­te Ver­bin­dun­gen erzwun­gen und zusätz­lich Bru­teforce-Angrif­fe erschwert. Bleibt noch eines zu tun:

Anonymous-Bind verbieten

Stan­dard­mä­ßig erlaubt openLDAP einen soge­nann­te anony­mous bind, d.h. man erhält lesend Zugriff auch ohne die Ein­ga­be eines Pass­wor­tes. Die­se lesen­de Zugriff ist sehr ein­ge­schränkt, z.B. gibt es kei­nen Zugriff auf bestimm­te Objekt­klas­sen oder gar Pass­wort­hash­es. Mir ist die Vor­stel­lung trotz­dem nicht geheu­er, dass sich u.a. Nut­zer­na­men auf die­sem Weg aus­le­sen las­sen. Daher ver­wen­de ich für den lesen­den Zugriff einen sepa­ra­ten User, der sich mit Pass­wort authen­ti­fi­zie­ren muss, ansons­ten aber nicht mehr Rech­te als beim anony­mous bind hat. Des­we­gen unter­bin­den wir das mit einer neu­en Datei noanonymous.ldif:

1
2
3
4
5
6
7

dn: olcDatabase={1}hdb,cn=config
add: olcRequires
olcRequires: authc
 
dn: olcDatabase={-1}frontend,cn=config
add: olcRequires
olcRequires: authc

Und jetzt kommt etwas ande­res, weil wir einen bereits bestehen­den Daten­bank­ein­trag aktualisieren:

1

ldapmodify -Y EXTERNAL -H ldapi:/// -f noanonymous.ldif

Nach dem Ein­spie­len der letz­ten Ände­rung hat man ohne Authen­ti­fi­zie­rung auch über die Kon­so­le kei­nen Zugriff mehr auf den Haupt­baum des OpenLDAP (dc=domain, dc=tld) – die war bis­her auch sowas wie „anonym“ aus Sicht des LDAP. Man muss dann aus­wei­chen auf eine ande­re Befehls­zei­le (cn=config ist davon nicht betroffen):

1

ldapadd -x -D cn=admin,dc=domain,dc=tld -W -f

Danach wird man zur Ein­ga­be des Admin­pass­wor­tes auf­ge­for­dert und kann so den Haupt­baum beschrei­ben und verändern.

Optionale Arbeiten

Performancetuning

Die­se Datei ( index.ldif )

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: cn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: sn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: uid pres,sub,eq
-
add: olcDbIndex
olcDbIndex: displayName pres,sub,eq
-
add: olcDbIndex
olcDbIndex: default sub
-
add: olcDbIndex
olcDbIndex: uidNumber eq
-
add: olcDbIndex
olcDbIndex: gidNumber eq
-
add: olcDbIndex
olcDbIndex: mail,givenName eq,subinitial
-
add: olcDbIndex
olcDbIndex: dc eq

ein­spie­len mit

1

ldapadd -Q -Y EXTERNAL -H ldapi:/// -f index.ldif

Benutzer für die Administration von cn=config einrichten

Wenn man sau­ch den cn=config-Baum auch über kom­for­ta­ble­re Frontends wie phplda­pad­min oder LAM ver­wal­ten möch­te, muss man das Objekt cn=admin, cn=config noch um wei­te­re Ein­trä­ge ergän­zen. Zunächst erzeu­gen wir uns über die Kon­so­le ein Passwort:

1

slappasswd -h {SSHA}

Wir erhal­ten einen Hash zurück, den wir in die Zwi­schen­ab­la­ge kopie­ren. Jetzt erstell­ten wir ein ldif-File (manager.ldif):

1
2
3
4
5
6
7
8
9
10
11

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}
 
# auskommentieren, wenn wir den Zugriff von root  auf cn=config 
# ohne Passwort sperren wollen. Sollte als Fallback besser erhalten bleiben
 
#dn: olcDatabase={0}config,cn=config
#changetype: modify
#delete: olcAccess

1

ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f manager.ldif

Wenn wir jetzt in phplda­pad­min (ab Ver­si­on 1.2.2) oder lam als Base-DN cn=config ver­wen­den und als Log­in cn=admin, cn=config, kön­nen wir cn=config auch gra­fisch verwalten.

Quel­le: https://wiki.debian.org/PhpLdapAdmin

War doch ganz einfach oder?

OpenLDAP ist extrem sper­rig, aber eine her­vor­ra­gen­de Authen­ti­fi­zie­rungs­mög­lich­keit, da im Gegen­satz zu Daten­bank­sys­te­men die Struk­tur hoch­gra­dig stan­dar­di­siert sowie mus­ter­gül­tig objekt­ori­en­tiert ist und sich OpenLDAP so recht schnell in belie­bi­ge Anwen­dun­gen inte­grie­ren lässt – fast alle ernst­zu­neh­men­den Online­tools unter­stüt­zen die Authen­ti­fi­zie­rung über LDAP. OpenLDAP dien­te nicht umsonst nicht als Vor­la­ge für die LDAP-Funk­tio­nen von Samba4 – weil es eben so sper­rig ist.

This work by Maik Riecken is licen­sed under a Crea­ti­ve Com­mons Attri­bu­ti­on-Non­Com­mer­cial-ShareA­li­ke 4.0 International