[Samba] Winbindd has still bottlenecks when used with interdomain trusts.

[Harald Strack]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings!

I run samba 3 since several years in a domain with more than 10000 users
and multiple departments. We have a central Domain running a PDC and
some domains in the departments. The domains in the
departments are connected to the central domain via interdomain trusts.
All PDCs are samba 3 using the same LDAP backends (very fast SunONE LDAP
infrastructure). This way the administrators of the
departments are able to handle the profiles of their users and
workstations locally while the user database is in the central domain:

Picture:

Central PDC  <-- trust --- (1..n) department PDCs

This works quite well. But their is a really serious problem how
winbindd in the domains of the departments handles logons /
authentication:  concurrent logons are serial processed, not parallel!

How I understand the changelog of samba this was the desired behavior up
to samba 3.0.14a. From samba 3.0.20 onwards winbindd was reimplemented
to work asynchronly, so it should be able to process
logons now in parallel.

I tested it with the actual samba 3.0.24 but it is still very slow and a
lot of requests are ending up in timeouts. When I look in the logs of
winbindd I see that it accepts all connections (pipes)
from local samba processes but uses still only one TCP connection to the
central Domain to process the SID to uid/gid mappings.

Picture of the situation:

Central PDC (smbd) <--- TCP  ---  department PDC (winbind) <--  (1..n)
smbd <-- 1..n Workstations / Logons

The TCP connection between the central PDC and the department PDC
(winbindd) seems to be still a bottleneck. Is this right? What can I do?
Any help or comment on this issue is very very welcome!

However I have this problem since a long time and I actually use a samba
version where I patched out all SID/gid mappings via winbind. This bad
hack speeds up everything so that up to about 40
concurrent logins are possible but that's no long-term solution...


Best regards

Harald Strack
                                              

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFF5fEvczpSApoeLSQRAu2FAKDkwVYD5dHt6vsmsg9snEArg4ihygCfYx/4
4AT6PVOqi/4a41ROT4mIv9g=
=sOCv
-----END PGP SIGNATURE-----