memberOf im eingenen Listener benutzen

UCS - Univention Corporate Server
#1

Moin,

wir haben das Problem, das wir das memberOf Attribut unter UCS 3.1 im eigenen Listener in zwei von drei Fällen nicht nutzen können.

Uns ist völlig schleierhaft, warum es in einem Fall geht, in zwei anderen aber nicht.

Der Filter hat die Form:

filter="(&(objectclass=digitecSugarCRM)(memberOf=cn=GRUPPE,cn=groups,ou=GRUPPE,dc=KUNDE,dc=local))"

Wir würden das Feature gerne Benutzen um mandatenenfähige SugarCRM Instanzen an UCS anzubinden.

Im Listener.log finden sich nach einem resync folgende Einträge:

27.12.12 12:19:27.719 LISTENER ( INFO ) : running handlers [sugarcrm-KUNDE] for uid=digitec,cn=users,dc=KUNDE,dc=local 27.12.12 12:19:27.719 LISTENER ( ALL ) : handler: sugarcrm-KUNDE considered 27.12.12 12:19:27.719 LISTENER ( ALL ) : handler: sugarcrm-KUNDE (filter doesn't match)
Und das obwohl wir mit univention-ldapsearch und dem Filter aus der Datei (copy and paste), den Benutzer mit der uid=digitec finden.

Also ein univention-ldapsearch "(&(objectclass=digitecSugarCRM)(memberOf=cn=GRUPPE,cn=groups,ou=GRUPPE,dc=KUNDE,dc=local))" uid

findet den Benutzer digitec.

Auch sieht dieser völlig okay aus:

root@crm:~# univention-ldapsearch uid=digitec memberof objectclass
# extended LDIF
#
# LDAPv3
# base <dc=KUNDE,dc=local> (default) with scope subtree
# filter: uid=digitec
# requesting: memberof objectclass
#

# digitec, users, kunde.local
dn: uid=digitec,cn=users,dc=KUNDE,dc=local
objectClass: top
objectClass: person
objectClass: univentionPWHistory
objectClass: posixAccount
objectClass: shadowAccount
objectClass: univentionMail
objectClass: sambaSamAccount
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: krb5Principal
objectClass: krb5KDCEntry
objectClass: oxUserObject
objectClass: digitecSugarCRM
memberOf: cn=Domain Users,cn=groups,dc=KUNDE,dc=local
memberOf: cn=SynCRMAdmin,cn=groups,dc=KUNDE,dc=local
memberOf: cn=SynCRMUser,cn=groups,dc=KUNDE,dc=local
memberOf: cn=GRUPPE,cn=groups,ou=GRUPPE,dc=KUNDE,dc=local

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

(KUNDE und GRUPPE haben wir aus Datenschutzgründen durch dieses Platzhalter ersetzt)

Viele Grüße

Sven Anders (DIGITEC GmbH digitec-ses.de/)

#2

memberOf wird durch ein Overlay Modul im OpenLDAP Server bereitgestellt. Dadurch verhält es sich vermutlich anders als die anderen Attribute.

Macht es einen Unterschied, wenn Sie attributes=['memberOf'] hinzufügen?

Könnten Sie ansonsten Testskripte zur Verfügung stellen (listener Modul + erstellen von Testdaten)?

Viele Grüße
Stefan Gohmann

#3

[quote=“Gohmann”]memberOf wird durch ein Overlay Modul im OpenLDAP Server bereitgestellt. Dadurch verhält es sich vermutlich anders als die anderen Attribute.

Macht es einen Unterschied, wenn Sie attributes=['memberOf'] hinzufügen?
[/quote]
Ich habe das eben nochmals ausporbiert. Es macht keinen Unterschied ob wir das Attribut hinzufügen, oder weglassen.

Wir können dafür natürlich ein Testskript/Testdaten erstellen. Wäre es evtl. auch möglich einmal auf das System mit dem Fehler zu schauen? Vom Kunden haben wir dafür das Okay, und ich weiß nicht ob wir das Verhalten (2 Gruppen gehen nicht, eine Gruppe funktioniert) auf einem Testsystem nachgestellt bekomme. [/quote]

#4

[quote=“digitec-san”]
Wir können dafür natürlich ein Testskript/Testdaten erstellen. Wäre es evtl. auch möglich einmal auf das System mit dem Fehler zu schauen? Vom Kunden haben wir dafür das Okay, und ich weiß nicht ob wir das Verhalten (2 Gruppen gehen nicht, eine Gruppe funktioniert) auf einem Testsystem nachgestellt bekomme. [/quote]
Mein Ziel wäre es eigentlich festzustellen, ob es ein generisches Problem oder ein spezifisches Problem der Umgebung ist. Von daher wäre ein Testskript oder eine Anleitung hilfreich.

Vielleicht könnten Sie auch nochmal das eigentliche Ziel beschreiben. Falls es tatsächlich an der Overlay-Implementierung liegt, dann wäre es vielleicht einfacher die Logik des Listener-Moduls zu ändern.

Viele Grüße
Stefan Gohmann

#5

Hallo Herr Gohmann,
Unser Ziel ist es mehere SugarCRM Instanzen auf einem Rechner zu betreiben. Z.B. wenn eine Holding mehrere Unternehmen hat und die EDV zentral bei der Holding betrieben wird. Der Benutzer soll, z.B. durch eine UCR Variable festlegen können, welche Benutzer auf welches SugarCRM zugreifen sollen.

Also z.B.

filter="(&(objectClass=digitecSugarCRM)(memberOf=cn=Firma1,dc=firma,dc=local))" für die erste SugarCRM Instanz und:

filter="(&(objectClass=digitecSugarCRM)(memberOf=cn=Firma2,dc=firma,dc=local))" für die zweite SugarCRM Instanz.

Uns ist klar, das es auch andere Möglichkeiten gibt das zu umschiffen (z.B. am Benutzerobjekt die CRM Instanz in der LDAP zu speichern), aber wir finden gerade diesen generischen Ansatz ganz gut (das der Kunde den Filter selbst festlegen kann). In einem anderen Fall, wo der Kunde die CRM Systeme evtl. nach Regionen sortieren möchte könnte der Filter wieder anders lauten, z.B.:

filter="(&(objectClass=digitecSugarCRM)(st=Niedersachsen))"

Ich werde Ihnen Beispieldaten liefern.

Viele Grüße
Sven Anders

#6

Hallo Herr Gohmann,

wir haben jetzt Beispielskripte, die ich im Anhang an diesen Beitrag angefügt habe.

Sie sollten auf jedem UCS System lauffähig sein, welches ein memberOf Overlay konfiguriert hat.

Der Filter in den Listenern sind für die Gruppen noch entsprechend der DN anzupassen.

Die Listener sind im Prinzip (Parameter und Name geändert) die Beispiellistener aus dem Univention-Wiki (und legen unter /tmp jeweils eine Datei an).

Ich habe die Skripte auf einem UCS 3.1 System erfolgreich testen können (das Problem taucht nicht auf).

Auf einem UCS 3.0 System (mit relativ aktuellen Patchstand, in 2013 aktualisiert), tritt das Problem auf.

Der ListenerNOGROUP ist nur zum testen gedacht und verwendet kein memberOf Attribut.

Hier haben wir unter UCS 3.0 einen interessanten Punkt beobachtet:

Der Filter in LDAP Listener ist für das Attribut “sn” Case Senstive, während der
univention-ldapsearch den Benutzer in Groß und Kleinschreibung findet. Evtl. tritt bei memberOf ja ein ähnliches Problem auf.

Viele Grüße von der Elbe an die Weser

Sven Anders
digitec-memberof-listener-example.tar.gz (1.81 KB)

#7

Hallo Herr Gohmann,
haben Sie meine letzten Beitrag gesehen? Gibt es neue Erkenntnisse?

Viele Grüße

Sven Anders

#8

Noch nicht, ich hoffe ich komme diese Woche dazu.

Viele Grüße
Stefan Gohmann

#9

Ich habe es jetzt auf einem Testsystem getestet (UCS 3.1):

#!/bin/bash

tar -C / -xzvf digitec-memberof-listener-example.tar.gz

eval $(ucr shell)

for file in /usr/lib/univention-directory-listener/system/listener*.py; do
    sed -i "s|dc=ucs3dev,dc=local|$ldap_base|g" $file
done

ucr set listener/debug/level='4' 

invoke-rc.d univention-directory-listener restart

/create-user.sh
sleep 20

for f in /tmp/UserListA.txt /tmp/UserListB.txt /tmp/UserListC.txt /tmp/UserListNOGROUP.txt; do
    echo "*** $f"
    cat $f
done

Die Ausgabe sieht soweit ich das jetzt verstanden habe OK aus:

root@master501:~# tar -C / -xzvf digitec-memberof-listener-example.tar.gz
usr/lib/univention-directory-listener/system/listenerA.py
usr/lib/univention-directory-listener/system/listenerB.py
usr/lib/univention-directory-listener/system/listenerC.py
usr/lib/univention-directory-listener/system/listenerNOGROUP.py
create-user.sh
remove-user.sh
root@master501:~# 
root@master501:~# eval $(ucr shell)
root@master501:~# 
root@master501:~# for file in /usr/lib/univention-directory-listener/system/listener*.py; do
>     sed -i "s|dc=ucs3dev,dc=local|$ldap_base|g" $file
> done
root@master501:~# 
root@master501:~# ucr set listener/debug/level='4' 
Setting listener/debug/level
File: /etc/runit/univention-directory-listener/run
root@master501:~# 
root@master501:~# invoke-rc.d univention-directory-listener restart
Restarting univention-directory-listener daemon.
ok: run: univention-directory-listener: (pid 2806) 0s, normally down
done.
root@master501:~# 
root@master501:~# /create-user.sh
I=1
Object created: uid=user1,dc=deadlock50,dc=local
I=2
Object created: uid=user2,dc=deadlock50,dc=local
I=3
Object created: uid=user3,dc=deadlock50,dc=local
I=4
Object created: uid=user4,dc=deadlock50,dc=local
I=5
Object created: uid=user5,dc=deadlock50,dc=local
Object created: cn=gruppeA,dc=deadlock50,dc=local
Object created: cn=gruppeB,dc=deadlock50,dc=local
Object created: cn=gruppeC,dc=deadlock50,dc=local
root@master501:~# 
root@master501:~#  sleep 20
root@master501:~# 
root@master501:~# for f in /tmp/UserListA.txt /tmp/UserListB.txt /tmp/UserListC.txt /tmp/UserListNOGROUP.txt; do
>     echo "*** $f"
>     cat $f
> done
*** /tmp/UserListA.txt
Name: "user User1"
User: "user1"
UID: "2017"
        added
Name: "user User2"
User: "user2"
UID: "2018"
        added
*** /tmp/UserListB.txt
Name: "user User1"
User: "user1"
UID: "2017"
        added
Name: "user User3"
User: "user3"
UID: "2019"
        added
*** /tmp/UserListC.txt
Name: "user User1"
User: "user1"
UID: "2017"
        added
Name: "user User4"
User: "user4"
UID: "2020"
        added
Name: "user User5"
User: "user5"
UID: "2021"
        added
*** /tmp/UserListNOGROUP.txt
Name: "user User1"
User: "user1"
UID: "2017"
        added

Ich bräuchte einen Testfall, der fehl schlägt, um die Ursache weiter debuggen zu können.

Ansonsten ja, die Filter im Listener sind Case-Sensitive.

Viele Grüße
Stefan Gohmann

#10

[quote=“Gohmann”]Ich habe es jetzt auf einem Testsystem getestet (UCS 3.1):
…
Ich bräuchte einen Testfall, der fehl schlägt, um die Ursache weiter debuggen zu können.
[/quote]

Ich vermute, die Test schlafgen bei UCS 3.0 fehlt. Zumindest war das bei uns so:

Viele Grüße

Sven Anders

#11

Wir haben mit UCS 3.1 einiges im Listener verbessert und angepasst, WebSVN-Link. Ein Rückportierung von den Anpassungen ist derzeit nicht geplant, dafür sind die Issues nicht kritisch genug.

In dem ursprünglichen Beitrag stand, dass Sie das Problem auch mit UCS 3.1 reproduzieren konnten. Wenn Sie dafür ein Testskript liefern können, dann schaue ich mir das gerne an.

Viele Grüße
Stefan Gohmann

Mastodon