Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

We are preparing 12.04 LTS for our userbase and have done some basic configuration to the login screen (disabled guest account, removed user list, etc). However, one thing that I've noticed is that once a user has authenticated at the login screen (KRB5), a user will no longer have to enter their password. In fact, even after reboot, if a user has previously authenticated, all they have to do is type their username and they can login with no other prompts.

Obviously this is a major security risk at the enterprise level. Please let me know if you need any other information. Any advice would be greatly appreciated!

Thanks for your consideration, but we've realized it is a GID conflict. We have an LDAP group with GID 112, which happens to be the GID of the nopasswdlogin group at least in Precise. We'll be migrating that LDAP group to another GID. This is just an FYI if others see this behavior by chance. I can't close this for another few hours.

share|improve this question
    
Is the password being cached, or is it just not required? Perhaps this is a problem with pam-auth not requiring a password at all. Check out etc/pam.d/common-auth. –  Chris May 15 '12 at 19:57
    
not too familiar with this file. It's just not prompting for a password after the first successful login. Here's what I see: root@host:~# less /etc/pam.d/common-auth \n auth [success=3 default=ignore] pam_krb5.so minimum_uid=256 \n auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass auth [success=1 default=ignore] pam_ldap.so use_first_pass auth requisite pam_deny.so auth required pam_permit.so –  Jonathan Lent May 15 '12 at 19:59
    
I wanted to add that this file is identical on our 10.04 hosts, which do not exhibit this behavior. thanks! –  Jonathan Lent May 15 '12 at 20:15
    
Does not seam to be the problem. Just a thought as an incorrectly configured pam-auth can subvert passwords. –  Chris May 15 '12 at 20:34
add comment

1 Answer 1

we've realized it is a GID conflict. We have an LDAP group with GID 112, which happens to be the GID of the nopasswdlogin group at least in Precise. We'll be migrating that LDAP group to another GID. This is just an FYI if others see this behavior by chance. I can't close this for another few hours.

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.