with most recent git master smbd fails to start in AD DC mode

Jeremy Allison jra at samba.org
Sat Mar 22 21:54:27 MDT 2014

On Sat, Mar 22, 2014 at 08:11:41PM -0700, Jeremy Allison wrote:
> Even if the 'username -> getpwnam() -> uid_to_sid()'
> part isn't done and we start with a SID from sam.ldb,
> if this SID is a primary user in a token (which
> it is in this case) I would expect that we must
> be able to do :
> sid_to_uid() -> getpwuid()
> and get back a valid 'struct passwd' coming
> from the smbd winbindd, or if we're inside the AD-DC
> code coming from the built-in winbindd.
> Even if winbindd isn't running the SID
> should be from the 'legacy' uid_to_sid/sid_to_uid
> code so it should still map to a valid user
> on the system (*somewhere* inside /etc/passwd :-).
> Under what circumstances is this not the
> case ?

Now I've gone through the code *REALLY CAREFULLY*
I actually now know when this is the case :-).

It's the case when we're creating a token for
the guest account specifically :-).

In this and *only* this case, the first SID in
the token list is not the SID created from
converting the pw->pw_uid of the guest account
into a SID, it's specifically set as the
DOMAIN\Guest user sid. In only this case
the primary UNIX user uid is different
from the sid_to_uid() conversion. So in
this case :

sid_to_uid(token_sid[0]) -> uid != pw->pw_uid

(where pw represents the guest account).

Updated patch to follow. The correct way
is not to ignore getpwuid() lookup failures
on the guest account, the correct way to
fix this is to special case the guest
account inside finalize_local_nt_token()
(is_guest is passed in as a bool aready
as we special case this in other places
in this function, which should have been
a red flag already :-) and use the guest
account *name* (which we already depend
on being correctly resolved by getpwnam())
instead of the uid.

Andrew, it isn't anything to do with the
sam.ldb SIDs.

Give me a few mins and I'll update the


More information about the samba-technical mailing list