Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am trying to enable AD authentication for Debian stable servers to enable users to logon via ssh authenticating against Windows AD. It all works fine and I can ssh to the server using my Windows credentials but I have noticed this message on remote ssh logon when logging on as root:

Your account has been locked. Please contact your System administrator
Your account has been locked. Please contact your System administrator
Your account has been locked. Please contact your System administrator
Last login: Sat Jun 13 14:15:14 2009 from workstation1

I have checked if I can login via local console as root and oops, I cannot. Same error pops up. This could kick me painfully in the future. At the same time I have tried the same setup for RedfHat and I don't have this problem. I believe the problem is somewhere in my pam configuration but can't see where.googling for error does not get me anywhere either.

Below are details for corresponding pam files on Debian and redhat...

Debian Version


account sufficient require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
account sufficient require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
account sufficient require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
account required


auth    sufficient require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
auth    sufficient require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
auth    sufficient require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
auth    required nullok_secure


session required skel=/etc/skel/ umask=0022
session sufficient  require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX 
session sufficient require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXXX
session sufficient require_membership_of=S-1-5-21-602162358-1844823847-725345543-XXXXX
session required

RedHat system-auth file:

auth        required
auth        sufficient nullok try_first_pass
auth        sufficient use_first_pass
auth        requisite uid >= 500 quiet
auth        required

account     required
account     sufficient uid < 500 quiet
account     sufficient use_first_pass
account     required

password    requisite try_first_pass retry=3
password    sufficient md5 shadow nullok try_first_pass use_authtok
password    sufficient use_first_pass
password    required

session     optional revoke
session     required
session     required    use_first_pass
session     [success=1 default=ignore] service in crond quiet use_uid
session     required
session     optional skel=etc/skel/ umask=0027


# PAM configuration for the Secure Shell service

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth       required # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
auth       required envfile=/etc/default/locale

# Standard Un*x authentication.
@include common-auth

# Disallow non-root logins when /etc/nologin exists.
account    required

# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account  required

# Standard Un*x authorization.
@include common-account

# Standard Un*x session setup and teardown.
@include common-session

# Print the message of the day upon successful login.
session    optional # [1]

# Print the status of the user's mailbox upon successful login.
session    optional standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session    required

# Set up SELinux capabilities (need modified pam)
# session  required multiple

# Standard Un*x password updating.
@include common-password
share|improve this question
I took the liberty of reformatting your file configs for legibility. Some of the RedHat config was word-wrapping, making it difficult to read. Hope you don't mind. – Avery Payne Jul 3 '09 at 16:33
Thanks Avery! Really appreciate it! – Sergei Jul 3 '09 at 16:46

1 Answer 1

up vote 2 down vote accepted

For the love of ${Diety}, don't adjust the common-* parts of the PAM stack when experimenting with a new authentication setup. It is the fastest, easiest way to Hole Hawg yourself. You could potentially lock yourself out of the system permanently because of a chicken-and-egg scenario: you are locked out of the system, but you need to log into the system to make the changes needed to prevent you from being locked out.

Consider experimenting on a single service, like SSH (assuming you have console access nearby). Once you have the service prototyped/configured to your exact requirements, don't apply it right away to the common-* files, instead, consider what impact it will have on other system services. Remember, common-* acts as a "catch-all" for most configurations and a single mistake here means a visit to the rescue CD to get it unlocked again. Once you have a good handle on how the config will interact with different services that depend on the system's default(s), then apply it.

Another point to consider is that if you are making this change to common-* to facilitate SSO for all services on the box, it will not catch every service, some services have their own authentication setup and you'll need to check those as well.

As far as the console messages are concerned, what has happened is that winbind is contacting your AD controller, which is seeing excessive failed login attempts. After 15 attempts (which I believe is the out-of-box number MS uses) the account is locked for a period of time, unless an administrator unlocks the account. This is why you're getting "account locked" messages when you log in - the winbind portion of your stack is failing the authentication attempts, and the process "falls through" to the next step in the stack.

I would look hard at your winbind settings to determine that the authentication is truly succeeding in the first place. If you're submitting credentials from a domain member that the AD controller doesn't like, it doesn't matter if the password is correct or not - sooner or later, the account will lock because the request is originating from what is perceived as a non-domain member. The first thing to check would be winbind's join to the domain, as this will affect if the credentials are even looked at. I would also look at how your administrative account is handled by winbind - I seem to recall there were one or two additional settings that were required to ensure proper behavior (I'll dig them out and re-edit when I have them...)

I would also recommend setting up a secondary password on the local linux box, using /etc/passwd, so that you have "fail-though" athentication. Should the winbind service fail to authenticate (and it has in this case) /etc/passwd will pick up the slack and allow you in. The fact that you're able to still get in seems to indicate that you've already done this by setting the local password the same as the AD password for the account your using.

Also consider installing another safety valve in the form of a sudo entry, so that a single, specific account will allow you to switch into root via sudo su.

share|improve this answer
thank you for pointing this out Avery, but this is not exactly an answer to the problem.. In my case I just do vm snapshot everytime I do something suspicious that can lock me out of the system. – Sergei Jul 3 '09 at 16:52
added answer, sorry. Too many questions to bounce around in ... busy busy busy... – Avery Payne Jul 3 '09 at 16:54
But the problem is that AD logons work fine via ssh, as well as root.Problem starts when I logon as root from the console.So I am not sure what exctly is locked out - root account on the box?So how come I still can logon via ssh? – Sergei Jul 3 '09 at 16:59
Ok , I guess then this means that winbind tries to authenticate root against AD and cannot.i will double chack that default ssh pam has not been changed – Sergei Jul 3 '09 at 17:09
So it looks like ssh logons try to authenticate root via AD and fail over to shasow password and console login does not fail over – Sergei Jul 3 '09 at 17:13

Your Answer


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.