[Samba] Samba 3.0.33/3.2.15 AD joined slow initial connect with LDAP backend

Hoogstraten, Ton Ton.Hoogstraten at ingram.nl
Mon Nov 23 04:09:03 MST 2009

I'm hoping someone can help me with the following. I currently have 2
Samba fileservers version 3.0.23d joined to our corporate Active
Directory. Clients currently are Windows XP. I'm asked to prepare to
migrate XP to Windows 7. From testing it looks like Samba 3.0.23d is not
compatible with Windows 7. Therefor I started testing with the latest
RHEL5 version 3.0.33-3.1e.el5 on RHEL5. Enabling 'client ntlmv2 auth =
yes' seems to be key to make this work for Windows 7.


However on the test 3.0.33 system I'm experiencing a problem that I
can't solve. The initial connect from either a XP or 7 client is slow
when not in the Samba cache (even when changing the config to the same
as the production server for XP, removing the ntlmv2 option). It depends
on the user connecting how slow. For example my own user account
requires an average of 40 seconds before displaying the Samba shares on
a fresh connect. The 3.0.23d server remains fast talking to same domain


The following settings I think I got from the Redhat Knowledgebase for
performance make no difference in this matter. They have been enabled
and disabled with no effect.


        client schannel = no

        client use spnego = no

        server signing = auto

        large readwrite = no


The client spnego setting however does get in your way when trying to
join a system to Active Directory when set to 'no'!


I think the explanation for the difference in slowness per user is based
on the group membership of that user. For example an user that is only a
member of Domain Users takes about 10 seconds to display the shares
(still to slow in my opinion). For testing purpose I've reduced the
cache for winbind and idmap so the server needs to keep looking up the
user and SID information.


idmap cache time = 120

winbind cache time = 120


The SID to UID/GID mappings are stored in an openldap database so both
servers have the same UID/GID mappings. For the test server this is
running on the localhost. I have updated the backend config to the
following on the test server to use the new idmap_ldap setup.


        idmap domains = ALLDOMAINS

        idmap config ALLDOMAINS:default      = yes

        idmap config ALLDOMAINS:backend      = ldap

        idmap config ALLDOMAINS:ldap_base_dn =

        idmap config ALLDOMAINS:ldap_user_dn =

        idmap config ALLDOMAINS:ldap_url     = ldap://

        idmap config ALLDOMAINS:range        = 10000 - 2000000


        #idmap backend where we write new entries:

        idmap alloc backend = ldap

        idmap alloc config:ldap_base_dn = ou=Idmap,dc=example,dc=com

        idmap alloc config:ldap_user_dn = cn=Manager,dc=example,dc=com

        idmap alloc config:ldap_url     = ldap://

        idmap alloc config:range        = 10000 - 2000000


The 'password server' option is set to a local Domain Controller. either
by DNS name or IP. This seems to be making no difference. Additional the
DNS name is als stored in /etc/hosts. I'm trying to keep the server
connecting on the local LAN instead of wandering to the "nearest" server
for example in Germany.


When I set the winbind logging to level 10 I see the server connecting
to the Domain Controller LDAP and retrieve the SID information and store
it in the local TDB files. Depending on the user more SIDs needs to be
resolved making the process slower.


Does anybody know what could be causing this? Has the caching method
changed since version 3.0.23d? I can try increasing the caching to cache
the information for days to try and reduce the queries for the Domain
Controller. But there must be a reason why the default settings are kept
low and I don't know if this will bring any other side affects.


It is worth to mention that the production server started when we had a
NT domain. In order to migrate we had double SID's resolving to single
UID/GIDs during the move between domains. When testing this with version
3.0.33 this could crash and make the winbind daemon coredump. I have
cleaned out all duplicate entries since the NT domain is gone now.


Can it be that I'm missing Indexes/config on my idmap openldap config
from version 3.0.23d? Does anybody know how I can optimize that if


Currently I have the following in my slapd.conf:

index sambaSID                          eq

index sambaPrimaryGroupSID              eq

index sambaDomainName                   eq


Last I can mentioned that upgrading the server to Samba version 3.2.15
to see if that solves anything is also not working. I have 2 test
servers now. One being version 3.0.33 and one being 3.2.15 displaying
the same problem. When connecting with empty cache the lookups are slow.


Kind regards,



More information about the samba mailing list