I've updated (via freebsd ports system) Samba from 3.0.23 to 3.0.25a. And now I have many errors in winbind log: [2007/06/13 15:53:38, 1] libads/ldap_utils.c:ads_do_search_retry_internal(115) ads reopen failed after error Referral [2007/06/13 15:53:38, 1] libads/ldap_utils.c:ads_do_search_retry_internal(115) ads reopen failed after error Referral ... and so on many many times "net ads testjoin", "wbinfo -p", "wbinfo --sequence", "wbinfo --domain DOMAIN -u -g", "wbinfo -i DOMAIN\username" work fine. NSSWITCH resolving via "id DOMAIN\username" works too. All work! But what does mean this errors?
Have seen this is as well while we are looking up DNs of foreign SIDs (via dn_lookup()). This is fixed in upstream Samba where we no longer require to look those SIDs up via LDAP ourselves but use msrpc calls for that. Can you please post a full log level 10 logfile ?
Thanks for the log (sent off list). This are indeed LDAP referrals returned by AD when looking up remote members from e.g. universal AD groups. The upcoming 3.0.26 release has this fixed (I just checked again), you can ignore those errors for now.
Hmmm... Right now I've updated (via freebsd ports system) Samba from 3.0.25a to 3.0.26a. And I found the same BUG in winbind.log: [2007/09/19 12:40:16, 1] nsswitch/winbindd.c:main(990) winbindd version 3.0.26a started. Copyright Andrew Tridgell and the Samba Team 1992-2007 [2007/09/19 12:40:17, 0] nsswitch/winbindd_cache.c:initialize_winbindd_cache(2223) initialize_winbindd_cache: clearing cache and re-creating with version number 1 [2007/09/19 12:42:16, 1] nsswitch/idmap.c:idmap_init(365) Initializing idmap domains [2007/09/19 12:42:51, 1] libads/ldap_utils.c:ads_do_search_retry_internal(115) ads reopen failed after error Referral [2007/09/19 12:42:51, 1] libads/ldap_utils.c:ads_do_search_retry_internal(115) ads reopen failed after error Referral [2007/09/19 12:42:51, 1] libads/ldap_utils.c:ads_do_search_retry_internal(115) ads reopen failed after error Referral ... and so on many many times
Yes, as implied with comment #2, the fix has indeed gone into the tree that *was* called 3.0.26 at that time but which now has become the SAMBA_3_2 and SAMBA_3_2_0 trees. As soon as 3.2.0 is out, you should have this fixed. The current released 3.0.26 releases do not have the fix yet.
Still fixed in the upstream code. Will be in 3.2.0.