Hi there guys.
Recently we had an internal audit and it seems that our opelndap server is not configured properly, it seems that null bind are allowed and Crafted request as well are permited and it would be nice if anyone of you could lend me a hand to fix this:
There are the access list:
olcAccess: {0}to attrs=userPassword by dn="cn=Manager,dc=domain,dc=com" wr ite by anonymous auth by self write by * none
olcAccess: {1}to attrs=cn,sn,memberUid,uidNumber,pwdHistory,pwdPolicySubentry, gidNumber,homeDirectory,givenName,description,loginShell by self write by ano nymous read by * none
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by dn="cn=Manager,dc=domain,dc=com" write by * read
And from a client I got the following:
ldapsearch -x -s base -b '' -H ldap://ldapserver "(objectClass=*)" "*" + # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectClass=*) # requesting: * +
# dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config monitorContext: cn=Monitor namingContexts: dc=domain,dc=com supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 entryDN: subschemaSubentry: cn=Subschema It seems it's no good at all, any help appreciated Best regards
Am Mon, 27 Oct 2014 10:53:07 -0300 schrieb Net Warrior netwarrior863@gmail.com:
Hi there guys.
Recently we had an internal audit and it seems that our opelndap server is not configured properly, it seems that null bind are allowed and Crafted request as well are permited and it would be nice if anyone of you could lend me a hand to fix this:
There are the access list:
olcAccess: {0}to attrs=userPassword by dn="cn=Manager,dc=domain,dc=com" wr ite by anonymous auth by self write by * none
olcAccess: {1}to attrs=cn,sn,memberUid,uidNumber,pwdHistory,pwdPolicySubentry, gidNumber,homeDirectory,givenName,description,loginShell by self write by ano nymous read by * none
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by dn="cn=Manager,dc=domain,dc=com" write by * read
And from a client I got the following:
ldapsearch -x -s base -b '' -H ldap://ldapserver "(objectClass=*)" "*" + # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectClass=*) # requesting: * +
# dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config monitorContext: cn=Monitor namingContexts: dc=domain,dc=com supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 entryDN: subschemaSubentry: cn=Subschema It seems it's no good at all, any help appreciated Best regards
A LDAP client should know the servers capabilities in order to connect in conformance with the protocol. So there is nothing bad about this search result.
-Dieter
Thanks for the answer, but, from the query I shown, you can see that the DIT is displayed "namingContexts: dc=domain,dc=com" and knowking that, I can make a ldapserch -x pointing tho the server and the base search for example and list all the domain users, isn't it a security concern? I tested it and it works, how can I create an access list to prevent this, disable the simple auth or disable those anonymous queries ?
Thanks for your time and support. Regards
2014-10-27 13:09 GMT-03:00 Dieter Klünter dieter@dkluenter.de:
Am Mon, 27 Oct 2014 10:53:07 -0300 schrieb Net Warrior netwarrior863@gmail.com:
Hi there guys.
Recently we had an internal audit and it seems that our opelndap server is not configured properly, it seems that null bind are allowed and Crafted request as well are permited and it would be nice if anyone of you could lend me a hand to fix this:
There are the access list:
olcAccess: {0}to attrs=userPassword by dn="cn=Manager,dc=domain,dc=com" wr ite by anonymous auth by self write by * none
olcAccess: {1}to attrs=cn,sn,memberUid,uidNumber,pwdHistory,pwdPolicySubentry, gidNumber,homeDirectory,givenName,description,loginShell by self write by ano nymous read by * none
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by dn="cn=Manager,dc=domain,dc=com" write by * read
And from a client I got the following:
ldapsearch -x -s base -b '' -H ldap://ldapserver "(objectClass=*)" "*" + # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectClass=*) # requesting: * +
# dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config monitorContext: cn=Monitor namingContexts: dc=domain,dc=com supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 entryDN: subschemaSubentry: cn=Subschema It seems it's no good at all, any help appreciated Best regards
A LDAP client should know the servers capabilities in order to connect in conformance with the protocol. So there is nothing bad about this search result.
-Dieter
-- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E
Net Warrior wrote:
Thanks for the answer, but, from the query I shown, you can see that the DIT is displayed "namingContexts: dc=domain,dc=com" and knowking that, I can make a ldapserch -x pointing tho the server and the base search for example and list all the domain users, isn't it a security concern? I tested it and it works, how can I create an access list to prevent this, disable the simple auth or disable those anonymous queries ?
Knowing namingContexts or not is not a matter of security.
Having decent ALCs in place to protect the entries beneath dc=domain,dc=com is.
Just locking down rootDSE does not help at all.
Ciao, Michael.
Hi Michael Based on the the ACL's I posted from my configuration, what else can you recommend to include, tweak or modify?
Thank you very much! Regards
2014-10-27 15:40 GMT-03:00 Michael Ströder michael@stroeder.com:
Net Warrior wrote:
Thanks for the answer, but, from the query I shown, you can see that the DIT is displayed "namingContexts: dc=domain,dc=com" and knowking that, I can make a ldapserch -x pointing tho the server and the base search for example and list all the domain users, isn't it a security concern? I tested it and it works, how can I create an access list to prevent this, disable the simple auth or disable those anonymous queries ?
Knowing namingContexts or not is not a matter of security.
Having decent ALCs in place to protect the entries beneath dc=domain,dc=com is.
Just locking down rootDSE does not help at all.
Ciao, Michael.
Net Warrior wrote:
Based on the the ACL's I posted from my configuration, what else can you recommend to include, tweak or modify?
I did not have a closer look at your ACLs.
ACL design depends very much on *your* requirements and system landscape. For example I've designed the system which does not allow any anonymous access and authorizes on a paranoid need-to-know principle.
The problem is: If you allowed anonymous access in the past it's usually hard to turn on authentication and authorization for all your existing applications.
All in all it's your homework.
Ciao, Michael.
On Mon, Oct 27, 2014 at 03:43:03PM -0300, Net Warrior wrote:
Based on the the ACL's I posted from my configuration, what else can you recommend to include, tweak or modify?
As both Michael and Dieter have said, this is very dependent on your site's requirements and policy. You need to work out what those are. If you can answer these questions, we might be able to help you some more:
1) Should an anonymous user be able to get any data at all? (Ignore the root entry: we are talking about the subtree under dc=domain,dc=com here)
2) What classes of user should have access to the data? Examples might be:
LDAP administrator Web applications Desktop addressbook users Webmail users Directory synchronisation processes
3) For each of the above, what data (entries and attributes) do they need?
4) How will the users authenticate to the LDAP service? i.e. Will the user DNs and passwords be configured into the applications, or is the human user expected to supply a username and password each time?
Andrew
Hi, really appreciate your help.
1 - Well, users only authenticate their passwords, nothing else, on the client side to login to the server, so I guess anon logins should not be allowed. 2 - I use the Manager account to login to the phplpdapadmin console or apache directory studio. 3 - Password and groups and ppolicy 4 - Using pam on the client side, a human is expected to provide username and password which is working along with the ppolicy, expiration time , password lenght and so on. I can provide how's configured if you want.
Thanks for your time and support Regards
2014-10-28 9:55 GMT-03:00 Andrew Findlay andrew.findlay@skills-1st.co.uk:
On Mon, Oct 27, 2014 at 03:43:03PM -0300, Net Warrior wrote:
Based on the the ACL's I posted from my configuration, what else can you recommend to include, tweak or modify?
As both Michael and Dieter have said, this is very dependent on your site's requirements and policy. You need to work out what those are. If you can answer these questions, we might be able to help you some more:
Should an anonymous user be able to get any data at all? (Ignore the root entry: we are talking about the subtree under dc=domain,dc=com here)What classes of user should have access to the data? Examples might be: LDAP administrator Web applications Desktop addressbook users Webmail users Directory synchronisation processesFor each of the above, what data (entries and attributes) do they need?How will the users authenticate to the LDAP service? i.e. Will the user DNs and passwords be configured into the applications, or is the human user expected to supply a username and password each time?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 |
On Tue, Oct 28, 2014 at 11:03:44AM -0300, Net Warrior wrote:
1 - Well, users only authenticate their passwords, nothing else, on the client side to login to the server, so I guess anon logins should not be allowed.
So is the LDAP service just used to provide passwd and group databases for Unix-like systems, and not for any other purpose?
2 - I use the Manager account to login to the phplpdapadmin console or apache directory studio.
If my guess above is right then you have missed a very important class of LDAP user. Every Unix-like server must access LDAP data. Do your Unix/Linux systems bind to LDAP with specific DNs? (This will be configured in files such as /etc/ldap.conf /etc/nslcd.conf /etc/sssd.conf etc...)
3 - Password and groups and ppolicy 4 - Using pam on the client side, a human is expected to provide username and password which is working along with the ppolicy, expiration time , password lenght and so on. I can provide how's configured if you want.
Right, so the account(s) used by the Unix-like systems must be able to search based on username, groupname, numeric UID and numeric GID. Those accounts must also be able to retrieve most attributes from the LDAP entries (though not the password value).
I assume you allow users to change their own passwords. How is this handled? Are users allowed to update any other details, or do all changes come to you?
Andrew
Hi Andrew.
So is the LDAP service just used to provide passwd and group databases for Unix-like systems, and not for any other purpose?
Yes, only password auth
If my guess above is right then you have missed a very important class of LDAP user. Every Unix-like server must access LDAP data. Do your Unix/Linux systems bind to LDAP with specific DNs? (This will be configured in files such as /etc/ldap.conf /etc/nslcd.conf /etc/sssd.conf etc...)
Yes, ldap.conf client config file. base dc=server,dc=com
# The distinguished name to bind to the server with. # Optional: default is to bind anonymously. #binddn cn=Manager,dc=example,dc=com
bind_policy soft idle_timelimit 3600 pam_filter objectClass=posixAccount pam_lookup_policy yes pam_check_host_attr yes pam_password exop nss_base_passwd ou=Users,dc=server,dc=com?one nss_base_shadow ou=Users,dc=server,dc=com?one nss_base_group ou=Groups,dc=server,dc=com?one
ssl start_tls #ssl on tls_cacertfile /etc/openldap/certs/cert.pem tls_cacertdir /etc/openldap/certs
I assume you allow users to change their own passwords. How is this
handled?
Are users allowed to update any other details, or do all changes come to
you?
yes, they can change their password based on the ppolicy and the pam module, other properties are changed by me, like phone number, photo, address and so on.
auth required pam_env.so auth required pam_tally2.so deny=5 unlock_time=1800 auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 minlen=7 dcredit=-2 ocredit=-2 difok=2 maxrepeat=2 password sufficient pam_unix.so sha256 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
Password policy dn: cn=default,ou=Policies,dc=server,dc=com cn: default objectClass: pwdPolicyChecker objectClass: pwdPolicy objectClass: person objectClass: top pwdMinAge: 604800 pwdMaxAge: 5184000 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 2 pwdExpireWarning: 432000 pwdFailureCountInterval: 30 pwdLockout: TRUE pwdSafeModify: FALSE sn: Password Policies structuralObjectClass: person entryUUID: 3cd52690-0ba9-1032-96ec-87e546c35b73 creatorsName: cn=Manager,dc=server,dc=com createTimestamp: 20130215105020Z pwdGraceAuthNLimit: 0 pwdMinLength: 8 pwdLockoutDuration: 54000 pwdInHistory: 3 pwdMaxFailure: 5
Default access lists creatorsName: cn=config createTimestamp: 20130215092101Z olcAccess: {0}to attrs=userPassword by dn="cn=Manager,dc=server,dc=com" wr ite by anonymous auth by self write by * none olcAccess: {1}to attrs=cn,sn,memberUid,uidNumber,pwdHistory,pwdPolicySubentry, gidNumber,homeDirectory,givenName,description,loginShell by self write by ano nymous read by * none olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by dn="cn=Manager,dc,server,dc=com" write by * read
Thanks for your time and support Regards
2014-10-28 11:41 GMT-03:00 Andrew Findlay andrew.findlay@skills-1st.co.uk:
On Tue, Oct 28, 2014 at 11:03:44AM -0300, Net Warrior wrote:
1 - Well, users only authenticate their passwords, nothing else, on the
client
side to login to the server, so I guess anon logins should not be
allowed.
So is the LDAP service just used to provide passwd and group databases for Unix-like systems, and not for any other purpose?
2 - I use the Manager account to login to the phplpdapadmin console or
apache
directory studio.
If my guess above is right then you have missed a very important class of LDAP user. Every Unix-like server must access LDAP data. Do your Unix/Linux systems bind to LDAP with specific DNs? (This will be configured in files such as /etc/ldap.conf /etc/nslcd.conf /etc/sssd.conf etc...)
3 - Password and groups and ppolicy 4 - Using pam on the client side, a human is expected to provide
username and
password which is working along with the ppolicy, expiration time ,
password
lenght and so on. I can provide how's configured if you want.
Right, so the account(s) used by the Unix-like systems must be able to search based on username, groupname, numeric UID and numeric GID. Those accounts must also be able to retrieve most attributes from the LDAP entries (though not the password value).
I assume you allow users to change their own passwords. How is this handled? Are users allowed to update any other details, or do all changes come to you?
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 |
On Tue, Oct 28, 2014 at 01:53:22PM -0300, Net Warrior wrote:
So is the LDAP service just used to provide passwd and group databases for Unix-like systems, and not for any other purpose?
Yes, only password auth
OK. How many systems (approximately) use this? How many users are registered, and how many groups?
If my guess above is right then you have missed a very important class of LDAP user. Every Unix-like server must access LDAP data. Do your Unix/Linux systems bind to LDAP with specific DNs? (This will be configured in files such as /etc/ldap.conf /etc/nslcd.conf /etc/sssd.conf etc...)
Yes, ldap.conf client config file. base dc=server,dc=com
# The distinguished name to bind to the server with. # Optional: default is to bind anonymously. #binddn cn=Manager,dc=example,dc=com
I hope you don't really bind with the ROOTDN account! That would expose the most important password in your system to anyone who managed to compromise a single server.
I would suggest creating either a single account for all client machines of a given type, or one account per client machine. That way if one client gets compromised you just have to change one password and don't have to rush around fixing every other client config. Please tell us what you decide to do here, as it affects how the ACLs might be written.
bind_policy soft idle_timelimit 3600 pam_filter objectClass=posixAccount pam_lookup_policy yes pam_check_host_attr yes pam_password exop nss_base_passwd ou=Users,dc=server,dc=com?one nss_base_shadow ou=Users,dc=server,dc=com?one nss_base_group ou=Groups,dc=server,dc=com?one
ssl start_tls #ssl on tls_cacertfile /etc/openldap/certs/cert.pem tls_cacertdir /etc/openldap/certs
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
I assume you allow users to change their own passwords. How is this handled? Are users allowed to update any other details, or do all changes come to you?
yes, they can change their password based on the ppolicy and the pam module, other properties are changed by me, like phone number, photo, address and so on.
OK, and the config lines above include 'pam_password exop' so it should use the modern mechanism.
I am signing off for the day, but you might like to read this paper bearing in mind what we have discussed:
http://www.skills-1st.co.uk/papers/ldap-acls-jan-2009/
I think we are heading for a very simple 'User read-only' policy, but there may be other issues to consider depending on the size of your user-base.
Andrew
Hi Andrew. I really appreciate your help!!
OK. How many systems (approximately) use this? How many users are
registered,
and how many groups?
200 Servers and 20 users
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.
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?
Thanks for your time and support Best regards.
2014-10-28 15:43 GMT-03:00 Andrew Findlay andrew.findlay@skills-1st.co.uk:
On Tue, Oct 28, 2014 at 01:53:22PM -0300, Net Warrior wrote:
So is the LDAP service just used to provide passwd and group databases for Unix-like systems, and not for any other purpose?
Yes, only password auth
OK. How many systems (approximately) use this? How many users are registered, and how many groups?
If my guess above is right then you have missed a very important class of LDAP user. Every Unix-like server must access LDAP data. Do your Unix/Linux systems bind to LDAP with specific DNs? (This will be configured in files such as /etc/ldap.conf /etc/nslcd.conf /etc/sssd.conf etc...)
Yes, ldap.conf client config file. base dc=server,dc=com
# The distinguished name to bind to the server with. # Optional: default is to bind anonymously. #binddn cn=Manager,dc=example,dc=com
I hope you don't really bind with the ROOTDN account! That would expose the most important password in your system to anyone who managed to compromise a single server.
I would suggest creating either a single account for all client machines of a given type, or one account per client machine. That way if one client gets compromised you just have to change one password and don't have to rush around fixing every other client config. Please tell us what you decide to do here, as it affects how the ACLs might be written.
bind_policy soft idle_timelimit 3600 pam_filter objectClass=posixAccount pam_lookup_policy yes pam_check_host_attr yes pam_password exop nss_base_passwd ou=Users,dc=server,dc=com?one nss_base_shadow ou=Users,dc=server,dc=com?one nss_base_group ou=Groups,dc=server,dc=com?one
ssl start_tls #ssl on tls_cacertfile /etc/openldap/certs/cert.pem tls_cacertdir /etc/openldap/certs
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
I assume you allow users to change their own passwords. How is this
handled?
Are users allowed to update any other details, or do all changes come
to you?
yes, they can change their password based on the ppolicy and the pam
module,
other properties are changed by me, like phone number, photo, address and so on.
OK, and the config lines above include 'pam_password exop' so it should use the modern mechanism.
I am signing off for the day, but you might like to read this paper bearing in mind what we have discussed:
http://www.skills-1st.co.uk/papers/ldap-acls-jan-2009/
I think we are heading for a very simple 'User read-only' policy, but there may be other issues to consider depending on the size of your user-base.
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 |
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
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 |
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 |
On Thu, Oct 30, 2014 at 08:11:31AM -0300, Net Warrior wrote:
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
Good.
3 ) Added olcTLSVerifyClient:demand to server side:
I suspect that you do not want that. It would force every client to have a client-side X.509 certificate. Good for secure authentication, but more effort to manage than most people are prepared to handle.
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
That is because you tried to add it to a database but it is a global option.
Are you really using the BDB database? It has been deprecated for some time now. I would suggest using MDB.
Andrew
Hi Andrew
I suspect that you do not want that. It would force every client to have a client-side X.509 certificate. Good for secure authentication, but more effort to manage than most people are prepared to handle.
Is it because of the certificte expiration or something like that tha's hard to mantain?
That is because you tried to add it to a database but it is a global
option. I added to the global section cn=config and do not see it.
Are you really using the BDB database? It has been deprecated for some
time now.
I would suggest using MDB
Yes my bad, after I went to production, I was told that backend was deprecated, is there any doc related to migrate from one backend to another or should I reconfigure the whole database from scratch ?
Thanks for your time and support, really appreciated. Regards.
2014-10-30 9:23 GMT-03:00 Andrew Findlay andrew.findlay@skills-1st.co.uk:
On Thu, Oct 30, 2014 at 08:11:31AM -0300, Net Warrior wrote:
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
Good.
3 ) Added olcTLSVerifyClient:demand to server side:
I suspect that you do not want that. It would force every client to have a client-side X.509 certificate. Good for secure authentication, but more effort to manage than most people are prepared to handle.
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
That is because you tried to add it to a database but it is a global option.
Are you really using the BDB database? It has been deprecated for some time now. I would suggest using MDB.
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 |
On Thu, Oct 30, 2014 at 09:54:57AM -0300, Net Warrior wrote:
I suspect that you do not want that. It would force every client to have a client-side X.509 certificate. Good for secure authentication, but more effort to manage than most people are prepared to handle.
Is it because of the certificte expiration or something like that tha's hard to mantain?
Yes. It is worth considering though, provided you have a well-organised system for distributing and installing new client-side certificates. You will also need to make sure that the admin tools you use can work with client-side certs.
That is because you tried to add it to a database but it is a global option.
I added to the global section cn=config and do not see it.
Odd. If you use ldapadd to do this then it should either work or return an error code.
Are you really using the BDB database? It has been deprecated for some time
now.
I would suggest using MDB
Yes my bad, after I went to production, I was told that backend was deprecated, is there any doc related to migrate from one backend to another or should I reconfigure the whole database from scratch ?
The safest approach is to slapcat each of your databases into LDIF files then configure new MDB databases and slapadd the data. You will find that loading MDB with slapadd -q is extremely fast.
Andrew
Am Mon, 27 Oct 2014 15:30:49 -0300 schrieb Net Warrior netwarrior863@gmail.com:
Thanks for the answer, but, from the query I shown, you can see that the DIT is displayed "namingContexts: dc=domain,dc=com" and knowking that, I can make a ldapserch -x pointing tho the server and the base search for example and list all the domain users, isn't it a security concern? I tested it and it works, how can I create an access list to prevent this, disable the simple auth or disable those anonymous queries ?
Thanks for your time and support.
If you allow an anonymous read access on a subtree, that in fact might be serious security issue, depending on the data. You, or your management, should define a policy, WHO is allowed to do WHAT on the directories data. Based on this written and agreed policy, access rules may be defined. This rules might be simple or paranoid, but that is the art of directory management.
-Dieter
openldap-technical@openldap.org
-
Andrew Findlay -
Dieter Klünter -
Michael Ströder -
Net Warrior