--On Monday, November 28, 2011 9:34 PM +0100 Axel Birndt towerlexa@gmx.de wrote:

But if i use ldapsearch with the following command i got nothing:

ldapsearch -b "" -s base 'objectclass=*'

ldap_sasl_interactive_bind_s: No such object (32)

Could you help me please to identify if there is a problem with reading the Root DSE?

What could i do next ?

Any help is very appreciated.

It is clearly failing with anonymous binds. So yes, this would be an ACL issue. I would suggest you peruse your ACLs and fix accordingly.

--Quanah

--

Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

--On Monday, November 28, 2011 10:07 PM +0100 Axel Birndt towerlexa@gmx.de wrote:

Am 28.11.2011 21:48, schrieb Quanah Gibson-Mount:

...

--On Monday, November 28, 2011 9:34 PM +0100 Axel Birndt towerlexa@gmx.de wrote:

...

But if i use ldapsearch with the following command i got nothing:

ldapsearch -b "" -s base 'objectclass=*'

ldap_sasl_interactive_bind_s: No such object (32)

...

It is clearly failing with anonymous binds. So yes, this would be an

ACL

...

issue. I would suggest you peruse your ACLs and fix accordingly.

Ok thanks. Of course i will fix my acl's, but in the moment its not clear for me how i've to change my acl's.

Here are my acls for the

olcDatabase={1}hdb,cn=config

olcAccess (5 values)

{0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=2axelscompany, dc=ro" write by anonymous auth by self write by * none {1}to dn.base="" by * read {2}to dn.base="cn=subschema" by * read {3}to dn.base="cn=schema,cn=config" by * read {4}to * by dn="cn=admin,dc=2axels-company,dc=de" write by * read

Could you please double check, my acl's?

i've added the entrys {2} and {3} after the hint to make the schema and subschema readable for all, but i'am afraid i make a mistake.

These apply to your olcDatabase={1}hdb,cn=config database. They do not apply to your frontend database, which is where the rootDSE is stored, and its ACLs. You may want to look at the acls in olcDatabase={-1}frontend.ldif

--Quanah

--

Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

Hi Ondrej,

Am 29.11.2011 08:37, schrieb Ondrej Kuznik:

Make sure you check your ldap.conf or explicitly say you require a simple bind using the "-x" command line switch. What you're receiving seems more like a bind failure (after which the client bails) than a search failure.

Try this: ldapsearch -x -D "" -s base -b "" -h localhost

If this does not print the RootDSE or returns anything other than a success, your server ACL or other settings are most likely misconfigured.

I tried the command from above:

ldapsearch -x -D "" -s base -b "" -h localhost # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL #

# search result search: 2 result: 0 Success

# numResponses: 1

With your description, i should got a little bit more, right?

I'll try to fix my acl's and test it again.

Could you tell me please, which output i could expect? Maybe you are able to give me an example, so i could verify it by myself?

On 11/29/2011 09:13 AM, Axel Birndt wrote:

Hi Ondrej,

Am 29.11.2011 08:37, schrieb Ondrej Kuznik:

...

Make sure you check your ldap.conf or explicitly say you require a simple bind using the "-x" command line switch. What you're receiving seems more like a bind failure (after which the client bails) than a search failure.

Try this: ldapsearch -x -D "" -s base -b "" -h localhost

If this does not print the RootDSE or returns anything other than a success, your server ACL or other settings are most likely misconfigured.

I tried the command from above:

ldapsearch -x -D "" -s base -b "" -h localhost # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL #

# search result search: 2 result: 0 Success

# numResponses: 1

With your description, i should got a little bit more, right?

I'll try to fix my acl's and test it again.

Could you tell me please, which output i could expect? Maybe you are able to give me an example, so i could verify it by myself?

ldapsearch -x -D "" -s base -b "" -h localhost

Set -D to your admin DN and set -W to get a password prompt.

You should get the following lines (I have SASL not simpleBind!) (Simplebind like this: ldapsearch -b "" -s base -xD cn=admin,dc=mydomain,dc=com -W)

[raffael.sahli@ldap-master001 ~]#--> ldapsearch -b "" -s base SASL/GSSAPI authentication started SASL username: raffael.sahli@MY_REALM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL #

# dn: objectClass: top objectClass: OpenLDAProotDSE

# search result search: 5 result: 0 Success

# numResponses: 2 # numEntries: 1

Am 29.11.2011 10:10, schrieb Ondrej Kuznik:

On 11/29/2011 09:13 AM, Axel Birndt wrote: You should expect a response exactly like this (unless your database suffix is set to ""):

ldapsearch -x -D "" -s base -b "" -h localhost

ldapsearch -x -D "" -s base -b "" -h localhost # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL #

# dn: objectClass: top objectClass: OpenLDAProotDSE

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1

Most likely you'll need to put something like this as the very first rule there: olcAccess: {0}to dn.base="" by * read

Ok, thanks for your really quick help. I set the rule from above and got the following result:

ldapsearch -x -h localhost -b "" -s base + # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: + #

# dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=2axels-company,dc=de supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: NTLM entryDN: subschemaSubentry: cn=Subschema

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1

Yeah!! This looks much better!

At least, of course. Some of the other ACL statements you listed in olcDatabase={1}hdb,cn=config should also be under olcDatabase={-1}frontend,cn=config to allow access to the schema.

This is the next step, give me some time.

Thanks @All for your mind and time ;-)

Am Wed, 30 Nov 2011 22:05:24 +0100 schrieb Axel Birndt towerlexa@gmx.de:

Hi @all & thanks for your help!

Am 29.11.2011 12:28, schrieb Axel Birndt:

...

Am 29.11.2011 10:10, schrieb Ondrej Kuznik:

...

On 11/29/2011 09:13 AM, Axel Birndt wrote: You should expect a response exactly like this (unless your database suffix is set to ""):

ldapsearch -x -D "" -s base -b "" -h localhost

ldapsearch -x -D "" -s base -b "" -h localhost

Now its working for me. I added the following ACL's in

olcDatabase={-1}frontend,cn=config

{0}to dn.base="" by * read {1}to dn.base="cn=schema,cn=config" by * read {2}to dn.base="cn=Subschema" by * read

But, does the first rule meaning, that everone could read all in this frontend??

Is this security conform? Or it is better to allow only authenticated Users to read this?

Are there any best practices for this?

dn.base="" exposes rootDSE which has to be read by any client, so this should be anonymous readable, same applies to cn=subschema as clients have to know the attribute types and objectclasses available. But nobody should have access to schema database, so remove rule {1}

-Dieter

Hi Dieter,

Am 01.12.2011 09:27, schrieb Dieter Klünter:

Am Wed, 30 Nov 2011 22:05:24 +0100 schrieb Axel Birndttowerlexa@gmx.de:

...

Is this security conform? Or it is better to allow only authenticated Users to read this?

Are there any best practices for this?

dn.base="" exposes rootDSE which has to be read by any client, so this should be anonymous readable, same applies to cn=subschema as clients have to know the attribute types and objectclasses available. But nobody should have access to schema database, so remove rule {1}

thanks for your hint.

I changed my rules now to this:

- for olcDatabase={-1}frontend,cn=config

{0}to dn.base="" by * read {1}to dn.base="cn=Subschema" by * read {2}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break

- for olcDatabase={1}hdb,cn=config

{0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=2axels-company,dc=ro" write by anonymous auth by self write by * none {1}to dn.base="" by * read {2}to dn.base="cn=Subschema" by * read {3}to * by dn="cn=admin,dc=2axels-company,dc=de" write by * read

In my opinion its not needed to have the rule {1} and {2} in the "olcDatabase={1}hdb,cn=config" section? Right?

In the moment this results from my testing all around the ACL-Rules...