Hello,
I have a working openLDAP server version 2.3.43. My configuration there works : the correct users have the correct access.
I have set up a new openLDAP-server with newer version 2.3.43.
I have no working openLDAP on version 2.3.43.
I have tried with the new syntax and with the command /usr/sbin/slaptest -f /etc/openldap/slapd.conf -v to use the build in converion tool, but I always got : ldap_bind: Invalid credentials (49)
So I forgot this conversion and continued with the "old" slapd.conf file.
But in this configuration (which is just a copy/paste of my openLDAP 2.3.43) no user can query the LDAP entries.
So this is the setup :
I have a user : cn=U101001,ou=101001,dc=mydomain This user is member of the group : cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain These members can read entries in the tree : ou=tbook1,ou=contacten,ou=101001,dc=mydomain
I have in slapd.conf :
access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read
This user cn=U101001,ou=101001,dc=mydomain really exists (if you should doubt) :
# extended LDIF # # LDAPv3 # base <cn=U101001,ou=101001,dc=mydomain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# U101001, 101001, mydomain dn: cn=U101001,ou=101001,dc=mydomain cn: U101001 sn: U101001 objectClass: inetOrgPerson objectClass: top userPassword:: e1NTSEF9OVBTNmltR3ZpUEhzK1JRQVpickNVdVR5cS9Iejg5TzY=
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
The group cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain also really exists (if you should doubt) :
# tbook1, gebruikers, 101001, mydomain dn: cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain cn: tbook1 member: cn=U101001,ou=101001,dc=mydomain objectClass: groupOfNames objectClass: top
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
When I query the LDAP-tree ou=tbook1,ou=contacten,ou=101001,dc=mydomain with my root-account (cn=Manager,dc=mydomain), the I get results :
[root@ldap1 ]# ldapsearch -x -D 'cn=Manager,dc=mydomain' -b "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=tbook1,ou=contacten,ou=101001,dc=mydomain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# tbook1, contacten, 101001, mydomain dn: ou=tbook1,ou=contacten,ou=101001,dc=mydomain ou: tbook1 objectClass: organizationalUnit objectClass: top
...<cut>...
# search result search: 2 result: 0 Success
# numResponses: 5 # numEntries: 4
But when I query this same LDAP-tree with my user cn=U101001,ou=101001,dc=mydomain, I get :
[root@ldap1 openldap]# ldapsearch -x -D 'cn=U101001,ou=101001,dc=mydomain' -b "dc=mydomain" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=mydomain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1
I also have phpLDAPadmin installed and there I see that there are definitely enries in the LDAP-directory ou=tbook1,ou=contacten,ou=101001,dc=mydomain.
So why does my user cn=U101001,ou=101001,dc=mydomain fails to get results ??
Kind regards,
Jonas.
--On Thursday, February 27, 2014 4:19 PM +0100 Jonas Kellens jonas.kellens@telenet.be wrote:
Hello,
I have a working openLDAP server version 2.3.43. My configuration there works : the correct users have the correct access.
I have set up a new openLDAP-server with newer version 2.3.43.
I have no working openLDAP on version 2.3.43.
I have tried with the new syntax and with the command /usr/sbin/slaptest -f /etc/openldap/slapd.conf -v to use the build in converion tool, but I always got : ldap_bind: Invalid credentials (49)
So I forgot this conversion and continued with the "old" slapd.conf file.
But in this configuration (which is just a copy/paste of my openLDAP 2.3.43) no user can query the LDAP entries.
So this is the setup :
I have a user : cn=U101001,ou=101001,dc=mydomain This user is member of the group : cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain These members can read entries in the tree : ou=tbook1,ou=contacten,ou=101001,dc=mydomain
I have in slapd.conf :
access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read
So why does my user cn=U101001,ou=101001,dc=mydomain fails to get results ??
Likely the 2.3 acl set needs adjusting for 2.4.
I would also note it appears you're using the utterly broken packages provided by RH. I'd strongly advise you to get sane, safe packages, such as those provided by Symas or the LTB project.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 27-02-14 17:49, Quanah Gibson-Mount wrote:
--On Thursday, February 27, 2014 4:19 PM +0100 Jonas Kellens jonas.kellens@telenet.be wrote:
Hello,
I have a working openLDAP server version 2.3.43. My configuration there works : the correct users have the correct access.
I have set up a new openLDAP-server with newer version 2.3.43.
I have no working openLDAP on version 2.3.43.
I have tried with the new syntax and with the command /usr/sbin/slaptest -f /etc/openldap/slapd.conf -v to use the build in converion tool, but I always got : ldap_bind: Invalid credentials (49)
So I forgot this conversion and continued with the "old" slapd.conf file.
But in this configuration (which is just a copy/paste of my openLDAP 2.3.43) no user can query the LDAP entries.
So this is the setup :
I have a user : cn=U101001,ou=101001,dc=mydomain This user is member of the group : cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain These members can read entries in the tree : ou=tbook1,ou=contacten,ou=101001,dc=mydomain
I have in slapd.conf :
access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read
So why does my user cn=U101001,ou=101001,dc=mydomain fails to get results ??
Likely the 2.3 acl set needs adjusting for 2.4.
I would also note it appears you're using the utterly broken packages provided by RH. I'd strongly advise you to get sane, safe packages, such as those provided by Symas or the LTB project.
--Quanah
Hello,
what kind of adjustments are needed then ?
access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read
What of the above ACL-statement is incorrect ?
Kind regards, Jonas.
--On Thursday, March 13, 2014 4:12 PM +0100 Jonas Kellens jonas.kellens@telenet.be wrote:
what kind of adjustments are needed then ?
access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read
What of the above ACL-statement is incorrect ?
Is that your one and only ACL? I'm going to guess not. It's not particularly easy to evaluate ACLs out of context, since the entire thing is contextual.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 13-03-14 18:38, Quanah Gibson-Mount wrote:
--On Thursday, March 13, 2014 4:12 PM +0100 Jonas Kellens jonas.kellens@telenet.be wrote:
what kind of adjustments are needed then ?
access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read
What of the above ACL-statement is incorrect ?
Is that your one and only ACL? I'm going to guess not. It's not particularly easy to evaluate ACLs out of context, since the entire thing is contextual.
--Quanah
Well actually, this is the entire ACL :
database bdb suffix "dc=mydomain" rootdn "cn=Manager,dc=mydomain" rootpw {SSHA}blCAG/CNdFPY597Cf4Ssujk
defaultaccess none
access to attrs=userPassword by * auth
access to dn.regex="ou=tbook[12345],ou=contacten,ou=101001,dc=mydomain" attrs=children by group.exact="cn=admins,ou=101001,dc=mydomain" write by * none break
access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook2,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook2,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook3,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook3,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook4,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook4,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook5,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook5,ou=gebruikers,ou=101001,dc=mydomain" read
Do you see anything wrong ?
As said before, works perfect on openLDAP version 2.3.42
Kind regards, Jonas.
On Mon, 2014-03-31 at 10:43 +0200, Jonas Kellens wrote:
Well actually, this is the entire ACL : (...) defaultaccess none
The defaultaccess keyword disappeared in OpenLDAP 2.1, and 2.4 won't start with it. Unless you're using a hacked version of OpenLDAP. Anyway, that's the default in RE24 for a database which has other access statements. And searching also needs "search" access to search-related items, like the baseDN. See man slapd.access.
So you get what you're specifying: No access to baseDN of your search. Append something like this to access list:
access to * by * search
On 31-03-14 12:52, Hallvard Breien Furuseth wrote:
On Mon, 2014-03-31 at 10:43 +0200, Jonas Kellens wrote:
Well actually, this is the entire ACL : (...) defaultaccess none
The defaultaccess keyword disappeared in OpenLDAP 2.1, and 2.4 won't start with it. Unless you're using a hacked version of OpenLDAP. Anyway, that's the default in RE24 for a database which has other access statements. And searching also needs "search" access to search-related items, like the baseDN. See man slapd.access.
So you get what you're specifying: No access to baseDN of your search. Append something like this to access list:
access to * by * search
Hello,
won't this statement give access to everything and everyone ? Because if it does, this is not what I want.
Thanks.
Jonas.
On Mon, 2014-03-31 at 12:57 +0200, Jonas Kellens wrote:
On 31-03-14 12:52, Hallvard Breien Furuseth wrote:
(...) So you get what you're specifying: No access to baseDN of your search. Append something like this to access list:
access to * by * search
won't this statement give access to everything and everyone ? Because if it does, this is not what I want.
Yes - search but not read access, to everything not covered by previous access statements. So people can search for '(sn=Kell*) and discover that you exist, but not read your attributes.
By all means replace it with a more restrictive statement. To see what, read man slapd.access section OPERATION REQUIREMENTS.
On 31-03-14 12:52, Hallvard Breien Furuseth wrote:
On Mon, 2014-03-31 at 10:43 +0200, Jonas Kellens wrote:
Well actually, this is the entire ACL : (...) defaultaccess none
The defaultaccess keyword disappeared in OpenLDAP 2.1, and 2.4 won't start with it. Unless you're using a hacked version of OpenLDAP. Anyway, that's the default in RE24 for a database which has other access statements. And searching also needs "search" access to search-related items, like the baseDN. See man slapd.access.
So you get what you're specifying: No access to baseDN of your search. Append something like this to access list:
access to * by * search
Hello,
made the change and added the extra line to /etc/openldap/slapd.conf
remove the line with "defaultaccess none" !
The output has changed from "32 No Such Object" to "result: 0 Success". Which is a step forward, but still no results.
When I query with cn=Manager, then the results are shown :
/[root@slap01 ]# ldapsearch -x -D 'cn=Manager,dc=mydomain' -b "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" -W// //Enter LDAP Password: // //# extended LDIF// //#// //# LDAPv3// //# base <ou=tbook1,ou=contacten,ou=101001,dc=mydomain> with scope subtree// //# filter: (objectclass=*)// //# requesting: ALL// //#// // //# tbook1, contacten, 101001, mydomain// //dn: ou=tbook1,ou=contacten,ou=101001,dc=mydomain// //ou: tbook1// //objectClass: organizationalUnit// //objectClass: top// // //<snip results>// // //# search result// //search: 2// //result: 0 Success// // //# numResponses: 5// //# numEntries: 4/
But when I query with the user cn=U101001, then there are no results :
/[root@slap01 ]# ldapsearch -x -D 'cn=U101001,ou=101001,dc=mydomain' -b "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" -W// //Enter LDAP Password: // //# extended LDIF// //#// //# LDAPv3// //# base <ou=tbook1,ou=contacten,ou=101001,dc=mydomain> with scope subtree// //# filter: (objectclass=*)// //# requesting: ALL// //#// // //# search result// //search: 2// //result: 0 Success// // //# numResponses: 1/
Can you help me further ?
Thanks, Jonas.
On 31-03-14 12:52, Hallvard Breien Furuseth wrote:
On Mon, 2014-03-31 at 10:43 +0200, Jonas Kellens wrote:
Well actually, this is the entire ACL : (...) defaultaccess none
The defaultaccess keyword disappeared in OpenLDAP 2.1, and 2.4 won't start with it. Unless you're using a hacked version of OpenLDAP. Anyway, that's the default in RE24 for a database which has other access statements. And searching also needs "search" access to search-related items, like the baseDN. See man slapd.access.
So you get what you're specifying: No access to baseDN of your search. Append something like this to access list:
access to * by * search
Hello,
even if I add at the beginning of slapd.conf the following :
access to * by *
I still get no results with the user 'cn=U101001,ou=101001,dc=mydomain'
I only get result with 'cn=Manager,dc=mydomain'
Kind regards, Jonas.
On Tue, 2014-04-01 at 09:58 +0200, Jonas Kellens wrote:
On 31-03-14 12:52, Hallvard Breien Furuseth wrote:
(...) Append something like this to access list:
access to * by * search
even if I add at the beginning of slapd.conf the following :
access to * by *
I still get no results with the user 'cn=U101001,ou=101001,dc=mydomain'
Quite. access controls at the beginning of slapd.conf become the global access list, which are overridden by the database's access list. The latter ends with a default 'access to * by * none'.
Also you didn't say what kind of access - read, write, search or whatever. The default is '+0', i.e. no change.
This is all as described in man slapd.access.
*Append* access to * by * search (or something like it) to the database's access list. That means, after the other access statements. Then it'll apply to the entries not described by those statements. My guess is your previous attempt put it in front, thus hiding most access controls.
On 01-04-14 16:16, Hallvard Breien Furuseth wrote:
On Tue, 2014-04-01 at 09:58 +0200, Jonas Kellens wrote:
On 31-03-14 12:52, Hallvard Breien Furuseth wrote:
(...) Append something like this to access list:
access to * by * search
even if I add at the beginning of slapd.conf the following :
access to * by *
I still get no results with the user 'cn=U101001,ou=101001,dc=mydomain'
Quite. access controls at the beginning of slapd.conf become the global access list, which are overridden by the database's access list. The latter ends with a default 'access to * by * none'.
Also you didn't say what kind of access - read, write, search or whatever. The default is '+0', i.e. no change.
This is all as described in man slapd.access.
*Append* access to * by * search (or something like it) to the database's access list. That means, after the other access statements. Then it'll apply to the entries not described by those statements. My guess is your previous attempt put it in front, thus hiding most access controls.
Hello,
I have now put "access to * by *" at the end of the ACL statements. My slapd.conf looks like this :
access to dn.regex="ou=tbook[12345],ou=contacten,ou=101001,dc=mydomain" attrs=children by group.exact="cn=admins,ou=101001,dc=mydomain" write by * none break
access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook2,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook2,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook3,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook3,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook4,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook4,ou=gebruikers,ou=101001,dc=mydomain" read
access to dn.one="ou=tbook5,ou=contacten,ou=101001,dc=mydomain" by group.exact="cn=admins,ou=101001,dc=mydomain" write by group.exact="cn=tbook5,ou=gebruikers,ou=101001,dc=mydomain" read
access to * by * search
access to attrs=userPassword by * auth
But still no results :
[root@slap01 ]# ldapsearch -x -D 'cn=U101001,ou=101001,dc=mydomain' -b "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=tbook1,ou=contacten,ou=101001,dc=mydomain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 0 Success
# numResponses: 1
Kind regards, Jonas.
Hi,
On Wed, 2 Apr 2014, Jonas Kellens wrote: <snipp/>
start with a simple
access to * by * read
and nothing else and see that you can list your directory.
Then start rebuilding your acl line by line.
And keep rereading slapd.access manpage if somehting does not work to see if you have masked something of by accident.
Greetings Christian
access to attrs=userPassword by * auth
But still no results :
[root@slap01 ]# ldapsearch -x -D 'cn=U101001,ou=101001,dc=mydomain' -b "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=tbook1,ou=contacten,ou=101001,dc=mydomain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 0 Success
# numResponses: 1
Kind regards, Jonas.
On 02-04-14 17:35, Christian Kratzer wrote:
Hi,
On Wed, 2 Apr 2014, Jonas Kellens wrote:
<snipp/>
start with a simple
access to * by * readand nothing else and see that you can list your directory.
Then start rebuilding your acl line by line.
And keep rereading slapd.access manpage if somehting does not work to see if you have masked something of by accident.
Greetings Christian
Like the title of my post says : my ACL works perfect on openLDAP v 2.3.43. I can not imagine I have to re-define my ACL rules from scratch because the version of openLDAP is higher ?!
My rules aren't even so complicated... Some users have read, some have write.
Kind regards,
Jonas.
Hi,
On Thu, 3 Apr 2014, Jonas Kellens wrote:
On 02-04-14 17:35, Christian Kratzer wrote:
On Wed, 2 Apr 2014, Jonas Kellens wrote:
<snipp/>
start with a simple
access to * by * readand nothing else and see that you can list your directory.
Then start rebuilding your acl line by line.
And keep rereading slapd.access manpage if somehting does not work to see if you have masked something of by accident.
Greetings Christian
Like the title of my post says : my ACL works perfect on openLDAP v 2.3.43. I can not imagine I have to re-define my ACL rules from scratch because the version of openLDAP is higher ?!
My rules aren't even so complicated... Some users have read, some have write.
I just pointed you to the basic steps in trouble shooting.
Either try to strip down your acl to see where the problem is or wait until somebody takes interest in your acl and debugs them for you.
As the acl is quite short you should be able to find the problem easily.
Greetings Christian
Christian Kratzer wrote:
Hi,
On Thu, 3 Apr 2014, Jonas Kellens wrote:
On 02-04-14 17:35, Christian Kratzer wrote:
On Wed, 2 Apr 2014, Jonas Kellens wrote:
<snipp/>
start with a simple
access to * by * readand nothing else and see that you can list your directory.
Then start rebuilding your acl line by line.
And keep rereading slapd.access manpage if somehting does not work to see if you have masked something of by accident.
Greetings Christian
Like the title of my post says : my ACL works perfect on openLDAP v 2.3.43. I can not imagine I have to re-define my ACL rules from scratch because the version of openLDAP is higher ?!
http://www.openldap.org/doc/admin24/appendix-upgrading.html#ACLs:%20searches...
My rules aren't even so complicated... Some users have read, some have write.
I just pointed you to the basic steps in trouble shooting.
Either try to strip down your acl to see where the problem is or wait until somebody takes interest in your acl and debugs them for you.
As the acl is quite short you should be able to find the problem easily.
Greetings Christian
On 02-04-14 17:35, Christian Kratzer wrote:
Hi,
On Wed, 2 Apr 2014, Jonas Kellens wrote:
<snipp/>
start with a simple
access to * by * readand nothing else and see that you can list your directory.
Then start rebuilding your acl line by line.
And keep rereading slapd.access manpage if somehting does not work to see if you have masked something of by accident.
Greetings Christian
I now have :
access to * by * search
But still no results !!
Results are only displayed when searching with the 'root' user (cn=Manager,dc=mydomain).
Kind regards, Jonas.
--On April 7, 2014 at 12:39:36 PM +0200 Jonas Kellens jonas.kellens@telenet.be wrote:
On 02-04-14 17:35, Christian Kratzer wrote:
start with a simple
access to * by * read
access to * by * search
These clearly are not the same thing.
--Quanah
On 07-04-14 19:05, Quanah Gibson-Mount wrote:
--On April 7, 2014 at 12:39:36 PM +0200 Jonas Kellens jonas.kellens@telenet.be wrote:
On 02-04-14 17:35, Christian Kratzer wrote:
start with a simple
access to * by * readaccess to * by * search
These clearly are not the same thing.
--Quanah
Hello,
also when I just put this rule in /etc/openldap/slapd.conf :
access to * by * read
nothing happens when searching with the user 'cn=U101001,ou=101001,dc=mydomain' :
[root@slap01 ]# ldapsearch -x -D 'cn=U101001,ou=101001,dc=mydomain' -b "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=tbook1,ou=contacten,ou=101001,dc=mydomain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 0 Success
# numResponses: 1
There are only results when searching with root user :
[root@slap01 ]# ldapsearch -x -D 'cn=Manager,dc=mydomain' -b "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=tbook1,ou=contacten,ou=101001,dc=mydomain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# tbook1, contacten, 101001, mydomain dn: ou=tbook1,ou=contacten,ou=101001,dc=mydomain ou: tbook1 objectClass: organizationalUnit objectClass: top
# Jonas BVBA, tbook1, contacten, 101001, mydomain dn: cn=Jonas BVBA,ou=tbook1,ou=contacten,ou=101001,dc=mydomain cn: Jonas BVBA sn: Jonas BVBA telephoneNumber: 1111111111 objectClass: inetOrgPerson
# Jonas Kellens, tbook1, contacten, 101001, mydomain dn: cn=Jonas Kellens,ou=tbook1,ou=contacten,ou=101001,dc=mydomain telephoneNumber: 111111111 objectClass: inetOrgPerson cn: Jonas Kellens sn: Jonas Kellens
# Center, tbook1, contacten, 101001, mydomain dn: cn=Center,ou=tbook1,ou=contacten,ou=101001,dc=mydomain cn: Center sn: Center telephoneNumber: 11111111 objectClass: inetOrgPerson
# search result search: 2 result: 0 Success
# numResponses: 5 # numEntries: 4
Kind regards, Jonas.
Hello,
any more input to this ?
Thanks.
Jonas.
On 08-04-14 15:21, Jonas Kellens wrote:
On 07-04-14 19:05, Quanah Gibson-Mount wrote:
--On April 7, 2014 at 12:39:36 PM +0200 Jonas Kellens jonas.kellens@telenet.be wrote:
On 02-04-14 17:35, Christian Kratzer wrote:
start with a simple
access to * by * readaccess to * by * search
These clearly are not the same thing.
--Quanah
Hello,
also when I just put this rule in /etc/openldap/slapd.conf :
access to * by * read
nothing happens when searching with the user 'cn=U101001,ou=101001,dc=mydomain' :
[root@slap01 ]# ldapsearch -x -D 'cn=U101001,ou=101001,dc=mydomain' -b "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=tbook1,ou=contacten,ou=101001,dc=mydomain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 0 Success
# numResponses: 1
There are only results when searching with root user :
[root@slap01 ]# ldapsearch -x -D 'cn=Manager,dc=mydomain' -b "ou=tbook1,ou=contacten,ou=101001,dc=mydomain" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=tbook1,ou=contacten,ou=101001,dc=mydomain> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# tbook1, contacten, 101001, mydomain dn: ou=tbook1,ou=contacten,ou=101001,dc=mydomain ou: tbook1 objectClass: organizationalUnit objectClass: top
# Jonas BVBA, tbook1, contacten, 101001, mydomain dn: cn=Jonas BVBA,ou=tbook1,ou=contacten,ou=101001,dc=mydomain cn: Jonas BVBA sn: Jonas BVBA telephoneNumber: 1111111111 objectClass: inetOrgPerson
# Jonas Kellens, tbook1, contacten, 101001, mydomain dn: cn=Jonas Kellens,ou=tbook1,ou=contacten,ou=101001,dc=mydomain telephoneNumber: 111111111 objectClass: inetOrgPerson cn: Jonas Kellens sn: Jonas Kellens
# Center, tbook1, contacten, 101001, mydomain dn: cn=Center,ou=tbook1,ou=contacten,ou=101001,dc=mydomain cn: Center sn: Center telephoneNumber: 11111111 objectClass: inetOrgPerson
# search result search: 2 result: 0 Success
# numResponses: 5 # numEntries: 4
Kind regards, Jonas.
--On April 14, 2014 at 10:06:58 AM +0200 Jonas Kellens jonas.kellens@telenet.be wrote:
Hello,
any more input to this ?
It appears you have more ACLs than you are listing in your configs. Since you won't provide your config, all we can do is speculate wildly.
--Quanah
Slapacl could be useful to test your acls.
-- JT 519.888.7465 ext 72548 (801) 72548
It is by caffeine alone I set my mind in motion. It is by the Beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah Gibson-Mount Sent: Monday, April 14, 2014 12:36 PM To: Jonas Kellens; openldap-technical@openldap.org Subject: Re: Problem after migration openldap 2.3.43 to 2.4.23 --> 32 No Such Object
--On April 14, 2014 at 10:06:58 AM +0200 Jonas Kellens jonas.kellens@telenet.be wrote:
Hello,
any more input to this ?
It appears you have more ACLs than you are listing in your configs. Since you won't provide your config, all we can do is speculate wildly.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Christian Kratzer -
Hallvard Breien Furuseth -
Howard Chu -
John Timon -
Jonas Kellens -
Quanah Gibson-Mount