No Users Can Log In; Only Root Can
 

Can't Log In to Linux

I have Fedora Core 5 and at some point in the past few weeks something has changed, to the effect that normal users cannot log in.
(Possibly, something done by a yum update caused this; I was chasing another problem at the time* and cannot be more specific about the source of the trouble.)
I found a detailed discussion on Tech Republic but no resolution to that person's problems. My symptoms are identical:

Root can log it both on GUI or command line. No user other than root can log in.
On a GUI log in attempt, an "Authentication failed" error box pops up. On command line, the error message "Error in service module" appears, very briefly, and the command line interface clears to the next log in attempt.
Interestingly, at the command line the response differs for a valid verus and invalid password attempt:
For the username's valid password, the "Error in service module" appears briefly then the login screen resets to a first-log in attempt.
For the username's password entered incorrectly, "Incorrect password" appears, does not blank and a new login attempt is presented.
It looks like something in the system recognizes the correct password -- but it does not permit login.

Other discussion have revolved around SELinux versus PAM. I have SELinux set to Disabled. It has been that way for a long time, and I don't think it has anything to do with this problem.

Entering the command: # tail -100 /var/log/messages reveals that
QUOTE
[pam_winbind] request failed, but PAM error 0!
[pam_winbind] internal module error (retval = 3, user = 'username')
UNQUOTE
appears at each attempted login (with the username's correct password.

Interestingly, I have a CRON job with fired off within the time period of the tail end of the logfile, and
QUOTE
[crond] Error in service module
[crond] CRON (username) ERROR: failed to open PAM security session: Success
[crond] CRON (username) ERROR: cannot set security context
UNQUOTE
appears within the last couple of lines of the logfile.

The other discussion suggested using 'trace' (or 'strace') to get a dump on what's happening to the command
# su - username
but it seems my system does not have either trace or strace installed.

Here is my /etc/pam.d/login file:
#%PAM-1.0
auth required pam_securetty.so
auth include system-auth
account required pam_nologin.so
account include system-auth
password include system-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session include system-auth
session required pam_loginuid.so
session optional pam_console.so
# pam_selinux.so open should be the last session rule
session required pam_selinux.so open
just now copied off my system.

I have tried creating testusers, and the results are the same.

I can (and have) modified the user accounts either from the GUI User Manager, or by setting passwords from command line passwd. From everthing I can tell, it seems all the changes are being entered properly. That is, the /etc/passwd and the /etc/shadow files both seem to be in order. (Changes can be detected in these file when entered in User Manager, and so on.)

Does anyone have any idea what might be going wrong here? Thanks,

- Bill

(P.S. * That "other problem" was that the message bus took over ten minutes to start on boot up, and essentially the Power Manager utility really prevented use of the GUI for normal users. After a lot of searching, I found on another board to disable LDAP in various conf files, and that cleared the problem. But I had the message bus / LDAP problem for over two months before this inability to log in showed up, and now I have cleared the LDAP problem but still cannot authenticate a log in password. I really don't think the two are connected, but wanted to mention it here just in case I'm wrong.)

is /etc/securetty file empty?

I had a similar problem with Fedora Core 5. You may want to check your selinux configuration. Good luck.

Contents of /etc/securetty
 

Here's the contents of my file as it now exists:
--------------
console
vc/1
vc/2
vc/3
vc/4
vc/5
vc/6
vc/7
vc/8
vc/9
vc/10
vc/11
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10
tty11
--------------
What should it look like? What does this file do?

As stated earlier, I have SELinux disabled, so I am sure that has nothing to do with it. In any case, nothing has changed with SELinux; it was disabled before I moved from FC4 to FC5, and at first (in FC5) I did not experience this trouble logging in.

I noticed that there is an uncommented line dealing with pam_selinux even though you said you disabled selinux, however it is a system group control. You may want to read through your system-auth file that pam.login includes. The errors in /var/log/messages indicates a winbind problem. Is the winbind service running. What does samba use for account information. It is possibly a networking problem if for example another server supplies account information.

I also noticed this problem today after doing a full yum update, the problem lies in the file /etc/pam.d/system_auth, I commented out the following line , which looks incorrectly written:

#account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_winbind.so

This should read

account sufficient /lib/security/$ISA/pam_winbind.so

I guess this was a typo in the latest release.

Works fine now.

Cod

THANK YOU! This worked perfectly!

- Bill

I know this thread is a little old, but I wanted to confirm the fix for the aformentioned problem. I had the same problem on FC6 and fixed it in a similar fashion. The only difference is that on my FC6 box, the line reads as follows:

account [default=bad success=ok user_unknown=ignore] pam_winbind.so

I changed this to:

account sufficient pam_winbind.so

and issue was resolved.

It may seem obvious that the path stays the same in the corrected line, but I wanted to display this for those who didn't catch the obvious.

Good Luck

Colonboy

root login only
 

I ran into this problem with pam updates to CentOS 6.2.

I found that certain pam files had been updated and in different sections but all containing the phrase:

"[default=bad success=ok user_unknown=ignore]"

in the line. when I commented out those lines (too tired to figure out the correct syntax ) the login problem was resolved.

I just register to say thank you, to all you, wherever you are right now, and after all this time.

20 years later you manage to solve my problem.

Best regards,

Alejandro.