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