habe soeben die MobyDick Telefonanlage an unseren Univention Server geknüpft.
Der Import/Abgleich der Benutzer hat soweit ohne Probleme funktioniert.
Nun hänge ich an dem Authentifizierungs- Dienst fest, dieser funktioniert leider nicht.
Wenn ich dort mit meinem User Testen will, klappt das nicht.
Wo werden die externen LDAP Auths geloggt? Vielleicht finde ich dort was aussagekräftiges nachdem ich schauen kann.
ich gehe mal davon aus das du die Werte anonymisiert hast, und deine Domäne nicht tatsächlich “example.de” ist?
Hast du du die UCS-Vorlage benutzt um die Authentifizierung bzw. den Import einzurichten?
Wenn du die Anmeldung testest, müsste bei einer Fehlgeschlagenen Authentifizierung der Grund in /var/log/mobydick/rest.log zu finden sein. Ansonsten kannst du am UCS-Server nachsehen, was diesem an der Authentifizierung nicht passt…
für die UCS-Logs musst du bei UCS nachfragen, da kann ich dir leider nicht weiterhelfen. Bist du dir auch sicher das du deine (vorhandenen) Benutzer auf Authentifizierung “Extern” und nicht auf “mobydick” geschaltet hast?
Ja alle waren nach dem Import auf Extern gestellt, musste ich jedoch wieder abändern, da der LDAP Auth ja leider nicht funktioniert.
Komischerweise klappt mit diesen Daten der Import der Daten, aber nicht der externe Auth, wo auch immer der große Unterschied dabei ist.
Liegt es vielleicht daran, dass wir die Nutzer im Active Directory in weitere “OU`s” unterteilt haben?
Zum Beispiel:
ja. Wir können hier nur eine automatische Vorlage nur für den “Standardfall” anbieten. Wenn du innerhalb der OU user noch weitere Gruppen hast, musst du den User-Bind entsprechend anpassen. z. B. also uid=%,ou=itgroup,ou=allgroups,dc=example,dc=de.
Grüße,
Jan
PS: Mit dem Anmeldung Testen Dialog kannst du ganz leicht testen ob die Auth funktioniert bevor du einen User wieder umstellst.
Ja so mache ich es im Moment auch, jedoch ergibt sich durch die OU dann ein weiteres Problem, da wir für jede interne Abteilung eine eigene OU
zwecks Group Policies haben und so wie ich das jetzt sehe kann ich für die Authentifizierung nur eine Angeben oder gibts da eine Art Wildcard?
Habe es nun Testweise bei Dienste-> Authentifizierung so eingetragen und mit dem User probiert der dort “haust” jedoch schläft auch dort die Anmeldung fehl…
univention-ldapsearch uid=user gibt folgendes aus = dn: uid=user,ou=itgroup,ou=allgroups,dc=example,dc=de
Zum Testen habe ich folgendes eingetragen:
Host: ldap://123.123.123.123:7389
Bind User: uid=%,ou=itgroup,ou=allgroups,dc=example,dc=de
Leider gibt es hier noch keine Wildcard. Ich gehe mal davon aus das bei uid=user tatsächlich der Benutzername steht - dann müsste da so eigentlich funktionieren? Ansonsten gehe dich davon aus das der Bind User falsch ist.
Hast du besondere Einstellungen beim UCS getroffen? Erzwingen von ldaps o. ä.?
Ja bei uid mit dem ldap search Befehl kommt der individuelle Benutzername raus, habe jetzt nur zum Beispiel den Nutzer user genommen
Im UCS haben wir nichts manuell an der LDAP Einstellung geändert oder besondere Einstellungen.
Habe anscheinend das Problem entdeckt, habe folgende Einstellungen nun im Authentifizierungdienst:
LDAP Host: ldap://123.123.123.123:389 <- statt Port 7389
Wobei lustigerweise es bei den Connectoren mit dem Port 7389 funktioniert o_0
LDAP BIND USER: DC=example,DC=de <- auch sehr komisch, da alte Connectoren auch mit der cn=users angegeben waren, die aber mittlerweile auch nicht mehr funktionierten.
Also beide dieser Änderungen sind notwendig sonst schlägt es weiterhin fehl.
Jetzt zeigt mir Icinga an das der LDAP Auth critical wäre? Was hat das jetzt zu bedeuten?
Bei UCS läuft auf Port 7389 immer der OpenLDAP. Wenn man die AD-Emulation aktiviert, ersetzt UCS den LDAP auf Port 389 (Dem Standardport) durch einen Samba-Server.
Normalerweise sollten beide die Authentifizerung akzeptieren (so verliefen zumindest meine Tests), aber nach Rücksprache mit den UCS-Leuten haben wir uns entschieden 7389 als Standard zu verwenden. Bestimmte LDAP-Attribute werden nämlich nicht in den Samba Server gespiegelt.
Zum Icinga-Check: Der ist leider nicht ganz zuverlässig (wir wollten vermeiden das man nur für den Check Benutzer-Credentials hinterlegen muss), aber das funktioniert in freier Wildbahn scheinbar nicht so wie wir uns das vorstellen.
Führe bitte einmal folgenden Befehl auf einer (am besten root) Shell aus, und poste mir hier die Ausgabe (Das ist auch exakt das der Icinga-Check intern tut). Besonders wichtig wäre der Return-Code:
Da fällst du jetzt leider in einen “Bug” mit rein. Der Tatsächliche Returncode des Programms ist hier “1”. 1 kann u. a. auftreten wenn z. B. die LDAP-Uri falsch geschrieben ist (und die Authentifizierung somit nicht geht). Diesen Zustand haben wir als “Problematisch” definiert, weshalb der Icinga Rot wird. Leider tritt dieser Code auch bei bestimmten Authentifizierungsfehlern auf, und somit schlägt der Check fehl, obwohl eigentlich alles gut ist.
Wenn bei dir die Authentifizierung jetzt funktioniert, dann kannst du den Roten Check ignorieren, wir werden das Fixen und mit einem der nächsten Bugfixes für die 7.10 wird es dann die Möglichkeit geben einen Benutzer / Passwort für den Auth-Check zu hinterlegen - was dieses Problem erschlägt.
