Benutzer anlegen für AD/Samba-Zugriff

Hallo,

wenn ich mir das app tutorial ansehe, dann wird ein User im openldap erzeugt.
docs.univention.de/app-tutorial.html#idp31761072

Boah hab ich da lange dran gehangen, um zu kapieren, dass der ein Object mit uid= und nicht mit cn= anlegt!

Wie ist da das offizielle Statement?
Soll man Benutzer vom LDAP auf Port 7389 abfragen?
Denn eigentlich hätte ich sie gerne auf Port 389 bzw. 636 aus Samba4 abfragen wollen.

Scheinbar kann ich mit dem udm keinen samba4 user anlegen??

Da ich aus der Applikation gerne die Benutzer nach memberOf filter möchte, muss ich auf Samba4 unter Port 636 zugreifen.
Dort kann ich aber nur zugreifen, wenn ich es schaffe, einen Account anzulegen…

Vielen Dank und Gruß
Cornelius

Ich würde Benutzer immer über 7389 und OpenLDAP abfragen. Einfach weil nicht in jeder Umgebung Samba 4 vorhanden ist.

Wenn die App Samba 4 voraussetzt, dann kann man via samba-tool auch direkt die Benutzer im Samba 4 anlegen, udm unterstützt nicht das direkte Anlegen in Samba 4.

Ansonsten werden im OpenLDAP angelegte Benutzer, automatisch nach Samba 4 synchronisiert. Das kann aber ein paar Sekunden dauern und dort können die Benutzer dann über cn= gesucht werden.

Würde die App auch ohne memberOf funktionieren?

In der App gibt es Administratoren. Die möchte ich gerne aus dem LDAP/Samba4 nehmen weil ich die an einem gewissen Attribut identifizieren möchte.
Da bietet sich das memberOf=CN=Domain Admins… an.

Dieses Attribut sehe ich aber nicht im LDAP unter 7636.
Im LDAP habe ich allenfalls das Attribut gidNumber.
DIeses kann ich aber über die UI nicht ändern.

Ich möchte doch den Anwendern die Möglichkeit geben, später noch andere Administratoren hinzuzufügen. D.h. wenn ich einen Benutzer zum Domain-Admin machen, soll der auch die App administrieren können. (oder eben irgendeine andere Gruppe)

Wenn ich rein auf LDAP 7636 gehe, habe ich scheinbar keine Möglichkeit im UMC einen Benutzer in eine Gruppe zu schieben, so dass er auch die App verwalten kann.

Wegen des samba-tools, das habe ich auch gesehen. Funktioniert das im join-script denn auch auf nicht-DC-Machinen?
Ich habe hier eine frische “vanilla” UCS4 installation.
Und der Service-Account, den ich mittels

[code]udm users/user create “$@”
–position “cn=users,$ldap_base”
–option ldap_pwd
–set username="$USERNAME"
–set lastname=“privacyIDEA”
–set password="$BINDPW"
–set description=“privacyIDEA service”

[/code]angelegt habe, wird nicht synchronisiert und ist mit einem

root@gandalf:~# ldapsearch -x -W -D cn=administrator,cn=users,dc=netknights-demo,dc=intranet -H ldap://localhost -b cn=users,dc=netknights-demo,dc=intranet | less

nicht zu finden.

Per Default haben wir memberOf in OpenLDAP in UCS nicht aktiviert. Man kann es installieren. Es muss aber auf allen OpenLDAP Servern installieren werden, das kann man über eine App im Moment aber nicht steuern: docs.univention.de/manual-4.0.ht … ::memberof

samba-tool funktioniert auch auf einem anderen Samba 4 DC, ggf. auch auf einem Memberserver. Der Benutzer aus dem Beispiel wird nicht ins Samba 4 synchronisiert, weil dieser mit der Option ldap_pwd angelegt wird. Das ist dann kein vollständiger Samba / Kerberos Benutzer.

Meine Empfehlung wäre aber auf Samba 4 zu verzichten, weil sonst die App zwingend Samba 4 benötigt. Viele Umgebungen setzen kein Samba 4 ein.

Ich kenne die App Anbindung nicht im Detail. Möglichkeiten wären sonst über ein Listener Modul oder wenn über OpenLDAP und das memberUid Attribut:

root@master401:~# univention-ldapsearch -xLLL cn=Domain\ Admins memberUid
dn: cn=Domain Admins,cn=groups,dc=deadlock40,dc=intranet
memberUid: Administrator

Danke für die Infos und Hinweise.

Wenn es nicht noch ein LDAP Search String voodoo gibt, von dem ich nichts weiß, nutzt mir das leider nichts, da ich nur mit Hilfe eines Searchstrings die Benutzer Objecte holen muss. Die memberUid’s sind ja Teil des Gruppen Objects.
In SQL-Sprech könnte man da ja ein join machen, aber imho gibt es sowas bei LDAP nicht.
Und mehrere LDAP-Requests kann ich nicht machen, das wären derzeit nicht sinnvolle excessive Code-Änderungen im privacyIDEA.

Das Overlay auf allen Servern zu installieren (univention-ldap-overlay-memberof) geht ja nicht - würde man als App ja auch nicht wollen.

Ich werde der Einfachheit halber dem Rat folgen und per Default bei der Installation der App einfach auf die gidNumber des Benutzerobjekts im LDAP gehen. Damit hat der Anwender erstmal Administratoren, die er verwenden kann.

Danach kann er - wenn er ein Samba4 hat und will - sich selber neue Benutzer-Resolver/Konnektoren einrichten.

Alternativ könnte man noch - was aber eigentlich auch gar nicht nötig ist - ein entsprechendes LDAP-Attribut in einer Schema-Erweiterung einführen.

    [ ] Dieser Benutzer ist privacyIDEA Admin

Will ich aber nicht, weil man sowas eigentlich über Gruppenzugehörigkeiten macht…

OK. Damit weiß ich nun bescheid, was geht und was nicht geht.