Hi Andrew, I've got some updates.
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
3 ) Added olcTLSVerifyClient:demand to server side:
Now as I can see this is good, the TLS is established with a strong security factor of 256.
Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 fd=252 ACCEPT from IP=X.X.X.X:58387 (IP=0.0.0.0:389) Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 STARTTLS Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=0 RESULT oid= err=0 text= Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 fd=252 TLS established tls_ssf=256 ssf=256
The user configured to bind from the client side Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=1 BIND dn="cn=ldapuser,ou=Users,dc=server,dc=com" method=128 Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=1 BIND dn="cn=ldapuser,ou=Users,dc=server,dc=com" mech=SIMPLE ssf=0
My user id used to login to the server: Oct 30 07:57:07 ldapserver slapd[12581]: conn=8575 op=3 BIND dn="cn=My Username,ou=Users,dc=serverdc=com" method=128
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 with slapcat -n0 I only see the this:
olcTLSCACertificateFile: /etc/openldap/certs/cert.pem olcTLSCertificateKeyFile: /etc/openldap/certs/private.key olcTLSCertificateFile: /etc/openldap/certs/cert.pem
Did I do something wrong?
Thanks for your time and support Regards
2014-10-29 14:51 GMT-03:00 Net Warrior netwarrior863@gmail.com:
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@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 |