Thanks for the answer, but, from the query I shown, you can see that the DIT is displayed "namingContexts: dc=domain,dc=com" and knowking that, I can make a ldapserch -x pointing tho the server and the base search  for example and list all the domain users, isn't it a security concern? I tested it and it works, how can I create an access list to prevent this, disable the simple auth or disable those anonymous queries ?

Thanks for your time and support.
Regards

2014-10-27 13:09 GMT-03:00 Dieter Klünter <dieter@dkluenter.de>:
Am Mon, 27 Oct 2014 10:53:07 -0300
schrieb Net Warrior <netwarrior863@gmail.com>:

> Hi there guys.
>
> Recently we had an internal audit and it seems that our opelndap
> server is not configured properly, it seems that null bind are
> allowed and Crafted request as well are permited and it would be nice
> if anyone of you  could lend me a hand to fix this:
>
> There are the access list:
>
> olcAccess: {0}to attrs=userPassword by
> dn="cn=Manager,dc=domain,dc=com" wr ite by anonymous auth by self
> write by * none
>
> olcAccess: {1}to
> attrs=cn,sn,memberUid,uidNumber,pwdHistory,pwdPolicySubentry,
> gidNumber,homeDirectory,givenName,description,loginShell by self
> write by ano
> nymous read by * none
>
> olcAccess: {2}to dn.base="" by * read
>
> olcAccess: {3}to * by dn="cn=Manager,dc=domain,dc=com" write by * read
>
> And from a client I got the following:
>
> ldapsearch -x -s base -b '' -H ldap://ldapserver "(objectClass=*)"
> "*" + # extended LDIF
> #
> # LDAPv3
> # base <> with scope baseObject
> # filter: (objectClass=*)
> # requesting: * +
>
> #
> dn:
> objectClass: top
> objectClass: OpenLDAProotDSE
> structuralObjectClass: OpenLDAProotDSE
> configContext: cn=config
> monitorContext: cn=Monitor
> namingContexts: dc=domain,dc=com
> 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.1466.20037
> 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
> entryDN:
> subschemaSubentry: cn=Subschema
> It seems it's no good at all, any help appreciated
> Best regards

A LDAP client should know the servers capabilities in order to connect
in conformance with the protocol. So there is nothing bad about this
search result.

-Dieter

--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E