openldap und memberof

Z

ziulmem1

New Member
Hallo,

ich hab folgendes Problem mit einen Openldap 2.4.20 unter SLS 11 und der memberof-Funktion.

Folgende Grundlage,
die slapd.conf wurde erweitert mit

moduleload memberof.la
overlay memberof

Ldap neu gestartet.
Nur wurde mit dem Apache Direktory Studio die Gruppen und User wie im Beispiel auf der Seite http://www.openldap.org/doc/admin24/overlays.html
eingerichtet / oder auch in einem weiteren Versuch ganz normale User und Gruppen.
Das Problem:
Ich trage in die Gruppen die member mit vollen dn ein:
uid=test1,ou=people,o=UKT_NS

Wenn ich jetzt mit
ldapsearch -LL -Y EXTERNAL -H ldapi:/// "(uid=*)" -b o=UKT_NS memberOf
den ldap durchsuche, erhalte ich als Ergebnis die User, allerdings ohne die member.

Zufällig hab ich dann bei einem User direkt einen memberof attribut hinzugefügt, dabei erhielt ich in der Ausgabe mit dem User dann auch:
memberOf: cn=group1,ou=group,o=UKT_NS

Vie kann man sich das Erklären?
Eigentlich dachte ich, wenn in der Gruppe die Mitgliedschaft eingetragen ist, dann wird das über die ldap-suche und der Erweiterung memberof overlay funktionieren.
Bitte um hilfreiche Tipps und Tricks.

Viele Dank
Michael
 
Stopp,

im Beispiel ist gezeigt, dass im in einem Gruppenobject ( mit groupofNames ) member hinzufüge mir meber: dn des Members,
und dann soll ich in einre ldap-Abfrage mit memberof auch diese Gruppenzugehörigkeit sehen. Das ist aber nicht so, ich sehe nix.

Andersrum, ich nehm einem User, und sagt dem direkt memberof und verweise auf die Gruppe DN, dann erhalte ich ein Ergebnis, aber : Ich sehe nichtdie Mitglieder in dem Gruppenobject mit Groupofnames.

Viele Grüße

Michael
 
ziulmem1 said:
Andersrum, ich nehm einem User, und sagt dem direkt memberof und verweise auf die Gruppe DN, dann erhalte ich ein Ergebnis, aber : Ich sehe nichtdie Mitglieder in dem Gruppenobject mit Groupofnames.
Click to expand...
Anhand eines konkreten Beispiels aus deinem DIT heißt das was?
 
Mein Beispiel LDAP:

version: 1

dn: o=UKT_NS
objectClass: organization
o: UKT_NS

dn: ou=people,o=UKT_NS
objectClass: top
objectClass: organizationalUnit
ou: people

dn: ou=group,o=UKT_NS
objectClass: top
objectClass: organizationalUnit
ou: group

dn: cn=internet,ou=group,o=UKT_NS
objectClass: top
objectClass: posixGroup
objectClass: groupOfNames
cn: internet
gidNumber: 5001
member: uid=testuser1,ou=people,o=UKT_NS

dn: uid=testuser1,ou=people,o=UKT_NS
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
cn: Test User
gidNumber: 100
homeDirectory: /export/home/aaaxtman
sn: User
uid: testuser1
uidNumber: 1000
employeeNumber: 9067
givenName: Test
loginShell: /bin/bash
mail: Test.User@med.uni-tuebingen.de

Die Ldap-Suche ergibt:
ldapsearch -LL -Y EXTERNAL -H ldapi:/// "(uid=*)" -b ou=people,o=UKT_NS memberOf

dn: uid=testuser1,ou=people,o=UKT_NS

Sollte nach meinem Verständnis aber auch noch ausgeben: ( was leider nicht geht )
memberOf: cn=internet,ou=group,o=UKT_NS


Vielen Dank
Michael
 
Last edited by a moderator:
Steht die overlay Anweisung innerhalb einer konkreten database-Sektion? So wie ich das lese, geht dieses Overlay nicht als globale Funktion.

Ansonsten: du änderst die Mitglieder der Gruppe erst nachdem diese User angelegt wurden? Dein Beispiel enthält nämlich zunächst die Gruppe mit dem member-Attribut und dann erst den darin referenzierten User.
 
@Roger Wilco: memberOf ist ein Overlay, da wird dem User kein Attribut angehängt - es ist nur eine Invertierung bei der Abfrage der Gruppenmitgliedschaft. Das ist beim OP schon richtig.

Ich denke aber, dass die LDAP Query falsch formuliert ist. memberOf gehört in den Filter:
Code: 
ldapsearch -LL "(&(objectClass=inetOrgPerson)(memberOf=cn=mygroup,ou=groups,dc=my-domain,dc=tld))"
 
"Geht nicht" ist keine brauchbare Fehlerbeschreibung. Was geht nicht? Was für eine Meldung bekommst Du?

Also Dein DIT sieht für mich soweit in Ordnung aus - vorausgesetzt, der Dump wurde mit slapcat erzeugt. Wie sieht denn nun Deine slapd.conf aus?
 
Meine slapd.conf

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/yast.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

# Load dynamic backend modules:
modulepath /usr/lib/openldap/modules
moduleload memberof.la

# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access to user password
# Allow anonymous users to authenticate
# Allow read access to everything else
# Directives needed to implement policy:
access to dn.base=""
by * read

access to dn.base="cn=Subschema"
by * read

access to attrs=userPassword,userPKCS12
by self write
by * auth

access to attrs=shadowLastChange
by self write
by * read

access to *
by * read

# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# BDB database definitions
#######################################################################

database bdb
suffix "dc=my-domain,dc=com"
checkpoint 1024 5
cachesize 10000
rootdn "cn=Manager,dc=my-domain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain
index objectClass eq
index uid,cn,mail,member,sn,manager eq

overlay memberof
memberof-group-oc groupOfNames
memberof-member-ad member
memberof-memberof-ad memberOf
memberof-refint true


über die Suche
ldapsearch -x -b "ou=people,o=UKT_NS" '(uid=aa*)' memberOf

erhalte ich zwar ein Ergebnis, aber leider keine Gruppenzugehörigkeit:

# extended LDIF
#
# LDAPv3
# base <ou=people,o=UKT_NS> with scope subtree
# filter: (uid=aa*)
# requesting: memberOf
#

# aaaxtman, people, UKT_NS
dn: uid=testuser1,ou=people,o=UKT_NS

was Fehlt: memberOf: cn=internet,ou=group,o=UKT_NS

Danke
Im Prinzip die Grundfunktion, die auf
http://www.openldap.org/doc/admin24/overlays.html unter Reverse Group Membership Maintenance beschrieben ist - funktioniert leider bei mir nicht.
Das einzige, was ich nicht habe: die Datei memberof.la im modulepath ist nicht vorhanden, bin mir aber nicht sicher, ob diese al Datei tatsächlich benötigt wird - unter SLES hab ich keine Möglichkeit, solch eine Datei zu erhalten.
 
Deine slapd.conf sieht für mich erst mal richtig aus (memberof ist seit einer der 2.4er Unterversionen nicht mehr als static library dabei, das hat aber keine Auswirkungen auf die Konfiguration)

Werde heute abend noch mal Deine Query zerlegen, komme hier grade nicht an eine Shell ran :-(

Kannst Du denn memberof als Bestandteil eines Filters verwenden, oder bekommst Du dann eine Fehlermeldung? (das würde darauf hindeuten, dass Dein Server memberof nicht korrekt aktiviert hat).
 
Vielen Dank im voraus für Deine Mühen,

einen Fehler erhalte ich bei dieser Abfrage nicht.

Die Abfrage mit:
ldapsearch -LL "(&(objectClass=*)(memberOf=cn=internet,ou=group,o=UKT_NS))"

bringt die Meldung:
ldap_sasl_interactive_bind_s: No such attribute (16)
 
ziulmem1 said:
Die Abfrage mit:
ldapsearch -LL "(&(objectClass=*)(memberOf=cn=internet,ou=group,o=UKT_NS))"

bringt die Meldung:
ldap_sasl_interactive_bind_s: No such attribute (16)
Click to expand...
OK, mein Fehler - der Authentifizierungsmechanismus war nicht angegeben. Du kannst ldapsearch entweder mit simple auth benutzen:
Code: 
ldapsearch -xwD cn=Manager,dc=my-domain,dc=com -LL <filter>
Oder Du verwendest (wie in der von Dir weiter oben geposteten Abfrage) einen SASL-Mechanismus:
Code: 
ldapsearch -Y EXTERNAL -H ldapi:/// <filter>

Bei mir führt übrigens folgende Abfrage zum Erfolg:
Code: 
ldapsearch -LL -ZZ -Wx -D cn=Manager,dc=my-domain,dc=com -b "ou=people,dc=my-domain,dc=com" '(uid=abc)' memberOf

Das Ergebnis sieht in etwa so aus:
Code: 
dn: uid=abc,ou=people,dc=my-domain,dc=com
memberOf: cn=gruppe1,ou=groups,dc=my-domain,dc=com
memberOf: cn=gruppe2,ou=groups,dc=my-domain,dc=com
Mit einer Wildcard für die uid klappt's natürlich auch.

An Deiner Konfiguration ist mir noch aufgefallen, dass Du in der moduleload-Direktive die Dateiendung ".la" mit rangehängt hast - ich hab die Endung immer weggelassen. Außerdem fehlt in der slapd.conf bei Dir die backend-Sektion. Hier mal in eingedampfter Form meine slapd.conf (ich verwende allerdings hdb anstelle von bdb - Pfade stimmen für SLES natürlich auch nicht):
Code: 
include		/usr/local/etc/openldap/schema/core.schema
include		/usr/local/etc/openldap/schema/cosine.schema
include		/usr/local/etc/openldap/schema/inetorgperson.schema
include		/usr/local/etc/openldap/schema/nis.schema
pidfile		/var/run/openldap/slapd.pid
argsfile	/var/run/openldap/slapd.args
modulepath	/usr/local/libexec/openldap
moduleload	back_bdb
moduleload	back_hdb
moduleload	memberof
moduleload	refint

TLSCertificateFile    /usr/local/etc/ssl/server-cert.pem
TLSCertificateKeyFile /usr/local/etc/ssl/server-key.pem
TLSCACertificateFile  /usr/local/etc/ssl/root.pem
TLSVerifyClient       allow

access to attrs=userPassword
  by self write
  by * auth
access to *
  by users read
  by anonymous auth

backend		hdb
sizelimit	unlimited

database	hdb
cachesize	10000
suffix		"dc=my-domain,dc=com"
rootdn		"cn=manager,dc=my-domain,dc=com"
rootpw		{SSHA}=geheimeszeugs=
directory	/var/lib/openldap
index		objectClass eq
overlay		memberof
 
Hallo und vielen Dank für die Mühe.
Ich hab jetzt herausgefunden, dass die slapd.conf bei mir nicht mehr gelesen wird, sondern dann diese Version die Config unter slapd.d/cn=config abgelegt ist.
Dort hab ich mit hilfe weiterer Seiten aus dem Netz die memberof Funktion erhalten.

Viele Grüße
ziulmem1
 
You must log in or register to reply here.
Back
Top