18
Remote-Powershell mit LAPS bzw lokalem Admin
Hallo zusammen,
ich habe bei uns seit einer Weile LAPS auf allen Clients ausgerollt, was soweit auch super funktioniert. Leider muss ich weiterhin einen Domänenuser als lokalen Admin überall eingetragen haben, weil ich es einfach nicht hinbekomme mit Powershell remote auf die Clients per LAPS-Admin zu verbinden.
Das Problem ist ja, das Powershell zur authentifizierung Kerberos verwendet und damit ein lokaler User ausscheidet. Wenn man liest, steht überall, das man dann die TrustedHosts Liste pflegen soll, damit man von da aus auch ohne Kerberos sich authentifizieren kann. Da habe ich meinen Server eingetragen und auch testweise mal einfach ein * eingetragen, aber ich darf weiterhin nicht verbinden.
Meine GPO zum aktivieren von PSRemote sieht also momentan so aus (+Service automatisch starten)
Führe ich am Server den Befehl
aus und gebe da als Benutzer CLIENT\lapsadmin + das PW ein, erhalte ich den Fehler
Nutze ich den Domänenbenutzer der lokaler Admin ist, geht das Problemlos.
Hat jemand eine Idee was ich hier falsch mache ?
Danke für eure Hilfe !
ich habe bei uns seit einer Weile LAPS auf allen Clients ausgerollt, was soweit auch super funktioniert. Leider muss ich weiterhin einen Domänenuser als lokalen Admin überall eingetragen haben, weil ich es einfach nicht hinbekomme mit Powershell remote auf die Clients per LAPS-Admin zu verbinden.
Das Problem ist ja, das Powershell zur authentifizierung Kerberos verwendet und damit ein lokaler User ausscheidet. Wenn man liest, steht überall, das man dann die TrustedHosts Liste pflegen soll, damit man von da aus auch ohne Kerberos sich authentifizieren kann. Da habe ich meinen Server eingetragen und auch testweise mal einfach ein * eingetragen, aber ich darf weiterhin nicht verbinden.
Meine GPO zum aktivieren von PSRemote sieht also momentan so aus (+Service automatisch starten)
Führe ich am Server den Befehl
New-PSSession -ComputerName 'CLIENT' -Credential (Get-Credential) New-PSSession : [CLIENT] Connecting to remote server CLIENT failed with the following error message : Access is denied. For more
information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:6
+ $s = New-PSSession -ComputerName 'CLIENT' -Credential (Get-Creden ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailedNutze ich den Domänenbenutzer der lokaler Admin ist, geht das Problemlos.
Hat jemand eine Idee was ich hier falsch mache ?
Danke für eure Hilfe !
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: 604627
Url: https://administrator.de/contentid/604627
Ausgedruckt am: 25.11.2024 um 18:11 Uhr
18 Kommentare
Neuester Kommentar
Hi.
Würde es Dich interessieren, ein Konzept zu haben, das ermöglicht, eine PS mit einem Domänennutzer, der remote lokaler Admin ist, zu sehen?
Man kann mein hier als Wissensbeitrag verfügbares Konzept derart umbauen: Sicherer Umgang mit Supportkonten
Würde es Dich interessieren, ein Konzept zu haben, das ermöglicht, eine PS mit einem Domänennutzer, der remote lokaler Admin ist, zu sehen?
Man kann mein hier als Wissensbeitrag verfügbares Konzept derart umbauen: Sicherer Umgang mit Supportkonten
Durchaus ein interessantes Konzept wenn es "nur" um die direkte Supportrolle geht.
Wir setzen allerdings Laps unter anderem auch für Aussendienstler und andere Offliner ein. Da würde das schon mal nicht klappen. Auch die Replikationszeit in andere Standorte und Domänen sind so ein Thema. Liese sich sicher mit entsprechendem Aufwand lösen, aber wir sind so weit mit LAPS glücklich
Wir setzen allerdings Laps unter anderem auch für Aussendienstler und andere Offliner ein. Da würde das schon mal nicht klappen. Auch die Replikationszeit in andere Standorte und Domänen sind so ein Thema. Liese sich sicher mit entsprechendem Aufwand lösen, aber wir sind so weit mit LAPS glücklich
Moin,
es dürfe daran liegen, dass du einen lokalen Benutzerkonto nutzen möchest, bei dem es sich nicht um dem BUILTIN\Administrator Konto handelt.
Führe einmal auf dem betroffenen Computer folgenden Befehl aus:
den obligatorischen Neustart nicht vergessen.
Gruß,
Dani
es dürfe daran liegen, dass du einen lokalen Benutzerkonto nutzen möchest, bei dem es sich nicht um dem BUILTIN\Administrator Konto handelt.
Führe einmal auf dem betroffenen Computer folgenden Befehl aus:
REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1Gruß,
Dani
Moin,
Irgendwie verstehe ich den letzten Satz so, als machtest Du es falsch. Du musst auf dem Client, auf dem das Skript ausgeführt wird, den Client, den Du per remote ansprechen willst, als trusted host eintragen.
hth
Erik
Zitat von @systonia:
Das Problem ist ja, das Powershell zur authentifizierung Kerberos verwendet und damit ein lokaler User ausscheidet. Wenn man liest, steht überall, das man dann die TrustedHosts Liste pflegen soll, damit man von da aus auch ohne Kerberos sich authentifizieren kann. Da habe ich meinen Server eingetragen und auch testweise mal einfach ein * eingetragen, aber ich darf weiterhin nicht verbinden.
Das Problem ist ja, das Powershell zur authentifizierung Kerberos verwendet und damit ein lokaler User ausscheidet. Wenn man liest, steht überall, das man dann die TrustedHosts Liste pflegen soll, damit man von da aus auch ohne Kerberos sich authentifizieren kann. Da habe ich meinen Server eingetragen und auch testweise mal einfach ein * eingetragen, aber ich darf weiterhin nicht verbinden.
Irgendwie verstehe ich den letzten Satz so, als machtest Du es falsch. Du musst auf dem Client, auf dem das Skript ausgeführt wird, den Client, den Du per remote ansprechen willst, als trusted host eintragen.
hth
Erik
Wir setzen allerdings Laps unter anderem auch für Aussendienstler und andere Offliner ein. Da würde das schon mal nicht klappen
Verstehe nicht, was da nicht klappen soll. Meiner Ansicht nach problemlos.Auch die Replikationszeit in andere Standorte und Domänen sind so ein Thema.
Ja, wenn alles "sofort" klappen soll, dann muss die Replikationszeit eben so eingerichtet werden, dass sie sehr kurz ist. Ist es denn so häufig nötig, dass Du mal schnell rauf musst? Wozu in dem Fall?
Moin,
Na die Außendienstler und anderen Offliner haben sich evtl. noch nie an dem Rechner gegen die Domain angemeldet und deshalb sind auch keine Creds zwischengespeichert. Evtl. sind es auch Dienstleister, die gar eine Domainmitglieder sind. Druckerdienstleister z. B., die vor Ort die Drucker installieren sollen.
Oder das.
Wenn das bei verteilten Standorten immer so einfach wäre. Aber da gibt das selbst in Hamburg noch Ecken, wo man mit unterirdisch langsamen Leitungen arbeiten muss. Also ich kann das Ansinnen durchaus verstehen.
Liebe Grüße
Erik
Zitat von @DerWoWusste:
Wir setzen allerdings Laps unter anderem auch für Aussendienstler und andere Offliner ein. Da würde das schon mal nicht klappen
Verstehe nicht, was da nicht klappen soll. Meiner Ansicht nach problemlos.Na die Außendienstler und anderen Offliner haben sich evtl. noch nie an dem Rechner gegen die Domain angemeldet und deshalb sind auch keine Creds zwischengespeichert. Evtl. sind es auch Dienstleister, die gar eine Domainmitglieder sind. Druckerdienstleister z. B., die vor Ort die Drucker installieren sollen.
Auch die Replikationszeit in andere Standorte und Domänen sind so ein Thema.
Oder das.
Ja, wenn alles "sofort" klappen soll, dann muss die Replikationszeit eben so eingerichtet werden, dass sie sehr kurz ist. Ist es denn so häufig nötig, dass Du mal schnell rauf musst? Wozu in dem Fall?
Wenn das bei verteilten Standorten immer so einfach wäre. Aber da gibt das selbst in Hamburg noch Ecken, wo man mit unterirdisch langsamen Leitungen arbeiten muss. Also ich kann das Ansinnen durchaus verstehen.
Liebe Grüße
Erik
Danke erikro, dass Du für Ihn antwortest.
Na die Außendienstler und anderen Offliner haben sich evtl. noch nie an dem Rechner gegen die Domain angemeldet und deshalb sind auch keine Creds zwischengespeichert.
Es braucht keine zwischengespeichetren Credentials. Du hast nicht verstanden, was ich verlinkt habe.Zitat von @DerWoWusste:
Na die Außendienstler und anderen Offliner haben sich evtl. noch nie an dem Rechner gegen die Domain angemeldet und deshalb sind auch keine Creds zwischengespeichert.
Es braucht keine zwischengespeichetren Credentials. Du hast nicht verstanden, was ich verlinkt habe.Und wie meldet er sich vor Ort gegen die Domain an, um die Creds zu kriegen, um das Skript ausführen zu dürfen, wenn die Domain nicht erreichbar ist?
Also... wenn jetzt wirklich der Fall betrachtet werden soll: "Internetverbindung steht, aber Domäne nicht erreichbar", dann brauchen wir uns nicht über die Verwendung von Domänenkonten unterhalten, keine Frage. Ist das so, systonia?
Zitat von @Dani:
Wow! Das ist das Problem. Danke!REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1Jetzt will ich das aber eigentlich nicht abschalten. Hat ja durchaus seine Berechtigung. Auf die schnelle habe ich jetzt nichts gefunden, was mir es ermöglichen würde diesen einen lokalen admin eben doch zuzulassen. Ist da vielleicht noch jemandem was bekannt?
Nein, diese Einstellung ("RemoteUAC"/Localaccountokenfilterpolicy) ist immer nur systemweit setzbar.
Sicherheitstechnisch ist es nur dann kritisch, wenn Du davon ausgehst, dass die Admincredentials in falsche Hände geraten sind, sonst nicht.
Sicherheitstechnisch ist es nur dann kritisch, wenn Du davon ausgehst, dass die Admincredentials in falsche Hände geraten sind, sonst nicht.
Zitat von @DerWoWusste:
Also... wenn jetzt wirklich der Fall betrachtet werden soll: "Internetverbindung steht, aber Domäne nicht erreichbar", dann brauchen wir uns nicht über die Verwendung von Domänenkonten unterhalten, keine Frage. Ist das so, systonia?
Also... wenn jetzt wirklich der Fall betrachtet werden soll: "Internetverbindung steht, aber Domäne nicht erreichbar", dann brauchen wir uns nicht über die Verwendung von Domänenkonten unterhalten, keine Frage. Ist das so, systonia?
Zitat von @DerWoWusste:
Also... wenn jetzt wirklich der Fall betrachtet werden soll: "Internetverbindung steht, aber Domäne nicht erreichbar", dann brauchen wir uns nicht über die Verwendung von Domänenkonten unterhalten, keine Frage. Ist das so, systonia?
Ja die User sind halt oft in irgendeiner Montagehalle ohne Wlan oder Mobilfunknetz. Jetzt müssen die da halt eine Software von irgendeiner maschine installieren oder im Gerätemanager was umkonfigurieren etc. Entsprechend brauchen die das Kennwort von einem Admin und das muss halt dann auch funktionieren. Nicht erst VPN starten und hoffen das der User dann wirklich freigeschaltet wurde etc. LAPS ist da halt perfekt, weil das Kennwort so lange gültig ist bis der Rechner wieder Kontakt zur Domäne hatte und das Kennwort ändert.Also... wenn jetzt wirklich der Fall betrachtet werden soll: "Internetverbindung steht, aber Domäne nicht erreichbar", dann brauchen wir uns nicht über die Verwendung von Domänenkonten unterhalten, keine Frage. Ist das so, systonia?
Das wäre mit deiner Lösung nicht möglich, weil da der User ja grundsätzlich deaktiviert ist.
Aber egal, darum gehts hier ja nicht
Trotzdem eine schöne Lösung!Zitat von @DerWoWusste:
Nein, diese Einstellung ("RemoteUAC"/Localaccountokenfilterpolicy) ist immer nur systemweit setzbar.
Sicherheitstechnisch ist es nur dann kritisch, wenn Du davon ausgehst, dass die Admincredentials in falsche Hände geraten sind, sonst nicht.
Wenn ich sicherstelle das der Default Administrator überall deaktiviert ist und keine anderen "Standard-Lokale-Adminkonten" existieren ausser dem LAPS Admin, dann sollte das eigentlich passen oder?Nein, diese Einstellung ("RemoteUAC"/Localaccountokenfilterpolicy) ist immer nur systemweit setzbar.
Sicherheitstechnisch ist es nur dann kritisch, wenn Du davon ausgehst, dass die Admincredentials in falsche Hände geraten sind, sonst nicht.
Irgendwie bescheuert das man für eine ordentliche Nutzung von LAPS das Sicherheitskonzept erst mal aushebeln muss
Aber ist halt soIrgendwie bescheuert das man für eine ordentliche Nutzung von LAPS das Sicherheitskonzept erst mal aushebeln muss
Du übertreibst stark. Es wird dadurch nicht unsicher. Ein lokaler Admin gehört immer geschützt, entweder deaktiviert, oder eben nur von remote benutzt, wie hier. Kein wirkliches Sicherheitsproblem.Noch ein Tipp zur Nutzung lokaler Admins: wenn deine lokalen offline-Nutzer eh das Adminkennwort haben, dann kannst Du es auch weglassen und ein leeres Kennwort konfigurieren (und weitere Schritte). Das klingt zunächst nach einem Fall von "wie bitte!?", aber schau es dir zumindest einmal an: Tipp zur UAC-Nutzung
1Zitat von @DerWoWusste:
Also... wenn jetzt wirklich der Fall betrachtet werden soll: "Internetverbindung steht, aber Domäne nicht erreichbar",
Also... wenn jetzt wirklich der Fall betrachtet werden soll: "Internetverbindung steht, aber Domäne nicht erreichbar",
So hatte ich den TO verstanden. Deine Lösung ist an sich genial.
Moin,
Auch nicht schlecht. Der Thread hat sich richtig gelohnt. Vielen Dank für die Mühe. Der Tipp löst eins meiner Probleme. Das ist ja quasi wie die sudoers unter Linux mit root ohne Recht sich anzumelden. Jetzt muss ich nur noch meinen Datenschutzbeauftragten davon überzeugen, dass das wirklich sicher ist.
Liebe Grüße
Erik
Zitat von @DerWoWusste:
Noch ein Tipp zur Nutzung lokaler Admins: wenn deine lokalen offline-Nutzer eh das Adminkennwort haben, dann kannst Du es auch weglassen und ein leeres Kennwort konfigurieren (und weitere Schritte). Das klingt zunächst nach einem Fall von "wie bitte!?", aber schau es dir zumindest einmal an: Tipp zur UAC-Nutzung
Noch ein Tipp zur Nutzung lokaler Admins: wenn deine lokalen offline-Nutzer eh das Adminkennwort haben, dann kannst Du es auch weglassen und ein leeres Kennwort konfigurieren (und weitere Schritte). Das klingt zunächst nach einem Fall von "wie bitte!?", aber schau es dir zumindest einmal an: Tipp zur UAC-Nutzung
Auch nicht schlecht. Der Thread hat sich richtig gelohnt.
Vielen Dank für die Mühe. Der Tipp löst eins meiner Probleme. Das ist ja quasi wie die sudoers unter Linux mit root ohne Recht sich anzumelden. Jetzt muss ich nur noch meinen Datenschutzbeauftragten davon überzeugen, dass das wirklich sicher ist. Liebe Grüße
Erik
Zitat von @DerWoWusste:
Noch ein Tipp zur Nutzung lokaler Admins: wenn deine lokalen offline-Nutzer eh das Adminkennwort haben, dann kannst Du es auch weglassen und ein leeres Kennwort konfigurieren (und weitere Schritte). Das klingt zunächst nach einem Fall von "wie bitte!?", aber schau es dir zumindest einmal an: Tipp zur UAC-Nutzung
:mind_blown_gif:Noch ein Tipp zur Nutzung lokaler Admins: wenn deine lokalen offline-Nutzer eh das Adminkennwort haben, dann kannst Du es auch weglassen und ein leeres Kennwort konfigurieren (und weitere Schritte). Das klingt zunächst nach einem Fall von "wie bitte!?", aber schau es dir zumindest einmal an: Tipp zur UAC-Nutzung
Das ist grandios! Das ist tatsächlich die perfekte Lösung für so Techniker-Notebooks. Die haben wir hier auch mit lokalen Konten und individuellem Kennwort etc. Verständlicherweise mag das keiner von denen.
Das wird ein paar Menschen glücklich machen !
Das freut mich doch von euch zu hören.
