Idmap feature request/suggestion

[Nimrod Sapir]

simo <idra at samba.org> wrote on 15/05/2012 16:27:35:



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

Maybe I fail to understand the behavior of the ldap backend. What I would 
like to have is using external ldap for matching Windows account to Linux 
accounts (similar to the usage of SFU). So, the customer should be the one 
writing the entries to the ldap (which contains a mapping between the 
Windows SID/account to the corresponding Linux UID). This is meant to be 
used for customer for which want to provide same permissions to Windows 
and linux accounts, but not to extend the AD scheme with SFU. Is the 
described behavior possible using the idmap_ldap?

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

Interesting. I saw some examples of using idmap_nss for mapping Domain 
users to NIS users (for example, 
https://lists.samba.org/archive/samba/2011-September/163970.html). It did 
work for me too. If I understand correctly, once you add the NIS to the 
/etc/nsswitch file, the system transparently uses the NIS for name->uid 
resolutions, so from the Samba perspectives, this is as if the uid came 
from a local user. Do you suggest using a mapping script for mapping 
against NIS? 

Anyway, the question of flexible mapping rules remains.

> > 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 understand the risk here. The user will have to be aware of the fact 
that adding a new mapping on an external database (for example, SFU) for 
an account that is already using the file system will have impact on the 
permissions of his files. Still, consider this scenario: A customer has an 
Active Directory of 10,000 accounts, of which 100 also have a 
corresponding Linux accounts. Assuming he has SFU enabled, he will 
actually need to provide a uid for each of the 10,000 user accounts, while 
making sure those UIDs do not belong to other windows users (across the 
forest), other linux users (including the ones who do not have a windows 
account at all), and any internal UID used by the system. This is a 
configuration nightmare and not always feasible. If he had a possibility 
of using two different backends (with two different ranges), he would be 
able to only provide the UID information for the 100 relevant accounts 
(whose UIDs he already knows), and let the system (usind rid/tdb2) provide 
auto-generated UIDs for all the other accounts, from a different pool. The 
same goes for users who want to use NIS as a backend for id mapping. Do 
you have any suggestion on how to handle such scenario?

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