LDAP Auth für externe Systeme

[mahescho]

Hallo,

ich versuche - zunächst zu Testzwecken - mit dem Apache-Directorystudio mit dem UCS LDAP-Verbindung aufzunehmen um dann im nächsten Schritt andere externe Systeme für die die Authentisierung anzubinden. Ich scheitere hier aber schon bei der Anmeldung. Lokal auf dem UCS funktioniert das wie hier beschrieben:

https://wiki.univention.de/index.php/Cool_Solution_-_LDAP_search_user

Versuche ich mich dann aber mit den Daten, die lokal funktioniert haben an den LDAP zu binden funktioniert es nicht. Was mache ich falsch?

TIA
Matthias

[Moritz_Bunkus]

Huhu,

auf einem Univention-System mit Samba4 laufen gleich zwei LDAP-Server: OpenLDAP und das Samba4-LDAP. Zwischen beiden werden Einträge synchronisiert, sodass Benutzer in beiden existieren. Allerdings verwenden beide leicht unterschiedliche Syntaxen. Hier ein Beispiel meines Testsystems:

[0 root@poledra ~] univention-ldapsearch uid=mosu dn
…
dn: uid=mosu,cn=users,dc=int,dc=bunkus,dc=org
[0 root@poledra ~] univention-s4search cn=mosu dn
…
dn: CN=mosu,CN=Users,DC=int,DC=bunkus,DC=org

Beides ist derselbe User-Eintrag. Man muss daher wissen, an welchem LDAP man sich anmeldet, um den richtigen Anmeldenamen nutzen zu können.

Das OpenLDAP läuft auf den Ports 7389 (unverschlüsselt mit optionalem STARTTLS-Upgrade) und 7636 (verschlüsselt), das Samba4-LDAP auf den Standard-Ports 389 (unverschlüsselt mit optionalem STARTTLS-Upgrade) und 636 (verschlüsselt).

Weiterhin muss man bei Verschlüsselung auf die üblichen zwei Dinge achten:

1. Der verbindende Client muss der CA vertrauen, die das Zertifikat ausgestellt hat. Daher ist es oft nötig, die UCS-CA in der Client-Anwendung oder dem Client-Betriebssystem zu importieren. Die CA liegt auf dem DC Master in /etc/univention/ssl/ucsCA/CAcert.pem.
2. Der Hostname, den der Client zum Verbinden nutzt, muss im Zertifikat als subjectAlternativeName mit angegeben sein. Andernfalls wird die Verbindung als unsicher abgelehnt. Man kann also nicht einfach die IP-Adresse oder den kurzen Hostnamen nehmen, man muss den FQDN des LDAP-Servers nutzen.

Das Samba4-LDAP (Ports 389, 636) akzeptiert drei Varianten für die Angabe des Loginnamens:

1. Die vollständige DN des Users: CN=mosu,CN=Users,DC=int,DC=bunkus,DC=org (also nicht uid=mosu,…, denn so heißt das Objekt nur im OpenLDAP!)
2. Die Variante user@do.ma.in: mosu@int.bunkus.org
3. Die Variante NetBIOSDomain\user: int\mosu

OpenLDAP (Ports 7389, 7636) akzeptiert ausschließlich die DN-Syntax: uid=mosu,cn=users,dc=int,dc=bunkus,dc=org (also nicht cn=mosu,…, so heißt das Objekt nur im Samba4-LDAP!)

Große Unterschiede zwischen beiden LDAP-Varianten sind:

1. Samba4 speichert Gruppenmitgliedschaften im Userobjekt direkt mittels des Attributs memberOf. OpenLDAP speichert die Mitgliedschaft hingegen im Gruppenobjekt mittels des Attributs uniqueMember. Wenn man in seiner Anwendung nur einen LDAP-Filter angeben kann, so ist daher die Samba4-Variante einfacher. Achtung: man kann das in OpenLDAP mit Hilfe des »memberOf-Overlays« nachrüsten. Das wird ab UCS 4.3 übrigens standardmäßig aktiv sein (yay!).
2. Diverse für Unix/Linux relevante Attribute wie z.B. das Home-Verzeichnis oder die Login-Shell stehen ausschließlich im OpenLDAP zur Verfügung.
3. Die von Univention bereitgestellten, beliebig zu vergebenden Free Attributes stehen ebenfalls nur im OpenLDAP zur Verfügung.

Gruß
mosu

[mahescho]

Ach, SO einfach … wenn man das alles weiss: trivial … danke für die ausführlich Antwort. Die hilft sicher auch jedem anderen den das interessiert !

Ich bin “natürlich” mit der OpenLDAP-Schreibweise auf die Standardports, also auf den Samba, los gegangen. Kein Wunder also, dass es nicht geklappt hat …

[mahescho]

@Moritz_Bunkus ich habe mir erlaubt deine Ausführungen zum Teil in mein Wiki zu übernehmen:

https://wiki.mhcsoftware.de/ucs_ldap

Damit konnte ich dann auch ein anderes Problem lösen:

https://wiki.mhcsoftware.de/kopano_mail-user_und_die_securepoint_utm

Danke noch mal !

[Moritz_Bunkus]

Bitte gern geschehen

[mahescho]

Ich bin hier eben bei der LDAP-Anbindung von iTop auf etwas seltsames gestossen. Wenn ich das alles richtig interpretiere (und vorallem bei allen anderen LDAP-Anbindungen, die ich gemacht habe war es auch so) dann ist es doch so, dass wenn ich den Port 7389 verwende wird der OpenLDAP bemüht wo “uid” verwendet wird und “samaccountname” nicht vorkommt. Sieht man auch sehr schön im “slapcat” und ist auch so wenn ich mich so im Apache-Directorystudio verbinde. Den Bind mache ich dort auch mit “uid=…”.

Die iTop-Anbindung funktioniert aber nur so:

	'authent-ldap' => array (
		'host' => 'ldap://ucs.domain.tld',
		'port' => 7389,
		'default_user' => 'svcread@domain.tld',
		'default_pwd' => 'password',
		'base_dn' => 'cn=users,dc=domain,dc=tld',
		'user_query' => '(samaccountname=%1$s)',
		'options' => array (
		  17 => 3,
		  8 => 0,
		),
		'start_tls' => true,
		'debug' => false,

Port 7389 und die User-Schreibweise und “samaccountname” scheint mir ein Widerspruch zu sein. Oder sehe ich das falsch? Ich verstehe das nicht …

[Moritz_Bunkus]

Ich vermute (!), dass der Key port ignoriert wird, wenn in host eine URI-Schreibweise verwendet wird. Die URI ldap://ucs.domain.tld sagt ja drei Dinge aus:

1. Unverschlüsselte Initialverbindung da ldap und nicht ldaps (sagt natürlich nichts über nachträgliches StartTLS aus)
2. Hostname ucs.domain.tld
3. Standardport

Ich würde es also mal mit 'host' => 'ucs.domain.tld' oder 'host' => 'ldap://ucs.domain.tld:7389' probieren — und dann natürlich wieder mit einem default_user, der eine DN ist (OpenLDAP kann kein Login via Principal-Namen), sowie einem user_query, das die uid verwendet.

Gruß
mosu

[mahescho]

Danke, 100% richtig vermutet! Geht sowohl so als auch so ohne URI-Schreibweise. Die Doku ist da leider etwas ungenau:

https://www.itophub.io/wiki/page?id=2_5_0%3Aadmin%3Auser_authentication_options#configuration_of_ldap_authentication

Und ich habe mich von der URI-Schreibweise in grünen Kasten auf die falsch Fährte locken lassen …