PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : LDAP, SASL: Proxu User Authentifizierung geht nicht



knoppsie
14.12.07, 15:04
Hallo zusammen,

ich arbeite mal wieder am LDAP unter Opensuse 10.3. SASL an sich zu konfigurieren ist ja schon recht kompliziert. Die Authentifizierung per Proxy User bekomme ich nicht hin. Im Web gesucht, gefunden und gelesen habe ich schon so vieles. Doch bisher habe ich noch nicht verstanden wie das funktionieren soll. Ich hab das gefuehl zu viel gelesen zu haben. Weswegen ich den Wald vor lauter Baeumen nicht mehr sehe. Nun hoffe ich auf Unterstuetzung.

1. Installiert sind die distributionseigenen Pakete:

linuxhost:/tmp # rpm -qa | egrep 'openldap2|cyrus-sasl'
cyrus-sasl-crammd5-2.1.22-82
openldap2-client-2.3.37-20
cyrus-sasl-otp-2.1.22-82
openldap2-2.3.37-7
cyrus-sasl-plain-2.1.22-82
cyrus-sasl-saslauthd-2.1.22-85
cyrus-sasl-devel-2.1.22-82
cyrus-sasl-ldap-auxprop-2.1.22-85
cyrus-sasl-2.1.22-82
cyrus-sasl-digestmd5-2.1.22-82
openldap2-devel-2.3.37-20
cyrus-sasl-gssapi-2.1.22-82

2. Der SASL Daemon ist konfiguriert:

linuxhost:/tmp # ps -o pid,command -C saslauthd; cat /etc/sasl2/saslauthd.conf; cat /etc/sasl2/slapd.conf
PID COMMAND
16043 /usr/sbin/saslauthd -a ldap -d -n 5 -O /etc/sasl2/saslauthd.conf
16044 /usr/sbin/saslauthd -a ldap -d -n 5 -O /etc/sasl2/saslauthd.conf
16045 /usr/sbin/saslauthd -a ldap -d -n 5 -O /etc/sasl2/saslauthd.conf
16046 /usr/sbin/saslauthd -a ldap -d -n 5 -O /etc/sasl2/saslauthd.conf
16047 /usr/sbin/saslauthd -a ldap -d -n 5 -O /etc/sasl2/saslauthd.conf

# /etc/sasl2/saslauthd.conf
ldap_servers: ldap://127.0.0.1/
ldap_search_base: ou=users,dc=domain,dc=org
ldap_scope: sub
ldap_filter: uid=%u
ldap_use_sasl: yes
ldap_mech: DIGEST-MD5
ldap_auth_method: fastbind
ldap_id: ldap
ldap_authz_id: ldap
ldap_password: ldap

# /etc/sasl2/slapd.conf
pwcheck_method: saslauthd
mech_list: DIGEST-MD5
linuxhost:/tmp #


3. Der Ldap-Server ist konfiguriert. Mehrere User sind angelegt. Zwei mit Klartextpasswort.

linuxhost:/tmp # egrep -v '^$|^#' /etc/openldap/slapd.conf
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
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
modulepath /usr/lib/openldap/modules
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

password-hash {CLEARTEXT}
authz-regexp
uid=([^,]*),cn=digest-md5,cn=auth
ldap:///ou=users,dc=domain,dc=org??one?(uid=$1)
authz-policy any
dn: uid=ldap,ou=users,dc=domain,dc=org
authzTo: ldap:///ou=users,dc=domain,dc=org??sub?(objectclass=posixA ccount)
dn: uid=knops,ou=users,dc=domain,dc=org
authzFrom: ldap:///ou=users,dc=domain,dc=org??sub?(uid=ldap)

referral ldap://192.168.178.8
loglevel 16838
database bdb
suffix "dc=domain,dc=org"
rootdn "cn=ldap,dc=domain,dc=org"
rootpw "secret"
directory /var/lib/ldap/
checkpoint 1024 5
cachesize 10000
index objectClass,uidNumber,gidNumber eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
index automountMapName eq
linuxhost:/tmp #

4.Ldapsearch funktioniert mit SASL:


linuxhost:/tmp # ldapsearch "(|(uid=ldap)(uid=knops))" -LLL
SASL/DIGEST-MD5 authentication started
Please enter your password:
SASL username: ldap
SASL SSF: 128
SASL installing layers
dn: uid=ldap,ou=users,dc=domain,dc=org
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: extensibleObject
userPassword:: bGRhcA==
cn: ldap
uid: ldap
uidNumber: 76
gidNumber: 70
homeDirectory: /var/lib/ldap
loginShell: /bin/bash
sn: ldap

dn: uid=knops,ou=users,dc=domain,dc=org
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: shadowAccount
cn: knops
uid: knops
uidNumber: 30035
gidNumber: 100
homeDirectory: /home/knops
loginShell: /bin/bash
sn: knops
shadowLastChange: 13839
shadowMin: 0
shadowMax: 99999
shadowWarning: 7

linuxhost:/tmp #


5. ldapwhoami nicht:

linuxhost:/tmp # date; ldapwhoami -U ldap -X u:knops
Fri Dec 14 14:35:54 CET 2007
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Insufficient access (50)
additional info: SASL(-14): authorization failure: not authorized

linuxhost:/tmp # egrep '^Dec 14 14:35:5' /var/log/messages
Dec 14 14:35:54 linuxhost slapd[31379]: conn=37 fd=19 ACCEPT from IP=127.0.0.1:57350 (IP=0.0.0.0:389)
Dec 14 14:35:54 linuxhost slapd[31379]: connection_get(19)
Dec 14 14:35:54 linuxhost slapd[31379]: conn=37 op=0 BIND dn="" method=163
Dec 14 14:35:54 linuxhost slapd[31379]: ==> sasl_bind: dn="" mech=DIGEST-MD5 datalen=0
Dec 14 14:35:54 linuxhost ldapwhoami: DIGEST-MD5 client step 2
Dec 14 14:35:54 linuxhost slapd[31379]: conn=37 op=0 RESULT tag=97 err=14 text=
Dec 14 14:35:56 linuxhost ldapwhoami: DIGEST-MD5 client step 2
Dec 14 14:35:56 linuxhost slapd[31379]: connection_get(19)
Dec 14 14:35:56 linuxhost slapd[31379]: conn=37 op=1 BIND dn="" method=163
Dec 14 14:35:56 linuxhost slapd[31379]: ==> sasl_bind: dn="" mech=<continuing> datalen=297
Dec 14 14:35:56 linuxhost slapd[31379]: SASL Canonicalize [conn=37]: authcid="ldap"
Dec 14 14:35:56 linuxhost slapd[31379]: slap_sasl_getdn: conn 37 id=ldap [len=4]
Dec 14 14:35:56 linuxhost slapd[31379]: bdb_idl_fetch_key: %ou=users,dc=domain,dc=org
Dec 14 14:35:56 linuxhost slapd[31379]: bdb_idl_fetch_key: [b49d1940]
Dec 14 14:35:56 linuxhost slapd[31379]: bdb_idl_fetch_key: [0ee1be42]
Dec 14 14:35:56 linuxhost slapd[31379]: => access_allowed: auth access to "uid=ldap,ou=users,dc=domain,dc=org" "uid" requested
Dec 14 14:35:56 linuxhost slapd[31379]: => dn: [1]
Dec 14 14:35:56 linuxhost slapd[31379]: => dn: [2] cn=subschema
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_get: [5] attr uid
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_mask: access to entry "uid=ldap,ou=users,dc=domain,dc=org", attr "uid" requested
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_mask: to value by "", (=0)
Dec 14 14:35:56 linuxhost slapd[31379]: <= check a_dn_pat: *
Dec 14 14:35:56 linuxhost slapd[31379]: <= acl_mask: [1] applying read(=rscxd) (stop)
Dec 14 14:35:56 linuxhost slapd[31379]: <= acl_mask: [1] mask: read(=rscxd)
Dec 14 14:35:56 linuxhost slapd[31379]: => access_allowed: auth access granted by read(=rscxd)
Dec 14 14:35:56 linuxhost slapd[31379]: send_ldap_result: err=0 matched="" text=""
Dec 14 14:35:56 linuxhost slapd[31379]: SASL Canonicalize [conn=37]: slapAuthcDN="uid=ldap,ou=users,dc=domain,dc=org"
Dec 14 14:35:56 linuxhost slapd[31379]: SASL [conn=37] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory
Dec 14 14:35:56 linuxhost syslog-ng[8399]: last message repeated 2 times
Dec 14 14:35:56 linuxhost slapd[31379]: base_candidates: base: "uid=ldap,ou=users,dc=domain,dc=org" (0x00000004)
Dec 14 14:35:56 linuxhost slapd[31379]: => access_allowed: auth access to "uid=ldap,ou=users,dc=domain,dc=org" "objectClass" requested
Dec 14 14:35:56 linuxhost slapd[31379]: => dn: [1]
Dec 14 14:35:56 linuxhost slapd[31379]: => dn: [2] cn=subschema
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_get: [5] attr objectClass
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_mask: access to entry "uid=ldap,ou=users,dc=domain,dc=org", attr "objectClass" requested
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_mask: to all values by "", (=0)
Dec 14 14:35:56 linuxhost slapd[31379]: <= check a_dn_pat: *
Dec 14 14:35:56 linuxhost slapd[31379]: <= acl_mask: [1] applying read(=rscxd) (stop)
Dec 14 14:35:56 linuxhost slapd[31379]: <= acl_mask: [1] mask: read(=rscxd)
Dec 14 14:35:56 linuxhost slapd[31379]: => access_allowed: auth access granted by read(=rscxd)
Dec 14 14:35:56 linuxhost slapd[31379]: => access_allowed: auth access to "uid=ldap,ou=users,dc=domain,dc=org" "userPassword" requested
Dec 14 14:35:56 linuxhost slapd[31379]: => dn: [1]
Dec 14 14:35:56 linuxhost slapd[31379]: => dn: [2] cn=subschema
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_get: [3] attr userPassword
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_mask: access to entry "uid=ldap,ou=users,dc=domain,dc=org", attr "userPassword" requested
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_mask: to all values by "", (=0)
Dec 14 14:35:56 linuxhost slapd[31379]: <= check a_dn_pat: self
Dec 14 14:35:56 linuxhost slapd[31379]: <= check a_dn_pat: *
Dec 14 14:35:56 linuxhost slapd[31379]: <= acl_mask: [2] applying auth(=xd) (stop)
Dec 14 14:35:56 linuxhost slapd[31379]: <= acl_mask: [2] mask: auth(=xd)
Dec 14 14:35:56 linuxhost slapd[31379]: => access_allowed: auth access granted by auth(=xd)
Dec 14 14:35:56 linuxhost slapd[31379]: send_ldap_result: err=0 matched="" text=""
Dec 14 14:35:56 linuxhost slapd[31379]: SASL Canonicalize [conn=37]: authzid="u:knops"
Dec 14 14:35:56 linuxhost slapd[31379]: slap_sasl_getdn: conn 37 id=u:knops [len=7]
Dec 14 14:35:56 linuxhost slapd[31379]: bdb_idl_fetch_key: %ou=users,dc=domain,dc=org
Dec 14 14:35:56 linuxhost slapd[31379]: bdb_idl_fetch_key: [b49d1940]
Dec 14 14:35:56 linuxhost slapd[31379]: bdb_idl_fetch_key: [067af5d3]
Dec 14 14:35:56 linuxhost slapd[31379]: => access_allowed: auth access to "uid=knops,ou=users,dc=domain,dc=org" "uid" requested
Dec 14 14:35:56 linuxhost slapd[31379]: => dn: [1]
Dec 14 14:35:56 linuxhost slapd[31379]: => dn: [2] cn=subschema
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_get: [5] attr uid
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_mask: access to entry "uid=knops,ou=users,dc=domain,dc=org", attr "uid" requested
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_mask: to value by "", (=0)
Dec 14 14:35:56 linuxhost slapd[31379]: <= check a_dn_pat: *
Dec 14 14:35:56 linuxhost slapd[31379]: <= acl_mask: [1] applying read(=rscxd) (stop)
Dec 14 14:35:56 linuxhost slapd[31379]: <= acl_mask: [1] mask: read(=rscxd)
Dec 14 14:35:56 linuxhost slapd[31379]: => access_allowed: auth access granted by read(=rscxd)
Dec 14 14:35:56 linuxhost slapd[31379]: send_ldap_result: err=0 matched="" text=""
Dec 14 14:35:56 linuxhost slapd[31379]: SASL Canonicalize [conn=37]: slapAuthzDN="uid=knops,ou=users,dc=domain,dc=org"
Dec 14 14:35:56 linuxhost slapd[31379]: SASL proxy authorize [conn=37]: authcid="ldap" authzid="u:knops"
Dec 14 14:35:56 linuxhost slapd[31379]: => bdb_entry_get: ndn: "uid=ldap,ou=users,dc=domain,dc=org"
Dec 14 14:35:56 linuxhost slapd[31379]: => bdb_entry_get: oc: "(null)", at: "authzTo"
Dec 14 14:35:56 linuxhost slapd[31379]: => bdb_entry_get: found entry: "uid=ldap,ou=users,dc=domain,dc=org"
Dec 14 14:35:56 linuxhost slapd[31379]: => access_allowed: auth access to "uid=ldap,ou=users,dc=domain,dc=org" "authzTo" requested
Dec 14 14:35:56 linuxhost slapd[31379]: => dn: [1]
Dec 14 14:35:56 linuxhost slapd[31379]: => dn: [2] cn=subschema
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_get: [5] attr authzTo
Dec 14 14:35:56 linuxhost slapd[31379]: access_allowed: no res from state (authzTo)
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_mask: access to entry "uid=ldap,ou=users,dc=domain,dc=org", attr "authzTo" requested
Dec 14 14:35:56 linuxhost slapd[31379]: => acl_mask: to all values by "", (=0)
Dec 14 14:35:56 linuxhost slapd[31379]: <= check a_dn_pat: *
Dec 14 14:35:56 linuxhost slapd[31379]: <= acl_mask: [1] applying read(=rscxd) (stop)
Dec 14 14:35:56 linuxhost slapd[31379]: <= acl_mask: [1] mask: read(=rscxd)
Dec 14 14:35:56 linuxhost slapd[31379]: => access_allowed: auth access granted by read(=rscxd)
Dec 14 14:35:56 linuxhost slapd[31379]: => bdb_entry_get: ndn: "uid=knops,ou=users,dc=domain,dc=org"
Dec 14 14:35:56 linuxhost slapd[31379]: => bdb_entry_get: oc: "(null)", at: "authzFrom"
Dec 14 14:35:56 linuxhost slapd[31379]: => bdb_entry_get: found entry: "uid=knops,ou=users,dc=domain,dc=org"
Dec 14 14:35:56 linuxhost slapd[31379]: SASL [conn=37] Failure: not authorized
Dec 14 14:35:56 linuxhost slapd[31379]: send_ldap_result: err=50 matched="" text="SASL(-14): authorization failure: not authorized"
Dec 14 14:35:56 linuxhost slapd[31379]: conn=37 op=1 RESULT tag=97 err=50 text=SASL(-14): authorization failure: not authorized
Dec 14 14:35:56 linuxhost slapd[31379]: connection_get(19)
Dec 14 14:35:56 linuxhost slapd[31379]: conn=37 fd=19 closed (connection lost)



Was ich nun vorhabe ist folgendes.
- Den User ldap moechte ich mit Klartextpasswort in der Datenbank belassen.
- Alle anderen User moechte ich moeglichst mit verschluesseltem Passwort in der Datenbank vorhalten.
Die User sollten nun z. B. die Moeglichkeit haben ihr Ldappasswort aendern koennen.

Die Fragen sind nun.
- Kann ich das mit dem Proxyuser realisieren?
- Muss ich das mit dem Proxyuser realisieren?
- Wie funktionert das mit dem Proxyuser ueberhaupt?
- Wie muss die Konfiguration aussehen, damit das ldapwhoami klappt?

403
15.12.07, 07:48
Hrmm,

also von Postfix weiss ich noch dass sich Plaintext Passwoerter und Shared-Secret mechanisms (digest-md5) nicht moegen.

Folgende Sachen wuerde ich jetzt mal nachgoogeln:

send_ldap_result: err=0 matched="" text=""

access_allowed: no res from state (authzTo)

bdb_entry_get: oc: "(null)", at: "authzTo"

Ich sehe bei dir jetzt auch kein authzTo.


http://www.openldap.org/doc/admin24/sasl.html#Mapping%20Authentication%20Identities
http://www.openldap.org/lists/openldap-software/200508/msg00097.html

Gruss 403

knoppsie
19.12.07, 11:01
@403: Vielen Dank fuer Deine Hilfe, hab das Problem loesen koennen. Einige Tage Abstand helfen doch immer wieder die Uebersicht wiederzuerlangen.

Was habe ich konfiguriert? Wie funktioniert es?

Die kurze Version:
1.


vm-john:/tmp # egrep -A13 '^#authz-policy' /etc/openldap/slapd.conf
#authz-policy <policy>
# Used to specify which rules to use for Proxy Authorization. Proxy
# authorization allows a client to authenticate to the server using
# one user's credentials, but specify a different identity to use for
# authorization and access control purposes.
...
...
#The all flag requires both
# authorizations to succeed.
authz-policy to

2.


vm-john:/tmp # egrep -A9 '^#authz-regexp' /etc/openldap/slapd.conf
#authz-regexp <match> <replace>
# Used by the authentication framework to convert simple user names,
# such as provided by SASL subsystem, to an LDAP DN used for
# authorization purposes.
...
...
# and MECHANISM are taken, when available, and combined into a name of the form
authz-regexp
uid=([^,]*),cn=digest-md5,cn=auth
ldap:///ou=users,dc=abaqus,dc=de??one?(uid=$1)

3.


dn: uid=ldap,ou=users,dc=domain,dc=org
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: extensibleObject
userPassword:: bGRhcA==
cn: ldap
uid: ldap
uidNumber: 76
gidNumber: 70
homeDirectory: /var/lib/ldap
loginShell: /bin/bash
sn: ldap
authzTo: ldap:///ou=users,dc=domain,dc=org??sub?(objectclass=posixA ccount)

Damit bin ich nun in der Lage mittels eines Proxyusers (namentlich ldap) andere User zu authentifizieren.
4.


vm-john:/tmp # date; ldapwhoami -U ldap -X u:knops -Y DIGEST-MD5
Wed Dec 19 10:09:16 CET 2007
SASL/DIGEST-MD5 authentication started
Please enter your password:
SASL username: u:knops
SASL SSF: 128
SASL installing layers
dn:uid=knops,ou=users,dc=domain,dc=org
Result: Success (0)
vm-john:/tmp #

Das funktioniert auch bei User mit verschluesseltem Passwort.
5.


vm-john:/tmp # date; ldapwhoami -U ldap -X u:vello -Y DIGEST-MD5
Wed Dec 19 10:11:34 CET 2007
SASL/DIGEST-MD5 authentication started
Please enter your password:
SASL username: u:vello
SASL SSF: 128
SASL installing layers
dn:uid=vello,ou=users,dc=domain,dc=org
Result: Success (0)
vm-john:/tmp #


Die lange Version:
- Was geht bei Proxy Authorisierung vor?
Der Ldap Server bietet die Proxy Authorisierung. Diese ermoeglicht z. B. sich als User A gegenueber dem Ldap-Server zutritt zu verschaffen. Sofern der Zutritt dann gewaehrt wurde kann User A eine Authentifizierung als User B anfordern. Zur Verifizierung muss User sein eigenes Passwort angeben, nicht das von User B! Wird die Authentifizierung vom Ldap Server angenommen wechselt User A seine Identitaet gegenueber dem Server zu User B.
- Wieso das ganze?
Die SASL Authentifizierung bietet den Mechanismus DIGEST-MD5. Dieser wiederum setzt allerdings Passwoerter in Klarschrift in der Ldap-Datenbank vor. Mir wiederum war das ein Negativpunkt. Fuer alle User wollte ich das haben. Fuer einen Systemuser lass ich das noch durchgehen. Hier greift die Proxy Authorisierung. Ich kann mir mittels des Systemusers Zutritt verschaffen und dann auf einen anderen User umschwenken, zum Beispiel bei der Passwortaenderung.

Soweit der Mechanismus. Jetzt muss das ganze noch umgesetzt werden.
Die Proxy Authorisierung ist in Openldap standardmaessig abgeschaltet. Aktiviert wird sie mittels der Zeile authz-policy in der Konfigurationsdatei ./slapd.conf.
Hierfuer muss man sich allerdings erst einmal fuer die Policy entscheiden. Man hat drei Wege.
1. Man erlaubt dem User A sich als andere User auszuweisen.
2. Man erlaubt anderen Usern sich als User A Zutritt zu verschaffen.
3. Man erlaubt beides.
Variante B hat den Vorteil, dass man explizit angeben kann, welche User die Authentifizierungsart nutzen duerfen. Sprich die Auswahl ist feinmaschiger. Dafuer muss allerdings fuer jeden Auserwaehlten ein entsprechendes Attribut in sein Ldap-Profli hinterlegt werden.
Variante A hat den Vorteil dass man nur User A ein Attribut in seinem Ldap-Profil hinterlegt. Allerdings wird die Erlaubnis umso grobmaschiger.
Ich hab mich erst einmal fuer Variante A entschieden. Wegen des Replikationsverfahrens.
Punkt 1. zeigt den Eintrag fuer die Policy.
Die letzte Zeile von Punkt 3. zeigt den Eintrag der dem User ldap das Recht gibt, sich als andere User des Zweiges ou=users,... auszugeben.
Wichtig ist hierbei allerdings auch Punkt 2.. Beim Anklopfen an den Ldap-Server besteht der DN aus dem Schlagwort auth und dem verwendeten Mechanismus. Teilweise taucht auch der sogenannte Realm auf. Dieser ist aus Hostname und Domaine zusammengesetzt. Damit man nun nicht einen entsprechenden Zweig im Ldap-Baum anlegen und pflegen muss, aendert man den DN, entsprechend der Vorgabe in der Daenbank. Hierfuer ist authz-regexp zustaendig. Bei der spaeteren Authorisierung kommt der gleiche Vorgang zum tragen. Dabei wird vom Server die gleiche Regel zurate gezogen.

Der Knackpunkt bei mir war im Endeffekt das authzTo Attribut im Profil. B. Z. W. das authzFrom, wenn man sich fuer Variante B entscheidet. Bisher ging ich davon aus, dass Ldap-Attribute zu ObjectClassen gehoeren. Und alle in den Schemadateien hinterlegt ist. So habe ich mehrmals nach den Attributen in den Schemadateien gesucht. Sowohl mittels grep, als auch ueber GQ und dem Zugriff auf den Server. Doch niemals habe ich die Attribute gefunden. Im Internet fand ich ebenfalls keine Hinweise auf ein entsprechendes Schema. Heute morgen fand ich in einem ldapadministrator forum einen Eintrag. Der Autor erklaert das Attribut nicht sehen zu koennen. Bei der Antwort kam mir dann der Gedanke, dass Attribut, ObjectClasse und Schema nicht unbedingt der Standard ist.
So habe ich die Zeile einfach mittels ldapmodify in das Profil eintragen lassen. Dem Debug Output nach hat der Server das auch ohne zu Knurren angenommen. Bei einem entsprechenden Ldapsearch sieht man ebenfalls nichts.
Doch scheinbar ist die Aenderung angenommen worden.
Denn nun funktioniert es.

MfG
knoppsie

cane
19.12.07, 11:57
Das ist mal wirklich ein gutes Beispiel wie man korrekt und ausführlich Fragen stellt :)

mfg
cane

403
19.12.07, 20:37
Das muss vor allem in die Tipz und Trickz Sektion :D