New approach for winbind to match Windows to UNIX users and back

[Michael Fair]

"Andrew Bartlett" <abartlet at samba.org> wrote in message
news:1047515548.10385.141.camel at piglett...

I'm going to rearrange the order, because I think there
is a second set of problems that can all be addressed
together.

First:
> > If the groups were published in LDAP, then winbind
> > wouldn't need to do any additional mapping since it
> > could just take the Windows Identifier and use it
> > directly as a GID.
>
> This has the problem that we have multiple domains.

Ok this proposal (slightly modified from the above) has
a possible problem with 16bit GIDs, but I think is really
reasonable with 32bit GIDs.  It may even be what you are
doing already within Winbindd already.

Would it be reasonable to limit the Windows Identifier
to less than 100,000,000?  We could then split the GID
namespace into 43 distinct groups 00-42 and give each
domain a GID offset at 100,000,000 increments.  This
would make Domain group entries of:
Domain01:  100,000,000
Domain02:  200,000,000
Domain03:  300,000,000
Domain42:4,200,000,000

Of course Domain42 doesn't get the full 99,999,999
identifers (only 94,967,294 of them).

Each UID would then be an offset within each domain.
GIDs less than 100,000,000 would be reserved for the
real local unix accounts.

As long as the Windows Identifiers do not exceed
100,000,000 and limiting a Samba server to only
being authenticate up to 42 domains then this
shouldn't be a problem.

(You could make it bit friendly and use 32 domains
 as the limit and 1,34,217,727 as the Domain offsets)

I'm not sure what to do about a 16bit environment.

> > UNIX users that mapped to Windows users could be
> > identified by adding the UID to the Windows based
> > GID for that user.
>
> We only need to do this for the Windows->unix layer, for unix->windows
> we can match it more on the existing lines - but given the name-space
> conflict, we might look into somthing here too.

The only time I thought this might be important is when
the user "michael" who is an ordinary UNIX user wants to
access the files in a Samba share where the admin has only
set the controls for the "Michael Fair" Windows Group user...

Of course, what I really want is that "michael" and
"Michael Fair" are viewed as the same user by the
UNIX system.  One way I think to accomplish this would
be to have winbindd create a UNIX user after it has
verified that the Windows user is actually a User and
not something else.

This gets into solving the problems listed below:

> This is where things get messy.  For ACLs changed via Samba, it's all
> fine, but we need to watch out that we don't create a mess for ACLs
> changed via local tools - and no, you can't trust the user's to 'do the
> right thing'.

> That said, if the user's get all the right groups at initgroups() time
> (including their new primary gid) it shouldn't matter.

> This would also solve a nasty problem we have that we don't know the
> 'real' primary group of every user for NT4 domains, when doing a
> getgrent().  Instead we assume 'domain users'.  This would allow us to
> always know that value.


Ok let's assume a Windows user goes through this process:
1) winbindd creates a group identifier
2) It is discovered that this ID is a user
3) It populates the GIDs with any Windows Groups that don't
   yet exist but that the user is a part of
4) It creates a local UNIX user using the same GID
   as the group object (which is offset 100,000,000 for the domain)
5) It then figures out from the Windows side what the appropriate
   default Group for the Windows user is and sets the GID in
   the passwd file to that group
6) For consistency sake it manually readds the Windows User
   to its own private group (though nothing should ever use
   this GID again it makes for easy lookups to leave it in the table)

A unix administrator could now do a step 7 and remap an already
existing user to the same UID/GID as the Windows User that now
exists and as far as the local system is concerned the local
unix user and the windows user are the same.

The admin would have to rechown all the files from the
old ids to the new ones, but a simple find command could
probably manage that.

How does that work?  Any major wrinkles?

-- Michael --