idmap enhancements

Dave Daugherty dave.daugherty at
Mon Jun 19 20:32:32 GMT 2006

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

> After the reject of my previous proposed unix socket based protocol
> external idmap caches I thought some more about the problem I have
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> be really appreciated.

> Simo.

> [1] Changing mappings is not recommended. Changing a mapping means
> file ownerships may change or become invalid. It is also understood
> on little installations the situation can be fixed just by deleting
> 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
> 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.

More information about the samba-technical mailing list