RalphT

Hatte ich schon gesetzt. Aber ich habe auf dem System 2 User. Hatte den einen nicht in der Adminruppe. Habe ich in dem ganzen Gehampel übersehen. Läuft jetzt aber. Ja genau, so habe ich das auch. Hatte mich oben nicht klar genug ausgedrückt. So praktiziere ich das auf den anderen Servern auch. Es werden dann immer Mails verschickt. Das funktioniert sehr gut.

Moin, ich verwende in einer PS-Datei folgenden Codeschnipsel: Get-WinEvent @{LogName="Security";Id=6273} -MaxEvents 1 | %{([xml]$_.ToXML()).Event.EventData} > C:\TMP\information.txt ; Dieser ließt einen Teil aus der Ereignisanzeige aus. Das funktioniert soweit auch. Jetzt habe ich folgendes Problem: Dieses Script soll auf einem Server laufen. Dort hat ein Nutzer aus der AD lokale Adminrechte. Die benötigt er auch, da für den Zweig Security Adminrechte notwendig sind. Wenn jetzt dieser Nutzer auf dem Server angemeldet ist, ein PS-Fenster ohne erhöhte Rechte öffnet, dann wird die Ereignisanzeige nicht ausgelesen. Mit erhöhten Rechten funktioniert das. Dieser Nutzer ist in der lokale Gruppe der Administratoren eingetragen. Kann man das Script auch so abändern, dass man kein Fenster mit erhöhten rechten öffnen muss? Hintergrund: Dieses Script soll mit diesen Nutzerdaten im Taskplaner ausgeführt werden.

Ich habe jetzt den Schlüssel verändert. Das funktoniert alles soweit. Ich bin vorher von zwei falschen Tatsachen ausgegangen: Ein erster Treffer bei google zeigte, dass das nur mit einer Neuinstallation möglich sei. Dann bin ich fälschlicherweise davon ausgegangen, dass die CaPolicy.inf nur bei der Installation wirksam sei. Daher dachte ich, dass dort eine Veränderung der Parameter nichts bringt. Problem ist also hiermit gelöst.

Dann habe ich wohl falsch gedacht. Ich dachte, dass bei der Installation nach der Schlüssellänge gefragt wird. Daher bin ich jetzt davon ausgegangen, dass der Wert mit dieser Installation fest ist und nicht mehr verändert werde kann.

Ich hatte nur vor Augen, dass ich keine Lust hatte, zwei neue Server aufzusetzen. Die alte CA eine Schlüssellänge von 2.048. Das soll geändert werden.

Der Plan wäre, dann danach eine neue PKI aufzusetzen. Ich glaube ich mache das so, dass ich vorher ein selbstsigniertes am Exchange erstelle. Dann bekommen die Mitarbeiter eine Zertifikatsnachricht, die dann in den vertrauenswürdigen Speicher installiert werden müsste. Danach wäre ja wieder Ruhe. Anschließend kann ich dann die neue PKI aufsetzen und dem Exchange wieder ein Zertifikat aus der neuen PKI geben. Das würde dann beim Mitarbeiter geräuschlos funktionieren. Meine Frage zielte daher nur darauf ab, ob es nur eine lästige Zertifikatswarnung geben würde. Damit könnte man kurzfristig leben.

Moin, ich wollte in einer AD-Umgebung die 2-stufige Zertifizierungstelle außer Betrieb nehmen. Der Exchangeserver hat von dieser Stelle auch ein Zertifikat. Ein Punkt bei der außer Betriebnahme ist, dass alle ausgestellten Zertifikate für ungültig erklärt werden. Wie reagiert Outlook darauf? Gibt es nur eine Zertifikatswarnung oder stellt Outlook seinen Dienst ein?

Der Trigger kam ja aus dieser Sicherheitsempfehlung, die bei uns hier vorgeschlagen wurden. Ich bin natürlich erst einmal davon ausgegangen, dass der Berater schon weiß, was gut ist. Vielleicht hatte er "das Ganze" nicht so direkt vor Augen. Denn schon wie du schreibst, ganz unsinnig ist der RODC nicht, hängt halt von den Gegebenheiten ab. Bestätigt fühlte ich mich dann von ein oder zwei Berichten, wovon ich ja einen hier gepostet habe. Um jetzt einen evtl. Ärger/Frust aus dem Weg zu gehen, werde ich den RODC entfernen. Ich werde dann wohl in einer ruhigen Minute das Thema in einer Testumgebung mal nachstellen. Besprechen kann ich diese Problematik ja beim nächsten Termin mit dem Berater. Dann kann ich immer noch einen Server aufsetzen.

Ungefähr so ähnlich wie in der Hauptzentrale. Ja diesen Grund hatte ich schon öfters gelesen. Wie würde das bei einem Angriff über der Firewall der Zweigstelle aussehen? Dann hätten die Angreifer ja erst mal einen RODC vor sich. Ok, natürlich existiert ein Tunnel zur Zentrale, wo die DCs stehen. Dieses Thema muss ich jetzt hier nicht durchpeitschen. Es war halt nur eine Empfehlung. Vielleicht sollte ich das mal in in einer Testungebung für mich aufbauen und dann in aller Ruhe schauen. Diesen RODC könnte ich ja wieder aus der Domäne entfernen.

Das hatte man mir empfohlen. Als Sicherheitsmaßnahme. Ich gebe zu, dass ich vorher noch nie mit einem RODC rumhantiert habe. Bislang läuft ja noch der DC. Da ich auch beim googlen Beiträge zu diesem Szenario gefunden habe, dachte ich, dass dieses Vorgehen schon ok ist. https://www.ip-insider.de/so-betreiben-sie-schreibgeschuetzte-domaenencontroller-a-f559470f963357cd5c8584b8fb8afb12/ Warum würdest du das nicht empfehlen?

Der eine DC soll abgeschaltet werden. Es soll dann nur noch der RODC in der Zweigstelle laufen. Die lautet 18.

Moin, ich hatte in einer Zweigstelle neben einem DC 2019 einen RODC aufgesetzt. Derzeit laufen noch beide Server parallel. Seit einiger Zeit gibt es die folgende Meldung im DC: Die Signatur auf dem PAC von krbtgt_1234 konnte vom KDC während der TGS-Verarbeitung nicht verifiziert werden. Dies deutet darauf hin, dass das PAC verändert wurde. Bislang habe ich noch keine Lösung dazu gefunden.

Ich habe gerade eben nochmal nachgesehen. Manchmal übersieht man ja was oder es ist anders sortiert. Hier fehlt diese Version. Ich habe hier 2015, 2016 und 2019. Vielleicht sollte ich mal meinen Verkäufer anrufen und diesen um Rat fragen.

Moin, ich möchte einen Client mit Windows 10 Enterprise LTSC 2019 auf 2021 aktualisieren. Im Admincenter (ehem. VLSC) wird mir diese Version nicht angeboten. Ist dieser Sprung kostenpflichtig? Die Version LTSC 2021 ist ja auch noch Windows 10. Wie kann ich diese Version aktualisieren?

Stimmt. Denn der hat sich die 2 Tage bei gutem Wetter eine Auszeit gegönnt. Ich war heute kurz vor Ort und habe die beiden DCs neu gestartet. Es war beiden tatsächlich ein Update vom Virenscanner (Panda) noch nicht fertig. Nach dem Neustart merkte man sofort, dass die beiden Geräte wieder wesentlich flotter auf Eingaben reagieren. Mir war auch so, dass ein DC erst mal so nicht viel an Resourcen benötigt. Das war damals bei Novell auch so. Das tückische hierbei war, dass der Virenschutz einen benötigten Neustart nicht angezeigt hatte. Anschließend habe ich das gleiche Verfahren auf beiden DCs wieder ausprobiert. Läuft! Beim Klick auf OK reagiert das Menü sofort. Das war vorher nicht der Fall. Man sah richtig, wie das manchmal klemmte. Jetzt habe ich zum Schluss aber trotzdem noch eine Frage: Wenn ich auf dem DC 1 den GPO-Editor öffne und dort etwas verändere, dann werden die Änderung ja auf dem SYSVOL geschrieben. Wird dann in diesem Fall auf dem SYSVOL vom DC 1 geschrieben? Also auf seine Festplatte? Oder kann man das gar nicht so genau sagen? Die Änderung ist doch auf allen DCs sofort verfügbar oder liege ich da falsch? Denn mit der eigentlichen Replikation hat dieses hier doch nichts zu tun.