A warm "Hello" from germany to the openldap-technical list!
I´m rather new to OpenLDAP, using version 2.4.12 on a SLES11 server. I need to write an ACL which allows a user to see his own entry (objectClass build up on inetOrgPerson) and nothing else. I know that this isn´t the intended use of the LDAP system, but our manager wants it that way.
I tried it with somekind of that:
access to dn.regex="uid=([^,]+),dc=justushere,dc=de$" attrs=entry by dn.regex="uid=$1,ou=Users,dc=justushere,dc=de" write by users none
but I just get a message about invalid credentials. Used command was: ldapsearch -xWD uid=user1,ou=users,dc=justushere,dc=de uid=user1
ldapsearch -xWD cn=admin,dc=justushere,dc=de uid=user1 with the rootdn account shows the information, but if the uid of the user1 is used for binding it fails.
Has anyone an idea how to realize these restrictions? Additionally not all attributes should get listed to the user, only a few important for him. My idea was to use a ACL like the above to be sure the user only gets access to his object and then add a second ACL below who restricts the access to the important attributes.
Best regards Florian Götz
--On Thursday, April 30, 2009 11:44 AM +0200 Florian Götz f.goetz@hs-mannheim.de wrote:
A warm "Hello" from germany to the openldap-technical list!
I´m rather new to OpenLDAP, using version 2.4.12 on a SLES11 server. I need to write an ACL which allows a user to see his own entry (objectClass build up on inetOrgPerson) and nothing else. I know that this isn´t the intended use of the LDAP system, but our manager wants it that way.
Have you looked at the "self" keyword?
The keyword self means access to an entry is allowed to the entry itself (e.g. the entry being accessed and the requesting entry must be the same). It allows the level{<n>} style, where _n_ indicates what ancestor of the DN is to be used in matches. A positive value indi- cates that the <n>-th ancestor of the user's DN is to be considered; a negative value indicates that the <n>-th ancestor of the target is to be considered. For example, a "by self.level{1} ..." clause would match when the object "dc=example,dc=com" is accessed by "cn=User,dc=example,dc=com". A "by self.level{-1} ..." clause would match when the same user accesses the object "ou=Address Book,cn=User,dc=example,dc=com".
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Florian Götz f.goetz@hs-mannheim.de writes:
A warm "Hello" from germany to the openldap-technical list!
I´m rather new to OpenLDAP, using version 2.4.12 on a SLES11 server. I need to write an ACL which allows a user to see his own entry (objectClass build up on inetOrgPerson) and nothing else. I know that this isn´t the intended use of the LDAP system, but our manager wants it that way.
I tried it with somekind of that:
access to dn.regex="uid=([^,]+),dc=justushere,dc=de$" attrs=entry by dn.regex="uid=$1,ou=Users,dc=justushere,dc=de" write by users none
but I just get a message about invalid credentials. Used command was: ldapsearch -xWD uid=user1,ou=users,dc=justushere,dc=de uid=user1
According to your ACL's a subtree search is not allowed.
ldapsearch -xWD cn=admin,dc=justushere,dc=de uid=user1 with the rootdn account shows the information, but if the uid of the user1 is used for binding it fails.
Has anyone an idea how to realize these restrictions?
access to dn.regex="^uid=([^,]+),dc=justushere,dc=de$" attrs=entry,more attrs by dn.exact,expand="uid=$1,ou=Users,dc=justushere,dc=de" write by * none
ldapsearch - -xDW -b uid=user1,ou=users,dc=justushere,dc=de -s base should do what you want.
-Dieter
Hi Dieter,
as I was trying to implement your ACL a more fundamental problem arose.
The structure at the moment is dc=justushere,dc=de -> ou= Users -> Some users in here with their data
If I do a ldapsearch with the admin DN I can get all the data from everything I want. The way it should be.
For example: ldapsearch -xWD cn=admin,dc=justushere,dc=de uid=goetzf gives me all the information about my own user.
If I try ldapsearch -xWD uid=goetzf,ou=Users,dc=justushere,dc=de uid=goetzf I get "ldap_bind: Invalid credentials (49)" as answer.
The only ACL left in the system now are the following:
#1 .Publishing subschemas for JXplorer access to dn.base="cn=Subschema" by dn="cn=admin,dc=justushere,dc=de" read
#2. Your ACL, now commented out for testing #access to dn.regex="^uid=([^,]+),dc=justushere,dc=de$" # attrs=entry,sn,cn,userPassword,mail # by dn.exact,expand="uid=$1,ou=Users,dc=justushere,dc=de" write # by * none
#3. Deny any other access access to * by none
I got no clue why I get a "invalid credential" message when using my own password. There are no ACLs restricting access. No matter if I you your ACL above or not, I´m not getting access with my password.
If I just use ACL Nr 1 and another access to * by self read I can´t get any info as well, no matter if i use ldapsearch -xWD uid=goetzf,ou=Users,dc=justushere,dc=de uid=goetzf or even ldapsearch -xWD uid=goetzf,ou=Users,dc=justushere,dc=de uid=goetzf,ou=Users,dc=justushere,dc=de
If I rewrite that to access to * by * read I get all information with my password.
As I mentioned above, I got no more clues how to handle that :(
Florian
On Thursday 30 April 2009 18:27:58 Dieter Kluenter wrote:
Florian Götz f.goetz@hs-mannheim.de writes:
A warm "Hello" from germany to the openldap-technical list!
I´m rather new to OpenLDAP, using version 2.4.12 on a SLES11 server. I need to write an ACL which allows a user to see his own entry (objectClass build up on inetOrgPerson) and nothing else. I know that this isn´t the intended use of the LDAP system, but our manager wants it that way.
I tried it with somekind of that:
access to dn.regex="uid=([^,]+),dc=justushere,dc=de$" attrs=entry by dn.regex="uid=$1,ou=Users,dc=justushere,dc=de" write by users none
but I just get a message about invalid credentials. Used command was: ldapsearch -xWD uid=user1,ou=users,dc=justushere,dc=de uid=user1
According to your ACL's a subtree search is not allowed.
ldapsearch -xWD cn=admin,dc=justushere,dc=de uid=user1 with the rootdn account shows the information, but if the uid of the user1 is used for binding it fails.
Has anyone an idea how to realize these restrictions?
access to dn.regex="^uid=([^,]+),dc=justushere,dc=de$" attrs=entry,more attrs by dn.exact,expand="uid=$1,ou=Users,dc=justushere,dc=de" write by * none
ldapsearch - -xDW -b uid=user1,ou=users,dc=justushere,dc=de -s base should do what you want.
-Dieter
-----
Am Montag 04 Mai 2009 10:32:42 schrieb Florian Götz:
Hi Dieter,
as I was trying to implement your ACL a more fundamental problem arose.
The structure at the moment is dc=justushere,dc=de -> ou= Users -> Some users in here with their data
If I do a ldapsearch with the admin DN I can get all the data from everything I want. The way it should be.
For example: ldapsearch -xWD cn=admin,dc=justushere,dc=de uid=goetzf gives me all the information about my own user.
If I try ldapsearch -xWD uid=goetzf,ou=Users,dc=justushere,dc=de uid=goetzf I get "ldap_bind: Invalid credentials (49)" as answer.
The only ACL left in the system now are the following:
#1 .Publishing subschemas for JXplorer access to dn.base="cn=Subschema" by dn="cn=admin,dc=justushere,dc=de" read
#2. Your ACL, now commented out for testing #access to dn.regex="^uid=([^,]+),dc=justushere,dc=de$" # attrs=entry,sn,cn,userPassword,mail # by dn.exact,expand="uid=$1,ou=Users,dc=justushere,dc=de" write # by * none
#3. Deny any other access access to * by none
I got no clue why I get a "invalid credential" message when using my own password. There are no ACLs restricting access. No matter if I you your ACL above or not, I´m not getting access with my password.
If I just use ACL Nr 1 and another access to * by self read I can´t get any info as well, no matter if i use ldapsearch -xWD uid=goetzf,ou=Users,dc=justushere,dc=de uid=goetzf or even ldapsearch -xWD uid=goetzf,ou=Users,dc=justushere,dc=de uid=goetzf,ou=Users,dc=justushere,dc=de
If I rewrite that to access to * by * read I get all information with my password.
As I mentioned above, I got no more clues how to handle that :(
In order to be able to authenticate using simple bind, you need to have "auth" privileges on the "userPassword" attribute. As none of your ACLs grants that right, your ldapsearch -x.... currently fails with "ldap_bind: Invalid credentials (49)". Please try to add the following ACL as the first in your list:
access to attr=userpassword by self =xw by anonymous auth
Addtionally you should have a look at: http://www.openldap.org/faq/data/cache/320.html and http://www.openldap.org/faq/data/cache/189.html and the admin guide for more information.
[..]
Hi Florian,
Ralf Haferkamp rhafer@suse.de writes:
Am Montag 04 Mai 2009 10:32:42 schrieb Florian Götz:
Hi Dieter,
as I was trying to implement your ACL a more fundamental problem arose.
[...]
As I mentioned above, I got no more clues how to handle that :(
You should probably run slapd in debugging modus, something like slapd -d acl, in order to parse the access control process.
In order to be able to authenticate using simple bind, you need to have "auth"
[...]
-Dieter
Hi Ralf,
that userpassword clause completely got lost on my reading for the first time. Now it´s added and so far working.
Now I can bind with the specific User via UID and start some searches. ACLs look like this now:
# (1) Zugang zum eigenen Passwort. Wichtig, sonst keine Auth möglich !!! access to attrs=userpassword by self write by anonymous auth
# (2) Zugang zu den Subschemas für Admin (erstellen von Einträgen in JXplorer) access to dn.base="cn=Subschema" by dn="cn=admin,dc=justushere,dc=de" read
# (3) Zugang für User zu einigen seiner Profildaten access to dn.regex="uid=(.+),ou=Users,dc=justushere,dc=de$" attrs=cn,description,telephoneNumber,facsimileTelephoneNumber,street,postOfficeBox,postalCode,postalAddress,<cut> by dn.exact="uid=$1,ou=Users,dc=hs-mannheim,dc=de" write by * none
#(4) Restliche Zugriffe verbieten access to * by self write by * none
No matter what I´m searching for, I always get result 32: No such object. The user object itself (at least the attributes listed in ACL 3) should now be read/writeable for the owner. It seems that I can only bind and can´t get any information from the directory, no matter what I´m searching for.
Florian
On Monday 04 May 2009 11:46:44 Ralf Haferkamp wrote:
Am Montag 04 Mai 2009 10:32:42 schrieb Florian Götz:
Hi Dieter,
as I was trying to implement your ACL a more fundamental problem arose.
The structure at the moment is dc=justushere,dc=de -> ou= Users -> Some users in here with their data
If I do a ldapsearch with the admin DN I can get all the data from everything I want. The way it should be.
For example: ldapsearch -xWD cn=admin,dc=justushere,dc=de uid=goetzf gives me all the information about my own user.
If I try ldapsearch -xWD uid=goetzf,ou=Users,dc=justushere,dc=de uid=goetzf I get "ldap_bind: Invalid credentials (49)" as answer.
The only ACL left in the system now are the following:
#1 .Publishing subschemas for JXplorer access to dn.base="cn=Subschema" by dn="cn=admin,dc=justushere,dc=de" read
#2. Your ACL, now commented out for testing #access to dn.regex="^uid=([^,]+),dc=justushere,dc=de$" # attrs=entry,sn,cn,userPassword,mail # by dn.exact,expand="uid=$1,ou=Users,dc=justushere,dc=de" write # by * none
#3. Deny any other access access to * by none
I got no clue why I get a "invalid credential" message when using my own password. There are no ACLs restricting access. No matter if I you your ACL above or not, I´m not getting access with my password.
If I just use ACL Nr 1 and another access to * by self read I can´t get any info as well, no matter if i use ldapsearch -xWD uid=goetzf,ou=Users,dc=justushere,dc=de uid=goetzf or even ldapsearch -xWD uid=goetzf,ou=Users,dc=justushere,dc=de uid=goetzf,ou=Users,dc=justushere,dc=de
If I rewrite that to access to * by * read I get all information with my password.
As I mentioned above, I got no more clues how to handle that :(
In order to be able to authenticate using simple bind, you need to have "auth" privileges on the "userPassword" attribute. As none of your ACLs grants that right, your ldapsearch -x.... currently fails with "ldap_bind: Invalid credentials (49)". Please try to add the following ACL as the first in your list:
access to attr=userpassword by self =xw by anonymous auth
Addtionally you should have a look at: http://www.openldap.org/faq/data/cache/320.html and http://www.openldap.org/faq/data/cache/189.html and the admin guide for more information.
[..]
-----
openldap-technical@openldap.org
-
Dieter Kluenter -
Florian Götz -
Quanah Gibson-Mount -
Ralf Haferkamp