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

[Andrew Bartlett]

On Thu, 2003-03-13 at 20:29, Michael Fair wrote:
> 
> "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.   

You would be supprised.. For example, my uni uses unix ids that match
the student ids - and they are 7 digits long.  Not quite 100,000,000,
but don't make assumptions.

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 next problem is the number of domains.  Many of the orginisations
that deploy samba live on *massive* internal networks with 100's of
domains!  Worse still, each and every workstation is it's own domain,
and the SIDs from that workstation can end up on the NAS!  

We need to be able to correctly map these SIDs, even if we have never
heard of the domain before.

> 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.

I don't like the offset idea.

> 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)

We should only create a passwd nss record for Users, and possibly only
map to a uid for users - but this means we have to look them up first -
and that has problems.

> 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.

'best practice' isn't a particularly good idea when things break if
people don't follow it.  We need solutions that don't rely on *users*
following 'best practice' but instead 'this works'.

> 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)

With SIDs they get very big.

I sit in two camps on this one - for local UIDs/GIDs, I actually like
the 'algorithmic', but it's confined to a single uid/gid space.

For winbindd, I'm convinced that the tdb mapping is the best way
forward, but that some extensions to cope with all SIDs as GIDs.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030313/70f6b1be/attachment.bin