suggestion to change idmap parameter usage [Was : Re: [Samba] winbindnss info = sfu is not so much working]

[William Jojo]

----- Original Message ----- 
From: "Jonathan C. Detert" <detertj at msoe.edu>
To: <samba at lists.samba.org>
Sent: Friday, April 28, 2006 10:03 AM
Subject: suggestion to change idmap parameter usage [Was : Re: [Samba]
winbindnss info = sfu is not so much working]


> I wanted to use winbind to get user and group (i.e. nss) info from
> a Microsoft Active Directory LDAP Server that supports an RFC2307
> compliant LDAP schema.  I was unable to make that work until Guenther
> Deschner (see below) explained that I still had to specify idmap guid
> and idmap uid ranges.
>
> That need is not intuitively obvious.  I suggest it be removed, or at
> least explained in the smb.conf manpage.  The man page
> suggests that 'idmap backend' and the idmap uid/gid ranges are
> mutually exclusive (except for when idmap backend = idmap_rid).
>
> To illustrate this, consider the first sentence under the description of
> the idmap backend parameter:
>
>         idmap backend (G)
>               The  purpose of the idmap backend parameter is to allow
idmap to NOT
>               use the local idmap tdb file to obtain SID to UID  /  GID
mappings,
>               but  instead to obtain them from a common LDAP backend.
>
> If we are to use LDAP for the map, then what good is it to specify the
> range of numbers that can be used in the map?  Hasn't the range already
> been set by whatever process populated LDAP with the uid/gid's?  Or are
> we to assume that winbind is the agent that will make the maps within
> the LDAP backend?

No, this is a table of UID/GID mapping outside the POSIX assigned values.
The intent is to have a table of values that could be used to map to NFS or
other but still be used in conjunction with Samba.

There is no implied mutual exclusion, it allows for a container in LDAP to
be used instead of the winbindd_idmap.tdb file in var/locks. The idea it to
share this among several servers. The values would still be chosen on a
first come, first served basis.

>
> Obviously the answers are,
>
> 'Yes, the range has already been set', and
> 'No, winbind is not making the maps within the LDAP backend.  Something
> else must have assigned the uid/gids within the LDAP backend server.'.

You can assign the values yourself, to be certain, but without IDMAP these
were algorithmic until 3.0.23. (uid * 2 + base <or> gid * 2 + base; bases
defaulted to 1000 and 1001)

>
> So, what is the reasoning behind requiring the specification of idmap uid
> and gid ranges when the backend is MsAD?
>
> Suppose there is a good reason.
>
> Then, what do we do with the problem of
> how to specify the idmap uid/gid ranges?  Do we query LDAP to determine
> the current range in order to make sure the range we specify includes
> all uids/gids already set within LDAP?  That is crazy.  If we don't,
> then it must not matter what ranges we specify.  So again, setting the
> range seems to have no natural, reasonable purpose.
>

Well, if you have the POSIX users in SFU for the AD tree, why not point nss
to the POSIX LDAP portion and set "winbind trusted domains only = yes". If I
understand this setting correctly (since we are using it in development) the
RID should map to the POSIX values of the users and groups as presented by
your LDAP backend.

I agree with you that *sometimes* the idmap ranges should be unnecessary as
I still need to have them even when using "winbind trusted domains only".
But this is a small price for me to eliminate the idmap table.

On AIX I have a tree on a domain that everyone else trusts. so:

dc=hvcc,dc=tst
    |-> dc=acdev
        |-> cn=Users (every person on our campus)
        |-> cn=Groups (every group)
        |-> cn=Computers (only those for ACDEV)
    |-> dc=devex
        |-> cn=Users (empty except root and nobody)
        |-> cn=Groups (a simple set of groups)
        |-> cn=Computers (only those for DEVEX)


DEVEX trusts ACDEV.

All systems point to dc=acdev,dc=hvcc,dc=tst for POSIX user information
specifying he cn=users and cn=groups for users and groups respectively.

Samba's perspective is this (in 3.0.23pre1):

Share mapped from ACDEV shows "ACDEV\username" in Security tab ACL. The
local user is mapped to the sambaSID from the the LDAP entry.

Share mapped from DEVEX shows "Unix User\username" in Security tab ACL. The
user is taken from nss and the SID becomes S-1-22-1-uid.

This is *perfect* for me since I want to use a single username across all
platforms from the POSIX user list regardless of the machine is a DC, DC
trusting another DC or a DMS. But that solution is not so great for
everyone.

> Lastly, if it really does make sense to set the idmap uid/gid
> ranges, then please update the smb.conf manual.  It is very misleading
> (at least in the v3.0.22 rendition).  Besides the misleading opening
> paragraph (pointed out above), there is another bit that implies setting
the
> uid/gid ranges is not needed when using idmap backend, _except_ when the
> idmap backend is set to 'idmap_rid':
>
>         An  alternate  method  of  SID  to UID / GID mapping can be
achieved
>         using the idmap_rid plug-in. This plug-in uses the account  RID
to
>         derive  the UID and GID by adding the RID to a base value
specified.
>         This utility requires that the parameter``allow  trusted domains
=
>         No'' must be specified, as it is not compatible with multiple
domain
>         environments. The idmap uid and idmap gid ranges must also be
speci-
>         fied.
>
> I suspect that as the code currently stands, it would be more accurate
> to remove that last sentence from the paragraph describing the idmap_rid
> plugin, and put it as part of the opening paragraph.  I.e. I suspect
> that the current code requires you to specify the idmap uid/gid ranges
> no matter what your idmap backend is.
>
> In any case, thank you for the wonderful software we have in samba.
>
> Sincerely,
>
> Jon Detert
>
> * Jonathan C. Detert <detertj at msoe.edu> [060427 12:11]:
> > * Guenther Deschner <gd at samba.org> [060427 11:56]:
> > > On Thu, Apr 27, 2006 at 11:21:45AM -0500, Jonathan C. Detert wrote:
> > > > with samba 3.0.22, I'm trying to integrate a linux box with
Microsoft AD
> > > > by using winbind for authentication as well as for the source of nss
info.
> > > >
> > > > When winbind is configured to use its own local id maps, everything
> > > > works fine.
> > > >
> > > > But when i configure winbind to use 'ad' as the source of nss info,
> > > > authentication fails, 'getent' commands return no results, and
> > > > 'wbinfo -r someusername' returns nothing (though wbinfo -u and -g
work
> > > > correctly).
> >
> > -- snip --
> >
> > > > And here is how smb.conf looks when winbind is configed to use AD
for
> > > > nss:
> > > > --------------
> > > >    winbind enum groups = yes
> > > >    winbind enum users = yes
> > > >    winbind separator = +
> > > >    winbind nested groups = yes
> > > >    winbind nss info = sfu
> > > >    winbind use default domain = yes
> > > >
> > > >    idmap backend = ad
> > >
> > > You still need to have the idmap ranges set so that winbind does not
fall
> > > into the "netlogon proxy only" mode. Does it work then?
> >
> > Yes, thanks!  I don't understand that at all.  What is 'netlogon proxy
only'
> > mose?
> >
> > If winbind is mapping a sid to the uid/gid recorded in AD via the sfu
> > schema attributes, then why would I tell winbind what range it can use
for
> > the uids and gids that it maps the sids to?
> >
> > Also, what relationship do my idmap id ranges have to the actual values
> > in AD for the msSFU30UidNumber and msSFU30GidNumber attributes?  Do I
> > need to ensure that my idmap id ranges match the ranges of values used
> > in AD for msSFU30UidNumber and msSFU30GidNumber?


It sounds like you just need to do something similar to above but instead of
nss using uidNumber and GidNumber, you'd use msSFU30uidNumber and
msSFU30GidNumber.

I hope I'm helping instead of making this more difficult :-)

Bill


> -- 
> Happy Landings,
>
> Jon Detert
> IT Systems Administrator, Milwaukee School of Engineering
> 1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A.
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/listinfo/samba
>