samba - Nov 2009 - Samba 3.0.33/3.2.15 AD joined slow initial connect with LDAP backend

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
controllers.

 

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 ou=Idmap,dc=example,dc=com

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

        idmap config ALLDOMAINS:ldap_url     = ldap://127.0.0.1/

        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://127.0.0.1/

        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
possible?

 

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,

 

Ton

Diego,

Thank you for your reply. I'm testing with 3.0.33 since that's the
latest version Redhat is using in RHEL5 (Redhat has the habbit of holding a
version and do backport patching). The 3.2.x version was marked for production
and what I saw in FAQ was that the 3.4.x was still to experiment with?

If you mean the 'winbind enum users/groups' setting that has been turned
off as suggested in the man pages. If activated it could crash a certain role AD
controller. That's not something I can risk. But would that in normal
behaviour not fill somekind of cache? If I increase the caching in theory that
would perhaps reduce the numer of queries required for a user at a given time. I
don't know if it would be a problem setting this to 3 days so the cache
could also pass over the weekend. Does not take away why it takes so long to
query the AD.

What do you mean with:

Looking up group names is really slow (up to a couple of minutes when using
"id user.name" or "groups user.name").

Is it always slow to query the AD? Would the 3.0.23d server that I need to
upgrade be using more caching then the later versions by default?

To answer your last question. Yes, the ldap is running on the local system for
the idmaps. In production I have one samba server running a master ldap idmap
backend and the other samba server configured as slave.

Kind regards,

Ton


-----Original Message-----
From: Diego Zuccato [mailto:diego.zuccato at unibo.it] 
Sent: maandag 23 november 2009 12:42
To: Hoogstraten, Ton
Subject: Re: [Samba] Samba 3.0.33/3.2.15 AD joined slow initial connect with
LDAP backend

Hoogstraten, Ton wrote:
> However on the test 3.0.33 system I'm experiencing a problem that I
Why are you using such an ancient version? What about 3.4.x ?
> 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.
Looking up group names is really slow (up to a couple of minutes when 
using "id user.name" or "groups user.name").

Have you tried playing with enum users/groups ? If activated on large AD 
trees, it could impact performances a lot!
>         idmap alloc config:ldap_url     = ldap://127.0.0.1/
Are you using a locally running (on localhost!) ldap server?

-- 
Diego Zuccato
Servizi Informatici
Dip. di Astronomia - Universit? di Bologna
Via Ranzani, 1 - 40126 Bologna - Italy
tel.: +39 051 20 95786
mail: diego.zuccato at unibo.it