emeriks
Goto Top

Win10 - Arbeitsstationsvertrauensstellung nicht vorhanden

Hi,
wir haben hier ein seltsames Problem.

Im Einsatz VMware Horizon. Damit werden nicht-persistente Desktops ausgerollt (Win10 Enterprise). D.h. nach Abmeldung eines Benutzers vom Desktop wird dieser zerstört und vom Image neu bereitgestellt. Dabei wird u.a. auch das Computer-Objekt im AD neu erstellt. Das funktioniert im Prinzip alles auch.

Nur haben wir hin und wieder den Fall, dass manche von den so bereitgestellten VMs nur "halb" in der Domäne sind. Beim Anmelden am Desktop mit einem Domänen-Konto kommt dann
Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung.

Lösung ist bisher: Betreffende VM durchstarten. Dabei wird sie von VMware Horizon zerstört und neu ausgerollt.

Das Dumme ist nur, dass Horizon selbst diesen Zustand nicht erkennt. D.h. diese VMs gelten dann als betriebsbereit und Benutzer landen beim Anmeldeversuch auf diesen.

Wenn ich mir solch eine gemeldete VM mal näher ansehe (ohne sie durchzustarten) dann kommt folgendes bei heraus:
(angemeldet mit dem lokalen Administrator-Konto)
  • Netzwerk alles, alles erreichbar (DNS, DC's, Namensauflösung ok)
  • Uhrzeit, Datum, Zeitzone alles synchron

  • Unter der Anmeldung des SYSTEM-Kontos
      • kann man per PowerShell das Computerkonto im AD abfragen. Das bedeutet, das SYSTEM-Konto kann sich mit dem Computer-Konto anmelden und das AD-Objekt lesen.
      • "get-childitem \\domain.tld\netlogon" liefert den Inhalt des NETLOGON-Verzeichnisses. Auch das bedeutet, dass das SYSTEM-Konto sich mit dem Computer-Konto am AD anmelden kann.
      • "Test-ComputerSecureChannel" liefert "True"
      • "Reset-ComputerMachinePassword" liefert:
Das Kennwort des sicheren Kanals für das Computerkonto konnte in der Domäne nicht zurückgesetzt werden. Fehler beim Vorgang mit der folgenden Ausnahme: Zugriff verweigert (Ausnahme von HRESULT:0x80070005 (E_ACCESSDENIED)).

  • In der CMD des Administrator-Konto ausgeführt
      • "runas /user:DOMAIN\domainuser cmd" fragt nach Passwort und meldet dann wieder
1787: Die Sicherheitsdatenbank auf dem Server enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung.

Das verstehe ich jetzt nicht. Wenn das SYSTEM-Konto (Computer-Konto) auf das AD zugreifen kann, dann konnte es sich dort also anmelden. Wie kann es sich aber anmelden, wenn angeblich die Arbeitsstationsvertrauensstellung nicht gegeben ist?

Hat jemand ne Idee?

E.

Content-Key: 5754298038

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

Printed on: July 27, 2024 at 11:07 o'clock

Member: emeriks
emeriks Jan 31, 2023 at 11:07:17 (UTC)
Goto Top
Wenn ich ausführe:
Reset-ComputerMachinePassword -Credential (get-credential)
Dann kommt die Anmeldemaske für die Credential. Benutzer und Passwort eines Admins eingeben, welcher die Konten verwalten darf, und es kommt keine Fehlermeldung.

Jedoch kann man sich anschließend immer noch nicht mit einem Domänen-Konto anmelden. Dann immer noch der Fehler mit der fehlenden Arbeitsstationsvertrauensstellung.
Mitglied: 2423392070
2423392070 Jan 31, 2023 at 11:21:17 (UTC)
Goto Top
Kannst Du in diesem Moment mit z.B. psexec und entsprechenden Rechten dich von der anderen Richtung anmelden? Oder mit Remote Powershell?
Member: emeriks
emeriks Jan 31, 2023 updated at 12:30:21 (UTC)
Goto Top
Von welcher anderen Richtung?

Edit:
Ich nehme an, Du meinst das:

Von remote kann ich auf so eine VM z.B. über C$ zugreifen. Wohlgemerkt: Mit einem Domänenkonto! Man sieht dann auch in der Auflistung der SMB-Sitzungen, dass da eine Sitzung mit diesem AD-Konto besteht.
Irre. Das scheint sich rein auf die lokalen interaktiven Anmeldungen zu beschränken.
Member: Franz-Josef-II
Franz-Josef-II Jan 31, 2023 at 12:34:42 (UTC)
Goto Top
Hello

Vorausgeschickt ich kenne das VMware Horizón nicht.

So, wie Du es beschreibst klingt es, als hätte das Netzwerk einen "Wackler" und die VM wird nicht im AD gelöscht und neu angelegt. Ich würde, wenn sowas passiert, einmal im AD das Erstellungsdatum und Zeit des Computerobjekts anschauen. Ist das noch von der "vorigen Maschine"?
Mitglied: 2423392070
2423392070 Jan 31, 2023 at 13:00:37 (UTC)
Goto Top
Zitat von @emeriks:

Von welcher anderen Richtung?

Edit:
Ich nehme an, Du meinst das:

Von remote kann ich auf so eine VM z.B. über C$ zugreifen. Wohlgemerkt: Mit einem Domänenkonto! Man sieht dann auch in der Auflistung der SMB-Sitzungen, dass da eine Sitzung mit diesem AD-Konto besteht.
Irre. Das scheint sich rein auf die lokalen interaktiven Anmeldungen zu beschränken.

Ich kenne jetzt eure SMB Hürden nicht, aber das Problem wird eher der Client sein, vielleicht auch das Netzwerk.
Member: emeriks
Solution emeriks Jan 31, 2023 at 14:23:56 (UTC)
Goto Top
Ich habe es gefunden.

Ursache sind fehlende Einträge im Attribut "servicePrincipalName" der betreffenden Computerobjekte: Setzt man die fehlenden Einträge im Objekt, funktioniert die Anmeldung an der VM sofort. Ohne Neustart.

Die fehlenden Einträge sind: (Bsp. COMPUTER1)
  • HOST/COMPUTER1
  • HOST/COMPUTER1.domain.tld

Warum diese Einträge bei diesen Computer-Objekten fehlen, das habe ich noch nicht herausgefunden. Aber ich habe mir als Workaround ein PS-Script geschrieben, welches das kompensiert.
Member: em-pie
em-pie Jan 31, 2023 at 17:07:51 (UTC)
Goto Top
Moin,

Erfolgt das Löschen und Neuerstellen vielleicht über zwei verschiedene DCs, welche sich nicht nicht sauber synchronisiert haben?
Wobei das der GC oder andere Rollen ja managen/ mitbekommen sollten…
Member: emeriks
emeriks Feb 01, 2023 at 07:10:12 (UTC)
Goto Top
Hallo @em-pie,
das weiß ich nicht, halte ich aber für unwahrscheinlich. Nach meiner Erfahrung werden solche Aktionen hintereinanderweg über den einmal ermittelten DC ausgeführt.
Aber unabhängig davon: Wie könnte das Einfluss darauf haben, dass die SPN manchmal fehlen?

E.