REDDOXX Anmeldung an UCS

[Jeroen]

Moin,
folgendes Szenario bringt mich gerade an meine Grenzen:
REDDOXX Archivierungs Appliance - Unterstützt OpenLDAP, MS Active Directory, OX und Novell.

Bei OpenLDAP kann ich zwar erfolgreich ein Query mit dem Admin-Konto durchführen - Beim Anmeldeversuch heißt es “Insufficient access rights”.

Bei Active Directory kann ich auch ein Query durchführen, dann findet der ArchivServer allerdings nichts, da weder “samAccountname” noch “UPN” vorhanden zu sein scheinen. Zumindest nicht in der OU wo die Kopano-Domänen hinterlegt sind.

Braucht der Admin für die Remote-Auth über OpenLDAP noch irgendwelche Rechte / Attribute?
Oder brauchen normale (Kopano) User noch zus. Attribute, damit sie sich über OpenLDAP anmelden können?

Oder kann ich im Active Directory den samAccountname “verlinken” mit dem uid?

[thorp-hansen]

Ist auf dem UCS Samba-4 (Active Directory Domain Controller) installiert (wenn nicht, kann REDDOXX keine Verbindung zu einem AD herstellen, weil es das nicht gibt)?

[birkefeld]

Moin,

ich würde die openLDAP Schnittstelle empfehlen, wie sie hier beschrieben ist.
Ebenfalls folgende “UCS LDAP Search User”-Anleitung genau lesen und in der Konfiguration von REDDOXX berücksichtigen. Wichtig ist, den richtigen LDAP Port zu verwenden und das Mapping der Attribute in REDDOXX auf die UCS-LDAP Attribute zu überprüfen und ggf. anzupassen.

Viele Grüße,
Tobi

[Jeroen]

Moin,

eben das habe ich schon mehrfach versucht.

Die Symptomatik: Queries functionieren, allerdings nur wenn der “bind user” Mitglied der Domain Admins ist. (In diesem Fall habe ich kurz das UCS Administrator-Konto verwendet.)

Wenn ich nun aber mit eben diese Daten die Einrichtung des sog. “Backends” vornehme in REDDOXX:

• Ich habe hier überall kurz eine random IP-Adresse und leicht abgewandelte Eingaben verwendet. Die FQDN kann ich hier leider nicht publizieren.
  Die Pfade etc. stimmen aber.

Wenn ich dann versuche mich anzumelden mit bspw. dem o.a. Konto “jeroen.keerl”, bekomme ich im Log nur das hier zu sehen:
13-07-2017 00:05:39 3 ControlServer Session created: {2B9553C6-3B5B-A336-30E0-31B750625589}
13-07-2017 00:05:39 2 ControlServer Authentication request from: 79.210.111.104
13-07-2017 00:05:39 0 ControlServer Authentication: Insufficient access rights
13-07-2017 00:05:39 3 ControlServer Session deleted: {2B9553C6-3B5B-A336-30E0-31B750625589}

Normalerweise würde ich hier zuerst REDDOXX als Schuldige ausmachen, wäre es nicht, dass ich sowohl Kunden mit einem AD Server alsauch Kunden mit OpenLDAP bereits erfolgreich angebunden habe - und zwar mit den exakt gleichen Einstellungen wie oben aufgeführt.

Daher meine Vermutung, dass eine Authentifzierung des Benutzers von REDDOXX gegen UCS anders abläuft als bei einem “normalen” OpenLDAP Instanz.
Gibt es für eine “Remote Authentifizierung” eines UCS Anwenders andere Vorgaben? Besondere Rechte?
Oder eine Möglichkeit die Sicherheitseinstellungen soweit anzupassen, dass bspw. Zertifikate (Die ich bei REDDOXX leider nur sehr eingeschränkt installieren kann) nicht benötigt werden?

[ahrnke]

Ein paar Gedanken:

Bei Active Directory kann ich auch ein Query durchführen, dann findet der ArchivServer allerdings nichts, da weder “samAccountname” noch “UPN” vorhanden zu sein scheinen. Zumindest nicht in der OU wo die Kopano-Domänen hinterlegt sind.

Objekte, die über den S4-Connector synchronisiert werden, haben definitiv sAMAccountName. Das kann man z.B. mit univention-s4search prüfen. Normalerweise synchronisiert UCS alles was nicht auf der Blacklist (ucr search --brief ignorelist) steht. Ich bin mir jetzt aber nicht ganz sicher, ob auch OUs und nicht nur Container synchronisert werden.

Wenn ich dann versuche mich anzumelden mit bspw. dem o.a. Konto “jeroen.keerl”, bekomme ich im Log nur das hier zu sehen:
13-07-2017 00:05:39 3 ControlServer Session created: {2B9553C6-3B5B-A336-30E0-31B750625589}
13-07-2017 00:05:39 2 ControlServer Authentication request from: 79.210.111.104
13-07-2017 00:05:39 0 ControlServer Authentication: Insufficient access rights
13-07-2017 00:05:39 3 ControlServer Session deleted: {2B9553C6-3B5B-A336-30E0-31B750625589}

Das sieht für mich stark nach LDAP-ACLs aus. Eventuell sind die “normalen” Open-LDAP nicht ganz so restriktiv konfiguriert. Ohne detailliertere Informationen, was die Anwendung da gerade versucht kann man eigentlich nur noch ldap/debug/level hochschrauben und in den Systemlogs vom UCS nachsehen.

[Jeroen]

Moin,

also, der Output von ucr search --brief ignorelist ergibt:

connector/s4/mapping/container/ignorelist: mail,kerberos,MicrosoftDNS
connector/s4/mapping/dc/ignorelist: <empty>
connector/s4/mapping/dns/ignorelist: _ldap._tcp.Default-First-Site-Name._site
connector/s4/mapping/gpo/ignorelist: <empty>
connector/s4/mapping/group/ignorelist: Windows Hosts,Authenticated Users,World Authority,Everyone,Null Authority,Nobody,Enterprise Domain Controllers,Remote Interactive Logon,SChannel Authentication,Digest Authentication,Terminal Server User,NTLM Authentication,Other Organization,This Organization,Anonymous Logon,Network Service,Creator Group,Creator Owner,Local Service,Owner Rights,Interactive,Restricted,Network,Service,Dialup,System,Batch,Proxy,IUSR,Self
connector/s4/mapping/msprintconnectionpolicy/ignorelist: <empty>
connector/s4/mapping/ou/ignorelist: <empty>
connector/s4/mapping/user/ignorelist: root,ucs-s4sync
connector/s4/mapping/windowscomputer/ignorelist: <empty>
connector/s4/mapping/wmifilter/ignorelist: <empty>

Loglevel habe ich auf 256 gesetzt, werde jetzt mal schauen, was passiert.
Schon verwunderlich, dass SAM Accountname gar nicht gefunden werden kann

Ich werde gleich mal schauen, was die Tests ergeben.

[Jeroen]

Hmmm,

es bleibt komisch:
OpenLDAP Search-Queries laufen nachwievor, Anmeldung aber nicht.
Inzwischen meldet REDDOXX 2 verschiedene Fehlermeldungen:
-Insufficient acces rights
-Connection refused
…und das bei 2x den gleichen Anmeldenamen!

Obwohl ich jetzt in der UCR das Logging auf 256 hochgesetzt hatte, gibt es 0 Einträge in irgendwelche Logs.
Reboot notwendig? Anderes Log?

Fragen über Fragen…

[Jeroen]

Nebenbei bemerkt:
REDDOXX synchronisiert “out of the box” mit einem Win2008R2 AD.
Sind die UCS Samba Settings soviel restriktiver, dass ich nur noch mit Zertifikat verbinden darf?

[ahrnke]

Reboot notwendig? Anderes Log?

slapd neu gestartet?
Wenn ich recht sehe, landet die Ausgabe in
/var/log/debug

REDDOXX synchronisiert “out of the box” mit einem Win2008R2 AD.

Ich dächte eigentlich auch, dass es einfacher sein könnte, die Anbindung über das S4-AD in UCS herzustellen. Vielleicht ist es einfacher, sich vom Generischen zum Speziellen durchzuarbeiten, sprich, erstmal mit Nutzerkonten zu arbeiten, bei denen man weiß (und nachgeprüft hat), dass sie im S4-AD existieren.

[Jeroen]

Also: debug meldet genau das Gleiche: insufficient Access Rights:

Jul 18 15:25:57 mail slapd[31949]: conn=1052 fd=28 ACCEPT from IP=***.***.***.***:50854 (IP=0.0.0.0:7389)
Jul 18 15:25:57 mail slapd[31949]: conn=1052 op=0 SRCH base="ou=keerl-it.com,ou=Hosted Customers,dc=keerl-it,dc=com" scope=2 deref=3 filter="(&(objectClass=inetOrgPerson)(uid=*@keerl-it.com))"
Jul 18 15:25:57 mail slapd[31949]: conn=1052 op=0 SRCH attr=uid
Jul 18 15:25:57 mail slapd[31949]: OVER: rs->sr_err != LDAP_SUCCESS on "ou=keerl-it.com,ou=Hosted Customers,dc=keerl-it,dc=com" ERR: 0x32
Jul 18 15:25:57 mail slapd[31949]: conn=1052 op=0 SEARCH RESULT tag=101 err=50 nentries=0 text=
Jul 18 15:25:57 mail slapd[31949]: conn=1052 op=1 UNBIND
Jul 18 15:25:57 mail slapd[31949]: conn=1052 fd=28 closed

Bzgl. S4:
Da komme ich leider nicht hin, da S4 SSL / TLS voraussetz. Die Zertifikate hierfür lassen sich aber auf REDDOXX nicht installieren, da man (inzwischen, früher soll das gegangen sein) keinen Zugriff auf die Konsole mehr bekommt.
Versuche über SSL zu verbinden schlagen komplett fehl.

Hier: LDAP Anbindung REDDOX
findet man die Einstellunegn für AD und LDAP bei REDDOXX

[ahrnke]

Also: debug meldet genau das Gleiche: insufficient Access Rights

was mich etwas irritiert ist das Fehlen eines Bind-Users im Log, oder sehe ich den nur nicht?
Kennen Sie diesen Teil der Doku: 3.4.5. Zugriffskontrolle auf das LDAP-Verzeichnis?

[O_Bertgen]

Hmmm … kenne mich jetzt mit OpenLDAP nicht so genau aus, deshalb interessierte mich dieses Thema.
Ich bin über folgendes bei der Reddoxx-Anleitung zu OpenLDAP gestolpert:

Der LDAP-Benutzer muss Leseberechtigung auf die Eigenschaften „uid“ und „mail“ der Benutzer im Verzeichnis haben.

Kann man das vielleicht irgendwie überprüfen ?
Würde evtl. zu der Fehlermeldung passen ?

[Jeroen]

Der BIND User!
Sie haben völlig recht! Bei Test-Queries wird der Bind-User eingetragen und die Ergebnisse zeigen das auch.
Wenn ich allerdings die Authorisierung hier eintrage, scheint keinen Bind-User mitgegeben zu werden. Ergo: OpenLDAP sagt: Nicht genügend Rechte irgendwas zu lesen.

Ich habe soeben noch mal die Anmeldungen der User die im Acttive Directory liegen überprüft: Auch bei denen kein Bind-User.

Ergo: Anonymes LDAP browsen muss wohl eingestellt sein. Oder, wie Herr Bertgen gerade schreibt: Der Benutzer selbst hat keine Rechte zu seine eigene Attribute (Was ich komisch fände…)

Wie fände ich die ACS zu den Attribute heraus?

Sonst bliebe mir tatsächlich nur das “öffnen” von LDAP für Anonyme Zugriffe.

[Jeroen]

Moin,

nebenbei habe ich ein Support-Ticket beim Hersteller aufgemacht und - nach ein Wenig hin und her - die Aussage bekommen, dass REDDOXX bei der Authentifizierung ein “Anonymous bind” erwartet.

Das werde ich nun testen und dann wieder hier berichten!

[Jeroen]

Tatsache: Anonymous ldap access funktioniert.
REDDOXX selbst scheint allerdings Web-Sessions zu “cachen”. Dementsprechend bekommt man häufig ein “Anmeldung fehlgeschlagen” … und LDAP selbst wurde nicht mal gefragt!

Nachdem ich nun auch das gelernt hatte, konnte ich das ganze zum Laufen bringen.

Danke an alle beteiligten für die Hilfe!