Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I just followed this guide on how to setup Ubuntu to authenticate with an Mac OS X 10.4 server. I followed the guide 100% and was left with the ability to see users by running

getent passwd
and
getent passwd (user)

Which would come up with all the right information about the user. My problem is that I want those users to be able to login through the login prompt, which isn't working. When I login as my local user though, I get the usual username and password prompt, but then I get an LDAP password prompt, where I can type in anything and still login successfully.

Any ideas on how to solve this? Thanks in advance!

Updates:

As mentioned below, I'm positive LDAP is setup correctly, since I can see all the LDAP users using getent passwd, but something else is going wrong since I cant use su, ssh, or gdm to login with these users.

share|improve this question
    
Can you post a link to the guide you followed? –  Kamil Kisiel Aug 25 '09 at 17:22
3  
The 'this' in his question is a link. –  oneodd1 Aug 25 '09 at 17:31
add comment

3 Answers

up vote 2 down vote accepted
+100

the problem is that that guide is wrong, or at least sub-optimal.

/etc/pam.d/common-auth should have:

auth sufficient pam_unix.so nullok_secure nodelay
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

that says that either pam_unix or pam_ldap are sufficient to login, and any login failing both of those is denied. it tries local unix login first - which is extremely useful if your LDAP server is down or unreachable and you still need to login as a local user.

it also uses 'use_first_pass' rather than 'try_first_pass'...they are very similar except that it won't prompt for a password again if the first is wrong.

see the man pages for pam_unix and pam_ldap for more details.

BTW, adding the following to /etc/pam.d/common-session is very useful:

session required pam_limits.so

it allows you to use /etc/security/limits.conf and access.conf etc to have very fine control over which users are allowed to login (e.g. i limit ssh logins on my servers to members of the admins group), and also set resource limits (memory, maxlogins, nice priority, etc) for their login.

share|improve this answer
    
You're right about pam_limits.so being handy, and about use_first_pass. auth sufficient pam_ldap.so auth required pam_unix.so does the same thing as the modules you're using though. to quote the man page on sufficient: success of such a module is enough to satisfy the authentication requirements of the stack of modules So if pam_ldap.so passes, the user gets in. If it fails pam_unix.so is tried, and auth. returns failure if that isn't successful. Same effect as your choice of modules. –  Cian Aug 27 '09 at 23:03
    
yep, the order is important (sufficient has to come before required). i still prefer to use sufficient because it more clearly expresses the intent. also, it's safer to have the exceptions ("sufficient" rules) before the default ("pam_deny") –  cas Aug 27 '09 at 23:13
    
It's in no way safer to have two sufficients, and then pam_deny, than to have a sufficient, and a required. They're exactly the same, in effect (at least, if you don't add extra stuff after the required). –  Cian Aug 31 '09 at 9:18
    
This did the trick but I've come across another problem. Right now, we have it setup so that when a user logs in on a mac, it mounts the user's home directory on the OS X server, so when a user tries to login on a ubuntu machine, it tries to use the mac's home directory path (/Volumes/Network_Server... etc), which obviously fails. Is there any way around this? –  Steve Gattuso Aug 31 '09 at 16:41
    
@cian: that's why it's safer - it's clearer and easy to see what the intent is, which makes it harder to make a mistake. human-error is a factor to be considered and made less likely. –  cas Aug 31 '09 at 21:49
show 1 more comment

Is the order correct in your common_(whatever) in /etc/pam.d/common-(whatever)? Check both these and /etc/pam.d/login and make sure that nothing marked 'required', or 'requisite' is above them.

Also, have you edited both /etc/ldap.conf and /etc/ldap/ldap.conf to reflect your ldap setup? If none of these work, you could try posting the log snippets from the failed logins, and possibly from the attempted binds on the LDAP server.

Note, that the fact that you can see users in getent passwd doesn't mean that you have ldap set up correctly. It means you have nss_ldap set up properly. Authentication is done by a separate module pam-ldap.

share|improve this answer
    
Yeah, everything is in order as it should be, still not authenticating. /etc/ldap.conf is definatly setup, since I can see all the users in getent passwd –  Steve Gattuso Aug 27 '09 at 18:12
    
What about /etc/ldap/ldap.conf? I believe PAM and NSS read different files for their ldap config. –  Cian Aug 27 '09 at 19:31
1  
The information in getent comes from NSS, which is totally seperate to PAM. PAM is what you need to work in order to login. –  theotherreceive Aug 27 '09 at 19:37
    
edited to better explain difference between pam and nss. –  Cian Aug 31 '09 at 9:17
add comment

Do you use anonymous binding with your LDAP server? Getting a list of users and authenticating them against an LDAP server is handled by 2 separate packages. Could you post your /etc/ldap.conf and and any related errors?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.