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