Idmap feature request/suggestion

simo idra at
Tue May 15 07:27:35 MDT 2012

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:

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 Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list