Bug 6833 - Can not login with AD account when system keytab is used
Summary: Can not login with AD account when system keytab is used
Status: NEW
Alias: None
Product: Samba 3.4
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.4.2
Hardware: x64 Linux
: P3 major
Target Milestone: ---
Assignee: Guenther Deschner
QA Contact: Samba QA Contact
Depends on:
Reported: 2009-10-20 16:05 UTC by Robert LeBlanc
Modified: 2012-02-13 17:46 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Robert LeBlanc 2009-10-20 16:05:40 UTC
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.
Comment 1 Robert LeBlanc 2009-10-30 17:22:46 UTC
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.
Comment 2 Michael Adam 2009-11-20 18:16:01 UTC
Robert - thanks for your bug report!

Günther: could you have a look? Thanks!

Cheers - Michael
Comment 3 Anton D 2009-12-07 20:47:54 UTC
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.


   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:

net ads join ...
net ads testjoin
net ads keytab create
wbinfo -u
wbinfo -g
pam_winbind without kerberos
kinit (but not kinit -k)

Let me know if I've left anything out...
Comment 4 Anton D 2009-12-08 19:23:21 UTC
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.
Comment 5 Robert LeBlanc 2009-12-18 18:09:27 UTC
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.
Comment 6 Anton D 2010-05-11 19:58:20 UTC
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.
Comment 7 Anton D 2010-05-12 07:37:10 UTC
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.


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.
Comment 8 Anton D 2010-05-12 22:58:08 UTC
SOLVED (mostly).

After browsing the source code where this behaviour changed in 3.4, I found this comment:

    /* 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.
Comment 9 mchugh19@yahoo.com 2012-02-13 17:46:43 UTC
Just ran into this on debian squeeze as well. Setting secrets and keytab fixed the issue.