Samba: task(ldap) pre-forked worker - 100 Prozent CPU Last

Hallo.
Wir haben vor laaaanger Zeit einen Linux-Server mit Samba und AD eingerichtet.
Nun ist es so, dass auf dem Server der Prozess

 samba: task[ldap] pre-forked worker(3)

immer wieder 100% CPU Last erzeugt:

ae3d282bc78427a88ac36856d0a48a37a5de6be6

Zwar sind Anmeldungen via Auth: [LDAP,simple bind/TLS] (z.B. über eine Webseite) weiterhin problemlos möglich, doch wenn es ein User an einem lokalen Client versucht, klappt die Anmeldung häufig nicht (wenn es zu viele User auf einmal versuchen). Wenn ich den Dienst

service samba-ad-dc restart

neu starte, ist die CPU-Last kurz unten aber nach kurzer Zeit fährt sie dann wieder hoch.

Natürlich habe ich schon das Log-Level höher gedreht:

# Debug-Mode:
log level = 3 passdb:5 auth:5 auth_audit:3
max log size = 10000

In der Logdatei "log.samba" sehe ich sehr häufig Meldungen wie diese hier:

[2023/09/28 08:20:24.071732,  2]
 ../../auth/auth_log.c:647(log_authentication_event_human_readable)
 Auth: [Kerberos KDC,ENC-TS Pre-authentication] 
user [(null)]\[RAUM2-PC30$@LINUX.MEINE-SCHULE.DE] at 
[Thu, 28 Sep 2023 08:20:24.071711 CEST] with [aes256-cts-hmac-sha1-96] status 

[NT_STATUS_WRONG_PASSWORD]

 workstation [(null)] 
remote host [ipv4:10.20.200.30:42963] mapped to [LINUX]\[RAUM2-PC30$]. 
local host [NULL] 

Die Meldung mit dem falschen Passwort kann allerdings nicht stimmen, da es kurze Zeit später auch so aussehen kann:

Auth: [Kerberos KDC,ENC-TS Pre-authentication] ... [NT_STATUS_OK].

In dem Fall hat die Anmeldung natürlich geklappt. Leider ist der Fehlerfall nicht leicht zu reproduzieren: Der o.g. genannte Prozess läuft zwar auf 100% CPU-Last aber wenn man sich alleine anmeldet, klappt es trotzdem noch. Erst wenn es viele User (z.B. eine ganze Schulklasse) gleichzeitig versuchen, klappt die Anmeldung bei vielen Benutzern nicht und liefert dann auch die o.g. Meldung. Wenn man etwas wartet und es "nach und nach" versucht, gelingt die Anmeldung wieder (so dass es nicht an einem falsch eingegebenen Passwort liegt!).
Die Frage ist natürlich: Wie kann man das genauer untersuchen? Welche Prozesse treiben den samba-Task so in die Höhe, dass kaum noch was anderes geht?
Hat jemand eine gute Idee? Danke!

Please also mark the comments that contributed to the solution of the article

Content-Key: 8170844313

Url: https://administrator.de/contentid/8170844313

Printed on: April 27, 2024 at 07:04 o'clock

1 Comment

Es überrascht mich immer wieder, dass selbst langjährige Mitglieder (selbst) aus der Nutzergruppe der Administratoren hier nicht in der Lage sind, eine Frage einigermaßen angemessen zu stellen. Dabei gibt es sogar eine FAQ dafür: How to correctly ask a question

Minimum wären doch bitte das verwendete Linux, dessen Version, die Samba-Version, die zugrunde liegende Hardware, Blech oder virtuell und eventuelle Spezialitäten aus der Konfiguration. Weitere Dienste? Auch, wie viele User dran hängen und wieviele GPOs wäre sicher interessant. Hilfreich wäre es sicher auch, einen Netzwerktrace zu machen, um zu klären, ob und ggf. wie die Last vom Netzwerk reingetragen wird.

Mit den entsprechenden Infos können dann vielleicht die wenigen Linux-Samba-Spezialisten hier (zu denen ich leider nicht gehöre) etwas anfangen.

Ohne Weiteres:

Wenn die Möhre so alt ist, ist sie vielleicht etwas zu schwach für den Usecase? Vielleicht sind die Anforderungen gestiegen? Läuft u.U. noch was auf der Kiste, was Ressourcen nimmt? Etwa gar Samba-FS? Oder gar eine Nextcloud?
Wie bei den Kollegen hier? (Irgendwie klingt Dein Usecase ähnlich

)
https://ask.linuxmuster.net/t/v7-samba-prozesse-gehen-durch-die-decke/61 ...

Generell gilt, auch für Informatiklehrer, ein DC ist ein DC, ist ein DC. Nichts sonst. Und auch der muss mal erneuert werden

Viele Grüße, commodity

German Question Samba