[PATCH] New external idmap module

[Dave Daugherty]

On Wednesday, May 31, 2006 6:46 AM Simo wrote:

> > 
> > Volker Lendecke wrote:
> > 
> > > What I fail to see in this whole thread is the reason why an
> > > existing mapping needs to be changed. You need to change the
> > > ownership of all files as well as all ACL entries in the
> > > file system if you change an existing mapping. You could
> > > play very nasty tricks remotely using remote set_secdesc on
> > > files but this is putting the box into maintenance mode for
> > > a while. The much easier way to do this is to remove the
> > > cache completely and restart the box.
> > > 
> > > What scenarios do you have in mind that require changing
> > > mappings?
> > 
> > On this point I will concede to Volker.  We need some specific
> > examples of why this support would be appropriate in order to
> > continue the discussion I think.

> I see that changing a mapping is a problem, because often it means a
> change in the ownership of some files, I am just trying to be
pragmatic
> and see that there are cases when a change is necessary.

> This is a fact, and out of my control, from my POV I may not even care
> why an admin may change the mapping.
> If I am not in control of the mapping (as is the case when an external
> authoritative mapping is used) then my only worry is to think what
> happen if that changes and what is the best way to deal with the case.

> What I see is that if you end up to need to do it and you have lots of
> servers it becomes a bit unpractical to go on each server and delete
the
> winbindd_idmap.tdb file.
> When you have hundreds of servers, that perhaps are not even under a
> single administrator control, being able to push the change is ok imo.

> 2 scenarios I can see are:

> 1) Wrong setting: the admin assigned by mistake the wrong uid to a
user
> that collide with another, one of the 2 mappings need to change.

> 2) Migrations or incorporation: you acquire new servers from a
different
> management and find out that you really need to change around some
user
> IDs to let them join because some broken application depends on some
> user uid to not change.
> If you know what are the uid's you have to change, you can just do it,
> and then connect only to the servers where the change uid user files
> where hosted as an administrator and change the ACLs.

> 3) different admins: in many companies it may happen that different
> branches have control on their own OU (ldap or AD) and can change
their
> data without the need to communicate it to someone else.
> So if I have admin1 in OU1 that decides to change one mapping he may
or
> may not tell it to admin2 of OU2. What it is certain is that admin1
does
> not have access to admin2 servers and can't decide when to stop the
> other admin servers. Still Admin1 is authoritative for his mappings
and
> usually have an assigned a range of uids to play with.
> In this case requiring to restart all 100 servers of each admin
because
> one admin made a mistake in assigning a single mapping (maybe just for
a
> day or 2) seem to be a bit too much in my opinion.

> If the idmap_tdb cache is involved, detecting the change in a local
> server daemon would require the daemon to keep a backup mapping and
> track the mappings by constantly querying the central mapping store
and
> comparing the result, this would mean you hit the central mapping
store
> quite a lot just to make sure mappings have not changed. And when you
> find something changed you will have to run a process that wipes the
> winbindd_idmap.tdb file and restarts samba (would you really like to
see
> samba restart under you ?), or do an idmap restore on a live system
> which is perfectly equivalent to not use idmap_tdb at all as you
change
> the mapping anyway just in a more complicated, error prone, non
scalable
> way.



> Changing a mapping is nothing different than changing the UID/GID of a
> local user. We allow that, I do not see why we can't allow the same on
a
> domain/forest scale.
> Keep in mind that changing the uid in ldap means that locally the user
> will have indeed a different UID (when I use nss_ldap) only the
> winbindd_idmap.tdb cache will be out of sync, and you have
inconsistent
> results.
> When the user connects he will have an NT token with assigned his SID
> but also his new UID (as the user sid comes form the nss layer), but
> when looking from windows you will have also the previous uid->sid
> mapping in the cache and things get really weird (2 uids -> 1 sid).



> Said that, if we still think that we must make actively difficult to
fix
> mappings, and require admins to get crazy, months after the forgotten
> supposedly fixed error, to find out why one mapping does not really
> match, all I need is to remove the local|remote option for the module
> and make is_local() always return False.


> I still think that being able to keep the module as a way to
communicate
> to local or remote mapping daemons without the overhead of launching a
> script at each mapping request make sense (exp, as a way to make it
easy
> to keep a centralized store without the need to build up an ldap
server
> just for that purpose. Many users on the mailing list cry when they
are
> required to use ldap as it is a bit too difficult for many of them).

Some Administrators want to control exactly who gets to access the Samba
servers, and having an easy way to remove their access when they quit.
Being able to control who has mappings turns out to be a convenient way
to do this, or at least is extra insurance.

Dave Daugherty
Centrify Corp.