samba - Nov 2009 - Cannot retrieve user/group information

Hi all,

I have done a fair bit of searching of the mailing list archives,  
google and the manual, but have not had any luck as yet.  I apologize  
for the length of this e-mail, but I thought it was better to provide  
what I could right off the bat instead of waiting to be asked for it.

I am having the following oddity with a new samba server:  I have it  
configured to talk to an rfc2307-enabled AD using the ad idmap  
backend.  The 'net ads join' command appears to have worked  
successfully, as an object was created in the appropriate OU.  The  
'net ads testjoin' reports success.  However, the service is  
unreliable at best.  There appears to be significant delays during  
some procedures, especially establishing the initial connection.  I  
believe this may be because it is timing out trying to retrieve user  
information.  I am leaning in this direction because while 'wbinfo -n  
<user>' returns a SID successfully, 'wbinfo -i <user>'
fails to work:

# wbinfo -n joeuser
S-1-5-21-3013314750-1269944620-1508481130-93739 User (1)
# wbinfo -i joeuser
Could not get info for user joeuser

When this happens, I see the following messages in the logs -- debug  
level 2 (irrelevant-looking messages stripped for clarity):

==> log.winbindd-idmap <=[2009/11/19 14:50:33,  2]
lib/module.c:64(do_smb_load_module)
   Module '/usr/lib64/samba/idmap/ad.so' loaded
[2009/11/19 14:50:33,  1] winbindd/idmap.c:580(idmap_alloc_init)
   could not find idmap alloc module ad
[2009/11/19 15:00:34,  1] winbindd/idmap_ad.c:143 
(ad_idmap_cached_connection_internal)
   ad_idmap_init: failed to connect to AD
[2009/11/19 15:00:34,  1] winbindd/idmap_ad.c:543 
(idmap_ad_sids_to_unixids)
   ADS uninitialized: No logon servers

This seems to indicate that the module may have trouble loading for  
some reason, or perhaps that is a spurious error message.  However, I  
don't see idmap_ad in the list of modules, either (perhaps these are  
only modules that aren't loaded on demand?):

# smbd -b
<snip>
Builtin modules:
     pdb_ldap pdb_smbpasswd pdb_tdbsam pdb_wbc_sam rpc_lsarpc  
rpc_winreg rpc_initshutdown rpc_dssetup rpc_wkssvc rpc_svcctl  
rpc_ntsvcs rpc_netlogon rpc_netdfs rpc_srvsvc rpc_spoolss rpc_eventlog  
rpc_samr idmap_ldap idmap_tdb idmap_passdb idmap_nss nss_info_template  
auth_sam auth_unix auth_winbind auth_wbc auth_server auth_domain  
auth_builtin auth_netlogond vfs_default vfs_posixacl

Are those messages expected?

This installation was from an RPM I built using the packaging scripts  
in the source tarball, specifically the RHEL script using GCC 4.1.2.   
The /usr/lib64/samba/idmap/ad.so file does appear to be there and  
looks healthy (no missing libraries or anything).

Other relevant system details:

OS: CentOS 5.4
Kernel: 2.6.18
Arch: x86_64
Samba version: 3.4.3

Relevent bits of smb.conf:

workgroup     = FOO
security           = ads
realm              = FOO.BAR.BAZ
idmap backend      = ad
idmap range = 1000-999999
password server    = foo.bar.baz
winbind nss info           = rfc2307
winbind separator          = /
winbind use default domain = yes
winbind nested groups      = yes

I should also mention that kinit works successfully on the machine,  
and getent paswd/group works as well (using pam_ldap against the AD).

Finally, I have a machine with very similar configuration already on  
the network which works.  The primary difference is that it is running  
a much older version of samba (3.0.22).

Thoughts?

Please let me know if I can include more information.  I tried to keep  
it as short as possible for this initial request.

Thanks,

--
Ryan Hardy <ryan.hardy at duke.edu>

> workgroup     = FOO
> security           = ads
> realm              = FOO.BAR.BAZ
> idmap backend      = ad
> idmap range = 1000-999999
> password server    = foo.bar.baz
> winbind nss info           = rfc2307
> winbind separator          = /
> winbind use default domain = yes
> winbind nested groups      = yes
Do you really need to specify a password server?  IIRC this is used in
standalone mode when you want to authenticate against a Windows machine.
 I don't know whether it would cause any confusion if you want AD to
handle authentication but then tell it not to use AD but another box
instead.

Given that the error message reports it can't find the login server,
that would seem to indicate that either your DNS isn't set up properly
for the domain, the machine can't resolve it properly, or there's some
sort of firewall blocking some or all of the communication with the AD
servers.

Can you run Wireshark/tcpdump while the problems are happening to see
where the box is trying to connect to, and if it's receiving any responses?

Cheers,
Adam.