17
Lösung für "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden" mit LAPS
Hallo zusammen,
wir überlegen LAPS (Local Admin Password Solution) von MS zu implementieren um die lokalen Admins loszuwerden. Es soll dann keine zusätzlichen lokalen Konten mehr geben.
Wie bzw. ist es dann noch möglich den Fehler "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden" zu beheben?
Vielen Dank im Voraus,
Fritz242
wir überlegen LAPS (Local Admin Password Solution) von MS zu implementieren um die lokalen Admins loszuwerden. Es soll dann keine zusätzlichen lokalen Konten mehr geben.
Wie bzw. ist es dann noch möglich den Fehler "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden" zu beheben?
Vielen Dank im Voraus,
Fritz242
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: 441157
Url: https://administrator.de/contentid/441157
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
17 Kommentare
Neuester Kommentar
Hi.
LAPS arbeitet mit dem lokalen Administrator. Du verstehst LAPS evtl. falsch.
LAPS arbeitet mit dem lokalen Administrator. Du verstehst LAPS evtl. falsch.
Hi,
E.
Zitat von @Fritz242:
wir überlegen LAPS (Local Admin Password Solution) von MS zu implementieren um die lokalen Admins loszuwerden. Es soll dann keine zusätzlichen lokalen Konten mehr geben.
Das Eine hat mit dem Anderen nichts zu tun.wir überlegen LAPS (Local Admin Password Solution) von MS zu implementieren um die lokalen Admins loszuwerden. Es soll dann keine zusätzlichen lokalen Konten mehr geben.
Wie bzw. ist es dann noch möglich den Fehler "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden" zu beheben?
Wann genau bekommst Du denn diesen Fehler? Nach dem Klonen eines PC's?E.
Zitat von @Fritz242:
Wie bzw. ist es dann noch möglich den Fehler "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden" zu beheben?
Wie bzw. ist es dann noch möglich den Fehler "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden" zu beheben?
Wenn du dich mit einem lokalen Admin anmelden musst, schaust du vorher nach, welches Passwort der Account auf der Maschine hat.
hi,
und danke für die Antworten.
Also ja kann sein, daß ich ich noch keine "Fritz242 kompatible Anleitung" für LAPS gelesen habe und es nicht richtig verstehe.
Wir klonen nicht, aber der Fehler tritt trotzdem ab und zu bei Fat-Clients auf (win7).
Da der "build in Administrator" automatisch deaktiviert wird und ich kein weiteres lokales Konto habe, wüsste ich nicht, ob oder wie ich dann LAPS nutzen kann um den oben genannten Fehler zu beheben.
und danke für die Antworten.
Also ja kann sein, daß ich ich noch keine "Fritz242 kompatible Anleitung" für LAPS gelesen habe und es nicht richtig verstehe.
Wir klonen nicht, aber der Fehler tritt trotzdem ab und zu bei Fat-Clients auf (win7).
Da der "build in Administrator" automatisch deaktiviert wird und ich kein weiteres lokales Konto habe, wüsste ich nicht, ob oder wie ich dann LAPS nutzen kann um den oben genannten Fehler zu beheben.
Zitat von @Fritz242:
Da der "build in Administrator" automatisch deaktiviert wird und ich kein weiteres lokales Konto habe, wüsste ich nicht, ob oder wie ich dann LAPS nutzen kann um den oben genannten Fehler zu beheben.
Da der "build in Administrator" automatisch deaktiviert wird und ich kein weiteres lokales Konto habe, wüsste ich nicht, ob oder wie ich dann LAPS nutzen kann um den oben genannten Fehler zu beheben.
LAPS überschreibt das Kennwort eines lokalen Admins und hinterlegt es auf der zuständigen Management Maschine. Sofern du dich also auf einem PC mit LAPS mit dem lokalen Adminkonto anmelden musst, schaust du vorher in der LAPS Datenbank das Kennwort nach und meldest dich damit an dem entsprechenden PC an. Nicht mehr, nicht weniger.
Zitat von @Tezzla:
LAPS überschreibt das Kennwort eines lokalen Admins und hinterlegt es auf der zuständigen Management Maschine. Sofern du dich also auf einem PC mit LAPS mit dem lokalen Adminkonto anmelden musst, schaust du vorher in der LAPS Datenbank das Kennwort nach und meldest dich damit an dem entsprechenden PC an. Nicht mehr, nicht weniger.
LAPS speichert im AD, keine extra Datenbank.LAPS überschreibt das Kennwort eines lokalen Admins und hinterlegt es auf der zuständigen Management Maschine. Sofern du dich also auf einem PC mit LAPS mit dem lokalen Adminkonto anmelden musst, schaust du vorher in der LAPS Datenbank das Kennwort nach und meldest dich damit an dem entsprechenden PC an. Nicht mehr, nicht weniger.
Zitat von @Fritz242:
Da der "build in Administrator" automatisch deaktiviert wird und ich kein weiteres lokales Konto habe, wüsste ich nicht, ob oder wie ich dann LAPS nutzen kann um den oben genannten Fehler zu beheben.
LAPS ändert nichts an diesem Symptom. Es setzt einfach nur die Passwörter von lokalen Benutzerkonten. Das kann es aber auch nur dann zuverlässig, wenn die Vertrauensstellung mit dem AD gegeben ist.Da der "build in Administrator" automatisch deaktiviert wird und ich kein weiteres lokales Konto habe, wüsste ich nicht, ob oder wie ich dann LAPS nutzen kann um den oben genannten Fehler zu beheben.
Probleme mit der Vertrauensstellung können z.B. eintreten
- wenn die Urzeiten des Computers und des Domaincontrollers zu weit auseinander sind
- wenn ein Benutzer noch nie an einem Computer angemeldet war oder - wenn doch - der Passwort-Hash inzwischen nicht mehr lokal zwischengespeichert ist und bei Anmeldung kein Domaincontroller bzw. kein DC mit Gobal Catalog erreichbar ist
2Zitat von @Tezzla:
LAPS überschreibt das Kennwort eines lokalen Admins und hinterlegt es auf der zuständigen Management Maschine. Sofern du dich also auf einem PC mit LAPS mit dem lokalen Adminkonto anmelden musst, schaust du vorher in der LAPS Datenbank das Kennwort nach und meldest dich damit an dem entsprechenden PC an. Nicht mehr, nicht weniger.
LAPS überschreibt das Kennwort eines lokalen Admins und hinterlegt es auf der zuständigen Management Maschine. Sofern du dich also auf einem PC mit LAPS mit dem lokalen Adminkonto anmelden musst, schaust du vorher in der LAPS Datenbank das Kennwort nach und meldest dich damit an dem entsprechenden PC an. Nicht mehr, nicht weniger.
Anmelden mit dem deaktivierten lokalen "build in" Administrator?
Das ist doch irrelevant! LAPS verwaltet Passwörter von lokalen Konten. Ob diese aktiviert sind oder nicht. Nichts weiter.
1Zitat von @emeriks:
LAPS ändert nichts an diesem Symptom. Es setzt einfach nur die Passwörter von lokalen Benutzerkonten. Das kann es aber auch nur dann zuverlässig, wenn die Vertrauensstellung mit dem AD gegeben ist.
Probleme mit der Vertrauensstellung können z.B. eintreten
- wenn die Urzeiten des Computers und des Domaincontrollers zu weit auseinander sind
- wenn ein Benutzer noch nie an einem Computer angemeldet war oder - wenn doch - der Passwort-Hash inzwischen nicht mehr lokal zwischengespeichert ist und bei Anmeldung kein Domaincontroller bzw. kein DC mit Gobal Catalog erreichbar ist
LAPS ändert nichts an diesem Symptom. Es setzt einfach nur die Passwörter von lokalen Benutzerkonten. Das kann es aber auch nur dann zuverlässig, wenn die Vertrauensstellung mit dem AD gegeben ist.
Probleme mit der Vertrauensstellung können z.B. eintreten
- wenn die Urzeiten des Computers und des Domaincontrollers zu weit auseinander sind
- wenn ein Benutzer noch nie an einem Computer angemeldet war oder - wenn doch - der Passwort-Hash inzwischen nicht mehr lokal zwischengespeichert ist und bei Anmeldung kein Domaincontroller bzw. kein DC mit Gobal Catalog erreichbar ist
ok, also muss man doch einen eigene lokalen Admin einrichten und das Kennwort aber mit LAPS verwalten - das ist dann der Sicherheitsgewinn ...
Zitat von @Fritz242:
ok, also muss man doch einen eigene lokalen Admin einrichten und das Kennwort aber mit LAPS verwalten - das ist dann der Sicherheitsgewinn ...
Nein, warum "muss" man das? Der Sicherheitsgewinn besteht darin, dass die lokalen Konten, welche LAPS verwalten soll (standardmäßig nur "der Administrator") mit zufälligen Passwörtern versehen werden. Und nur wer diese im AD auslesen darf, kann sich dann mit einem solchen lokalen Konto am Computer anmelden, vorausgesetzt, das Konto ist aktiviert.ok, also muss man doch einen eigene lokalen Admin einrichten und das Kennwort aber mit LAPS verwalten - das ist dann der Sicherheitsgewinn ...
1
prima danke, jetzt hab ich s wohl.
Also muss ich verhindern das der build-in Administrator deaktivert und versteckt wird oder ein eigenes lokales Konto anlegen?!
Also muss ich verhindern das der build-in Administrator deaktivert und versteckt wird oder ein eigenes lokales Konto anlegen?!
Zitat von @emeriks:
Zitat von @Tezzla:
LAPS überschreibt das Kennwort eines lokalen Admins und hinterlegt es auf der zuständigen Management Maschine. Sofern du dich also auf einem PC mit LAPS mit dem lokalen Adminkonto anmelden musst, schaust du vorher in der LAPS Datenbank das Kennwort nach und meldest dich damit an dem entsprechenden PC an. Nicht mehr, nicht weniger.
LAPS speichert im AD, keine extra Datenbank.LAPS überschreibt das Kennwort eines lokalen Admins und hinterlegt es auf der zuständigen Management Maschine. Sofern du dich also auf einem PC mit LAPS mit dem lokalen Adminkonto anmelden musst, schaust du vorher in der LAPS Datenbank das Kennwort nach und meldest dich damit an dem entsprechenden PC an. Nicht mehr, nicht weniger.
Ich meinte damit die GUI zum Nachschauen, hätte ich anders formulieren sollen.
Gespeichert wird im AD, korrekt.
Zitat von @Fritz242:
Also muss ich verhindern das der build-in Administrator deaktivert und versteckt wird oder ein eigenes lokales Konto anlegen?!
Wofür musst Du das verhindern? Falls Du das Problem mit der Vertrauensstellung meinst - Nein, hat nichts damit zu tun.Also muss ich verhindern das der build-in Administrator deaktivert und versteckt wird oder ein eigenes lokales Konto anlegen?!
wir schreiben aneinander vorbei, oder drücke mich nicht klar aus - sorry.
Ausgangssituation:
1: Ein Rechner verliert die Vertrauensstellung
2: Das lokale Konto "Administrator" ist nach zeit x von Windows Mechanismen versteckt und deaktiviert
3: Kein anderes lokales Konto vorhanden -> Pech gehabt (ohne spezielle Eingriffe beim booten und admin Rechte erschleichen)
Wenn nun LAPS für den build in "Administrator" aktiviert ist, wird dann der interne lokale Account "Administrator" nicht mehr von den Windows Mechanismen versteckt und deaktivert? Dann bring mir an der Stelle LAPS auch nichts -> Punkt 2/3.
Daher wollte ich verhindern, das der build-in Administrator deaktivert/versteckt wird.
Oder wäre die bessere Lösung einen eigenes lokales Konto zu erstellen und das mit LPAS verwalten und den Administrator in Ruhe zu lassen?
"Müssen" muss man nix aber es gibt immer einen best practice der sinnvoll/sicherer ist.
Ausgangssituation:
1: Ein Rechner verliert die Vertrauensstellung
2: Das lokale Konto "Administrator" ist nach zeit x von Windows Mechanismen versteckt und deaktiviert
3: Kein anderes lokales Konto vorhanden -> Pech gehabt (ohne spezielle Eingriffe beim booten und admin Rechte erschleichen)
Wenn nun LAPS für den build in "Administrator" aktiviert ist, wird dann der interne lokale Account "Administrator" nicht mehr von den Windows Mechanismen versteckt und deaktivert? Dann bring mir an der Stelle LAPS auch nichts -> Punkt 2/3.
Daher wollte ich verhindern, das der build-in Administrator deaktivert/versteckt wird.
Oder wäre die bessere Lösung einen eigenes lokales Konto zu erstellen und das mit LPAS verwalten und den Administrator in Ruhe zu lassen?
"Müssen" muss man nix aber es gibt immer einen best practice der sinnvoll/sicherer ist.
Ach man, durch die Brust ins Auge ...
Beachte: Wenn Du den Administrator einfach so aktivierst, dann hat er kein Passwort! Damit kann man dann zwar nicht über Netzwerk damit arbeiten, aber sich dennoch lokal interaktiv anmelden. Also am besten, zuerst LAPS ausrollen und die Passwörter setzen lassen. Dann erst die lokalen Admins per GPO aktivieren. Wenn mal wieder ein Client spinnt, dann kannst Du von einem anderen Client aus ins AD schauen, welches Passwort gerade für den betreffenden Administrator gilt, und Dich dann damit lokal an diesem PC anmelden.
Zitat von @Fritz242:
Daher wollte ich verhindern, das der build-in Administrator deaktivert/versteckt wird.
Das machst Du unabhängig vom LAPS per GPO/GPP. Dort kannst Du einstellen, ob er lokale Administrator aktiviert sein soll, oder nicht. Passwort entweder über LAPS verwalten lassen oder manuell eintragen.Daher wollte ich verhindern, das der build-in Administrator deaktivert/versteckt wird.
Beachte: Wenn Du den Administrator einfach so aktivierst, dann hat er kein Passwort! Damit kann man dann zwar nicht über Netzwerk damit arbeiten, aber sich dennoch lokal interaktiv anmelden. Also am besten, zuerst LAPS ausrollen und die Passwörter setzen lassen. Dann erst die lokalen Admins per GPO aktivieren. Wenn mal wieder ein Client spinnt, dann kannst Du von einem anderen Client aus ins AD schauen, welches Passwort gerade für den betreffenden Administrator gilt, und Dich dann damit lokal an diesem PC anmelden.
2
prima! danke für Deine Geduld und Hilfe 
