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

[Michael Fair]

"Michael Steffens" <michael.steffens at hp.com> wrote in message
news:3E703C49.5040509 at hp.com...
> Hi Michael,
>
> Michael Fair wrote:
> > 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?
>
> I'm not feeling really comfortable with winbind assigning all
> UIDs and GIDs on a system, as it does need to coexist with other
> means and tools for Unix user management.
>
> Reassigning their IDs is a major pain, and often impossible.
>
> If winbind could only be used when taking over ID management
> entirely, we would be in trouble. So this behaviour needs to
> be at least optional...

Oh yes, entirely!  Nothing I mentioned was an attempt
to put winbind in control of all the UID/GIDs on a system.

I personally have never used, nor even heard of a system
that used UID/GIDs 100,000,000 and above.   That's the address
space that winbind would be using.  Everything below that
0 through 99,999,999 would be reserved for the normal system
(as I mentioned earlier in the post).  But just because I
haven't encountered doesn't mean it doesn't exist which was
my primary concern (if the address space is in use, then
it is not a solution and we'll need to come up with
something else).

The snippet you grabbed was part of an optional step 7 that
an administrator could, if they were so inclined, use to get
an existing UNIX user to be directly mapped to the new Windows
User created by winbind (mostly because the admin doesn't
want to specify the ACL for the unix user separate from
the ACL for the Windows User).  This not something winbind
would do.  This is only something an administrator would do
manually (perhaps with the aid of some scripts, and only if
it was found to actually be a valuable operation).

If the existing UNIX UID is heavily ACLed then this of
course would probably not be used.  The two IDs would
remain separated.  If the UNIX admin was following the
"best practices" recommendation and only assigning ACLs
on the GIDs that Winbind created, then the same effect
could be gotten by placing the UNIX user in the "private
group" that Winbind created for the Windows User.  The
only purpose having winbind create a UNIX user serves is
exactly that, to let the system have an honest to goodness
UNIX user to use for operations in the system.

The concept is:
1) Winbind only uses IDs 100,000,000 and above ( the bit
   friendly version is IDs 134,217,728 and above)
2) Each domain encountered gets its own 100,000,000 offset.
   So 100,000,000 for D1, 200,000,000 for D2, etc.
3) Winbind only creates GIDs, except in the case it has
   detected a Windows User, then it also creates a UID
   with the same number as the GID for that object (and
   for that object only)
4) Suggest that a "best practice" be adopted where only
   the GID gets ACLs on the local system (this might be
   unnecessary with the addition of the "Give users a UID
   as well" approach.

The only thing this proposal really does is break up the
UID/GID space into 100,000,000 offest segments, the first
of which is for the UNIX system (Local_Machine if you will)
and the rest for each Domain it encounters, up to 42 domains
(or 31 domains if using the bit friendly version).

(I personally thing that even 67,108,864 offsets is reasonable
with up to 63 domains, but I've never deployed a large scale
enterprise before so I don't know how big those numbers get)

-- Michael --