hacori

Bei mehreren Apps/Netzwerkdiensten kann ich zwar wie von Windows angefragt den PIN eingeben und dieser wird akzeptiert, seitens App erfolgt dann aber ein Fehler, weil die Anmeldung via PIN nicht unterstützt ist. Daher meine Frage: Gibt es eine Möglichkeit per GPO oder in der Registry, die Verwendung von Windows Hello bzw. PIN nur auf dem Sperrbildschirm standardmässig anzubieten? In allen anderen Fällen soll das Passwort verlangt und ggf via SSO oder in der Windows Anmeldeinformationsverwaltung gespeichertem Passwort automatisch. Windows Hello bzw. der PIN soll da höchstens als alternative Option zur Verfügung stehen oder ganz blockiert werden. In den Kontoeinstellungen gibt es keine entsprechende Option (siehe Screenshot). Zusatzinfo: Es handelt sich im gegebenen Fall um einen Domänencomputer, auf dem ich mit meinem Benutzerkonto lokale Adminrechte habe.

Mein Chef ist ist eindeutig der Profi was physische Server und Netzwerke anbelangt. Er hält die Dinge aber lieber möglichst 'einfach' und wartet bei Neuerungen stets ab. Im Gegensatz dazu bin ich geneigt, zumindest die definitiv kommenden Neuerungen frühzeitig anzugehen. Leider nein, ... nicht zuletzt wegen den Kosten, welche stets eine entscheidende Rolle spielen. Je mehr es einzurichten gibt, desto länger dauert ein Projekt und desto teurer wird es oder desto mehr legt man als Dienstleister drauf, falls die Kosten nicht verrechenbar sind. Manchmal sind einem eben 'die Hände gebunden'. Nicht sind gewisse Optionen denen vorbehalten, die sich die teuren Lizenzen leisten können. Konkretes Beispiel: MFA ist heute eigentlich Standard. Mit einer E1 Lizenz kann man aber im Azure Portal keine zusätzliche Richtlinie erstellen und darum keine Benutzer/Gruppen gezielt ausklammern. Als im Frühling bei ein paar Tenents die MFA-Aktivierung für nach 7 Tagen angekündigt wurde, war es die Entscheidung meines Chefs, diesen Schritt zu verhindern. Folglich blieb MFA ausgeschaltet. Ausnahme: Bei einem Tenant war MFA vor langer Zeit (ohne unser Wissen) aktiviert worden. Die beim Administratorkonto hinterlegte Telefonnummer war keine von uns. Nachdem der Zugriff wieder möglich war, deaktivierten wir MFA soweit möglich. Seither fordert Microsoft bei jedem Login auf, entsprechende Einstellungen vorzunehmen. Den vorherigen Status konnten wir nicht wiederherstellen. Sinngemäss ist das sehr ähnlich wie bei dem im ersten Post gemeldeten Phänomen - ungehindert in die eine Richtung, unmöglich in die engegengesetzte.

Ja, der Begriff 'natürlich' war schlecht gewählt. Dass der Domain-Administrator nur die Domänencontroller verwaltet, wäre logischerweise besser. Dass dieser allgemein verwendet wird, ist/war halt seit Jahren so. Diesen Punkt erachte ich zwar für kleine IT-Umgebungen als nicht zwingend nötig. Dass zumindest eine teilweise Abgrenzung mit Dienstaccounts besser ist, leuchtet mir aus sicherheitstechnischen Gründen jedoch ein. Es wird wohl Zeit, das bestehende Konzept betreffend Accunts zu überdenken / zu ändern. Leider habe ich da wenig mitzureden. Aber ich werde bei Gelegenheit den Chef darauf ansprechen.

Danke an alle für die bisherigen Tipps. @testperson@Weingeist Natürlich wird der Domänenadministrator-Account für manche Dienste verwendet, schliesslich ist es der (Haupt-)Administrator. Darüber läuft so ziemlich alles. Deswegen verwundert es mich überhaupt nicht, dass ich dessen lokales Profil nicht löschen kann - auch wenn er nicht angemeldet ist und nicht im Task Manager erscheint. @daabm Die zwei Sysinternal Tools testete ich auf meinem privaten Laptop, bei dem die Edge-Synchronisierung zu zwei Microsoft Accounts aktiviert ist. Einer davon (persönliches Konto) ist ebenfalls im Aktivitätsverlauf erwähnt, der andere nicht. - Mit "handle.exe" kam ich gar nicht klar. - ProcMon wäre dank der Filteroptionen zwar besser, ist aber auch nicht wirklich hilfreich. Dass OneDrive aktiv ist, weiss ich auch ohne das Tool. Ansonsten sah ich nichts, was weiterhelfen könnte - in Bezug auf den persönlichen Microsoft Account. Eine Suche nach dem vorderen Teil der E-Mail-Adresse stoppte ich. Die einzige Aufgabe, welche auf dem Server wissentlich mit der Mailadresse des verknüpften Microsoft Kontos in Verbindung steht, ist der Versand von Statusreports (per SMTP) aus Veeam Backup and Replication (Community Edition). Der Versand erfolgt zweimal pro Tag. Falls nur deswegen der Microsoft Account permanent 'verwendet' wird und nicht mehr vollständig aus Edge bzw. den Windows Einstellungen getrennt werden kann, finde ich das etwas sonderbar. In Betracht gezogen hatte ich es natürlich schon. Aber ich verzichtete darauf, einen (oder mehrere) Veeam Dienst(e) zu deaktivieren, da mir dies als wenig aussichtsreich erschien. Weil nach wie vor keine Lösung in Sicht ist, werde ich im Veeam vorübergehend eine andere Mailadresse hinterlegen und nach einem Serverneustart nochmals schauen ob ich etwas ändern kann. Falls nein, werde ich das Ganze wohl auf sich bewenden lassen. Die Lust an weiterem Troubleshooting ist mir vergangen.

Das Feature zum automatisch anmelden ist beim Server grundsätzlich nicht vorgesehen und kann nicht über den Gruppenrichtlinieneditor abgeschaltet werden. Den im Heise-Artikel erwähnten Registry-Key habe ich geändert, den Server neu gestartet, als .\administrator angemeldet und nochmals versucht, das Profil von domain\administrator zu löschen. Zuerst erstellte ich eine Kopie des Profils. Wie schon beim ersten Versuch gab es dabei mehrere Fehler, weil einige Dateien (unter anderem die ntuser.dat) geöffnet seien. Das Administrator-Konto wird also durchaus von irgendeinem Dienst automatisch gestartet/verwendet, im Task Manager ist davon aber nichts sichtbar. Die versuchte Profil-Löschung gab wieder folgenden Fehler zurück: Remove-CimInstance : Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. Die Synchronisation des Microsoft Accounts hatte ich vorübergehend nochmals aktiviert in der Hoffnung, dass ich ihn deses Mal korrekt/vollständig trennen bzw. abmelden könnte. In der Anmeldeinformationsverwaltung war er danach zweifach unter Windows-Anmeldeinformationen erwähnt, einmal mit 'MicrosoftAccount:user=' und einmal mit 'SSO_POP_User:user='. Beide Einträge habe ich gelöscht und den Server neu gestartet. Leider brachte das nichts. Er wird weiterhin zur erneuten Synchronisierung vorgeschlagen und ist somit noch mit dem Server verknüpft. Etwas Zusätzliches, was mich irritiert: Seit ich am 6. Juni versuchte, das Benutzerprofil zu löschen, ist der Desktophintergrund meistens schwarz, wie wenn jemand zuvor eine Fernwartung zum Server via Teamviewer aufgebaut hätte. Zwar kann ich den Standard-Hintergrund über die Einstellungen auswählen, es bewirkt aber nichts. Gemäss folgendem Thread habe ich die Datei C:\WINDOWS\web\wallpaper\Windows\img0.jpg mit der eines anderen Servers ersetzt. Das hatte kurzfristig gewirkt. Beim nächsten Zugriff war der Desktophintergrund aber wieder schwarz. https://www.mcseboard.de/topic/212356-windows-10-hintergrundbild-wird-nicht-mehr-angezeigt-schwarzer-desktop/

Nein, natürlich nicht. Das zu löschende Profil ist dasjenige des Domänenadministrators (domain\administrator). Das Konto, mit dem ich angemeldet war, um es zu löschen, ist dasjenige des Servers selbst (.\administrator). Es betrifft selbstverständlich nicht den Domänencontroller, sondern einen normalen Mitgliedsserver. Darum hätte das theoretisch funktionieren müssen. Aber wenn irgendwas die Löschung blockiert, lasse ich es eben lieber bleiben.

Theoretisch würde nichts dagegen sprechen. Obschon ich dies als Lösungsmöglichkeit fand, hatte ich Zweifel, ob dies möglich/sinnvoll ist. Mit dem erwähnten Befehl habe ich es nun doch versucht, da mir dieser nicht bekannt war. Leider kann das Profil so nicht gelöscht werden. Grund: Die Datei(en) werden von anderen Prozess verwendet. Ein Server-Neustart unmittelbar zuvor hatte keinen Einfluss darauf, obschon ich danach mit dem lokalen Administrator-Konto anmeldete und das Domänenadmin-Konto in Ruhe liess. Ich will nicht versuchen herauszufinden, welcher Prozess die Löschung blockiert, da vielleicht genau dieser in einen Fehler liefe, falls das Profil doch gelöscht / neu erstellt würde.

Hallo zusammen Vielleicht kann mir jemand einen entscheidenden Tipp geben. Wegen eines Fehlers bei der Einrichtung von Veeam Backup for Office 365 auf einem Windows Server 2022 hatte ich testhalber die Synchronisierung in Edge für ein Microsoft Konto aktiviert. Die Software-Einrichtung konnte ich inzwischen abschliessen, jetzt bekomme ich aber den Account nicht mehr weg. Er erscheint sowohl im Edge als auch in den Windows Einstellungen unter Datenschutz > Aktivitätsverlauf (siehe Screenshots). Diverse Hinweise aus dem Internet - fast ausschliesslich auf PCs bezogen - halfen nicht weiter: Im Online-Portal des Accounts erscheint der Server nicht unter Geräte. Die Edge-Einstellungen hatte ich gelöscht. Anschliessend war der Account immer noch (oder wieder) sichtbar Das Profil im Edge hatte ich auch schon gelöscht. Danach wurde der Account im neu erstellten Profil gleich wieder zur Synchronisierung angeboten. Zurücksetzen von Edge via Windows Einstellungen > Apps steht nicht zur Auswahl. Die zuvor unter Anmeldeinformationsverwaltung gespeicherten Einträge sind gelöscht. Den Inhalt von "%localappdata%\Microsoft\Edge\User Data" hatte ich bereits gelöscht, ebenso die Dateien unter "%localappdata%\Microsoft\Windows\Safety\edge\remote", welche mit einer Nummer versehen sind. Ein Tipp, die vom Gerät in Azure (oder Intune) gespeicherten Daten zu löschen, half auch nicht. Die diesbezügliche Seite von Microsoft finde nicht mehr, es war u.a. auf OneDrive bezogen (ist auf dem Server nicht installiert). Via Registry konnte ich einstellen, dass gar keine Accounts für die Synchronisation in Edge angezeigt werden sollen bzw. immer ein unpersönliches Profil genutzt wird. Nachdem ich den Registry-Eintrag wieder gelöscht hatte, erschien der Account erneut. Das war somit nur ein Workaround war und hatte keinen bleibenden Einfluss auf den hintergründig verlinkten Account. In der folgenden Diskussion geht es im Prinzip genau um diese Problematik. In meinem Fall erscheint der Account zwar nicht als "Connected to Windows", indirekt kommt es aber vielleicht aufs Gleiche heraus. https://techcommunity.microsoft.com/t5/discussions/allow-removal-of-quot-connected-to-windows-quot-accounts-from/m-p/1534251

Danke für den Tipp. Das hatte ich schon versucht. Vorgängerversionen werden keine angezeigt. Und im Papierkorb war auch nichts. Ich hatte etwas später OneDrive auf dem PC neu angemeldet, woraufhin mehrere Dateien synchronisiert wurden. Die vermissten Dateien kamen dadurch aber nicht wieder zum Vorschein.

Hallo Ich wollte auf einem Windows 10 Computer einen Ordner (Unterordner von OneDrive) in einen anderen Ordner (ebenfalls in OneDrive) kopieren. Der Ordner wurde aber nicht kopiert und es kam auch keine Fehlermeldung. Danach versuchte ich, den Ordner zu verschieben. Das ging aber auch nicht. Es kam ebenfalls keine Fehlermeldung. Jetzt fehlen alle Dateien, welche zuvor im Ordner gespeichert waren. Erst m Nachhinein ist mir aufgefallen, dass das OneDrive Symbol einen Fehler anzeigt (rotes X). Ich kann nicht sagen, ob das vorher schon so war oder erst nachher. Gibt es irgendeine eine Möglichkeit, die Daten zu retten bzw. wiederherzustellen?

Ok, danke Norbert. Dann werde ich den Eintrag mal schrittweise so setzen. Ja, das müsste eigentlich so sein. Jedenfalls hatte ich mal eine entsprechende Ankündigung dazu gesehen. Allerdings lässt sich dies via Registry nicht verifizieren, da offenbar kein Eintrag dafür erstellt wurde. Es sieht aus wie vorher, als die Einstellung standardmässig deaktiviert war.

Besteht auf Ordnerebene 1 oder auf Ordnerebene 2 eine Freigabe für die Benutzer? Werden die Berechtigungen der Ordnerebene 2 durch Ordnerebene 1 geerbt oder sind diese explizit gesetzt? Sofern die Rechte geerbt werden, kann ich mir vorstellen, dass es ausgehend von der Verknüpfung auf F2 Probleme gibt, weil dort nur die Speziell Rechte gelten. Die Ordnerebene 2 'erbt' dann quasi die Speziell Rechte. Ändere in dem Fall die Rechte indem du die Vererbung ausschaltest. Ich nehme an, dass auf F1 die gleichen Adminrechte gelten wie auf F2 (Vollzugriff). Falls nein, bitte richtigstellen. Funktioniert es, wenn bei der Ordnerebene 1 (testhalber) die Berechtigung zum Ändern auch für die Benutzer gesetzt wird? Zusätzliche Fragen, da mir die genaue Ausgangslage unbekannt ist. Werden die Daten im verknüpften Ordner nur 'manuell' von Benutzern genutzt (Office-Dokumente)? Oder sind dort auch Daten enthalten, die von Dienstkonten zugreifbar sein müssen (z.B. SQL Server / ERP-Lösungen)? Die nächste Frage ist ggf. davon abhängig. Soll F1 demnächst durch F2 abgelöst werden? Falls nein, warum reicht die Ordnerstruktur auf F2 nicht noch längerfristig? Falls ja, wäre es nicht einfacher, die gesamte Orderstruktur von F1 mit Robocopy zu kopieren nach F2 mit Übernahme der gesetzten Berechtigungen und anschliessend den Ordner auf F1 entweder zu löschen oder nur noch mit Leserechten als Referenz zu belassen?

Hallo zusammen Aufgrund eines HealthChecker Reports zu einem Exchange Server 2016 korrigierte ich die Protokoll-Einstellungen betreffend TLS 1.0 und TLS 1.2 in der Registry, Diese waren für Server / Client abweichend gesetzt. Jetzt sind alle Protokolle mit Ausnahme von 1.3 aktiviert. Zusätzlich setzte ich die Werte von SystemDefaultTlsVersions für .NET 3.5 und .NET 4.0 auf 1. Ausgeführt habe ich die Anpassungen gemäss den Informationen auf dieser Seite. Auf den übrigen Server der Domäne ist TLS 1.2 aktiviert seit 1.0 und 1.2 von Microsoft standardmässig deaktiviert worden waren. Auf diesen Servern ist SystemDefaultTlsVersions für .NET nun ebenfalls auf 1 gesetzt. Unsicher bin ich, ob ich gemäss HealthChecker Empfehlung zusätzlich den Wert von SchUseStrongCrypto (betreffend .NET) auf 1 setzen soll/kann. Daher ein paar Fragen zur Klärung. Können, nachdem die Server neugestartet sind, Probleme wegen selbstsignierten Zertifikaten mit SHA1 auftreten? Es heisst, dass SchUseStrongCrypto nur für Client-Verbindungen genutzt wird. Kann es trotzdem - namentlich beim Terminalserver - passieren, dass gewisse Verbindungen/Programme nicht mehr funktionieren? Gibt es eine Möglichkeit, allfällige Auswirkungen im voraus zu eruieren? Ist es besser, die Einstellung auf allen Servern gleichzeitig zu ändern oder eher gestaffelt pro Server? Ist es sinnvoll, für PCs/Notebooks die Einstellung via GPO-Richtlinie zu forcieren oder gibt es damit grössere Probleme? Danke im voraus für eure Tipps/Erfahrungen.

Ja, das wird sicher so sein. Falls davon ausgegangen werden muss, dass das verwaiste Postfach bei einer späteren Servermigration erneut ohne zugehörigen AD-User übernommen wird, fände ich es zwar schon sinnvoll, dem nachzugehen. Aber viel Aufwand will ich dafür auch nicht aufwenden.

Nein, weder das eine noch das andere.