[Samba] idmap troubles with any version 3.30 or later

[Jim Stalewski]

Michael, 

Thanks for the response.  As to the other symlinks question referenced
in this, please disregard.  I believe I have a handle on what is causing
my troubles, and have posted my theory in another thread.  I believe it
has something to do with libnss_winbind.so.2 (or a component thereof)
looking by default for a group called "Domain Users" with an Unix GID,
and only iterating members of said group, instead of simply looking for
users with RFC2307 attributes populated as it used to do pre 3.30.

If that's the case, it would have been nice to have something in a wiki
or help or man page explaining that specific aspect of the change to
idmap functionality, at the very least.

There's still a flaw with that process regardless, which I will follow
in the other thread.

Thanks again,

Jim. 

-----Original Message-----
From: Michael Adam [mailto:obnox at samba.org] 
Sent: Friday, January 21, 2011 5:53 AM
To: Jim Stalewski
Cc: samba at lists.samba.org
Subject: Re: [Samba] idmap troubles with any version 3.30 or later

Hi Jim,

Jim Stalewski wrote:
> Hello list.
> 
> The issue I have is that with the changes made to the idmap 
> functionality of winbind, as regards the enumeration of rfc2307 users 
> and groups using getent passwd and getent group, only those AD users 
> that are not in the domains included in the "idmap config (domain)"
> statements (the ones in trusted domains that get their ID mappings 
> auto-assigned by the TDB backend with id's in the idmap uid / gid
> ranges) get enumerated.  The ones that have the RFC2307 attributes 
> defined within the idmap group (domain) range statements will return 
> their uid/gid/homedir/shell info only if you specify "getent passwd 
> (username)" but they do not enumerate with a "getent passwd."  Same 
> with getent group (groupname) vs getent group.

If this is a case, then it is a bug and needs fixing.
There have been bugs with enumeration in the past and I need to go
recheck bugzilla.
Maybe such bug reappeared or there is a fix that is not yet in the
versions you tested.
Otherwise, we need to file a new bug.

Could you be more precise and send your smb.conf file and indicate for
which of the idmap configs listed, users are not enumerated?

> I have had to create the symlinks in /usr/lib and /usr/lib64 for the 
> /lib/nss_winbind.so.2, /lib/nss_wins.so.2, /lib64/nss_winbind.so.2 and
> /lib64/nss_wins.so.2 libs manually because the installer did not 
> create them for me, and until I did so, getent passwd and getent group

> only displayed the local /etc/passwd and /etc/group entries.

Hm, so you compiled and installed samba manually?
This can also be considered a bug.
Usually, on linux, this is taken care of by the distribution packagers
in the RPMs /.debs and whatnot. This may be the reason why this did not
pop up prominently yet.

Could provide more info about your system?
OS, version, architecture, build system, ...

> Question - are there any other symlinks that should be created for any

> other aspect of the nss idmap functionality that may not have been 
> created by the install process, that would be breaking the user / 
> group enumeration functionality of nss_winbind.so, and if so, what 
> libs need to be symlinked to which folders using what names?

This question is too general instead.
Usually each component providing nss backends should take care of
installing the correct libs/symlinks in its installer itself. If you are
manually installing samba, then you might have to There should

Could you paste your /etc/nsswitch.conf ?


Best regards,

Michael


> I have tried version 3.3x, 3.4.3 and 3.5.4 all with the same lack of 
> results from getent passwd and getent group but it functioned properly

> under 3.2.7, so it can't be
> 
> Thanks in advance,
> 
> Jim.
> 
> 
> 
> This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender and delete it. Please note that any views or opinions presented
in this email are solely those of the author and do not necessarily
represent those of the company. 
> No employee or agent is authorized to conclude any binding agreement
on behalf of?Visa Lighting with another party by email without express
written confirmation by?an authorized representative of the Company.
> Finally, the recipient should check this email and any attachments for
the presence of viruses. The company accepts no liability for any damage
caused by any virus transmitted by this email.
> 
> 
> 

> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba



This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender and delete it. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. 
No employee or agent is authorized to conclude any binding agreement on behalf of Visa Lighting with another party by email without express written confirmation by an authorized representative of the Company.
Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.