Hi.
Sorry for my english...
So... I have installed OpenLDAP and nss_ldap. I'm using Slackware 12.
All works fine, I can search, add... getent works for passwd and group, etc.
But if I run 'su - username', the 'username' is found but seems password never work. I receive a 'Sorry' from su.
If I'm root and run 'su - username', all works fine... I become 'username' with my home directory, etc (id command show 'username' informations right too).
It seems to be something with password configuration, but... I don't know... I have 3 or 4 users, all with the same password. I tried all of them, and... the same problem.
I tried 3 "encryption" modes (md5, md5crypt and clear). I was change /etc/login.defs to disable MD5_CRYPT_ENABLE, enable again... and nothing works.
/var/log/debug show no errors.
I don't asking for a solution, just a way to still searching (I don't know where to go now).
[]'s Alexander Brazil - Rio de Janeiro
On Thu, 8 May 2008, =?ISO-8859-1?Q?AlexanDER Franca?= wrote:
Hi.
Sorry for my english...
So... I have installed OpenLDAP and nss_ldap. I'm using Slackware 12.
All works fine, I can search, add... getent works for passwd and group, etc.
But if I run 'su - username', the 'username' is found but seems password never work. I receive a 'Sorry' from su.
If I'm root and run 'su - username', all works fine... I become 'username' with my home directory, etc (id command show 'username' informations right too).
I think, all distributions do it differently, that's also the reason why noone here could help me with my problem(s) under Debian (now I've got most of them resolved in the meantime). I have no idea about Slackware, so, just speaking from the Debian point of view, and hoping, your case will not be very different.
Look under /etc/pam.d/. There you see configuration files for various services, including su, login, ssh, etc. If you look into those files (at least on Debian) they all have lones like
@include common-auth @include common-account @include common-session
So, here I only had to modify those three common files, and then all services worked automatically. So, that's where I would look - whether "su" includes all those three files (if Slackware does it similarly), and if it looks similar enough to other files. Nothing concrete, sorry.
Regards Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer
So, here I only had to modify those three common files, and then all services worked automatically. So, that's where I would look - whether "su" includes all those three files (if Slackware does it similarly), and if it looks similar enough to other files. Nothing concrete, sorry.
Hi.
Thanks, but Slackware don't use PAM...
But you help me telling to treat the services separatelly.
I'll try other services than su and see what happens.
[]'s Alexander Brazil - Rio de Janeiro
Hi. Thanks, but Slackware don't use PAM... But you help me telling to treat the services separatelly. I'll try other services than su and see what happens. []'s Alexander Brazil - Rio de Janeiro
Hello Alexander,
Can you log onto the machine with the users in question? For if you cannot, then this sounds a bit like what we had here: In our Solaris 10 environment and it turned out that it was an issue with an ACL:
The following solved the problem for us access to attrs=userpassword by self write by * read by anonymous auth
whereas this was too restrictive: #access to attr=userpassword by self write by self read by anonymous auth
So, Solaris needed to be able to read the password.
If you have other ACLs in place, perhaps one of those is creating this situation.
Btw, su-ing from root does not check anything; if you are root and su to a user, you can simply do it, you are root, after all.
Hope this helps, Claus
Hi.
Now it works.
My problem was in acl's... or better... /etc/ldap.conf haven't any information about rootdn, binddn and rootpw.
After configure the user who will bind the server, and fix acl to that user (to get userPassword attribute), su becomes to login users.
Thanks!
[]'s AlexanDER
Tue, 13 May 2008 15:00:25 +0200, "Kick, Claus" claus.kick@siemens.com escreveu:
Hi. Thanks, but Slackware don't use PAM... But you help me telling to treat the services separatelly. I'll try other services than su and see what happens. []'s Alexander Brazil - Rio de Janeiro
Hello Alexander,
Can you log onto the machine with the users in question? For if you cannot, then this sounds a bit like what we had here: In our Solaris 10 environment and it turned out that it was an issue with an ACL:
The following solved the problem for us access to attrs=userpassword by self write by * read by anonymous auth
whereas this was too restrictive: #access to attr=userpassword by self write by self read by anonymous auth
So, Solaris needed to be able to read the password.
If you have other ACLs in place, perhaps one of those is creating this situation.
Btw, su-ing from root does not check anything; if you are root and su to a user, you can simply do it, you are root, after all.
Hope this helps, Claus
openldap-technical@openldap.org
-
AlexanDER Franca -
Guennadi Liakhovetski -
Kick, Claus