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