Idmap feature request/suggestion

Nimrod Sapir NIMRODS at
Tue May 15 03:04:58 MDT 2012


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

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

Thanks a lot!
Nimrod Sapir
IBM - Israel

More information about the samba-technical mailing list