NilsK

Moin, ja, das kann ich gut verstehen, und das wäre auch entschieden zu viel für das, was wir hier diskutieren. Ganz so war es auch nicht gemeint, solche Entscheidungen sind immer langfristig. Trotzdem solltet ihr euch das mit den vielen Netzlaufwerken mal grundsätzlich überlegen. Und ihr solltet über euren Berechtigungs-Grundansatz sprechen. Auch das ist nicht simpel, da gibt es kein Patentrezept für alle. Was du berichtest, klingt aber an einigen Stellen so, als könne man da technische Missverständnisse beheben, die sehr verbreitet sind. Gruß, Nils

Moin, Sprache war noch nie logisch. Deshalb eignet sie sich ja auch so gut, um sich voneinander abzugrenzen. Aber wir schweifen ab ... @tgyssling kommst du mit den beiden Hinweisen von Norbert und Martin weiter? Gruß, Nils

Moin, also, ist etwas off-topic, aber man neigt im Deutschen dazu, bei unklarem Genus die weibliche Form anzunehmen. Das ist bei vielen Abkürzungen und Fremdwörtern so, wenn auch längst nicht bei allen. Eine sehr schöne Variante, die ich nur von zwei Leuten kenne: die Switch (bezogen auf Netzwerk-Switches). Und ich kenne Leute, die sich beim Autofahren auf "die Navi" verlassen. Gruß, Nils

Moin, nein, so würde ich das nicht sagen. Für bestimmte Workloads kann das interessant sein. VDI etwa wäre ohne in vielen Situationen kaum machbar. Hat aber mit Dateisystemfehlern ziemlich sicher nix zu tun. Gruß, Nils

Moin, was sagen denn die Win7-VMs selbst dazu? Die werden doch sicher auch was davon mitbekommen. Vielleicht hilft das weiter. Gruß, Nils

Moin, dafür ist es ja da. Die Quelle steht dabei, also prima. Inhaltlich stimme ich dir zu: Einfach halten. Maximal einfach. Sonst wird es nur Probleme bereiten. Man kann sich viele schöne Sachen mit GPOs ausdenken ... sollte man aber nicht. Gruß, Nils

Moin, aber wäre es in so einem Szenario nicht ohnehin besser, die VM herunterzufahren und dann zu exportieren? (Oder einfach zu kopieren ...) Gruß, Nils

Moin, vielleicht hakst du es besser ab. Zu hacken wäre unnötig gewalttätig. (Eine andere Variante, die ich in Betracht zöge, wäre ein Test mit einer frisch aufgesetzten VM.) Gruß, Nils

Moin, zum Beispiel an einem Update des Radius-Systems oder einer Konfigurationsänderung eines Systems in der Kette. Es kann durchaus sein, dass das hier nicht zutrifft, mein Punkt ist einfach, dass die Fehlermeldung anscheinend nicht nur dann auftritt, wenn es wirklich ein Problem mit der Authentifizierung gibt. Darauf weisen die Fundstellen im Web hin. Und was du berichtest, legt den Gedanken ja durchaus nahe. Gruß, Nils

Moin, eine Möglichkeit: Weil eine per Inplace Upgrade übernommene Applikation eben manchmal zickt. Gerade bei einer Applikation wie Access auf einem Terminalserver überrascht mich das jetzt nicht. Und dann kann es noch -zig andere Möglichkeiten geben. Glaskugeln haben wir keine. Gruß, Nils

Moin, prima, danke für die Rückmeldung. Gruß, Nils

Moin, also ein Inplace-Upgrade? Zusammen mit dem lokal installierten SQL Server also schon zwei Dinge, die nicht Best Practice sind. Ich würde den Terminalserver neu machen und den SQL Server separieren. Gruß, Nils

Moin, interessante Story, man versteht aber nur begrenzt, was jetzt im Detail Sache ist. Mit "Upgrade" meinst du genau was? Und was heißt "oder SQL"? Ist auf dem Terminalserver direkt auch ein SQL Server installiert? Gruß, Nils

Moin, übrigens scheint mir die oben zitierte Angabe auch nicht korrekt zu sein. @meinerjunge, hast du eine Quelle dazu? Die Angaben, die ich dazu finde, sind: es darf nicht der komplette SAM Account Name vorkommen ("NilsK") - sofern der kürzer als drei Zeichen ist, gilt die Regel nicht der Display Name wird in seine Teile zerlegt, und keiner der Teile darf vollständig vorkommen ("Nils", "Kaczenski") - auch hier die 3-Zeichen-Regel Das ist ja dann doch was anderes und senkt die Ausschlusswahrscheinlichkeit. Meine Quellen z.B.: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh994562(v=ws.11) https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements Gruß, Nils Edit: Zwei Nerds, ein Gedanke.

Moin, da sekundiere ich Norbert. Ich nutze seit ca. 20 Jahren sehr lange Kennwörter und habe damit noch nie ein Problem mit den vordefinierten Kennwortrichtlinien gehabt. Und ja, es geht um eine große Zahl sehr langer Kennwörter. Mein Eindruck ist, dass ihr euch da zu "akademische" Gedanken vor dem Hintergrund traditioneller Ansätze macht. Aber wie gesagt - wenn das bei euch so ist, dann recherchier halt nach einem Drittanbietertool. Gruß, Nils

Moin, "Kette" war missverständlich. Natürlich muss die Zertifikatskette auch gültig sein. Ich meinte aber die Systemkette. Ich habe mehrere Quellen gefunden, wo die Ursache Änderungen an den Systemen waren, z.B. dem Radius. Gruß, Nils

Moin, da kann man sich jetzt mit gewisser Berechtigung fragen, ob eure Vorgabe sinnvoll ist. Wenn ihr tatsächlich von der nicht abrücken könnt, dürfte an kommerzieller Software kein Weg vorbeigehen. Eine Webrecherche nach "Password Filter Active Directory" weist den Weg. Gruß, Nils PS. 10 Zeichen gelten schon lange nicht mehr als "sicher", unabhängig vom geforderten Zeichensatz. PPS. oder deutlicher: eure Vorgabe erzeugt weder hochkomplexe noch lange Kennwörter.

Moin, ich habe keine Lösung, aber eine schnelle Websuche deutet an, dass das Problem evtl. gar nichts mit dem User oder dem Zertifikat zu tun haben muss, sondern woanders in der Kette liegen kann. Gruß, Nils

Moin, für schützenswerte Konten würde ich ein oder mehrere PSOs (Password Settings Objects) einrichten und lange Kennwörter vorschreiben. Dann reicht die normale Komplexität völlig aus. Für Service Accounts lässt man sich dann gute Kennwörter generieren und Benutzern mit Accounts dieser Kategorie empfiehlt man, mit Kennwortsätzen zu arbeiten, die man gut tippen kann. (Eine Suche nach "Correct Horse Battery Staple" illustriert, was ich meine.) Gruß, Nils

Moin, falls das aber bei euch tatsächlich auch die DCs und SQL Server betrifft, dann war es eben ein Beispiel dafür, dass da irgendwas falsch laufen muss. Da auf diesen Servern schlicht nichts zu indizieren ist, ist irgendwas nicht gesund, wenn der Indexdienst tatsächlich für Verzögerungen sorgt. Ob du den abschalten kannst, kannst du selbst entscheiden, indem du rausfindest, ob du den Index auf den Servern brauchst oder nicht. Ich würde aber trotzdem prüfen, ob da nicht noch ein anderes Problem vorliegt. Gruß, Nils

Moin, mit Bordmitteln (ohne "a" übrigens) geht das nicht. Es gibt kommerzielle Software für sowas, mittlerweile auch ein paar Community-Projekte*. Falls ihr eine Anbindung an Azure AD und die passenden Subscriptions habt, lassen sich auch AAD-Bordmittel einsetzen. Gruß, Nils * das ist das, was Norbert mit seiner Anspielung meinte. An solche Software hat sich lange in der Community niemand rangetraut. Welche Qualität die vorhandenen Projekte haben, kann ich aber nicht sagen. * PS. vielleicht meint Norbert auch, dass die sog. "Komplexität" viel weniger wichtig ist als die Länge von Kennwörtern. Mindestens für Admins und andere hochprivilegierte Accounts würde ich daher vor allem lange Kennwörter vorschreiben, die Komplexität kann man sich dann eher sparen.

Moin, ja, genau das ist die Idee. Ich habe dich so verstanden, dass es noch mindestens einen funktionierenden DC gibt. Dann ist das schnell und ohne Risiko gemacht. Gruß, Nils

Moin, also, ich würde da nicht lang fackeln. Du hast einen nicht funktionierenden DC, da würde ich keine Forensik betreiben, sondern für einen neuen DC sorgen. Das dauert ne Stunde. Dann noch mal ne Stunde aufräumen. Die Master-Rollen werden meist völlig überschätzt, so auch hier. Die sind kein Hindernis. https://www.faq-o-matic.net/?s=betriebsmaster Gruß, Nils

Moin, warum würdest du das umgehen wollen? Gruß, Nils

Moin, spontan würde ich sagen, mach die VM neu. Gruß, Nils