NilsK

Moin, ist vielleicht die Anwendung auf dem Client noch aktiv, wenn ihr sie das zweite Mal startet? Sodass sie dann zweimal läuft? Es gibt manchmal Applikationen, die sowas nicht mögen. Gruß, Nils

Moin, FOR-Schleifen sind immer eine Sache für sich. Da muss man enorm viel rumprobieren, bis man mal die richtige Variante hat. Um hier nicht gleich mit der Lern-mal-PowerShell-Keule zu arbeiten, werfe ich folgendes Verfahren in den Ring, das ich bei "statischen Schleifen" gern einsetze: [Excel: Admins unbekannter Liebling | faq-o-matic.net] https://www.faq-o-matic.net/2008/01/19/excel-admins-unbekannter-liebling/ Ansonsten haben die Kollegen schon recht - gerade für sowas ist PowerShell nach etwas Einarbeitung viel einfacher und flexibler. Gruß, Nils

Moin, schau mal hier: [Windows-PKI: Computerzertifikat manuell anfordern | faq-o-matic.net] https://www.faq-o-matic.net/2017/09/13/windows-pki-computerzertifikat-manuell-anfordern/ Gruß, Nils

Moin, ... und das lässt sich auch automatisieren, am einfachsten, indem man eine Weile ein Batch im Logon- oder Startupskript aufruft, das das Verzeichnis C:\Users per dir irgendwohin ausgibt. Zum Beispiel so: dir c:\Users > E:\Daten\%computername%-profile.txt Und die Datei kopiert dann der nächste Batch-Befehl auf ein zentrales Share. Vorsicht, wenn es einen Betriebsrat gibt, sollte man den davon in Kenntnis setzen. Das kann als Überwachungsmaßnahme gewertet werden. Gruß, Nils

Moin, so war das nicht gemeint. Dass du das nicht gebaut hast, hatte ich verstanden. Mir geht es um "denjenigen", der das gemacht hat. Hyper-V hat halt auf einem Server, der noch irgendwas anderes macht, nichts verloren. Dass das Netzwerk erst wieder "funktioniert", wenn man Hyper-V ganz deinstalliert, liegt an der Art, wie Hyper-V aufgebaut ist. Das führt hier zu weit; wer es wissen will: [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Trifft im Wesentlichen noch zu. Gruß, Nils

Moin, ich finde es schade, dass ein solch halbseidener Tipp in diesem Thread jetzt als "Lösungsansatz" dasteht. Ich distanziere mich davon und weise noch einmal ausdrücklich darauf hin, dass der hier diskutierte Umgang mit Zertifikaten überhaupt nicht in Ordnung ist. Die Gründe dafür habe ich oben genannt. Gruß, Nils

Moin, wenn sie Zugriff auf den Private Key haben, hindert sie nichts daran, diesen zu exportieren. Ich verstehe ja, dass Zertifikate und das ganze Drumrum nicht einfach zu kapieren sind. Aber müssen auch Profis (also Leute, die Geld dafür bekommen) deshalb immer wieder so grundlegende Fehler machen? Kann man dann nicht lieber auf Zertifikate verzichten, damit man sich wenigstens nicht in Sicherheit wiegt? Gruß, Nils

Moin, und, ist dem Schweizer Zoll schon mal jemand aufs Dach gestiegen? Wenn das tatsächlich so vorgesehen ist und nicht nur eine Bequemlichkeits- oder Kostensparlösung, dann ist das ein Skandal ersten Ranges. Gruß, Nils

Moin, wie - auf dem SBS, der jetzt als VM lief, war Hyper-V eingerichtet? Auf die Idee wäre nicht gekommen. Dass das nicht funktioniert, liegt auf der Hand. Dann wird das System aber vorher auch schon gelaufen sein wie ein Sack Nüsse. Auf Ideen kommen die Leute ... Gruß, Nils

Moin, ich halte dieses Anliegen für nicht supportfähig. Ein Userzertifikat soll die Identität eines (eines!) Users bestätigen. Und ein privater Schlüssel hat per definitionem geheim zu bleiben. Ein bestimmtes Userzertifikat mit privatem Schlüssel bei mehreren Usern einzusetzen, widerspricht daher fundamental den Grundsätzen zertifikatsbasierter Authentifizierung bzw. Verschlüsselung. Gruß, Nils

Moin, du müsstest bitte näher beschreiben, was du erreichen willst. Gruß, Nils

Moin, Da scheinst du ein paar Dinge durcheinander zu bringen. Gruß, Nils

Moin, Dein SBS hat jetzt eine virtuelle Netzwerkkarte. Die hat aber keine Konfiguration. Die ehemalige Konfiguration hängt noch an der deaktivierten alten Karte im SBS. Gruß, Nils

Moin, ich verstehe nicht, warum ihr zehn Stunden Puffer einbauen wollt. Kann man machen, wenn es einen Grund gibt, aber ich wüsste keinen. Hier ist ein simples Toolset, um die Replikationslatenz zu testen: [ADRepCheckLatency: AD-Replikationslatenz messen | faq-o-matic.net] https://www.faq-o-matic.net/2009/09/30/adrepchecklatency-ad-replikationslatenz-messen/ Und hier ein anderes: [(2010-10-24) Testing Active Directory Replication Latency/Convergence Through PowerShell « Jorge's Quest For Knowledge!] https://jorgequestforknowledge.wordpress.com/2010/10/24/testing-active-directory-replication-latency-convergence-through-powershell/ Gruß, Nils

Moin, das ist eine konzeptionelle Frage über eure Betriebsprozesse. Dazu kann ich aus der Ferne wenig sagen. Man könnte sich fragen, ob die Ablage für die Installationsdaten überhaupt so kritisch ist, dass man den Zugriff einschränken muss. Falls nein, könnte man in solchen Fällen die nötigen Daten vorher auf den Client herunterladen und dann die Installation mit "Ausführen als" machen. Es ist immer besser, Installationen von lokalen Dateien aus durchzuführen als über das Netzwerk. Man könnte auch einmal ein CMD-Fenster mit "Ausführen als" oder "Als Administrator ausführen" öffnen und von dort dann den Kopierprozess und die Installation ausführen. Dann kann man die Freigabe passend berechtigen. Man kann sich auch entscheiden, dass solche Zwischendurch-Aktionen Käse sind und man ein koordiniertes und funktionierendes Verfahren zur Softwareinstallation einsetzt. Gruß, Nils

Moin, habt ihr denn mehrere Sites, sodass ihr überhaupt warten müsstet? Wenn ja, wie lang sind dort die konfigurierten Intervalle? Ein zu langer Abstand zwischen den Kennwortwechseln ist im Zweifel kontraproduktiv. Falls man so einen Wechsel durchführt, um mögliche Golden-Ticket-Angriffe zu beenden, möchte man den effektiven Kennwortwechsel (also beide Einzelschritte) so schnell wie möglich durch haben. Sonst könnte es passieren, dass der Angreifer das bemerkt (was er durch Abfrage des AD sehr einfach könnte) und nach dem ersten Kennwortwechsel sich ein neues Golden Ticket erzeugt. Das könnte er, weil er den Hash des Vorgängerkennworts noch hätte. Den zweiten Kennwortwechsel würde dieses Golden Ticket dann überstehen, weil es zu den Eigenheiten der ganzen Mechanik gehört, dass sowohl das aktuelle Kennwort als auch dessen direkter Vorgänger akzeptiert werden. Man muss also aufpassen, dass man sich nicht durch scheinbare Vorsichtsmaßnahmen ein Fußpilzproblem erzeugt. Genau deshalb macht das Skript von Jorge recht viel Aufwand und versucht die tatsächliche Replikationslatenz zu messen. Gruß, Nils

Moin, eigentlich macht man sowas ja auch nicht. Kann auch sein, dass im Fall von SMB-Verbindungen die Rückfrage nur kommt, wenn es Berechtigungseinträge für Konten aus anderen Sicherheitsbereichen gibt, also etwa für lokale Konten oder solche aus einer anderen Domäne. Da es sich hier anscheinend immer um dieselbe Domäne handelt, fragt Windows (anscheinend) nicht. Ergäbe Sinn, habe ich nicht mehr im Kopf. Wie gesagt, sowas macht man eigentlich nicht, daher hab ich das auch seit vielen Jahren nicht mehr so machen müssen. Da das alles aber auch ein wenig sinnvolles Herangehen ist, sollte man die Vorgehensweise überdenken. Einzelne Verbindungen mit anderen Useraccounts herzustellen, ist immer eine Krücke mit zahlreichen Nachteilen. Gruß, Nils

Moin, Windows fragt dann, wenn der aktuelle User keine Berechtigung hat (auch keine Verweigerung, sondern einfach kein zutreffender Eintrag), es aber Berechtigung für andere User oder Gruppen gibt. Das muss dann kein Admin sein. Gruß, Nils

Moin, von mir aus nicht. Aber ich glaube eigentlich nicht, dass eure Umgebung so hohe Replikationslatenz hat. Gruß, Nils

Moin, technisch ist das egal. Nur in einer großen, geografisch verteilten Struktur mit großen Replikationslatenzen würde man dafür den PDC-Emulator vorziehen, weil man dann (in manchen Topologien) evtl. Replikations-Hops spart und so die Wartezeit zwischen den beiden Kennwortwechseln verzögert. Das dürfte allerdings heutzutage in fast allen Umgebungen keine ernsthafte Rolle spielen. In einer Multi-Site-Umgebung könnte man sich die konfigurierten Latenzen ansehen und ein wenig Puffer draufrechnen. Oder einfach zwischen den beiden Wechseln zu Mittag gehen. Gruß, Nils

Moin, im Prinzip profitiert ein SQL Server durchaus von mehreren CPUs bzw. vCPUs. "Je mehr desto besser" ist aber nicht ohne Weiteres richtig - wie viele er nutzt, hängt von der Version und Edition ab. Und "viel hilft viel" ist bei vCPUs kein guter Weg. Vier oder acht vCPUs sieht man bei SQL Servern oft, das kann okay sein (wie gesagt, je nach Edition). Alles Weitere müsste man dann schon genauer analysieren. Nur im Ausnahmefall (also eigentlich: auf keinen Fall) sollte man einer VM so viele vCPUs geben wie der Host Cores hat. Und wenn man sowas tut, dann nicht für mehrere VMs gleichzeitig. Das wäre ein prima Weg, den Host in die Knie zu zwingen. Gruß, Nils

Moin, also, richtig ist: in einem AD ohne RODCs macht man das einmalig für die Domäne, nicht pro DC. in einem AD mit RODCs gibt es den "echten" krbtgt und je einen pro RODC. Falls das so ist, muss man die Kennwörter von allen diesen Accounts ändern. Man tut dies auf einem normalen DC. zum Ändern setzt man ein neues Kennwort, das zunächst den Kennwortrichtlinien genügen muss, wie bei jedem anderen Account auch. ABER: Das Kennwort bleibt nicht, sondern das AD setzt dann automatisch einen neuen, geheimen Wert. einmal ändern reicht nicht. Man muss die Replikation abwarten und dann das Kennwort ein zweites Mal ändern. Das liegt daran, dass das AD sowohl das aktuelle als auch das vorhergehende Kennwort akzeptiert. Das ist nur bei diesem Account so. Das TechNet-Skript macht all dies von selbst und prüft vorher genau, was es tun muss. Dass das Skript manchmal abbricht, liegt i.d.R. daran, dass Jorge die Lokalisierung nicht richtig hinbekommen hat. Man braucht das Skript aber nicht, sondern kann das wie beschrieben einfach manuell machen. Wichtig ist nur, dass man zwischendurch die Replikation abwartet, was bei einer weltweit verteilten Umgebung schon mal Stunden dauern kann. Gruß, Nils PS. sorry für die Verwirrung durch meine vorherige, nicht ganz korrekte Antwort.

Moin, fragen wir so: Wozu würdest du eine autorun.inf brauchen? Gruß, Nils

Moin, das macht man einmalig für die Domäne, nicht pro DC. Und auf den RODCs sowieso nicht, die sind Read-only und können keine Daten ändern. Im übrigen hilft eine Websuche nach "krbtgt change password" durchaus weiter. Gruß, Nils

Moin, mit "krudes Szenario" meine ich den Ansatz, das Teilen von Accounts durch den Kennwortwechsel eindämmen zu wollen. Käme mir nicht in den Sinn. Gruß, Nils