One of the ADS member scenarios advertised is Samba with 3rd party NSS and PAM
modules and no WINBIND.
However if 3rd Party NSS responds to REALM\User then Winbind is required to
look up groups
sesssetup.c : reply_spnego_kerberos() tries to map the REALM name embedded in
the PAC data into an NTLM Domain name by calling WINBIND. When this fails,
Samba logs "Could not find short name -- winbind not running?".
In this case, Samba forms the name REALM\user, i.e. SAMBA.ORG\user rather than
the expected SAMBA\user - probably a bug - but okay.
The name is then handed to getpwnam(). If the 3rd party NSS responds to the
REALM\user form (necesary for Forests and Trusted Domains) the name stands,
and later in AUTH_UTIL.C : get_user_groups(), Samba checks for the '\', in the
user name and if present again tries to call Winbind to get the user groups.
When this fails because Winbind is not loaded, Samba fails the authentication -
the motivation for this bug report. I believe the correct behavior is that if
the Winbind lookup fails, the should continue on and try the get_group_list
methods so that that 3rd party NSS can get a crack at it.
If the 3rd party NSS ignores the REALM\user, Samba will eventually strip the
REALM and just submit the user. This works around the problem above requiring
Winbind. However we then are limited to only the users within the local domain
and lose support for trusted domains and forests.
If the 3rd party NSS module, supports DOMAIN\user
format, then you would need to talk to those
developers. I'm not sure how you loose trusted domains
as the same code path should eventually fall back
to performaing a simple getpwnam(user) call just as
for users in our domain.
Can you give me more details on how the trusted users
are failing ?
Note there are 2 related problems here for Kerberos authentication
1) If winbind is not running REALM cannot be translated to NTLM DOMAIN to form
a proper DOMAIN\USER (you get a "Winbind not running?" message). Not good but
not sure how you would fix this.
2) Once any NSS responds to DOMAIN\USER or (malformed) REALM\User, SMBD
assumes it was winbind. Later when it goes to lookup the groups for the user
its specifically looks at the user name for the '\' character and if it is
there it does a direct call into winbind to get the groups. Since winbind is
not running get_user_groups() fails - SMBD gives up (it does NOT call the
normal Unix get_group_list functions) and fails the logon.
Now if Winbind is NOT running and no one (rightfully) responds to REALM\USER,
Samba will eventually strip it down to just USER, and a third party NSS can
then respond to it. Unfortunately, the domain that user user belongs to is
now lost - so unless the third party NSS has some way of guessing the domain
it has to assume that the user is in the local domain - breaking trusted
As a third party NSS developer I guess I am asking that
1) Some way other than winbind be used to translate REALM to DOMAIN - (but I
could support REALM\USER if I really have to).
2) If the group lookup for Winbind fails - don't just give up - try the normal
Unix functions too, so I have a chance to find the groups.
Thank you for your attention - I am sure you have heard it before but Samba is
simply fantastic! Its incredible what you guys have done here in your spare
time. I use Samba every day. Its fast and its rock solid.