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