2016-07-20 23 views
3

Wenn LogonUser() mit LOGON32_LOGON_NETWORK verwendet wird, um die Windows-Anmeldung und das Windows-Kennwort eines Benutzers zu bestätigen, scheint das Konto nicht gesperrt zu werden, auch wenn das falsche Kennwort häufiger als die Sicherheitsrichtlinie des Benutzers aktiviert wird.Wird wiederholt LogonUser von Delphi mit LOGON32_LOGON_NETWORK aufgerufen, damit das Konto gesperrt wird?

Es gibt eine ähnliche Frage:

Incorrect password passed to LogonUser() but the Active Directory account is not locked as expected

Aber in ihrem Fall, sie LOGON32_LOGON_INTERACTIVE stattdessen verwendet haben.

In meinem Fall ist der Domänencontroller verfügbar, um die Anmeldung zu authentifizieren, aber es ist nicht klar, aus den documentation ob LOGON32_LOGON_NETWORK mit Mitteln nicht mit dem Domänencontroller nur authentifizieren, dass es nicht die Anmeldeinformationen zwischengespeichert werden, wenn sie richtig.

Was ich suche ist eine Richtlinieneinstellung, die ein Windows-Domänenkonto sperren wird, wenn LogonUser() mit dem falschen Kennwort zu oft verwendet wird.

EDIT: Zusätzliche Informationen zur Klärung der Situation.

Wenn LoginUser() auf meiner XE2 Entwicklung Maschine Aufruf mit dem richtigen Domäne \ Benutzer aber falschem Passwort, ist das Ergebnis falsch. SysUtils.SysErrorMessage(System.GetLastError) Aufruf gibt mir:

Der Betrieb

Der gleiche Test durchgeführt auf einer der Maschinen beim Kunden vor Ort erfolgreich

abgeschlossen zeigt:

Ausfall Anmeldung: unbekannter Benutzername oder schlecht Passwort

Fortsetzung des Tests auf einer ihrer Maschinen hat schließlich Berichterstattung:

Das angesprochene Konto ist momentan gesperrt und kann nicht

zu

angemeldet sein Was ich versuche, um zu bestimmen, warum das Client anders verhält, als wir Systeme haben möchten auf unserer Domäne sperren auch Konten. Vielleicht ist es eine Eigenschaft des Windows-Accounts?

+0

Ich denke, es muss etwas falsch sein mit der Art, wie Sie den Fehlercode überprüfen - wenn der Aufruf fehlschlägt, sollte der Fehlercode nie Null sein. (Ich vermute, dass der Grund dafür, dass der Account nicht gesperrt ist, darin besteht, dass der Anmeldeversuch fehlschlägt, bevor er das Passwort überprüft. Aber ohne den eigentlichen Fehlercode ist das reine Ratespiel.) Ich kann das mit LOGON32_LOGON_NETWORK bestätigen Der Anmeldetyp verhindert nicht, dass das System versucht, sich bei einem Domänencontroller zu authentifizieren.Ich bin mir nicht sicher, ob gegen zwischengespeicherte Anmeldeinformationen erfolgreich sein kann, wenn der Domänencontroller nicht vorhanden ist. –

+0

(Beachten Sie, dass in der Zeile "LogonUser Anmeldeinformationen für diesen Anmeldetyp nicht zwischenspeichern" über eine andere Art von zwischengespeicherten Anmeldeinformationen gesprochen wird.) –

Antwort

4

Die Richtlinieneinstellung, nach der Sie suchen, ist Account Lockout Threshold.

Ich glaube nicht, dass dies irgendetwas mit der Tatsache zu tun hat, dass Delphi die Sprache ist, die beim Aufruf der API involviert ist. Dies ist eine reine Windows-API/Sicherheitsrichtlinienfrage.

+0

Sie haben Recht. Die Entwicklungsdomäne hatte den Schwellenwert auf 0 gesetzt. Das wurde nun behoben und wir sehen dasselbe Ergebnis wie der Client. – SiBrit