idmap enhancements

[Dave Daugherty]

>From simo: Monday, June 19, 2006 1:03 PM

> After the reject of my previous proposed unix socket based protocol
for
> external idmap caches I thought some more about the problem I have
with
> the current implementation of idmap and on ways to fix it in a
> reasonable way.

> Problem:
> How do we allow the change of uid/gid to sid mappings while
maintaining
> the current idmap model and the tdb cache ?
> Some modules already allow administrators to easily and externally
> change mappings (idmap_ad, idmap_ldap) but actually the tdb cache will
> not acknowledge this changes resulting, eventually, in inconsistent
> situations across multiple servers. It is not my desire to discuss
> whether changing mappings is a good policy or not[1].

> Proposed Solution:
> Introduce an date timestamp on cached mappings so that entries can be
> expired.
> Actually idmap_tdb implement a persistent cache where values, once
> assigned, are never again validated against the remote central mapping
> facility. Adding a creation date timestamp to each mapping entry will
> easily allow to expire the mapping regularly so that it can be checked
> against the remote servers. This behavior will be regulated by a new
> parameter called "idmap expire time" set by default to 0 meaning
"never"
> and only checked when an idmap backend is actually configured so that
> standalone installations will continue to work as usual.
>
> In case a remote backend is configured and idmap exipre time is not 0,
> each time a mapping is requested idmap_tdb will check if the retrieved
> mapping is still valid or expired. In case it is expired it will
request
> the remote backend to return the current mapping.
> If the mapping is confirmed the mapping timestamp in the cache will be
> renewed, otherwise the old mapping will be deleted and a new mapping
> will be returned.

> In case the remote server is temporarily not available expired entries
> will be returned as valid until they can be validated against a
working
> remote server. They will not be removed, but the timestamp will not be
> updated until the validation can be performed.

> This schema requires to add a new SID-timestamp set of entries in the
> idmap tdb database (winbind_idmap.tdb) and to make sure remote
backends
> return a different error for invalid mappings and unreachable servers.

> Actually the idmap module returns NT_STATUS_UNSUCCESSFUL in most cases
> when an operation fails.

> I propose to change the modules to return NT_STATUS_UNSUCCESSFUL in
case
> of any generic error (like memory allocation errors or connection
> errors), and NT_STATUS_NONE_MAPPED only when it is clear that the
> mapping is not valid anymore and no mapping has been found. (This may
be
> used later on to implement some form of negative caching).

> I will not be able to work on this before next week but any comment
will
> be really appreciated.

> Simo.


> [1] Changing mappings is not recommended. Changing a mapping means
that
> file ownerships may change or become invalid. It is also understood
that
> on little installations the situation can be fixed just by deleting
the
> local tdb cache and restarting samba.
> But in the case the administrator has carefully considered all his
> options and thinks that changing uid mappings is the best thing to do,
> and the installation consist of a big number of samba servers I am
> convinced that a way to cope with this situation without requiring
error
> prone human intervention is a much better option.

Since idmap_ad and idmap_ldap do not have a local cache, I can see why
you would want to do this to help performance, understanding that it
complicates the implementation of the TDB caching.  However I still
think the best thing is to bypass the TDB cache completely (especially
if the idmapper does its own local caching).  Please continue to allow
for this too.

Dave Daugherty
Centrify Corp.