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 <[email protected]>: > Am Mon, 27 Oct 2014 10:53:07 -0300 > schrieb Net Warrior <[email protected]>: > > > 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 > >
