8
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
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)
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.
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.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5754298038
Url: https://administrator.de/contentid/5754298038
Ausgedruckt am: 18.11.2024 um 13:11 Uhr
8 Kommentare
Neuester Kommentar
Wenn ich ausführe:
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.
Reset-ComputerMachinePassword -Credential (get-credential)Jedoch kann man sich anschließend immer noch nicht mit einem Domänen-Konto anmelden. Dann immer noch der Fehler mit der fehlenden Arbeitsstationsvertrauensstellung.
Kannst Du in diesem Moment mit z.B. psexec und entsprechenden Rechten dich von der anderen Richtung anmelden? Oder mit Remote Powershell?
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.
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.
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"?
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"?
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.
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.
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)
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.
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.
1
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…
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…
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.
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.
