samba - Apr 2012 - Can't authenticate any more, KVNO mismatch? (alpha 17-19)

Hi all,

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] 
../source4/auth/gensec/gensec_gssapi.c:639(gensec_gssapi_update)
   GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see 
text): Failed to find VIE-SRV001$@VENTUM.AT(kvno 3) in keytab 
FILE:/usr/local/samba/private/secrets.keytab (arcfour-hmac-md5)
[2012/04/23 01:58:29,  1] 
../auth/gensec/spnego.c:574(gensec_spnego_parse_negTokenInit)
   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
KVNO Principal
---- 
--------------------------------------------------------------------------
[...]
    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:
https://lists.samba.org/archive/samba-technical/2010-September/073075.html,
http://www.spinics.net/lists/samba/msg101195.html

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?

Regards,
Oliver

Hi,

Am 23.04.2012 02:42, schrieb Oliver Martin:
> 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.
Just a quick follow-up: I solved our problem. Something had changed the 
DC object in the Domain Controllers OU, causing the mismatch. I restored 
that object from a recent backup using ldbedit, and now everything is 
working again.

The most likely candidate for the root cause seems to be the recent 
FreeNAS install, which, as I heard, failed. Maybe something did get 
mixed up there at first.

Regards,
Oliver