LDAP Auth für externe Systeme

german
ldap

#1

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


#2

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


#3

Ach, SO einfach :slight_smile: … 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 …


#4

@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 !


#5

Bitte gern geschehen :slight_smile: