[PATCH] New external idmap module

[simo]

Dave I created this daemon just to solve the same problems you have.
I need it for Quest's VAS product which I think you know very well :-)
Any help and enhancement is very welcome.

Simo.

On Tue, 2006-05-30 at 15:43 -0700, Dave Daugherty wrote:
> 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