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     |
-----------------------------------------------------------------------