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
.
Okay, I found the solution for that one. First : I would strongly recommend anyone getting into this to study PAM modules basics. This really helps understanding the whole thing. Now, let's have a look at my common-*
files. They all have the same structure :
facility required pam_unix.so [...]
facility sufficient pam_mysql.so [...]
Now, after reading more about PAM modules, this looks ridiculous to me. Here is some documentation about the PAM control flags :
required : if the module succeeds, the rest of the chain is executed, and the request is granted unless some other module fails. If the module fails, the rest of the chain is also executed, but the request is ultimately denied.
sufficient : if the module succeeds and no earlier module in the chain has failed, the chain is immediately terminated and the request is granted. If the module fails, the module is ignored and the rest of the chain is executed.
Basically, my configuration makes PAM behaves in the following way : the UNIX authentication through /etc/passwd
and /etc/shadow
must succeed in all cases. The MySQL lookup will also be performed, yet if the UNIX authentication failed, its result won't be taken into account.
With this setup, the MySQL authentication mechanism is rendered useless in all situations. A proper configuration would be :
facility sufficient pam_mysql.so [...]
facility required pam_unix.so [...]
Which tells : The MySQL authentication mechanism is sufficient. If it succeeds, no further mechanisms are to be tested. If it fails however, the UNIX authentication must succeed. Since I'll have more MySQL users than UNIX users, it is more logical to authenticate against MySQL first.
It is also important to note the difference in the roles of PAM and NSS. With my setup, the authentication was perfectly functional since the NSS configuration was correct. NSS handles basic UNIX authentication, but not account/session management, nor service-specific (SSH/FTP/...) connections. All these are handled by PAM. This separation is the reason why it was possible for root
to connect as a MySQL user : the NSS did find the entry, and since root
does not need to authenticate against anything to take a user's identity, PAM modules were never called.
Best Answer
You cannot allow or deny authentication with pam_exec. What you should do is add something like
just above the google authetnicator line and in
/etc/security/access.conf
put