[Samba] Winbind separator char causing make_server_info_from_pw failed errors

[malk at sidehack.sat.gweep.net]

Hi all-

In migrating from 3.0.2 to 3.0.8 on a box that's an ADS domain member, I
had a relic line in smb.conf like this:

   winbind separator char = -

With 3.0.2, users connecting wouldn't have a domain and separator char
component, so spnego kerberos replies to the 2003 domain controller
would be fine.

In 3.0.8, users connections would have the domain and separator char
for spnego kerberos replies and if the separator is something other than
the default of \, it will cause errors like this:

[2004/12/13 17:44:21, 1] smbd/service.c:make_connection_snum(648)
  192.168.171.131 (192.168.171.131) connect to service debian-mirror initially as user VIASAT-emalkowski (uid=10356, gid=10000) (pid 11519)
[2004/12/13 17:44:22, 1] smbd/sesssetup.c:reply_spnego_kerberos(265)
  make_server_info_from_pw failed!
[2004/12/13 17:44:24, 1] smbd/sesssetup.c:reply_spnego_kerberos(265)
  make_server_info_from_pw failed!
[2004/12/13 17:44:24, 1] smbd/sesssetup.c:reply_spnego_kerberos(265)
  make_server_info_from_pw failed!
[2004/12/13 17:44:24, 1] smbd/sesssetup.c:reply_spnego_kerberos(265)
  make_server_info_from_pw failed!
[2004/12/13 17:44:24, 1] smbd/sesssetup.c:reply_spnego_kerberos(265)
  make_server_info_from_pw failed!


It seems the VIASAT-emalkowski is confusing windows -- it would rather see
VIASAT\emalkowski.

Anyway -- I simply removed my winbind separator char override from smb.conf
as I use "winbind use default domain = yes" anyway making the separator
setting a relic from the days I had DOMAIN-usernames in the pw entries winbind
provided.

Perhaps a note in the documentation might be a good idea to warn the user
about changing the winbind separator char from "\" and how it could cause
errors like above since the separator is affecting what gets sent back
as the username to a windows domain controller and anything other than "\"
will seems to cause havoc.

Hope this post will help anyone having similar problems ... this one
didn't seem too obvious to me until I noticed the DOMAIN-username in the logs
on 3.0.8, but only username in the logs on 3.0.2.  Once DOMAIN\username
was in the logs, all was well.

-Eric Malkowski