[Samba] High cpu load on LDAP

Heinz Hölzl heinz.hoelzl at gvcc.net
Mon Jan 27 09:33:11 UTC 2025


Hi,

I suspect that the problem lies elsewhere.

1. we have a trust with 12 other domains, all with Microsoft AD

The queries of type “show me everyone” [(|(objectClass=user)(objectClass=group))] basedn: [dc=xxx,dc=xxx] all come from NAS of the trusted domains. I blocked them via IPTABLES and got a slight improvement of the situation. These are probably all NAS with older Samba versions.

Could the 12 trusts themselves be problematic?


2. we use openLDAP to authenticate various services. Slapd uses “saslauthd -a kerberos5” to authenticate against the samba DCs.

The slapd servers are located in our doamain, but must also authenticate users of the trusted domains.

e.g.

user from own domain:
userPassword in openldap: {SASL}user1 at MYDOMAIN.COM<mailto:{SASL}user1 at MYDOMAIN.COM>
---
user from trusted domain:
userPassword in openldap: {SASL}user2 at OTHERDOMAIN.COM<mailto:{SASL}user2 at OTHERDOMAIN.COM>


Today (another Monday) I saw that one of our DCs, which is actually almost exclusively responsible for authentication via openLDAP, was also partially under high load (always the ldap processes). This DC is located in a site where there are no clients. It is also protected with iptables so that only the other DCs and the slapd servers can communicate with it.


Could this configuration affect the performance?


Regards,
Heinz


On 22/01/25 19:54, Heinz Hölzl via samba wrote:

> hi,

>

>

> here is the number of member assignments:

>

> regards,

> Heinz

>

> ldbsearch -H /usr/local/samba/private/sam.ldb | \

> grep -o -C1 '^member\b' | uniq -c | grep member | sort -n


I guess adding another `| uniq -c` at the end of that would save

scrolling. And something like


ldbsearch -H /usr/local/samba/private/sam.ldb  | \

   grep -oP '(member:)|(dn:.+)' | uniq -c | grep -PB1 '\d\d\d member:'


will show you the big groups, which might help confirm that this

greppery is correct.


Anyway,


[...]

> 174 member

> 175 member

> 179 member

> 222 member

> 275 member

> 408 member

> 530 member

> 604 member

> 694 member

> 785 member


That's not too bad.


As Denis Cardon said in

https://urldefense.com/v3/__https://lists.samba.org/archive/samba/2024-October/249848.html__;!!IC0dFnBEFA8modo!S3aHN65Fn1ih_t2m5OlaQpmBO-ZIArbxHJBv4Zx7MphefeUpEVpTnkFBXvhFnGnkyygCrXS-VU6cXsPId_S0FpufGoAIO1xBh1Y$, "you

shouldn't go beyond a few thousand members" and you don't.


So it comes down to the other thing he mentions, LDAP responses that are

just really big.


In this other recent message

https://urldefense.com/v3/__https://lists.samba.org/archive/samba/2025-January/250841.html__;!!IC0dFnBEFA8modo!S3aHN65Fn1ih_t2m5OlaQpmBO-ZIArbxHJBv4Zx7MphefeUpEVpTnkFBXvhFnGnkyygCrXS-VU6cXsPId_S0FpufGoAISaxgtqI$

I was noticing that you have a lot of these requests:


>    ldapsrv_SearchRequest: LDAP Query: Duration was 1.74s, SearchRequest

> by S-1-5-21-xxxxxxxxxxxxx-xxxxxxxxxxxxxx-xxxxxxxxxxxxxxx-3084 from

> ipv4:192.168.48.87:33768 filter:

> [(|(objectClass=user)(objectClass=group))] basedn: [dc=GVCC,dc=NET]

> scope: [SUB] result: Success


which to me looks like multiple clients repeatedly asking for 90% of the

database. Maybe they can behave better.


cheers,

Douglas




More information about the samba mailing list