Da ich einen Authentik-Server zur Anmeldung betreibe, will ich nun die Benutzer nicht mehr direkt über den Domänenkontroller per LDAP und LDAPS zur Vergügung stellen, sondern mache das nun an meiner zentralen Anmeldeinstanz.

Konzept: LDAP über Authentik bereitstellen

Authentik stellt LDAP über einen sogenannten LDAP Outpost bereit. Dieser lauscht auf Port 389 (LDAP) und 636 (LDAPS) und übersetzt LDAP-Anfragen in Authentik-interne Abfragen – die Benutzer kommen dabei weiterhin aus deinem AD.

Das Design

Schritt 1 – LDAP Source prüfen (Authentik ← AD)

Das ist die bestehende Verbindung. Stelle sicher, dass sie korrekt synchronisiert:

Admin → Directory → Federation & Social login → deine LDAP Source

Wichtige Einstellungen:

• Sync-Intervall aktiv (z. B. alle 5 Minuten)
• Benutzer und Gruppen werden in Authentik gespiegelt
• User Property Mappings für Felder wie AD UPN to Email, AD Mapping: givenName, AD Mapping: sAMAccountName, AD Mapping: sn, AD Mapping: userPrincipalName, LDAP Mapping: DN to User Path, LDAP Mapping: Name gesetzt.
• Group Property Mappings für das Feld authentik default LDAP Mapping: Name setzen.

Schritt 2 – LDAP Provider anlegen

Admin → Applications → Providers → Create → LDAP Provider

Feld	Wert
Name	z. B. LDAP Provider Internal
Bind DN	DC=software2eu,DC=de (anpassen)
Bind Flow	default-authentication-flow
Search mode	Cached binding
Base DN	DC=software2eu,DC=de
Certificate	dein TLS-Zertifikat für LDAPS

Schritt 3 – Application für den LDAP Provider anlegen

Admin → Applications → Applications → Create

Feld	Wert
Name	LDAP Application
Slug	ldap-internal
Provider	der eben angelegte LDAP Provider

Schritt 4 – LDAP Outpost einrichten

Admin → Applications → Outposts → Create

Feld	Wert
Name	LDAP Outpost
Type	LDAP
Applications	die eben angelegte LDAP Application
Integration	Local (da Outpost auf demselben Host läuft)

Der Outpost startet als Docker-Container oder Embedded-Service direkt auf s2kirsaml01 (192.168.111.15) und lauscht auf:

• 389 → LDAP
• 636 → LDAPS

Schritt 5 – KEMP Loadbalancer konfigurieren

Am KEMP muss ein neuer Virtual Service für LDAP angelegt werden, analog zur bestehenden HTTPS-VIP:

Parameter	Wert
VIP	192.168.111.7 (sso.software2eu.de)
Port	389 und 636
Protocol	TCP
Real Server	192.168.111.15:389 / :636
Health Check	TCP-Check auf Port 389
Persistence	Source IP (wichtig für LDAP-Sessions)

Wichtig: LDAP ist zustandsbehaftet (Bind-Session). Stelle sicher, dass der KEMP Persistence/Sticky Sessions auf Basis der Source-IP aktiviert hat, damit ein gebundener Client immer denselben Backend-Server trifft.

Schritt 6 – Bind-User für LDAP-Clients

LDAP-Clients benötigen einen Service-Account zum Binden. In Authentik legst du dafür einen dedizierten Benutzer an:

Admin → Directory → Users → Create

• Username: z. B. ldap-service
• Passwort setzen
• Ist kein AD-User, sondern ein lokaler Authentik-User

Der Bind-DN für Clients lautet dann:

cn=ldap-service,ou=users,DC=software2eu,DC=de

Schritt 7 – Test

LDAP-Verbindung testen (von einem Client aus)

ldapsearch -H ldap://sso.software2eu.de \
-D „cn=ldap-service,ou=users,DC=software2eu,DC=de“ \
-w „PASSWORT“ \
-b „DC=software2eu,DC=de“ \
„(objectClass=user)“