idmap_ad group id mapping.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

idmap_ad group id mapping.

Nimrod Sapir
Hi

When using id mapping with SFU for domain users, I've noticed that Samba
tries to map the SID of the group defined as "primary group" for that user
to a GID. However, there is no guarantee that this group has a gid
defined, and if it does not, the mapping fails and the user cannot access
the share.

However, in Active directory with SFU extension there is also the "primary
group name/GID" field which always contains a GID or a group name with GID
defined, and must be defined for a user which has UID in the scheme. So, I
guess that there should be a way to use this field instead of the "primary
group" field in the "member of" tab.

I believe there is also an open samba bug detailing the same problem:
https://bugzilla.samba.org/show_bug.cgi?id=8694

Is that an expected behavior? Is this a configuration issue? open bug?

I am using Samba build  3.6.0-GIT-5b1b65c-devel. The relevant entries in
my smb.conf file are:

   security = ads
   realm = SMBTEST.XIV.COM
        winbind enum users = no
        winbind enum groups = no
        winbind use default domain = no
        idmap config * : range = 100000-200000
        idmap config * : backend = tdb
        idmap config SMBTEST:backend = ad
        idmap config SMBTEST:schema mode = rfc2307
        idmap config SMBTEST:range = 200000 - 300000

Thanks!
Nimrod Sapir
IBM - XIV, Israel
NAS Development Team
Office: +972-3-689-7763
Cell:   +972-54-7726-320

_1_0CF5163C0CF513D0005C2925C2257A38 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: idmap_ad group id mapping.

Michael Adam-3
Hi Nimrod,

Nimrod Sapir wrote:

> Hi
>
> When using id mapping with SFU for domain users, I've noticed that Samba
> tries to map the SID of the group defined as "primary group" for that user
> to a GID. However, there is no guarantee that this group has a gid
> defined, and if it does not, the mapping fails and the user cannot access
> the share.
>
> However, in Active directory with SFU extension there is also the "primary
> group name/GID" field which always contains a GID or a group name with GID
> defined, and must be defined for a user which has UID in the scheme. So, I
> guess that there should be a way to use this field instead of the "primary
> group" field in the "member of" tab.
>
> I believe there is also an open samba bug detailing the same problem:
> https://bugzilla.samba.org/show_bug.cgi?id=8694
>
> Is that an expected behavior? Is this a configuration issue? open bug?
Yes, this is actually how it should work:
Samba takes the windows user token and turns it into
a unix token. Here the expected thing is to turn the windows
groups into unix groups (by id mapping) one-to-one.

I would say that the windows admins should give the
user a primary (windows) group that also carries a gidnumber
unix attribute. I can't see why a windows admin would give
the user a primary windows group (maybe w/o gid number) and
primary gid number in the unix attributes that refers to a
different windows group or to no windows group at all.

But it seems to be a rather frequent request.
If it is really important, then we could make it configurable
to let samba choose the primary gid from the windows user
sfu attributes as the unix primary gid.

Note on your config below:
The ranges for "*" and "SMBTEST" overlap (by 1 id - 200000).
You should exclude that from one of the ranges.

Cheers - Michael

> I am using Samba build  3.6.0-GIT-5b1b65c-devel. The relevant entries in
> my smb.conf file are:
>
>    security = ads
>    realm = SMBTEST.XIV.COM
>         winbind enum users = no
>         winbind enum groups = no
>         winbind use default domain = no
>         idmap config * : range = 100000-200000
>         idmap config * : backend = tdb
>         idmap config SMBTEST:backend = ad
>         idmap config SMBTEST:schema mode = rfc2307
>         idmap config SMBTEST:range = 200000 - 300000
>
> Thanks!
> Nimrod Sapir
> IBM - XIV, Israel
> NAS Development Team
> Office: +972-3-689-7763
> Cell:   +972-54-7726-320

attachment0 (214 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: idmap_ad group id mapping.

Nimrod Sapir
Michael Adam <[hidden email]> wrote on 12/07/2012 01:20:57:


>
> Yes, this is actually how it should work:
> Samba takes the windows user token and turns it into
> a unix token. Here the expected thing is to turn the windows
> groups into unix groups (by id mapping) one-to-one.
>
> I would say that the windows admins should give the
> user a primary (windows) group that also carries a gidnumber
> unix attribute. I can't see why a windows admin would give
> the user a primary windows group (maybe w/o gid number) and
> primary gid number in the unix attributes that refers to a
> different windows group or to no windows group at all.
>
> But it seems to be a rather frequent request.
> If it is really important, then we could make it configurable
> to let samba choose the primary gid from the windows user
> sfu attributes as the unix primary gid.

I would say that the existing behavior is reasonable (as well as expecting
the user to enforce the gid value of the primary group) if the "primary
group name/GID" field was not there, right below the UID field. I, as a
user, was sure that this field would determine the GID. I believe this is
also what Microsoft expect from systems which are using this scheme
(otherwise, why is it there?), and from the perspective of a customer
which has large Active Directory, and want to allocate different GID to
different users, the existing behavior is error-prone while the second
approach ensures consistency.


Reply | Threaded
Open this post in threaded view
|

Re: idmap_ad group id mapping.

Michael Adam-3
Nimrod Sapir wrote:

> Michael Adam <[hidden email]> wrote on 12/07/2012 01:20:57:
> >
> > Yes, this is actually how it should work:
> > Samba takes the windows user token and turns it into
> > a unix token. Here the expected thing is to turn the windows
> > groups into unix groups (by id mapping) one-to-one.
> >
> > I would say that the windows admins should give the
> > user a primary (windows) group that also carries a gidnumber
> > unix attribute. I can't see why a windows admin would give
> > the user a primary windows group (maybe w/o gid number) and
> > primary gid number in the unix attributes that refers to a
> > different windows group or to no windows group at all.
> >
> > But it seems to be a rather frequent request.
> > If it is really important, then we could make it configurable
> > to let samba choose the primary gid from the windows user
> > sfu attributes as the unix primary gid.
>
> I would say that the existing behavior is reasonable (as well as expecting
> the user to enforce the gid value of the primary group) if the "primary
> group name/GID" field was not there, right below the UID field. I, as a
> user, was sure that this field would determine the GID. I believe this is
> also what Microsoft expect from systems which are using this scheme
> (otherwise, why is it there?),
Well, I think the primary use of this is Unix/NFS interaction.
Also, from Windows 2003R2 on, the schema extensions are part of
the so called "services for NFS"...

http://technet.microsoft.com/en-us/library/cc782783%28v=ws.10%29
http://technet.microsoft.com/en-us/library/cc753302%28v=ws.10%29.aspx

This is meant for systems that unlike samba/winbindd don't do
an id mapping of the windows SIDs themselves.

> and from the perspective of a customer which has large Active
> Directory, and want to allocate different GID to different
> users, the existing behavior is error-prone while the second
> approach ensures consistency.

The point is that the samba server is more on the windows side
than on the unix side, from the windows clients' point of view.
So we should by default map the windows world to the unix world
as 1:1 as possible. We can optionally add in the primary gid
from the unix attributes in the idmap_ad scenario. But what
relevance would the primary windows group have, if it is also
mapped to a GID?

Difficult.

There is by the way already a mechanism for choosing the
gid from idmap_ad: you need to configure the nss_info
correspondingly. Set

"winbind nss info = sfu"

in addition to your idmap config (or = rfc2307, you have to check).
Please read the "smb.conf" manpage for more background.

Cheers - Michael



attachment0 (214 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: idmap_ad group id mapping.

Nimrod Sapir
Hi Adam

I'm not sure I understand all your comments below. It still seems to me
that for a customer using SFU for ID mapping, the consistent and intuitive
way to determine the GID for a AD account which has UID in the schema is
the Primary group name/GID entry. When looking at the UNIX attributes tab
it is very obvious that this field is meant by Microsoft to be used as the
matching GID for the UID. Also, the way it is defined enforces the user to
provide GID to every UID, either by choosing a group which has GID, or by
adding it manually to the schema.

Yesterday, I dived into the code trying to understand how this patch can
be done. The fix doesn't seem to be trivial at all, as the flow that leads
from the first AD query of the user to the SID->GID resolution in AD is
quite complicated. I added some hacks to winbind_ads.c and idmap_ad.c, but
with partial success. adding the "winbind nss info = rfc2307" did change
the flow a bit, but eventually the smbd process runs using the gid of the
primary group rather than the gid written in the Primary group name/GID
field.

Do you think that the change described is of interest to the community? Do
you have any suggestion regarding the easiest way to change the flow to
match this behavior?

Thanks
Nimrod



Michael Adam <[hidden email]> wrote on 12/07/2012 17:48:42:

> From: Michael Adam <[hidden email]>
> To: Nimrod Sapir/Israel/IBM@IBMIL,
> Cc: Dan Cohen1/Israel/IBM@IBMIL, Lior Chen/Israel/IBM@IBMIL, samba-
> technical <[hidden email]>
> Date: 12/07/2012 17:48
> Subject: Re: idmap_ad group id mapping.
>
> Nimrod Sapir wrote:
> > Michael Adam <[hidden email]> wrote on 12/07/2012 01:20:57:
> > >
> > > Yes, this is actually how it should work:
> > > Samba takes the windows user token and turns it into
> > > a unix token. Here the expected thing is to turn the windows
> > > groups into unix groups (by id mapping) one-to-one.
> > >
> > > I would say that the windows admins should give the
> > > user a primary (windows) group that also carries a gidnumber
> > > unix attribute. I can't see why a windows admin would give
> > > the user a primary windows group (maybe w/o gid number) and
> > > primary gid number in the unix attributes that refers to a
> > > different windows group or to no windows group at all.
> > >
> > > But it seems to be a rather frequent request.
> > > If it is really important, then we could make it configurable
> > > to let samba choose the primary gid from the windows user
> > > sfu attributes as the unix primary gid.
> >
> > I would say that the existing behavior is reasonable (as well as
expecting
> > the user to enforce the gid value of the primary group) if the
"primary
> > group name/GID" field was not there, right below the UID field. I, as
a
> > user, was sure that this field would determine the GID. I believe this
is

> > also what Microsoft expect from systems which are using this scheme
> > (otherwise, why is it there?),
>
> Well, I think the primary use of this is Unix/NFS interaction.
> Also, from Windows 2003R2 on, the schema extensions are part of
> the so called "services for NFS"...
>
> http://technet.microsoft.com/en-us/library/cc782783%28v=ws.10%29
> http://technet.microsoft.com/en-us/library/cc753302%28v=ws.10%29.aspx
>
> This is meant for systems that unlike samba/winbindd don't do
> an id mapping of the windows SIDs themselves.
>
> > and from the perspective of a customer which has large Active
> > Directory, and want to allocate different GID to different
> > users, the existing behavior is error-prone while the second
> > approach ensures consistency.
>
> The point is that the samba server is more on the windows side
> than on the unix side, from the windows clients' point of view.
> So we should by default map the windows world to the unix world
> as 1:1 as possible. We can optionally add in the primary gid
> from the unix attributes in the idmap_ad scenario. But what
> relevance would the primary windows group have, if it is also
> mapped to a GID?
>
> Difficult.
>
> There is by the way already a mechanism for choosing the
> gid from idmap_ad: you need to configure the nss_info
> correspondingly. Set
>
> "winbind nss info = sfu"
>
> in addition to your idmap config (or = rfc2307, you have to check).
> Please read the "smb.conf" manpage for more background.
>
> Cheers - Michael
>
>
> [attachment "atti45z3.dat" deleted by Nimrod Sapir/Israel/IBM]