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 <[email protected]>: > 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 | > ----------------------------------------------------------------------- >
