Idmap feature request/suggestion
idra at samba.org
Tue May 15 07:27:35 MDT 2012
On Tue, 2012-05-15 at 12:04 +0300, Nimrod Sapir wrote:
> 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.
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>
More information about the samba-technical