I am using OpenSuse 11.2 and Samba/Kerberos to authenticate to a Active Directory Domain Server. It works fine if the enter the correct password, but if I enter an incorrect password samba keeps trying to used the same credentials to authenticate, and after five attempts AD locks out the account. I verified this with wireshark. I can't find any configuration options to limit attempts to one and then ask the client to renter the password.

Not a networking question, moved to Linux - Newbie.

I tried changing the pam configuration:

auth required pam_winbind.so try_first_pass

instead of "use_first_pass" -> see "#man pam_winbind"

but it doesn't work yet.

I am not sure whether winbind itself is retrying with the wrong password or winbind is beeing invoked several times with that wrong password instead of failing the complete chain. But i lack of a clear understanding of how winbind is invoked by pam and that is invoked by sshd.

I found this figure explaining Samba / Linux and AD integration and ask myself whether pam->winbind is actually the path the ssh login takes:
http://sman.informatik.htw-dresden.d...sec.ad.bg.html

Could this be an issue with "...wrong_pass.." returning from AD is not beeing interpreted correctly by winbind?

Edit: I have postred that issue to the opensuse forums, maybe someone over there has an idea:
http://forums.opensuse.org/get-help-...d-attempt.html

A few things I noticed.

Besides OpenSuse we also have some servers with Suse Enterprise Server, and they do not have the problem. If I try to login with an invalid password the client tries once and asks me for the password again. Oddly the pam authorization looks like this:

auth required pam_env.so
auth required pam_unix2.so
~

so I do not even see how winbind or kerberos is even being invoked.

On OpenSuse the pam authoization looks like this:

auth required pam_env.so
auth optional pam_gnome_keyring.so
auth sufficient pam_unix2.so
auth sufficient pam_krb5.so use_first_pass
auth required pam_deny.so

On my OpenSuse system it does not matter is winbind is active or not, things works the same either way.

When I run a packet trace between the client and the domain controller, I see the client trying to use the same password eight times before quitting, unless active directory is configured to lock the account after less than eight tries, in which case entering the password incorrectly always locks the account.

Hi chapan,

this is the content of my /etc/pam.d/common-auth

auth required pam_env.so
auth sufficient pam_unix2.so
#auth required pam_winbind.so use_first_pass
auth required pam_winbind.so try_first_pass

which version of SuSE Enterprise are you running?

Version 10 with SP3.

I got it to work. First of all I added debug to the auth_common file:

auth sufficient pam_krb5.so try_first_pass debug

When I logged in with an invalid password, I saw this message in /var/log/messages"

Authentication failure (Looping detected inside krb5_get_in_tkt)

I went here http://web.mit.edu/kerberos/ to get the kerberos source code. When I unpacked all the files, I found file "get_in_tkt.c'. I looked at the source code and found this line:

#define MAX_IN_TKT_LOOPS 16

I changed the 16 to a 2 and did the normal "./config" "./make" "./make install" which installed new kerberos lib files in /usr/local/lib.

I then went here http://sourceforge.net/projects/pam-krb5/ and got the pam_krb5 source code. I installed with "./configure --with-krb5=/usr/local/lib", "make", "make install" which installed a new pam_krb5.so in /lib/security.

I set up common-auth as:

auth required pam_env.so
auth optional pam_gnome_keyring.so
auth sufficient pam_unix2.so
auth sufficient pam_krb5.so try_first_pass
auth required pam_deny.so

and common-account as:

account sufficient pam_unix2.so
account sufficient pam_krb5.so use_first_pass ignore_unknown_principals

I tried logging in with an invalid password and it only tried the password once before asking for another login.

The only other thing I had to do was on the 64-servers, I copied pam_krb5.so from /lib/security to /lib64/security, and that seemed to work ok.