NilsK

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

Moin, dann läuft da was falsch. Bei einem DC oder einem SQL Server verändert sich ja nix, was eine laufende Indizierung beschäftigen würde. Gruß, Nils

Moin, worin liegt denn das Problem, wenn die User "im Web surfen"? Kann man das im Zweifel einfach ignorieren oder gibt es einen handfesten Grund, das zu vermeiden? Gruß, Nils

Moin, ich merke noch an, dass gerade "jede Menge spezielle, über die Jahre von -zig Stellen installierte Komponenten" regelmäßig dafür sorgen, dass ein Inplace-Upgrade nicht wie gewünscht funktioniert. Aber wir wollen natürlich niemanden daran hindern, seinen Erfahrungsschatz zu vergrößern. Gruß, Nil"inplace upgrades on servers are evil"s PS. Wenn du so viel Zeit hast, das zu diskutieren ... die hätte man ja auch investieren können, um ... na, du weißt schon.