[Samba] Can't authenticate any more, KVNO mismatch? (alpha 17-19)
oliver.martin at ventum.com
Sun Apr 22 18:42:07 MDT 2012
we've been running a Samba4 domain with alpha17 for a few months now
without any problems. However, a few days ago, something happened and
now winbind can't authenticate against the domain any more. Strangely,
logging into (at least one) Windows box still works, even with a user
that was never used on this particular box before, and therefore can't
have any cached credentials. Trying to use the AD admin tools on that
Windows box fails again though.
The log file (with -d2) contains lots of the following errors
(vie-srv001.ventum.at is the DC), and another pair of messages is
appended every minute or so and every time I try to run the AD admin
tools on said Windows box. Nothing happens when I try to mount a Samba3
share that should authenticate against the domain.
[2012/04/23 01:58:29, 1]
GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see
text): Failed to find VIE-SRV001$@VENTUM.AT(kvno 3) in keytab
[2012/04/23 01:58:29, 1]
SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE
Indeed, klist -ke FILE:/usr/local/samba/private/secrets.keytab shows this:
Keytab name: WRFILE:/usr/local/samba/private/secrets.keytab
1 HOST/vie-srv001 at VENTUM.AT (ArcFour with HMAC/md5)
1 HOST/vie-srv001.ventum.at at VENTUM.AT (ArcFour with HMAC/md5)
1 VIE-SRV001$@VENTUM.AT (ArcFour with HMAC/md5)
The KVNO is always 1, instead of the 3 Samba seems to be looking for.
I found a few threads about similar problems:
In the first one, running upgradeprovision seems to have helped, but it
doesn't help here. I only tried it without --full though, since I'm a
bit scared of the side-effects --full might have. Could it help to try that?
The second problem seems to have arisen after joining a FreeNAS server
configured to have the same name as the DC. Somebody did in fact
recently install FreeNAS in our network too. I doubt he made the same
mistake (at least it's configured correctly now), but I'll ask.
I've tried upgrading to alpha19, but that didn't help either. I made a
backup of the old alpha17 install, so I can easily revert to it in case
it turns out to have made things worse. Running samba-tool dbcheck --fix
found only one error, but the problem persists after fixing it:
Checking 306 objects
Fix isDeleted originating_change_time on 'CN=Deleted
Objects,DC=ventum,DC=at' [y/N/all/none] y
Checked 306 objects (1 errors)
The only other thing that changed recently in our network is that we
installed MS Dynamics CRM on a W2K8 R2 member server, no idea if that's
related in any way. I don't think it tried to change the AD schema
though from what I've found about it, or at least about an older version
of that product.
Any ideas what's causing this?
More information about the samba