Idmap feature request/suggestion

[simo]

On Tue, 2012-05-15 at 12:04 +0300, Nimrod Sapir wrote: 
> Hello
> 
> I am working for a development team in IBM which is planing to use Samba 
> as a CIFS front-end solution for our product. When looking into the id 
> mapping capabilities of Samba, I came up with a few gaps which are 
> required to adjust Samba to our needs. As far as I understand, some of 
> those features required to close those gaps were already discussed by the 
> Samba team. The gaps we are seeing are:
> 
> LDAP is not supported as id mapping only backend, but as a full 
> authentication/id mapping mechanism. So, if we would like to allow the 
> user to authenticate windows accounts using AD, while using ldap to match 
> the SID of those users to the UID of their corresponding linux  accounts, 
> that cannot be done.

Sorry, but this is not true, take a look at the idmap_ldap man page.

> When using NIS (by using idmap_nss), the system assumes that mapping is 
> done in the form of domain_name\userName -> userName. We would like to 
> allow the user some more flexibility regarding the name mapping between 
> Windows and Linux user accounts. Looking at the code, it seems that a 
> solution could be to extand the idmap_nss module to support those kind of 
> rules (the list of rules can be kept on a text file or tdb). Of course, 
> this should not affect the default behavior of the module. I'm not sure if 
> such feature has ever been discussed. 

No you are on the wrong course, and idmap_nss should be used exclusively
with local users.

> For all of the mapping methods, failing to retrieve the uid using the 
> external database, will fail the entire id mapping process. This means 
> that the customer will have to keep and maintain the mapping for all 
> windows accounts to linux UIDs on the external database (including for the 
> many users which do not have both Windows and Linux user names). I believe 
> that a feature that allows multiple idmap backend was already discussed in 
> this presentation:
>         
> http://www.samba.org/~obnox/presentations/sambaXP-2011/sambaxp-2011-talk-idmap-handout.pdf 

Using multiple idmao backends ahs been supported for the whole life of
the samba 3.x series albeit in slightly different ways, they all assume
different backends only for different domains.

> Anyway, a reasonable solution would be to add two additional 
> parameters: "idmap config: secondary_backend" and "idmap config : 
> secondary_range" which will contain details of a secondary backend (which 
> will likely be rid/autorid or tdb2). If the system fails in     locating 
> the mapping in the external DB it will fail back to the secondary backend, 
> thus allowing the user to minimize the amount of administration needed for 
> id mapping. Since the id mapping code is extremely modular, it seems that 
> it shouldn't be very hard to create a generic solution to support 
> secondary backend. 

I would veto such hack, the reason is that if later on the 'primary'
backend add a mapping it will almost certainly have different values
than the 'secondary' gave out earlier. Meaning a user will not be able
to access its files any more as the mapping changes. This is a nightmare
and we will not support such a broken configuration upstream.

> I'm not a Samba expert, so you are welcome to correct me if I'm wrong 
> here. Of course, if some of my suggestion will be accepted by the 
> community, my team will probably be able to help with the development and 
> testing of the relevant code. 

You did the right thing to contact upstream, feel free to ask if
something is not clear about idmap_ldap.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>