samba - Jun 2005 - net ads join fails on W2K3 server with latest MS patches

Hi All,

For the past few months I've been running a SUSE 9.2 server here
(mostly as an app server) which was a member of an AD domain
(w2k3 domain controller.) I used winbind to enable domain members
to log into the box, all was well.

This week the w2k3 server had some MS security patches applied
and suddenly logins became impossible, because winbind was unable
to retrieve user info from the AD. The linux box seemed to have
lost some trust relationships.

Naturally the w2k3 server was suspected, but as a first check
I removed the linux box from the ads domain (net ads leave)
and then re-added it. No dice (see logs below)

I have updated to 3.0.14a but with exactly the same result.

Here's what *is* working:

1) Kerberos authentication works (I can "kinit" successfully)

2) My account on the ADS domain has privilege to add machines
to the domain (I've added several Linux boxes before)

3) smbclient works.

4) The linux box does appear in the AD, but it the process
of joining doesn't complete.

5) Yes, I have tried removing old *.tdb files :)

Here's the end of the run of "net ads join -U xxxxxx -d 10"
where xxxxx is my user name. Various host names are also redacted.

----log start----
[2005/06/17 18:41:55, 4] libads/sasl.c:ads_sasl_bind(447)
  Found SASL mechanism GSS-SPNEGO
[2005/06/17 18:41:55, 3] libads/sasl.c:ads_sasl_spnego_bind(204)
  ads_sasl_spnego_bind: got OID=1 2 840 48018 1 2 2
[2005/06/17 18:41:55, 3] libads/sasl.c:ads_sasl_spnego_bind(204)
  ads_sasl_spnego_bind: got OID=1 2 840 113554 1 2 2
[2005/06/17 18:41:55, 3] libads/sasl.c:ads_sasl_spnego_bind(204)
  ads_sasl_spnego_bind: got OID=1 2 840 113554 1 2 2 3
[2005/06/17 18:41:55, 3] libads/sasl.c:ads_sasl_spnego_bind(204)
  ads_sasl_spnego_bind: got OID=1 3 6 1 4 1 311 2 2 10
[2005/06/17 18:41:55, 3] libads/sasl.c:ads_sasl_spnego_bind(211)
  ads_sasl_spnego_bind: got server principal name =xxx3$@XXX.LAN
[2005/06/17 18:41:55, 3] libsmb/clikrb5.c:ads_cleanup_expired_creds(318)
  Ticket in ccache[FILE:/tmp/krb5cc_0] expiration Sat, 18 Jun 2005 04:24:29
GMT
[2005/06/17 18:41:55, 10] libsmb/clikrb5.c:ads_krb5_mk_req(408)
  ads_krb5_mk_req: Ticket (xxx3$@XXX.LAN) in ccache (FILE:/tmp/krb5cc_0) is
valid until: (Sat, 18 Jun 2005 04:24:29 GMT - 1119065069)
[2005/06/17 18:41:55, 10] libsmb/clikrb5.c:get_krb5_smb_session_key(510)
  Got KRB5 session key of length 16
[2005/06/17 18:41:55, 10] lib/util.c:name_to_fqdn(2623)
  name_to_fqdn: lookup for yyyyyy -> yyyyyy.xxx.lan.
[2005/06/17 18:41:55, 0] libads/ldap.c:ads_add_machine_acct(1512)
  Warning: ads_set_machine_sd: Unexpected information received
[2005/06/17 18:41:55, 5] libads/ldap_utils.c:ads_do_search_retry(56)
  Search for (objectclass=*) gave 1 replies
[2005/06/17 18:41:55, 1] libads/krb5_setpw.c:parse_setpw_reply(237)
  Got error packet 0x7e from kpasswd server
[2005/06/17 18:41:55, 1] libads/krb5_setpw.c:do_krb5_kpasswd_request(450)
  parse_setpw_reply failed (Message stream modified)
[2005/06/17 18:41:55, 10] intl/lang_tdb.c:lang_tdb_init(135)
  lang_tdb_init: /usr/lib/samba/en_GB.UTF-8.msg: No such file or directory
[2005/06/17 18:41:55, 2] utils/net.c:main(902)
  return code = -1
----log end------

The crux of the matter seems to be the (non-fatal) failure on
ads_set_machine_sd()
but the actual death-knell is the failure of do_krb5_kpasswd_request() - I
seem to
recall that the "Message stream modified" is a low-level Kerberos
error?

Googling around reveals a handful of similar (though not identical problems,
most
with no published resolution. :-/

I'm happy to run various tests to provide more information, or to co-operate
with a developer if it turns out this is another little caltrop thrown under
the wheels by Redmond... :)

Vince




Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this 
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such 
privilege. Please advise the sender if you receive this e-mail by mistake.