Schritt-für-Schritt-Einrichtung des LDAP-Servers und Client-Verbindung unter CentOS 7

Was ist LDAP und wofür wird es verwendet?

LDAP (oder Lightweight Directory Access Protocol) dient dazu, Informationen über Benutzerkonten in einem zentralen Datenbankserver zu speichern, den Anwendungen dann zum Durchsuchen verschiedener Informationen (wie Benutzerkennungen, Kennwörter, E-Mail-Adressen usw.) verwenden können. LDAP ist besonders wertvoll, wenn ein Administrator eine große Anzahl von Benutzern verwalten muss, ohne dies auf jedem einzelnen Server innerhalb der Umgebung tun zu müssen.

Als Beispiel können wir das Folgende verwenden:

Der Benutzer Timmy ist ein Entwickler, der Zugriff auf den Datenbankserver, den Redis-Server und den Webserver beantragt hat. Je nach Umgebung kann es noch weitere Anwendungsserver geben, auf die der Entwickler direkten Zugriff benötigt. Bislang haben wir für Timmy bereits sein Konto an drei verschiedenen Stellen, wo es erstellt und für die Berechtigungen konfiguriert werden muss (vielleicht muss der Benutzer bestimmte sudo-Befehle verwenden), und wenn Timmy zufällig sein Passwort vergisst, muss es an mehreren Stellen zurückgesetzt werden. Wenn Lastverteilung im Spiel ist, kann es mehr als einen der besprochenen Anwendungsserver geben, wodurch weitere Stellen hinzukommen, an denen jede einzelne Änderung vorgenommen werden muss, um das Konto aktuell zu halten.

Die oben beschriebene Situation kann auch für den Benutzer selbst mühsam werden, da er sein Passwort auf allen Rechnern auf der Grundlage bestimmter Richtlinien aktualisieren muss (vielleicht sind die Passwörter so eingestellt, dass sie alle 3 Monate ablaufen).

Man kann sehen, wie die normalerweise einfache und schnelle Aufgabe der Verwaltung eines einzelnen Benutzerkontos zu einem langen und ermüdenden Prozess werden kann. LDAP löst alle oben genannten Probleme und bietet darüber hinaus einen sehr anpassbaren Satz von Regeln, die pro Server/Benutzer und nach den Wünschen des Administrators festgelegt werden können.

Bevor wir fortfahren, möchte ich darauf hinweisen, dass ich beim Schreiben der folgenden Anweisungen davon ausgehe, dass der Leser mindestens sudo-Rechte hat, da die meisten Befehle zur Ausführung root-Rechte benötigen. Jedes Mal, wenn eine Zeile mit dem Dollar-Symbol ($) beginnt, bedeutet dies, dass es sich bei der betreffenden Zeile um einen Befehl handelt. Nachdem das gesagt ist, lassen Sie uns fortfahren.

Bis jetzt haben wir eine Vorstellung davon, in welchen Situationen LDAP benötigt wird, aber wie richten wir es ein?

Wie richtet man LDAP ein?

1. Zunächst müssen wir ein paar Pakete installieren:

• Auf dem LDAP-Server müssen die folgenden Pakete installiert werden:

openldap-Clients, openldap, openldap-Server, openldap-devel, ldapvi

Oder all dies in einem einzigen Befehl:

$ yum install openldap-clients openldap openldap-servers openldap-devel ldapvi -y

• Auf dem/den LDAP-Client/s benötigen wir die folgenden Pakete:

openldap, openldap-clients, nss-pam-ldapd, openssh-ldap, sssd

Mit einem einzigen Befehl:

$ yum install openldap openldap-clients nss-pam-ldapd openssh-ldap sssd -y

2. Sobald dies geschehen ist, müssen wir die LDAP/S-Ports innerhalb der Firewall öffnen:

$ firewall-cmd --permanent --zone=public --add-port=636/tcp
$ firewall-cmd --permanent --zone=public --add-port=389/tcp
$ firewall-cmd --reload

Wenn Sie sie nicht zur öffentlichen Zone hinzufügen möchten, können Sie natürlich auch eine andere Zone wie "vertrauenswürdig" usw. verwenden.

3. Als Nächstes müssen wir die Zertifikate für die verschlüsselte Kommunikation mit dem Server erstellen; wir beginnen mit der Erstellung des Schlüssels und der CSR:

$ openssl req -new -newkey rsa:2048 -nodes -keyout /etc/openldap/certs/openldap.key -out /etc/openldap/certs/openldap.csr -subj '/C=EX/ST'=exampleST/L=ExampleLocation/O=exampleOrganization/OU=exampleOU/CN=example.com

Dabei können die Pfade sowie die Beispieleinträge frei nach Ihren Wünschen verändert werden.

Danach unterschreiben wir den Schlüssel:

$ openssl x509 -req -days 365 -in /etc/openldap/certs/openldap.csr -signkey /etc/openldap/certs/openldap.key -out /etc/openldap/certs/openldap.crt

Hinweis: Wenn Sie die Pfade für die CSR-Erstellung geändert haben, müssen natürlich auch die oben genannten Pfade entsprechend angepasst werden.

Mit dem obigen Verfahren werden 3 Dateien erstellt:

/etc/openldap/certs/openldap.csr

/etc/openldap/certs/openldap.key

/etc/openldap/certs/openldap.crt

die wir später in der Konfigurationsdatei von slapd (ldap daemon) verwenden werden.

Außerdem müssen wir die oben genannten Dateien auf die Client-Rechner übertragen (vorzugsweise in dieselben Pfade).

Ich empfehle, diesen Vorgang zu automatisieren, da er bei einer großen Anzahl von Client-Systemen mühsam werden kann, insbesondere wenn die Umgebung größer wird.

4. Erstellen Sie eine Beispiel-DB-Konfigurationsdatei.

Als Standard kann die folgende Beispielkonfiguration verwendet werden:

Hinweis: Das folgende HereDoc kann ausgewählt und direkt in das Terminal eingefügt werden, da es die Datei /var/lib/ldap/DB_CONFIG erstellt und den Inhalt darin einfügt. Ich werde diese Art von Ansatz für alle ähnlichen Dateien verwenden, da es eine einfache Möglichkeit ist, die Anweisungen zu befolgen.

$ cat > /var/lib/ldap/DB_CONFIG <<EOF

# $OpenLDAP$
# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases.
#
# See the Oracle Berkeley DB documentation
#   <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html>
# for detail description of DB_CONFIG syntax and semantics.
#
# Hints can also be found in the OpenLDAP Software FAQ
#	<http://www.openldap.org/faq/index.cgi?file=2>
# in particular:
#   <http://www.openldap.org/faq/index.cgi?file=1075>

# Note: most DB_CONFIG settings will take effect only upon rebuilding
# the DB environment.

# one 0.25 GB cache
set_cachesize 0 268435456 1

# Data Directory
#set_data_dir db

# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152
#set_lg_dir logs

# Note: special DB_CONFIG flags are no longer needed for "quick"
# slapadd(8) or slapindex(8) access (see their -q option). 
EOF

5. Sobald die oben genannten Voraussetzungen erfüllt sind, können wir mit der Konfiguration unseres neuen slapd (open-LDAP)-Servers beginnen.

Zunächst müssen wir die Datei sysconfig erstellen:

$ cat > /etc/sysconfig/slapd <<EOF
# OpenLDAP server configuration
# see 'man slapd' for additional information
# Where the server will run (-h option)
# - ldapi:/// is required for on-the-fly configuration using client tools
#   (use SASL with EXTERNAL mechanism for authentication)
# - default: ldapi:/// ldap:///
# - example: ldapi:/// ldap://127.0.0.1/ ldap://10.0.0.1:1389/ ldaps:///
SLAPD_URLS="ldapi:/// ldap:/// ldaps:///"

# Any custom options
SLAPD_OPTIONS="-s 256"

# Keytab location for GSSAPI Kerberos authentication
#KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"
EOF

Dann müssen wir den Dienst starten:

$ systemctl start slapd

Wir sollten es auch aktivieren, damit es nach einem Neustart läuft:

$ systemctl enable slapd

6. Wir beginnen damit, den LDAP-Server mit einigen Schemata zu füttern, die in der Datei "" verfügbar sein werden./etc/openldap/schema" Verzeichnis. Der Befehl, den wir dafür verwenden werden, lautet wie folgt:

$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/ppolicy.ldif

Zusätzlich zu den obigen Angaben müssen wir eine zusätzliche externe ldif-Datei mit Informationen zur LDAP-Datenbank erstellen (ldif ist das Syntaxformat von ldap). Die Datei sollte wie die folgende aussehen:

$ cat > databases.ldif <<EOF
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
  read by dn.base="cn=manager,dc=example,dc=com" read by * none

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=com

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=manager,dc=example,dc=com

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: examplePassword

dn: olcDatabase={2}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by
  dn=cn=manager,dc=example,dc=com write by anonymous auth by self write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=manager,dc=example,dc=com" write by * read

dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: examplePassword

dn: cn=openssh-lpk,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: openssh-lpk
olcAttributeTypes: {0}( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey' DES
 C 'MANDATORY: OpenSSH Public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.
 1.1466.115.121.1.40 )
olcObjectClasses: {0}( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' DESC
  'MANDATORY: OpenSSH LPK objectclass' SUP top AUXILIARY MAY ( sshPublicKey $ 
 uid ) )

dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/openldap.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/openldap.key

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib64/openldap
olcModuleLoad: ppolicy.la


dn: olcOverlay=ppolicy,olcDatabase={2}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=passwordDefault,ou=Policies,dc=example,dc=com

dn: cn=sudo,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: sudo
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' DESC 'User(s) who may  run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.2 NAME 'sudoHost' DESC 'Host(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.3 NAME 'sudoCommand' DESC 'Command(s) to be executed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.4 NAME 'sudoRunAs' DESC 'User(s) impersonated by sudo (deprecated)' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.5 NAME 'sudoOption' DESC 'Options(s) followed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.6 NAME 'sudoRunAsUser' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.7 NAME 'sudoRunAsGroup' DESC 'Group(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcObjectClasses: ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ description ) )
EOF

Sobald die Datei erstellt ist, können wir sie mit dem folgenden Befehl in die LDAP-Datenbank einspeisen:

$ ldapadd -Y EXTERNAL -H ldapi:/// -f databases.ldif

Wenn keine Fehler angezeigt werden, sind alle oben genannten Konfigurationen gespeichert worden. Wir können dies bestätigen, indem wir die LDAP-Datenbank auflisten:

$ slapcat -n 0

Das sollte alle Einträge anzeigen, die wir importiert haben.

7. Nachdem die erste Datenbank importiert wurde, müssen wir auch das LDAP-Skelett importieren:

Auch hier müssen wir eine neue Datei mit folgendem Inhalt erstellen (die von uns verwendeten Domänenkomponenten sind dc=example und dc=com; sie können jedoch je nach Bedarf geändert werden, solange sie überall, wo sie in diesem Dokument erscheinen, geändert werden):

$ cat > skeleton.ldif <<EOF
#Create the root DN:
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example com
dc: example

#Create the Manager(LDAP administrator) DN
dn: cn=manager,dc=example,dc=com
objectClass: organizationalRole
cn: manager
description: Directory Manager

#Create the People DN (this is the dn under which we will populate the actual user accounts):
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People

#Create the Group DN
dn: ou=Group,dc=example,dc=com
objectClass: organizationalUnit
ou: Group

#Create the SUDOers DN
dn: ou=SUDOers,dc=example,dc=com
objectclass: organizationalunit
ou: SUDOers
description: LDAP SUDO Entry

#Create the default sudo LDAP sudo configuration
dn: cn=defaults,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: SUDO via LDAP
sudoOption: !authenticate
sudoOption: !visiblepw
sudoOption: always_set_home
sudoOption: match_group_by_gid
sudoOption: always_query_group_plugin
sudoOption: env_reset
sudoOption: env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
sudoOption: env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
sudoOption: env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
sudoOption: env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
sudoOption: env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
sudoOption: env_keep+=SSH_AUTH_SOCK
sudoOption: secure_path = /sbin:/bin:/usr/sbin:/usr/bin

#Create the SudoUsers group under the SUDOers OU:
dn: cn=SudoUsers,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: SudoUsers
sudoUser: %SudoUsers
sudoHost: ALL
sudoRunAs: ALL
sudoCommand: ALL

#Create the SudoUsers group itself:
dn: cn=SudoUsers,ou=Group,dc=example,dc=com
objectClass: top
objectClass: posixGroup
gidNumber: 4321

#Create the policies DN:
dn: ou=Policies,dc=example,dc=com
ou: Policies
objectClass: organizationalUnit

#Populate the policies DN (these will be the rules for the users’ passwords expirations etc.):
dn: cn=passwordDefault,ou=Policies,dc=example,dc=com
objectClass: pwdPolicy
objectClass: person
objectClass: top
cn: passwordDefault
sn: passwordDefault
pwdAttribute: userPassword
pwdCheckQuality: 2
pwdMinLength: 8
pwdMinAge: 0
pwdMaxAge: 0
pwdInHistory: 4
pwdMaxFailure: 6
pwdFailureCountInterval: 0
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdAllowUserChange: TRUE
pwdExpireWarning: 0
pwdGraceAuthNLimit: 0
pwdMustChange: TRUE
pwdReset: TRUE
pwdSafeModify: FALSE
EOF

Übermitteln Sie die Datei an den Server:

$ ldapadd -x -D 'cn=manager,dc=example,dc=com' -W -f skeleton.ldif

8. Okay! Das LDAP-Skelett ist fertig, jetzt müssen wir nur noch ein paar Benutzer hinzufügen.

Je nachdem, ob wir die lokalen Benutzer zu LDAP migrieren oder ganz neu beginnen wollen, können wir einen von zwei Wegen einschlagen:

• Migrieren Sie die aktuellen Benutzer aus /etc/passwd:

Hinweis: Ich werde mich nicht auf diesen Teil konzentrieren, da er ziemlich viele Zeilen dieses ohnehin schon recht umfangreichen Dokuments beanspruchen würde; wenn Sie jedoch die Benutzer migrieren müssen, heißt das Paket "migrationtools". Es gibt eine Menge Dokumentation im Internet darüber, wie es verwendet wird.

• Fügen Sie völlig neue Benutzer hinzu:

In diesem Fall werden wir den Benutzer Timmy hinzufügen. Wie immer erstellen wir eine Datei mit dem Namen Timmy.ldif und fügen den folgenden Inhalt darin ein:

Hinweis: uidNumber und gidNumber müssen für zukünftige neue Benutzererstellungen verfolgt werden. Ein Beispiel: Timmy verwendet die uidNummer 1337 und die gidNummer 1337. Wenn ich einen neuen Benutzer, Alex, hinzufüge, muss ich die uidNummer und gidNummer von Alex auf andere Nummern als die von Timmy setzen (z. B. 1338 für beide, um die Verfolgung zu erleichtern).

Erzeugen Sie Timmys verschlüsseltes Passwort:

$ slappasswd

Sobald wir das verschlüsselte Passwort generiert haben, müssen wir es kopieren und in das Feld "userPassword:" in der unten stehenden Textdatei eingeben.

$ cat > timmy.ldif <<EOF
dn: uid=timmy,ou=People,dc=example,dc=com
uid: timmy
cn: timmy
sn: timmy
mail: timmy@example.com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
userPassword: {SSHA}1n8RJajTNhx5W8FecLP002MFzg8RZmWO
pwdReset: TRUE
loginShell: /bin/bash
uidNumber: 1337
gidNumber: 1337
homeDirectory: /home/timmy
EOF

Geben Sie sie an den LDAP-Server weiter:

$ ldapadd -x -D 'cn=manager,dc=example,dc=com' -W -f timmy.ldif

Nachdem die Benutzerinformationen in die Datenbank eingegeben wurden, müssen wir auch seine Gruppe hinzufügen:

$ cat > timmy_group.ldif <<EOF
dn: cn=timmy,ou=Group,dc=example,dc=com
objectClass: top
objectClass: posixGroup
gidNumber: 1337
cn: timmy
memberUid: timmy
EOF

Geben Sie sie an den LDAP-Server weiter:

$ ldapadd -x -D 'cn=manager,dc=example,dc=com' -W -f timmy_group.ldif

9. Da Timmy ein sehr erfahrener Entwickler ist, wird er wahrscheinlich sudo-Rechte benötigen. Zuvor haben wir die sudo-Gruppe "SudoUsers" erstellt, jetzt müssen wir nur noch Timmy dazu hinzufügen. Wie üblich erstellen wir eine neue ldif-Datei namens sudo_timmy.ldif und füllen sie mit den folgenden Informationen aus:

$ cat > sudo_timmy.ldif <<EOF
dn: cn=SudoUsers,ou=Group,dc=example,dc=com
changetype: modify
add: memberuid
memberuid: timmy
EOF

Geben Sie sie an den LDAP-Server weiter:

$ ldapadd -x -D 'cn=manager,dc=example,dc=com' -W -f sudo_timmy.ldif

Und voila! Bis jetzt haben wir die Regeln des Servers eingerichtet und die Datenbank mit unserem allerersten Benutzer namens Timmy befüllt, außerdem haben wir Timmy die Rechte gegeben, sudo-Befehle auszuführen. Aber wie soll sich Timmy mit seinem neuen Benutzer mit der Umgebung verbinden?

10. Einrichten der Client-Rechner.

Wie bereits erwähnt, werden wir SSSD verwenden, um die LDAP-Client>Server-Verbindung einzurichten, daher können wir die folgende Konfiguration in /etc/sssd/sssd.conf hinzufügen:

$ vi /etc/sssd/sssd.conf //Oder Editor der eigenen Wahl

[domain/default]

debug_level = 2
cache_credentials = True
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = ldap

ldap_search_base = dc=example,dc=com
ldap_uri = ldaps://$your_ldap_server_ip_address:636
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_tls_reqcert = allow
ldap_sudo_search_base = ou=SUDOers,dc=example,dc=com

[sssd]
services = nss, sudo, pam, ssh
domains = default

Anmerkung: ldap_uri in den obigen Zeilen muss geändert werden, damit sie mit der IP-Adresse des Rechners übereinstimmt, auf dem der LDAP-Server läuft.

Ändern Sie die Berechtigungen:

$ chmod 600 /etc/sssd/sssd.conf

$ chown root:root /etc/sssd/sssd.conf

Starten Sie anschließend den sssd-Client, damit die Änderungen wirksam werden:

$ systemctl start sssd

oder

$ systemctl restart sssd

Als nächstes konfigurieren wir die ldap-Client-Anwendung, indem wir die folgende Konfiguration in die Datei /etc/openldap/ldap.conf einfügen

$ cat > /etc/openldap/ldap.conf <<EOF
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE	dc=example,dc=com
#URI	ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT	12
#TIMELIMIT	15
#DEREF		never

tls_cacert /etc/openldap/certs/openldap.crt
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow
# Turning this off breaks GSSAPI used with krb5 when rdns = false
#SASL_NOCANON	on
BASE dc=example,dc=com
sudoers_base ou=SUDOers,dc=example,dc=com
URI ldaps://$your_ldap_server_ip_address:636
EOF

Nun müssen wir einige Änderungen an der obigen Datei vornehmen:

$ vi /etc/openldap/ldap.conf

Und ändern Sie die letzte Zeile in:

ldaps://${THE_IP_OF_THE_YOUR_LDAP_SERVER}.

Außerdem müssen wir die folgende Zeile in unsere Datei /etc/nsswitch.conf einfügen:

sudoers:    files sss

Zum Schluss führen wir den folgenden authconfig-Befehl aus:

$ authconfig --enableldap --enableldapauth --enableshadow --ldapserver=ldaps://$your_ldap_server_ip_address:636 --ldapbasedn=dc=example,dc=com --enablemkhomedir --update

Wenn der Befehl erfolgreich ausgeführt wird, sollten wir nun vom Client-Rechner aus Zugriff auf den LDAP-Server haben. Um das zu testen, können wir eine einfache Abfrage an die Datenbank durchführen:

$ getent passwd timmy
timmy:*:1337:1337:timmy:/home/timmy:/bin/bash

$ su timmy
$ ls

11. Hinzufügen eines Replikationsservers

Um einen Replikationsserver zum Hauptserver von openldap hinzuzufügen, müssen wir viele der Schritte vom Hauptserver übernehmen. Zunächst müssen wir die folgenden Pakete installieren:

openldap-clients,openldap, openldap-server, openldap-devel, ldapvi

Oder ein einziger Befehl:

$ yum install openldap-clients openldap openldap-servers openldap-devel ldapvi -y

Öffnen Sie die erforderlichen Ports:

$ firewall-cmd --permanent --zone=public --add-port=636/tcp
$ firewall-cmd --permanent --zone=public --add-port=389/tcp
$ firewall-cmd --reload

Kopieren Sie außerdem die generierten openldap-Zertifikate vom Hauptserver in dieselben Pfade auf dem Replikationsserver.

Sobald wir die oben genannten Voraussetzungen erfüllt haben, können wir mit der Konfiguration beginnen. Zunächst erstellen wir die DB wie beim Hauptserver:

$ cat > /var/lib/ldap/DB_CONFIG <<EOF

# $OpenLDAP$
# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases.
#
# See the Oracle Berkeley DB documentation
#   <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html>
# for detail description of DB_CONFIG syntax and semantics.
#
# Hints can also be found in the OpenLDAP Software FAQ
#	<http://www.openldap.org/faq/index.cgi?file=2>
# in particular:
#   <http://www.openldap.org/faq/index.cgi?file=1075>

# Note: most DB_CONFIG settings will take effect only upon rebuilding
# the DB environment.

# one 0.25 GB cache
set_cachesize 0 268435456 1

# Data Directory
#set_data_dir db

# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152
#set_lg_dir logs

# Note: special DB_CONFIG flags are no longer needed for "quick"
# slapadd(8) or slapindex(8) access (see their -q option). 
EOF

Erstellen Sie die Datei sysconfig:

$ cat > /etc/sysconfig/slapd <<EOF
# OpenLDAP server configuration
# see 'man slapd' for additional information

# Where the server will run (-h option)
# - ldapi:/// is required for on-the-fly configuration using client tools
#   (use SASL with EXTERNAL mechanism for authentication)
# - default: ldapi:/// ldap:///
# - example: ldapi:/// ldap://127.0.0.1/ ldap://10.0.0.1:1389/ ldaps:///
SLAPD_URLS="ldapi:/// ldap:/// ldaps:///"

# Any custom options
SLAPD_OPTIONS="-s 256"

# Keytab location for GSSAPI Kerberos authentication
#KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"
EOF

Starten Sie den Dienst:

$ systemctl start slapd

Aktivieren Sie es, damit es nach einem Neustart ausgeführt wird:

$ systemctl enable slapd

Wir beginnen damit, den LDAP-Server mit einigen Schemata zu füttern, die im Verzeichnis /etc/openldap/schema zur Verfügung stehen werden. Der Befehl, den wir dazu verwenden werden, ist der folgende:

$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/ppolicy.ldif

Zusätzliche Struktureinträge für die interne slapd-Datenbank (das Feld oclRootPW: wird verwendet, um das Administrator-Passwort für den "manager"-Benutzer zu erstellen, also ändern Sie es entsprechend Ihren Bedürfnissen):

$ cat > databases.ldif <<EOF
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
  read by dn.base="cn=manager,dc=example,dc=com" read by * none

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=com

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=manager,dc=example,dc=com

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: examplePassword

dn: olcDatabase={2}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by
  dn=cn=manager,dc=example,dc=com write by anonymous auth by self write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=manager,dc=example,dc=com" write by * read

dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: examplePassword

dn: cn=openssh-lpk,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: openssh-lpk
olcAttributeTypes: {0}( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey' DES
 C 'MANDATORY: OpenSSH Public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.
 1.1466.115.121.1.40 )
olcObjectClasses: {0}( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' DESC
  'MANDATORY: OpenSSH LPK objectclass' SUP top AUXILIARY MAY ( sshPublicKey $ 
 uid ) )

dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/openldap.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/openldap.key

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib64/openldap
olcModuleLoad: ppolicy.la


dn: olcOverlay=ppolicy,olcDatabase={2}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=passwordDefault,ou=Policies,dc=example,dc=com

dn: cn=sudo,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: sudo
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' DESC 'User(s) who may  run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.2 NAME 'sudoHost' DESC 'Host(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.3 NAME 'sudoCommand' DESC 'Command(s) to be executed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.4 NAME 'sudoRunAs' DESC 'User(s) impersonated by sudo (deprecated)' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.5 NAME 'sudoOption' DESC 'Options(s) followed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.6 NAME 'sudoRunAsUser' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcAttributeTypes: ( 1.3.6.1.4.1.15953.9.1.7 NAME 'sudoRunAsGroup' DESC 'Group(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
olcObjectClasses: ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ description ) )
EOF

Geben Sie es an den Server weiter:

$ ldapadd -Y EXTERNAL -H ldapi:/// -f databases.ldif

Wenn keine Fehler angezeigt werden, sind alle oben genannten Konfigurationen gespeichert worden. Wir können dies bestätigen, indem wir die LDAP-Datenbank auflisten:

$ slapcat -n 0

Sobald dies geschehen ist, müssen wir die Kopie mit dem Hauptserver verbinden:

Zu diesem Zweck müssen wir dem MAIN-Server einige Dinge hinzufügen. Zunächst fügen wir den Replikationsbenutzer hinzu (der Benutzername dafür lautet "readonly" und das Passwort "ExamplePassword"):

$ cat > readonly.ldif << EOF
dn: uid=readonly,dc=example,dc=com
objectClass: simpleSecurityObject
objectclass: account
objectClass: shadowAccount
uid: readonly
description: Read only Replication  User
userPassword: {SSHA}vnocdPa1k3PZXAfWSe+Nru0ubuhKE3lj
EOF

Jetzt geben wir den Eintrag an den MAIN LDAP-Server weiter:

$ ldapadd -x -D 'cn=manager,dc=example,dc=com' -W -f readonly.ldif

Als Nächstes müssen wir, wiederum auf dem MAIN-Server, das Replikations-Overlay hinzufügen:

$ cat > syncprov.ldif << EOF
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov.la

dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
EOF

Und füttern Sie es:

$ ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov.ldif

Danach kehren wir zum Replikationsserver zurück und stellen die Verbindung zum Hauptserver her:

$ cat > connection.ldif << EOF
dn: olcDatabase={2}hdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: 
  rid=001
  provider=ldaps://${main_server_ip_address}:636
  binddn="uid=readonly,dc=example,dc=com"
  tls_cert="/etc/openldap/certs/openldap.crt"
  tls_key="/etc/openldap/certs/openldap.key"
  tls_cacertdir=/etc/openldap/certs
  tls_reqcert=allow
  credentials=ExamplePassword
  searchbase="dc=example,dc=com"
  type=refreshAndPersist
  timeout=0
  network-timeout=0
  retry="60 +"
EOF

Füttern Sie die Replik mit der obigen Datei:

$ ldapadd -Y EXTERNAL -H ldapi:/// -f connection.ldif

Wenn alles ordnungsgemäß abläuft, sollten wir in der Lage sein, die Replik aufzulisten, so wie wir den Hauptserver auflisten:
$ slapcat | grep -i timmy

memberUid: timmy
dn: uid=timmy,ou=People,dc=example,dc=com
uid: timmy
cn: timmy
sn: timmy
mail: timmy@example.com
homeDirectory: /home/timmy
dn: cn=timmy,ou=Group,dc=example,dc=com
cn: timmy
memberUid: timmy

Wenn wir die obige Ausgabe erhalten, bedeutet dies, dass der Replikatserver erfolgreich eine Verbindung hergestellt und den Timmy-Eintrag kopiert hat und sich mit jedem Eintrag, den wir dem Hauptserver hinzufügen, aktualisiert.

12. Jetzt müssen nur noch die Client-Systeme mit dem neu hinzugefügten Replikationsserver aktualisiert werden, so dass sie bei Problemen mit dem Hauptserver auf den Replikationsserver zurückgreifen können:

Auf dem Client-Rechner müssen wir in der Datei /etc/sssd/sssd.conf den zweiten Eintrag direkt neben dem ersten Eintrag hinzufügen (durch Komma getrennt):

$ vi /etc/sssd/sssd.conf

ldap_uri = ldaps://$main_server_ip_address:636,ldaps://$replica_server_ip_address:636

Starten Sie sssd auf dem Client-Rechner neu, damit die obigen Änderungen wirksam werden:

$ systemctl restart sssd

13. Manchmal werden wir bestimmte Einträge bearbeiten müssen. Vielleicht hat Timmy sein Passwort vergessen, so dass wir es zurücksetzen müssen, oder vielleicht müssen wir einige sudo-Zugänge entfernen oder sogar neue hinzufügen. Was auch immer der Fall sein mag, das Tool namens "ldapvi" kann uns dabei sehr helfen.

"ldapvi" ist ein Paket, das ldif-Einträge mit dem Editor "vi" öffnet.

Als Beispiel werden wir das Passwort von Timmy ändern und ihn aus der Liste der sudo privilegierten Benutzer entfernen:

$ ldapvi -D "cn=manager,dc=example,dc=com" -b uid=timmy,ou=People,dc=example,dc=com

Mit diesem Befehl authentifizieren wir uns beim LDAP-Server als Benutzer "manager" (auch bekannt als unser administrativer Benutzer) und geben an, dass wir Timmys ldif-Einträge bearbeiten möchten. Daraufhin sollte sich die folgende Information öffnen:

# -*- coding: utf-8 -*-
# http://www.lichteblau.com/ldapvi/manual#syntax

0 uid=timmy,ou=People,dc=example,dc=com
uid: timmy
cn: timmy
sn: timmy
mail: timmy@example.com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
userPassword: TimmysSuperSecretPassword!
loginShell: /bin/bash
uidNumber: 1337
gidNumber: 1337
homeDirectory: /home/timmy

Von dort aus können wir jede beliebige Zeile bearbeiten, um die gewünschten Änderungen vorzunehmen. Wir haben zum Beispiel ein neues Passwort für den Benutzer Timmy erstellt:

$ slappasswd -s TimmysSuperSecretPassword

{SSHA}BteytVTtuT7n4hIU8QyhDYAjlYwhMYf2

Wir kopieren die obige Zeichenfolge und setzen sie in das Feld userPassword. Danach speichern und schließen wir vi, wie wir normalerweise ein Textdokument mit vi speichern würden. Es wird uns eine kleine Zusammenfassung dessen geben, was gemacht wird, und uns auffordern, die Änderungen zu bestätigen. Sobald wir die Eingabezeile erhalten, müssen wir nur noch ein "y" hinzufügen, und das war's - wenn sich Timmy das nächste Mal beim Server anmeldet, muss er sein neues Passwort verwenden.

Das Entfernen aus der administrativen Gruppe kann ebenso einfach mit dem entsprechenden Befehl erfolgen:

$ ldapvi -D "cn=manager,dc=example,dc=com" -b cn=SudoUsers,ou=Group,dc=example,dc=com

Im obigen Beispiel öffnen wir den Gruppeneintrag selbst. Das sollte uns den folgenden Text im Editor liefern:

# -*- coding: utf-8 -*-
# http://www.lichteblau.com/ldapvi/manual#syntax

0 cn=SudoUsers,ou=Group,dc=example,dc=com
objectClass: top
objectClass: posixGroup
gidNumber: 4321
cn: SudoUsers
memberUid: timmy

Wenn wir Einträge hinzufügen oder entfernen möchten, bearbeiten wir einfach den Text wie gewohnt und fügen einen neuen Eintrag hinzu oder entfernen den Eintrag "memberUid:". Wenn wir zum Beispiel den Benutzer "george" auch als sudo-Benutzer hinzufügen wollen, fügen wir einfach eine neue Zeile ein:

0 cn=SudoUsers,ou=Group,dc=example,dc=com
objectClass: top
objectClass: posixGroup
gidNumber: 4321
cn: SudoUsers
memberUid: timmy
memberUid: george

Speichern Sie erneut und beenden Sie das Programm. Die Änderungen sollten relativ schnell wirksam werden (es kann einige Minuten dauern, bis die Änderungen aufgrund der Zwischenspeicherung übertragen werden).

Zum Abschluss:

Auch wenn LDAP aufgrund der vielen Konfigurationen, der Syntax usw. zunächst einschüchternd wirken kann, ist es doch ein wesentlicher Bestandteil der meisten IT-Umgebungen, und wenn man sich erst einmal an die Funktionsweise gewöhnt hat, kann die Verwaltung recht einfach sein, vor allem, wenn man die große Menge an Informationen bedenkt, die im Internet verfügbar ist.