idmap enhancements

simo idra at
Mon Jun 19 20:03:11 GMT 2006

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.

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


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

Simo Sorce
Samba Team GPL Compliance Officer
email: idra at

More information about the samba-technical mailing list