LDAPS (LDAP over TLS/SSL)

Wo sind wir?

Wir befinden uns auf dem LDAP Server.

Dort kommt KEY und CERT rein.

Wir holen uns ein Zertifkat une ein Schlüssel

• wget https://xinux.de/downloads/script/get-cert.sh
• chmod +x get-cert.sh
• get-cert.sh

Sie liegen unter /etc/ssl/

Das Zertifilat

/etc/ssl/own.crt

Der private Schlüssel

/etc/ssl/own.key

Rechte für den slapd anpassen

Der User openldap muss den privaten Schlüssel lesen können:

• chown openldap:openldap /etc/ssl/own.crt /etc/ssl/own.key
• chmod 640 /etc/ssl/own.key

LDIF-Datei für die TLS-Konfiguration erstellen

• vi /root/tls_config.ldif

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

Konfiguration einspielen

Die Änderung direkt in die cn=config schreiben:

• ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f /root/tls_config.ldif

Ports in /etc/default/slapd anpassen

Sicherstellen, dass ldaps aktiviert ist:

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

Dienst neu starten

• systemctl restart slapd

Ports prüfen

• ss -4lntp | grep slapd

LISTEN 0      2048         0.0.0.0:636       0.0.0.0:*    users:(("slapd",pid=788,fd=10))
LISTEN 0      2048         0.0.0.0:389       0.0.0.0:*    users:(("slapd",pid=788,fd=7))

Funktionstest

Prüfen, ob der Server das Zertifikat auf Port 636 ausliefert:

• openssl s_client -connect ldap.it213.int:636 -showcerts

Nun zu den Clients

Funktionstest

Prüfen, ob der Server das Zertifikat auf Port 636 ausliefert:

• openssl s_client -connect ldap.it213.int:636 -showcerts

SSSD Konfiguration auf TLS umstellen

Da der Server nun Zertifikate ausliefert, wird die Verschlüsselung auf den Clients in der aktiviert:

• vi /etc/sssd/sssd.conf

[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = it213.int

[domain/it213.int]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = permit
sudo_provider = ldap

ldap_uri = ldaps://ldap.it213.int
dns_discovery_domain = it213.int

ldap_search_base = dc=it213,dc=int
ldap_sudo_search_base = ou=sudo,dc=it213,dc=int

ldap_default_bind_dn = cn=admin,dc=it213,dc=int
ldap_default_authtok = 123Start$

cache_credentials = True
ldap_id_use_start_tls = false
# ldap_auth_disable_tls_never_use_in_production = true
ldap_tls_reqcert = hard

[nss]
filter_users = root,daemon,bin,sys,sync,games,man,lp,mail,news,uucp,proxy,www-data,backup,list,irc,gnats,nobody,systemd-network,systemd-resolve,messagebus,_apt,uuidd,nslcd
filter_groups = root,daemon,bin,sys,adm,tty,disk,lp,mail,news,uucp,man,proxy,kmem,dialout,fax,voice,cdrom,floppy,tape,sudo,audio,dip,www-data,backup,operator,list,irc,src,gnats,shadow,utmp,video,sasl,plugdev,staff,games,users,nogroup,systemd-journal,systemd-network,systemd-resolve,input,kvm,render,crontab,netdev,messagebus,_apt,uuidd,ssh,nslcd

[pam]
offline_credentials_expiration = 2

Dienst neu starten

Damit die TLS-Einstellungen geladen werden:

• systemctl restart sssd

Verbindungstest

Prüfen, ob die Benutzerauflösung über den verschlüsselten Kanal weiterhin funktioniert:

• getent passwd thomas

Status prüfen

Falls es Probleme gibt, hilft das SSSD-Tool:

• sssctl domain-status it213.int

Analyse des Netzwerkverkehrs

Um sicherzugehen, dass die Kommunikation tatsächlich verschlüsselt über Port 636 erfolgt, nutzen wir tcpdump auf dem Client:

• tcpdump -i any -nn port 636

14:29:33.586737 IP 172.26.213.99.52646 > 10.213.1.3.636: Flags [P.], seq 1:759, ack 3951, win 501, options [nop,nop,TS val 2702684736 ecr 3149566692], length 758
14:29:33.586816 IP 10.213.1.3.636 > 172.26.213.99.52646: Flags [P.], seq 4795:4831, ack 759, win 504, options [nop,nop,TS val 3149566694 ecr 2702684736], length 36

Auswertung

Port 636

Die Pakete gehen gezielt an den LDAPS-Port.

Flags [P.]

Das "Push"-Flag mit einer "length > 0" zeigt den Austausch von verschlüsselten Anwendungsdaten nach dem TLS-Handshake.

Keine Klartextdaten

Im Gegensatz zu Port 389 sind hier keine Benutzernamen oder Passwörter im Dump lesbar.