[PATCH] New external idmap module

Dave Daugherty dave.daugherty at centrify.com
Tue May 30 22:43:56 GMT 2006


Hope we can reach an agreement about this...

Centrify has a need for something very similar to what is being proposed
here.  In our case our ID mapper caches [GU]ID<->SID mappings (including
negative hits) and we always want to be asked. I was going to propose
yet another smb.conf parameter to control whether or not Winbind TDB id
cache is bypassed, but this proposal should work nicely for us.

Besides the possibility of ID mappings change (and I agree there are
file ownership problems in doing this), we would like the ability to
"forget" existing mappings when administrators decide to restrict
someone who previously had access to a Samba server - maybe someone who
has left the company.

I will be presenting a new ID mapper soon that uses Centrify's ADCLIENT
to provide the mappings.

Dave Daugherty
Centrify Corp.



On Tue, 2006-05-30 at 15:01 -0400, simo wrote:
> Recently I have been involved in making it easier to provide custom id
> mapping for samba. In some situations it is preferable to do the
mapping
> from outside samba to keep control on what get mapped.
> 
> One of the goals was also to make it easier to provide such mapping
> without the need to change the source and keep it in sync at each new
> samba version.
> 
> The idmap interface has not changed much if at all since we introduced
> it in 3.0 and I do not see it changing much in future, so I decided to
> make a module that forwards mapping calls to an external daemon using
> either a unix socket or eventually a tcp socket.
> 
> Actually I tested only the unix socket, but I added the tcp transport
> too because I think it is a great idea to be able to use this module
to
> keep multiple samba server in sync without requiring to set up an ldap
> server just to keep the shared map. (The tcp socket may also help the
> architectures that does not have a viable unix socket facility if
any).
> 
> This is the smb.conf syntax to use this module:
> 
> idmap_backend = external:<local|remote>:<unix|tcp>:<path|address>
> 
> 1) Define whether it is a local or a remote store
> 
> You must be careful with this parameter, usually you will want to
> declare the external store as "remote", this will let samba use
> idmap_tdb to keep a local fixed cache, this also means that if your
> daemon dies, samba will be able to solve all the mapping that are
> already in the cache and you will loose only the capability to store
new
> mappings.
> 
> Anyway in some cases you may want total control of the cache too, to
be
> able to change mappings without the need to wipe out the tdb cache,
you
> will just need to reconnect and spawn a new smbd process to see the
new
> mappings, in this case you may declare the module as "local" and it
will
> take the place of the idmap_tdb cache.
> 
> 2) Select the desired transport.
> 
> I advice you to use "unix" against "tcp", the tcp transport actually
has
> no authentication mechanisms so you must use special care when using
it
> (I advice to use stunnel if you need to use it between 2 machines, so
> that the communication is sealed and x509 certificates can be used for
> mutual authentication).
> The unix socket on the other side can rely on file system permissions
> and I strongly advice to keep the socket readable and writable by root
> only.
> 
> 3) either the path of the unix socket (remember that unix socket paths
> cannot exceed 108 characters), or the tcp address in the form:
> a.b.c.d:port
> 
> Jerry,
> if there are no objections I would like to commit this code into trunk
> and see it in 3.0.24, I think it will be of great use for many people
> that want better control on their mappings without being constrained
by
> the current available modules. The communication mechanism (described
in
> the module source code) is really simple and can be easily
implemented.
> The example daemon uses an sqlite3 database to keep the maps just to
> show how it is easy to use alternative methods.
> 
> If there is real interest in the tcp support, let me know so that I
can
> dedicate some energy in enhancing it.
> 
> Have fun,
> Simo.
> 
-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org


More information about the samba-technical mailing list