I read your changes about db_config in the howto.
The db_config also applies to redhat and fedora and any other system that doesn’t have it in the dbd directory. The defaults are openldap defaults, not distribution defaults.
About the user on the LDAP server, he has no write rights at all, but can browse and read a lot, so that is a security risk.
The easiest way to prevent this is not to switch on ldap user authentication on the ldap server.
It is not a major issuefor now, but for the future, thinking of your plans, it might become an issue.
Maybe it doesn’t belong in this howto, but is worth remembering.
On 15/Mar/2008 11:07 Rob Tielen wrote ..
We installed our CentOS 5 test systems from scratch and followed the complete howto about combining Virtualmin and LDAP step by step.
The whole howto is perfect, everything works, even using an LDAP directory on a separate server.
There are two things worth mentioning in the howto:
First on Redhat/Centos systems the default in Webmin config in the LDAP client module for LDAP client configuration file is /etc/pam_ldap/auth_ldap.conf.
This should be changed to /etc/ldap.conf. I don’t understand where Webmin gets this from, but the default file doesn’t exist and because of that, the Webmin module is placed in unused modules.
Thanks for pointing this out - it seems that older Redhat-derived systems
used /etc/pam_ldap/auth_ldap.conf , but CentOS 5 and later uses /etc/ldap.conf
. Unfortunately, Webmin's default configs incorrectly were looking in
I'll fix this default in the next release.
Second it might be worth to mention to copy the db_config.example from /etc/openldap to /var/lib/openldap and rename it to db_config (on CentOS in this case, I don’t know about other distributions).
Not having this db_config file lets LDAP use the defaults and they give really bad performance.
This db_config file needs to be there before you start LDAP for the first time, otherwise you first have to recreate the compete dbd.
Thanks, I'll add this to the docs.
It also might worth mentioning that if you use (like we did) a separate LDAP server, you should watch out not to use LDAP users and groups on this LDAP server.
If a user created on the client server logs in to the LDAP server, his home directory doesn’t exist, but his userid does, so he is logged into the root directory.
This is a big security risk.
Surely normal Unix permissions will apply though, so he won't
have any access to files that he could if is home directory did exist?