AD User Konto dauernd gesperrt

[NilsK 2.958]

Moin,

 

alle DCs in einer AD-Domäne sind gleichberechtigt. Dass der "zweite" DC die Ereignisse zur Sperrung anzeigt, liegt einfach daran, dass er "zufällig" (vereinfacht gesagt) die Anmeldeversuche bearbeitet hat. Solche Ereignisse finden immer nur auf einem der DCs statt und werden nur dort protokolliert. Einen ursächlichen Zusammenhang zwischen dem konkreten DC und der Sperrung gibt es nicht.

 

Wenn der protokollierende DC feststellen kann, von welchem Endgerät der Anmeldeversuch kommt, sollte sich dies in den Ereignisdetails finden. Je nach Netzwerkaufbau kann es durchaus aufwändig sein, die Ursache genau herauszufinden. Es ist aber kaum anzunehmen, dass etwas anderes dahintersteckt. Natürlich kann es sich auch um automatisierte Angriffsversuche handeln, aber auch das wäre eher untypisch. Fast immer ist es was "Simples".

 

Nebenbei bemerkt, sollten alle DCs natürlich auch gleichartig konfiguriert sein, sprich, der zweite sollte auch DNS ausführen und in der Konfiguration aller Clients als DNS-Server mit angegeben sein. Sonst gibt es keine Ausfallsicherheit.

 

Gruß, Nils

 

[zahni 554]

In den Security-Events an allen DCs nachschauen. Bei Kerberos 4771 "Kerberos pre-authentication failed." Dort steht in den Details die Remote-Adresse.

Oder z.B. 4476. Da seht dann der u.U. Name des PCs.

 

 

[smothy 0]

Hallo zusammen,

 

erstmal vielen Dank für eure rege Beteiligung und Hilfe.

 

@Nils, natürlich ist bei dem 2. Server ( DC ) auch DNS mit dabei - alles soweit identisch.

 

Protokolle hatte ich auch bereits angeschaut - ( 4771 etc- ) dort steht, was mich etwas verwundert unser GatewayFirewall Server drin ( Linux basiert ).

Und da weiß ich nicht woran es liegen könnte denn dort hat die "Kollegin" nie etwas gemacht kommt auch gar nicht dort drauf.

 

bearbeitet 23. April 2019 von smothy

[NilsK 2.958]

Moin,

 

mir fiele dazu ein: Der Anmeldeversuch kommt von außen. Vielleicht also ein Mobilgerät mit falscher/zwischengespeicherter Anmeldung. Oder was auch immer bei euch über das Gateway geht. Falls es, wie du schilderst, nur um wenige Konten geht, spricht das gegen einen Angriffsversuch, da wäre eher zu erwarten, dass zahlreiche Konten durchprobiert werden.

 

Gruß, Nils

 

[smothy 0]

Mobil-Teile o.ä. laufen definitiv nicht darüber oder sind integriert.

Über das Gateway gehen nur die beiden Domains ( Haupt - und subdomäne ) mit einigen Servern und Clients.

 

Evlt. mal den Gateway Server abschalten und schauen ob es dann funktioniert - wäre das eine Idee um überhaupt sicher zu gehen, dass es an diesem liegt ?

 

[NilsK 2.958]

Moin,

 

vor 33 Minuten schrieb smothy:

Mobil-Teile o.ä. laufen definitiv nicht darüber oder sind integriert.

was heißt "sind integriert"?

 

Zitat

Über das Gateway gehen nur die beiden Domains ( Haupt - und subdomäne ) mit einigen Servern und Clients.

Was heißt das? Wohin "gehen" die?

 

Zitat

Evlt. mal den Gateway Server abschalten und schauen ob es dann funktioniert - wäre das eine Idee um überhaupt sicher zu gehen, dass es an diesem liegt ?

Ich halte das nicht für zielführend.

 

Gruß, Nils

 

[smothy 0]

vor 5 Minuten schrieb NilsK:

Moin,

 

was heißt "sind integriert"? 

 

Was heißt das? Wohin "gehen" die?

 

Ich halte das nicht für zielführend.

 

Gruß, Nils

 

sind keine integriert meinte ich - sind keine Mobiltelefone oder Accounts welche über diese Domain oder DC laufen.

Das Gateway ist für das www ( nach außen ) zuständig.

 

ok dann weiß ich imoment nicht wie ich es überprüfen könnte/sollte ob dieser Gateway Server die Ursache ist.
oder hättest du einen Vorschlag ?

[Lian 2.439]

vor 49 Minuten schrieb smothy:

Über das Gateway gehen nur die beiden Domains ( Haupt - und subdomäne ) mit einigen Servern und Clients.

 

vor 6 Minuten schrieb smothy:

Das Gateway ist für das www ( nach außen ) zuständig.

Kannst Du genauer beschreiben, was dort für Server und/oder Clients stehen und was deren Aufgabe in Gänze ist?

[smothy 0]

Kann ich machen, wobei ich nicht weiß ob das so notwendig ist wirklich alles aufzulisten.

 

Ich versuch mal das wichtigste wiederzugeben.

Es gibt eine Firmen-Domäne ( Sitz woanders in Deutschland ) mit dieser Domäne haben wir hier eine Vertrauensstellung geschafft für unsere beiden Domänen ( Haupt- und Subdomäne )

Soweit das Grobe.

 

Hier geht die Internetleitung in den Gateway Rechner rein mit zwei Netzwerkkarten für jeweils eine Domäne bzw. natürlich vorher in die entsprechenden Switche.

 

Was ich evlt noch erwähnen sollte, glaube das hängt zeitlich recht nah zusammen als die Accounts "gesperrt" wurden, dass ein Kollege zusammen mit mir ( er ist etwas mehr linux affine als ich ) am Gateway konfiguriert hatten, damit unsere Subdomäne auch Zugang zum www hat, was zuvor nicht oder eingeschränkt möglich war.

 

Dann gibt es eben verschiedene Server ( Hardware ) wie eben DC inkl. DNS und DHCP

dann noch drei/vier Server als Application/ Monitoring / Testsystem etc. ( ebenso VM´s ) - XenServer

[v-rtc 88]

Macht Ihr eine Authentifizierung zum Surfen?

[smothy 0]

Es werden keine Zertifikate eingesetzt/verwendet falls das die Frage war.

[v-rtc 88]

Nein, eher ob Ihr über das Gateway "irgendetwas" prüft gegen das AD.

[smothy 0]

Nein da wird nichts geprüft ist wie gesagt reines Gateway / firewall ohne zusätzliche Features oder Software, rein nur IP Adressen basiert. Gateway / DHCP ....

 

 

 

 

Folgend - das ist z.B. ein Eintrag in den Logs ( Ereignisse ) - das der ehemalige Mitarbeiter welcher nicht mehr in der Firma tätig ist. Dieser Account sowie meine zwei und der einer Kollegin werden ständig gesperrt.

 

Fehler beim Anmelden eines Kontos.

Antragsteller:
    Sicherheits-ID:        NULL SID
    Kontoname:        -
    Kontodomäne:        -
    Anmelde-ID:        0x0

Anmeldetyp:            3

Konto, für das die Anmeldung fehlgeschlagen ist:
    Sicherheits-ID:        NULL SID
    Kontoname:        ol_am
    Kontodomäne:        do

Fehlerinformationen:
    Fehlerursache:        Das Konto ist gesperrt.
    Status:            0xc0000234
    Unterstatus::        0x0

Prozessinformationen:
    Aufrufprozess-ID:    0x0
    Aufrufprozessname:    -

Netzwerkinformationen:
    Arbeitsstationsname:    \\10.92.200.248
    Quellnetzwerkadresse:    10.92.200.248
    Quellport:        47393

Detaillierte Authentifizierungsinformationen:
    Anmeldeprozess:        NtLmSsp
    Authentifizierungspaket:    NTLM
    Übertragene Dienste:    -
    Paketname (nur NTLM):    -
    Schlüssellänge:        0

Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.

Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".

Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).

Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.

Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an.  Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.

Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
    - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
    - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
    - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.

 

bearbeitet 23. April 2019 von smothy

[Squire 269]

dann hast Du irgendwo auf Deinem "Gateway-Server" Deine Anmeldeinformationen drinnen .. sicher, dass Du nicht irgendwo eine LDAP Anbindung und somit einen LDAP-Bind User hast? 

[smothy 0]

Ja das stimmt wohl so.

Also auf dem Gateway Server ( Linux basiert ) sind meine Benutzer drin. Aber diese sind manuell hinzugefügt worden. ein "normaler" und einer mit Admin rechten - sodass "sudo" nicht benötigt werden würde.

Und wie schon erwähnt. wäre in dem Fall dann merkwürdig, warum die Kollegin gesperrt wird, welche niemals auf den Gateway kommt - weil sie keinen Account dafür hat bzw keinen user in der user-liste steht.

bearbeitet 23. April 2019 von smothy