When upgrading to 3.4.2 from 3.2.5, I've changed "use kerberos keytab = yes" to "kerberos method = system keytab" and I'm not able to login using an Active Directory domain account. I see this in the error logs: [2009/10/20 12:46:52, 1] libads/kerberos_verify.c:190(ads_keytab_verify_ticket) ads_keytab_verify_ticket: krb5_kt_start_seq_get failed (Permission denied) [2009/10/20 12:46:52, 1] libads/authdata.c:450(kerberos_return_pac) ads_verify_ticket failed: NT_STATUS_LOGON_FAILURE net ads keytab commands work without a problem and there seems to be no unusual permission issues with the system keytab file at /etc/krb5.keytab. If I comment out the kerberos method = system keytab then I am once again able to log in. If I delete the keytab, then I get: [2009/10/20 15:02:01, 1] libads/kerberos_verify.c:190(ads_keytab_verify_ticket) ads_keytab_verify_ticket: krb5_kt_start_seq_get failed (No such file or directory) [2009/10/20 15:02:01, 1] libads/authdata.c:450(kerberos_return_pac) ads_verify_ticket failed: NT_STATUS_LOGON_FAILURE If I create a new keytab 'net ads keytab create -P', I get a new keytab with the right SPNs. When I try to log in, I get the permission denied messages as above. I'm not sure what to look at to try to fix the problem.
If Kerberos is set-up correctly I can SSH into a machine that is using "kerberos method = system keytab" using kerberos tickets just fine. If I have to use password authentication whether on the console or SSH, it doesn't work. Hopefully that helps find the bug. I haven't had time to try to figure out the code myself yet.
Robert - thanks for your bug report! Günther: could you have a look? Thanks! Cheers - Michael
I have the exact same problem myself with 3.4 that I never had with 3.0, 3.2 or 3.3. I can confirm that commenting out "kerberos method = system keytab" helps. I had also noticed that pam_winbind works fine if you leave out the krb5_auth related settings. But I had no problem using kinit to get a ticket for my user principal. I had a feeling the system keytab generated by "net ads keytab create" was the problem, as "kinit -k" wouldn't authenticate. Active Directory would have preauthentication errors even if preauthentication was turned off for the user account. More details: OS: Ubuntu 9.10 AMD64 (which uses 3.4.0 + some bug fixes). I've successfully used many previous versions of Ubuntu (and Debian) against the same Active Directory domain. The desktop only has the winbind and samba-common packages installed (no samba server package). KDC: Windows 2003 (SBS) with the SFU 3.5 schema extensions. There is only one domain/realm on the network. smb.conf: [global] workgroup = EXAMPLE realm = EXAMPLE.COM preferred master = no security = ADS winbind enum users = Yes winbind enum groups = Yes winbind use default domain = Yes winbind nested groups = Yes winbind nss info = sfu winbind offline logon = true winbind refresh tickets = true idmap backend = tdb idmap uid = 50000 - 50999 idmap gid = 50000 - 50999 idmap config EXAMPLE:backend = ad idmap config EXAMPLE:readonly = yes idmap config EXAMPLE:default = yes idmap config EXAMPLE:schema_mode = sfu idmap config EXAMPLE:range = 10000 - 19999 kerberos method = system keytab Everything else seems to work - eg: testparm net ads join ... net ads testjoin net ads keytab create wbinfo -u wbinfo -g pam_winbind without kerberos kinit (but not kinit -k) etc Let me know if I've left anything out...
After some more digging: I don't think the keytabs themselves are the problem. I can most of the time get a working keytab from "net ads keytab create". I have noticed though that the problems with "kerberos method = system keytab" or "kerberos method = dedicated keytab" only appear when "krb5_ccache_type=FILE" is specified in the pam_winbind config. If smb.conf specifies a dedicated or system keytab, pam_winbind will work (for me at least) via kerberos using "krb5_auth", and only fails once you tell it to create a credential cache. So it seems as though the problem appears when using a combination of a keytab and a credential cache.
I have confirmed that removing krb5_ccache_type=FILE allows both Kerberos logins and password challenged logins. We would like to have this option. Thanks.
Some more info: I've also run into this with Ubuntu 10.04 which ships winbind 3.4.7. I don't know of this is distro specific - I'll be testing that soon. Something else I've discovered is that it seems related to being able to read the system keytab file. Normally the system keytab is sensitive and should only be able to be read by root, and when winbind creates the keytab this is the case. But winbind 3.4 seems to require that the user account logging in also needs to be able to read the keytab file. If I make the system keytab world readable (which isn't a good idea) suddenly pam_winbind works again. I would have assumed that only the winbind daemon itself (running as root) needs to read the keytab file. Another way to demonstrate this: Start with only root being able to read the keytab (the default permissions). Try authenticating a kerberos UPN / Windows domain account as a non root user $ wbinfo -K anton Enter anton's password: plaintext kerberos password authentication for [anton] failed (requesting cctype: FILE) error code was NT_STATUS_LOGON_FAILURE (0xc000006d) error messsage was: Logon failure Could not authenticate user [anton] with Kerberos (ccache: FILE) Try the same again, but as root $ sudo wbinfo -K anton Enter anton's password: plaintext kerberos password authentication for [anton] succeeded (requesting cctype: FILE) credentials were put in: FILE:/tmp/krb5cc_0 Now change permissions of the keytab and try again without root permissions $ sudo chmod 644 /etc/krb5.keytab $ wbinfo -K anton Enter anton's password: plaintext kerberos password authentication for [anton] succeeded (requesting cctype: FILE) credentials were put in: FILE:/tmp/krb5cc_10000 (Note: wild unsubstantiated guess) It almost seems as though winbind is switching to the non root user before it reads the keytab file. One other baffling data point that I haven't fully reproduced yet: Systems that have upgraded from pre 3.4 Samba versions don't seem to have this problem despite having practically identical settings and permissions.
After some more testing with Samba built from source tarballs (both 3.4.8 and 3.5.2) on a clean system, I still get the same results. So it doesn't seem to be an Ubuntu packaging issue. Summary: With Samba 3.4 and 3.5, the system keytab needs to be world readable when using "kerberos method = system keytab" in smb.conf. These insecure keytab permissions weren't required with 3.3 and earlier.
SOLVED (mostly). After browsing the source code where this behaviour changed in 3.4, I found this comment: case KERBEROS_VERIFY_SECRETS_AND_KEYTAB: /* First try secrets.tdb and fallback to the krb5.keytab if necessary. This is the pre 3.4 behavior when "use kerberos keytab" was true.*/ So it turns out that "kerberos method = secrets and keytab" is the proper match to the old "use kerberos keytab = true" rather than "kerberos method = system keytab" (or dedicated keytab). SOLUTION: Using "kerberos method = secrets and keytab" gives me my desired result. I'm not sure what the intended behaviour for "system keytab" is, so I'm not sure if the permissions/ccache situation is actually by design or not (eg if it is only supposed to be used as root). Could this be documented better? There isn't really much in the smb.conf man page or the release notes that indicates which setting matches 3.3 and earlier or what system keytab will/won't do.
Just ran into this on debian squeeze as well. Setting secrets and keytab fixed the issue.