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