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

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 ?

Based on the the ACL's I posted from my configuration, what else can you recommend to include, tweak or modify?

Based on the the  ACL's I posted from my configuration, what else can you recommend to include, tweak or modify?

1 - Well, users only authenticate their passwords, nothing else, on the client side to login to the server, so I guess anon logins should not be allowed.

2 - I use the Manager account to login to the phplpdapadmin console or apache directory studio.

3 - Password and groups and ppolicy 4 - Using pam on the client side, a human is expected to provide username and password which is working along with the ppolicy, expiration time , password lenght and so on. I can provide how's configured if you want.

>So is the LDAP service just used to provide passwd and group databases >for Unix-like systems, and not for any other purpose? Yes, only password auth

>If my guess above is right then you have missed a very important class >of LDAP user. Every Unix-like server must access LDAP data. >Do your Unix/Linux systems bind to LDAP with specific DNs? >(This will be configured in files such as /etc/ldap.conf /etc/nslcd.conf >/etc/sssd.conf etc...) Yes, ldap.conf client config file. base dc=server,dc=com # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. #binddn cn=Manager,dc=example,dc=com

bind_policy soft idle_timelimit 3600 pam_filter objectClass=posixAccount pam_lookup_policy yes pam_check_host_attr yes pam_password exop nss_base_passwd         ou=Users,dc=server,dc=com?one nss_base_shadow         ou=Users,dc=server,dc=com?one nss_base_group          ou=Groups,dc=server,dc=com?one ssl start_tls #ssl on tls_cacertfile /etc/openldap/certs/cert.pem tls_cacertdir /etc/openldap/certs

>I assume you allow users to change their own passwords. How is this handled? >Are users allowed to update any other details, or do all changes come to you? yes, they can change their password based on the ppolicy and the pam module, other properties are changed by me, like phone number, photo, address and so on.

200 Servers and 20 users

>I hope you don't really bind with the ROOTDN account! NO!  and I have a user to test the configuration but I do not use it  to bind purposes, but I could if I knew how to configure it.

>You should also add: >tls_reqcert demand >and you may want to consider restricting the connection to high-grade ciphers e.g.: >tls_ciphers HIGH:MEDIUM:@STRENGTH Both, client and server side right?

Ok, thank you very much, I'm gonna review the configuration and follow your advice. Best regards. 2014-10-29 13:43 GMT-03:00 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk >: On Wed, Oct 29, 2014 at 08:19:03AM -0300, Net Warrior wrote: > > > 200 Servers and 20 users > > OK - that means that you will not have problems with the default > limits on result-set size (500 entries). > > > >I hope you don't really bind with the ROOTDN account! > > NO! and I have a user to test the configuration but I do not use it > to bind > > purposes, but I could if I knew how to configure it. > > As you have quite a lot of servers and a policy of hiding all data > from anonymous users, I would suggest having more than one LDAP-client > account. Either create one per client server, or one per group of similar > servers. > > I would suggest putting the client accounts in a dedicated part of the > LDAP tree, so it might look like this: > > ou=Users,dc=server,dc=com POSIX user accounts > ou=Groups,dc=server,dc=com POSIX groups > ou=Clients,dc=server,dc=com Client machine accounts > > You need to get all your client machines to bind with their account DN > and password before you start changing ACLs. Config file entries will look > something like this: > > binddn cn=server1,ou=Clients,dc=server,dc=com > bindpw SomeLongAndSecurePassword > > > >You should also add: > > >tls_reqcert demand > > >and you may want to consider restricting the connection to high-grade > ciphers > > e.g.: > > >tls_ciphers HIGH:MEDIUM:@STRENGTH > > > > Both, client and server side right? > > Yes, but the keyword for slapd.conf is TLSCipherSuite > and for ldap.conf it is TLS_CIPHER_SUITE > > Once you have *all* the clients using TLS and binding with their client > account and password, you can start on ACLs. If your logging includes > the 'stats' category (256) you will be able to see TLS setup and bind > in the logs, e.g.: > > Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 ACCEPT from > IP=[::1]:43386 (IP=[::]:389) > Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 EXT > oid=1.3.6.1.4.1.1466.20037 > Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 STARTTLS > Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 RESULT oid= err=0 > text= > Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 TLS established > tls_ssf=128 ssf=128 > Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND > dn="cn=client234,ou=Clients,dc=server,dc=com" method=128 > Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND > dn="cn=client234,ou=Clients,dc=server,dc=com" mech=SIMPLE ssf=0 > Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 RESULT tag=97 > err=0 text= > > After all that, the ACLs turn out to be really simple! Something like this > will probably be close to what you need for the main database: > > access to attrs="userPassword" > by self =w > by * auth > > access to * by users read > > access to * by * none > > If you have a replica server then you will need to add an ACL giving read > access > to all attributes. This should go right at the top of the list, and will > look something > like this: > > access to * by dn.exact="cn=replicator,ou=Clients,dc=server,dc=com" read > > If you are using the Monitor database then you should probably protect it > like this: > > access to dn.subtree="cn=Monitor" > by users read > by * none > > And to make sure that critical stuff like the root DSE and the schema can > be > read by everyone, add this to the global section of the config: > > access to * by * read > > > Andrew > -- > ----------------------------------------------------------------------- > | From Andrew Findlay, Skills 1st Ltd | > | Consultant in large-scale systems, networks, and directory services | > | http://www.skills-1st.co.uk/ +44 1628 782565 | > ----------------------------------------------------------------------- >

I suspect that you do not want that. It would force every client to have a client-side X.509 certificate. Good for secure authentication, but more effort to manage than most people are prepared to handle.

That is because you tried to add it to a database but it is a global

Are you really using the BDB database? It has been deprecated for some

I would suggest using MDB

On Thu, Oct 30, 2014 at 08:11:31AM -0300, Net Warrior wrote: > 1 ) Added tls_reqcert demand to the client side > 2 ) Configured a user to bind instead of anonymous > binddn cn=ldapuser,Ou=Users,dc=server,dc=com > bindpwd :$6$oZ8qYohy$lU0sYJXInOO1ISO4WKgzeuDyyFh9a Good. > 3 ) Added olcTLSVerifyClient:demand to server side: I suspect that you do not want that. It would force every client to have a client-side X.509 certificate. Good for secure authentication, but more effort to manage than most people are prepared to handle. > Object added to server: > > dn: olcDatabase={2}bdb,cn=config > changetype:modify > add: olcTLSVerifyClient:demand > > Still I did not corrected my ACL but I do not see olcTLSVerifyClient:demand > reflected on my configuration That is because you tried to add it to a database but it is a global option. Are you really using the BDB database? It has been deprecated for some time now. I would suggest using MDB. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------