samba - Jan 2011 - idmap troubles with any version 3.30 or later

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.

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.

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?

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.

This point is of interest. I just have a look at the ldapsam:trusted =yes
 and       ldapsam:editposix=yes parameters and set up a test system.
But if this is true I use the old way without winbind.


-----------------------------------------------
EDV Daniel M?ller

Leitung EDV
Tropenklinik Paul-Lechler-Krankenhaus
Paul-Lechler-Str. 24
72076 T?bingen

Tel.: 07071/206-463, Fax: 07071/206-499
eMail: mueller at tropenklinik.de
Internet: www.tropenklinik.de
-----------------------------------------------

-----Urspr?ngliche Nachricht-----
Von: samba-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org]
Im
Auftrag von Jim Stalewski
Gesendet: Donnerstag, 20. Januar 2011 21:04
An: samba at lists.samba.org
Betreff: [Samba] idmap troubles with any version 3.30 or later

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.

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.

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?

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/samba/attachments/20110121/6c90a6a2/attachment.pgp>