daabm

Ne, die Surfaces kommen ab Werk mit aktiviertem TPM und aktivierter Verschlüsselung. Ich kann mich aber nicht mehr genau erinnern, wie das initial auf die Speicherung des Recovery Key hingewiesen hat - ich glaube, ich hab mich schon direkt mit dem MS-Konto angemeldet. Und das ganze "Kleingedruckte" liest ja niemand mehr, weil es einfach zu viel geworden ist :-(

Nur Home kann nicht sein - meiner ist von einen Surface Pro3, das kam mit Professional. Aber "non domain joined" und "nicht Enterprise" kann sein - ich hab grad genauer geschaut, der Key ist von 2013 und damit hoffnungslos veraltet. Ich hab das Pro3 damals erst mal so in Betrieb genommen und später erst auf Enterprise und Domain umgestellt. Kann sein, daß der Key noch von "davor" übrig ist. Man lernt jeden Tag dazu

Damit machst Du Dir halt das Leben auch extrem schwer - wenn zum Boot eine PIN erforderlich ist, rennst dann bei jedem Patchday stundenlang (virtuell) auf den ILOs rum und tippst die überall ein? Ich würd ja sagen "nicht praktikabel"...

Die Webservices von MS interessieren sich glücklicheweise nicht für groß oder klein Und Home oder Enterprise ist egal, hier ist es Enterprise.

...und eine kleine Erklärung, was genau nun das Problem war und wie genau es gelöst wurde, wäre auch nett... Hilft dann dem nächsten.

@tesso Den Link hat er selber schon gepostet - und wenn ich bei mir schaue, finde ich da auch meinen Recovery Key. So gesehen weiß ich auch nicht, was da grad schiefgeht...

@4zap es gibt keine technische Alternative zu Brain 2.0... Euch hätte eine Tier-Trennung geholfen - Domain Admins "Deny Interactive Logon" auf Clients und Member Servern (- ESAE). Und Cached Credentials auf 0 bei Desktops/Servern, auf 1 bei Laptops. Dann hat sich das mit dem Hash aus lokaler SAM auslesen relativ erledigt. Aber das ist auch nur ein kleiner Stein im großen Security-Mosaik.

KeePass rafft das irgendwie, welches Fenster es auswählen muß - hab mich da aber auch noch nicht wirklich eingelesen. Das Risiko des wahlfreien Abspulens ist mir wohlbekannt

Für die Diagnose werfe ich mal "nltest /dsaddresstosite:" in den Raum

...und ganz oldschool, weil ich sowas noch nie gesehen habe: Kannst Du das mal abfotografieren? Wenn ein Screenshot nicht geht (könnte ja sein, daß da wieder alles drauf ist), sogar tatsächlich fotografieren.

Die Addins der gängigen Passwortmanager sind lediglich ein Komfort-Feature. Sicherheitslücken reißen sie nicht auf. Und wie schon geschrieben: Letztlich ist es egal, ob KeePass das Kennwort automatisch eintippt oder per Strg-V, oder ob ich es eintippe. Chrome kann es auf jeden Fall immer lesen...

Ich hatte nen Vorsprung - die Frage kam im Technet früher, da hab ich mal kurz recherchiert

Das kann immer getriggert werden - gibt doch den Task Scheduler Und welcher User, das kriegt man auch immer aus dem Eventlog raus. Oder über WMI. Oder sonstwie. Ein Client unterscheidet sich da seit Vista in nahezu nichts von einem Server.

Jupp, das sollte man abschalten... Stimmt.

Naja, man könnte Forenregeln lesen und auf Crossposts hinweisen In Powershell 4 (mit der 2012R2 ab Werk kam) kennt Get-Item noch kein .Target... Das kam erst mit Version 5. Deshalb geht's auch mit Win10...

...und wenn schon per GPO: Es empfiehlt sich DRINGEND, für alle GPP das Debug Logging zu aktivieren. Dann kann man wenigstens "irgendwas" nachlesen, was passierte. https://blogs.technet.microsoft.com/askds/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat/ Ansonsten bin ich bei Jan - wer das per Skript bisher gelöst hat oder lösen kann, sollte das auch weiter so tun. GPP Laufwerke (und GPP Drucker) sind Grütze.

Schlangenöl? Fahr lieber AppLocker hoch und mach ein restriktives Ruleset...

Aber wenn er das doch in Kixtart machen möchte Die Frage hab ich doch im Technet auch gesehen?

@MurdocX Wer - auch unter Win7 - noch PS2.0 hat, sollte mal sein Update-Verfahren/-Verhalten auf den Prüfstand stellen. WMF5 gibt es nicht erst seit gestern

@mwiederkehr Soo einfach ist das nicht Das geht nur, wenn man a) das per Scheduled Task löst, Trigger "Wiederverbinden" b) die Bildschirmsperre NICHT per GPO konfiguriert ist Der Task startet ein Skript. Das holt sich erst mal den Client aus der Registry (Volatile Environment, darunter dann der Subkey mit der Session ID - Umgebung geht nicht, weil die beim Auslösen des Triggers den Clientname noch nicht enthält). Und dann kann das Skript abhängig von den Clienteigenschaften die Bildschirmsperre konfigurieren. Woher ich das so sicher weiß? Weil wir genau das implementieren mußten: Connect von einen Linux Thinclient: BS aktiv. Connect vom Windows-PC: BS nicht aktiv.

Get-Childitem | Select-Object -Index Get-Random | Move-Item. So als Idee. Der Code funktioniert so aber natürlich nicht Und MurdocX hat ja die gleiche Idee.

Du kannst ne Zielgruppenadressierung draufsezten, daß die Verbindungen nur verarbeitet werden, wenn die GP-Aktualisierung "Nicht Hintergrund" ist... Richtig elegant geht das ganze mit GPP eh nicht, da brauchts ein gutes Skript. Was man aber machen kann: Alle Laufwerkzuordnungen mit dem ILT auf "Nicht Hintergrund". Dann als erstes eine, die stupide alle Laufwerke trennt. Und dann weitere, die die erforderlichen Laufwerke verbinden. BTW: Was ist "GPIO"?

Ums mal anders zu beantworten: Du hast eine Session (=Anmeldesitzung) auf dem Client. Die sperrt sich. Und Du hast eine zweite Session auf dem RDS, die sperrt sich auch. Was Du willst, geht so nicht. Schalte die Sperre auf dem RDS aus oder lebe damit

Da gibts halt mittelfristig Rüffel von den Mods wegen "User suchen Hilfe" War aber oft auch meine bevorzugte Antwort - "Ja/Nein", fertig.

Komisch - Geduld gehört nicht zu meinen hervorstechenden Eigenschaften