[Samba] how to make 'winbind nss info = sfu' work in v >= 3.0.26a
Jonathan Detert
For Unix' applied.
I use winbind v3.0.24 to get user/group info from that Ms.Active directory
instance like so:
-------- begin smb.conf snippet: ------------
security = ADS
realm = mydomain.com
workgroup = MYDOMAIN
winbind enum groups = yes
winbind enum users = yes
winbind nested groups = yes
winbind nss info = sfu
winbind separator = +
winbind use default domain = yes
idmap gid = 500-45000
idmap uid = 500-45000
idmap backend = ad
-------- end smb.conf snippet: ------------
that works fine on ubuntu v7.04.
The same config, shown above, does not work under winbind v3.0.26a
running on ubuntu v7.10. I can turn an name into a sid, and the sid
back into a name (via wbinfo -n and -s, respectively), but I can't turn
a sid into a unix uid or gid (via the -S argument). Also, 'getent passwd'
doesn't return any users from Active Directory.
Any idea what's wrong? Is it my config?
--
Jon Detert
IT Systems Administrator, Milwaukee School of Engineering
1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A.
--
Linus Torvalds can divide by zero.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
Jonathan Detert
reference to 'sfu' with 'rfc2307', as well as converting to the newer
idmap config directives. However, I still can't resolve sids to uids.
Now, instead of complaining about not finding sfu.so, the log complains
about not finding rfc2307.so:
/* BEGIN log.wb-MYDOMAIN excerpt : */
[2008/04/16 13:21:15, 5] nsswitch/nss_info.c:smb_register_idmap_nss(79)
smb_register_idmap_nss: Successfully added idmap nss backend 'template'
[2008/04/16 13:21:15, 5] lib/module.c:smb_probe_module(108)
Probing module 'rfc2307'
[2008/04/16 13:21:15, 5] lib/module.c:smb_probe_module(119)
Probing module 'rfc2307': Trying to load from /usr/lib/samba/nss_info/rfc2307.so
[2008/04/16 13:21:15, 3] lib/module.c:do_smb_load_module(49)
Error loading module '/usr/lib/samba/nss_info/rfc2307.so': /usr/lib/samba/nss_info/rfc2307.so: cannot open shared object file: No such file or directory
[2008/04/16 13:21:15, 3] nsswitch/nss_info.c:nss_init(209)
nss_init: no nss backends configured. Defaulting to "template".
/* END log.wb-MYDOMAIN excerpt */
It seems strange that log.winbindd-idmap says it successfully loaded nss backend 'sfu':
/* BEGIN log.winbindd-idmap excerpt : */
[2008/04/16 13:21:15, 1] nsswitch/idmap.c:idmap_init(365)
Initializing idmap domains
[2008/04/16 13:21:15, 5] lib/module.c:smb_probe_module(108)
Probing module 'ad'
[2008/04/16 13:21:15, 5] lib/module.c:smb_probe_module(119)
Probing module 'ad': Trying to load from /usr/lib/samba/idmap/ad.so
[2008/04/16 13:21:15, 2] lib/module.c:do_smb_load_module(64)
Module '/usr/lib/samba/idmap/ad.so' loaded
[2008/04/16 13:21:15, 5] nsswitch/idmap.c:smb_register_idmap(163)
Successfully added idmap backend 'ad'
[2008/04/16 13:21:15, 5] nsswitch/nss_info.c:smb_register_idmap_nss(79)
smb_register_idmap_nss: Successfully added idmap nss backend 'rfc2307'
[2008/04/16 13:21:15, 5] nsswitch/nss_info.c:smb_register_idmap_nss(79)
smb_register_idmap_nss: Successfully added idmap nss backend 'sfu'
[2008/04/16 13:21:15, 5] nsswitch/idmap.c:idmap_init(452)
Forcing to readonly, as this module can't store arbitrary mappings.
/* END log.winbindd-idmap excerpt */
Anyone have an idea of what is messed up here? Thanks,
Jon
* Jonathan Detert <Jonatha...@msoe.edu> [080415 16:00]:
Fashion is a form of ugliness so intolerable that we have to alter it every six months.
~ Oscan Wilde
Jonathan Detert
> At the suggestion of someone who replied offline, I tried replacing
> reference to 'sfu' with 'rfc2307', as well as converting to the newer
> idmap config directives. However, I still can't resolve sids to uids.
>
> Now, instead of complaining about not finding sfu.so, the log complains
> about not finding rfc2307.so:
-- snip --
more news:
Just for fun, I made these changes:
a) re-established the schema mmode as sfu instead of rfc2037:
idmap config MSOE:schema_mode = sfu
b) changed winbind nss info of 'rfc2037' to 'template sfu':
winbind nss info = template sfu
and restarted winbind. Now Sids map to Uids/Gids, the way I expect.
Yay! But, of course, the homedir and loginshell are from template, and
not sfu, like I want. The whacked out thing here is that simply by
adding 'template' before 'sfu' in the 'winbind nss info' directive, now
'getent passwd username' returns something. Previously, it returned
nothing. And, it returns the uid:gid as sfu has them. So, sfu is
working, to an extent. It just can't seem to figure out the homedir and
loginshell.
Any ideas?
Thanks
p.s. here are the relevant lines from my smb.conf in it's present state:
workgroup = MSOE
realm = msoe.edu
security = ADS
idmap domains = MSOE
idmap config MSOE:backend = ad
idmap config MSOE:default = yes
idmap config MSOE:schema_mode = sfu
idmap config MSOE:range = 500-45000
idmap alloc backend = tdb
idmap alloc config:range = 5000 - 9999
winbind enum groups = yes
winbind enum users = yes
winbind nested groups = yes
winbind nss info = template sfu
If the facts don't fit the theory, change the facts.
Gerald (Jerry) Carter
Hash: SHA1
Jonathan Detert wrote:
> At the suggestion of someone who replied offline, I tried replacing
> reference to 'sfu' with 'rfc2307', as well as converting to the newer
> idmap config directives. However, I still can't resolve sids to uids.
>
> Now, instead of complaining about not finding sfu.so, the log complains
> about not finding rfc2307.so:
and then run How did you compile Samba ? you need the
- --with-shared-modules=idmap_ad "make install" to get the
necessary bits. You should see $(libdir)/nss_info/rfc2307.so
as a symlink to ../idmap/ad.so.
>
> /* BEGIN log.wb-MYDOMAIN excerpt : */
> [2008/04/16 13:21:15, 5] nsswitch/nss_info.c:smb_register_idmap_nss(79)
> smb_register_idmap_nss: Successfully added idmap nss backend 'template'
> [2008/04/16 13:21:15, 5] lib/module.c:smb_probe_module(108)
> Probing module 'rfc2307'
> [2008/04/16 13:21:15, 5] lib/module.c:smb_probe_module(119)
> Probing module 'rfc2307': Trying to load from /usr/lib/samba/nss_info/rfc2307.so
> [2008/04/16 13:21:15, 3] lib/module.c:do_smb_load_module(49)
> Error loading module '/usr/lib/samba/nss_info/rfc2307.so': /usr/lib/samba/nss_info/rfc2307.so: cannot open shared object file: No such file or directory
> [2008/04/16 13:21:15, 3] nsswitch/nss_info.c:nss_init(209)
> nss_init: no nss backends configured. Defaulting to "template".
> /* END log.wb-MYDOMAIN excerpt */
>
> It seems strange that log.winbindd-idmap says it successfully loaded
> nss backend 'sfu':
Because the nss_info sfu and rfc2307 modules are built in the
idmap ad.so module and therefore initialized at the same time.
So if the idmap plugin is loaded first you are fine. But
often in the parent winbindd process you will see it attempt to
load the nss_info module first which seems to be failing.
cheers, jerry
- --
=====================================================================
Samba ------- http://www.samba.org
Likewise Software --------- http://www.likewisesoftware.com
"What man is a man who does not make the world better?" --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIBnirIR7qMdg1EfYRAt0zAJwKgTQMeiWho9TxfDOoV63voghRHACdGzEH
GwWTI+5+gfk+ismcwaX7Y5c=
=qssH
-----END PGP SIGNATURE-----
Jonathan Detert
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jonathan Detert wrote:
> > At the suggestion of someone who replied offline, I tried replacing
> > reference to 'sfu' with 'rfc2307', as well as converting to the newer
> > idmap config directives. However, I still can't resolve sids to uids.
> >
> > Now, instead of complaining about not finding sfu.so, the log complains
> > about not finding rfc2307.so:
>
> and then run How did you compile Samba ? you need the
I didn't : Ubuntu did (gutsy, v7.10). Maybe I need to compile it
myself. I was hoping not to have to.
> - --with-shared-modules=idmap_ad "make install" to get the
> necessary bits. You should see $(libdir)/nss_info/rfc2307.so
> as a symlink to ../idmap/ad.so.
-- snip --
> > It seems strange that log.winbindd-idmap says it successfully loaded
> > nss backend 'sfu':
>
> Because the nss_info sfu and rfc2307 modules are built in the
> idmap ad.so module and therefore initialized at the same time.
> So if the idmap plugin is loaded first you are fine. But
> often in the parent winbindd process you will see it attempt to
> load the nss_info module first which seems to be failing.
So, is that something that can be controlled via config?
Or, are you saying it's just noise in the log file that works itself out
ok in the end?
--
Jon Detert
IT Systems Administrator, Milwaukee School of Engineering
1025 N. Broadway, Milwaukee, Wisconsin 53202, U.S.A.
--
"If there were no God, there would be no atheists."
~ G. K. Chesterton
Gerald (Jerry) Carter
Hash: SHA1
Jonathan Detert wrote:
>>> It seems strange that log.winbindd-idmap says it successfully loaded
>>> nss backend 'sfu':
>> Because the nss_info sfu and rfc2307 modules are built in the
>> idmap ad.so module and therefore initialized at the same time.
>> So if the idmap plugin is loaded first you are fine. But
>> often in the parent winbindd process you will see it attempt to
>> load the nss_info module first which seems to be failing.
>
> So, is that something that can be controlled via config?
> Or, are you saying it's just noise in the log file that
> works itself out ok in the end?
No. It's real. Each winbindd process is responsible for
loading the nss info plugin and calling the init function.
The parent seems to be failing (my guess is due to a packaging
error leaving out the nss_info directory).
cheers, jerry
- --
=====================================================================
Samba ------- http://www.samba.org
Likewise Software --------- http://www.likewisesoftware.com
"What man is a man who does not make the world better?" --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIDIWoIR7qMdg1EfYRAnJFAKDsb4cmm/OqWXRiEYa87G31a0sFqACgjBni
u6pCfvAJ485hyzPXmCp4xpA=
=FC1u
-----END PGP SIGNATURE-----