RalphT

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.

Darüber hatte ich auch schon nachgedacht. Habe es aber aus einem anderen Grund erstmal verworfen. Mir ist aufgefallen, dass die beiden DCs hier recht lahme Krücken sind. Ein STRG-ALT ENTF dauert bestimmt 5 bis 10 Sekunden, bis mal der Bildinhalt zu sehen ist. RAM haben die jeweils 16G, der ist nur zu 30% ausgelastet. Die Prozessorleistung ist ständig bei 30% ausgelastet. Das kam mir recht viel vor. Ich habe noch andere Server, ähnlicher Bauart. Das sind z.B. einfache Fileserver usw. Die regieren wesentlich flotter. Bei denen ist die Dauerlast vom Prozessor bei mal gerade 5%. Die Prozessorlast kommt bei den DCs vom Virenschutz. Jetzt hatte ich heute noch gesehen, dass der Virenschutz überall einen Neustart erfordert. Ich werde daher jetzt als aller erstes die Rechner alle neustarten. Danach sehe ich mir nochmal die Prozessorlast auf den beiden DCs an. Ich hatte letzt den Exchange 5 oder 6 mal booten müssen, bis alle Windows-Updates und Virenschutzupdates zufrieden waren. Daher war vorhin noch meine Vermutung, dass das vielleicht die Fehlerursache sein könnte. Anschließend werde ich mal wie du geschrieben hattest die Replikation anschubsen. Zwischenzeitlich hatte ich vorhin mit einer Test-GPO rumgespielt. Mir einen Wert ausgesucht, z. B. "Anmelden am Dienst verweigern" und dann immer einen Nutzer nach dem anderen im Sekundentakt reingebracht und wieder entfernt. Mal gehts zwei mal, und dann wieder 2 oder 3 mal nicht. Die Latenz? Hm, ich glaube ein Ping hat so eine Antwortzeit von 10 - 15 ms. Bin mir da aber nicht so genau sicher.

Habe ich auch schon gerade im Verdacht. Ich bin ja immer noch in der Findungsphase. Ich habe hier 2 DCs und woanders auch 2 DCs stehen. Der DC mit den FSMO-Rollen steht hier. Verbunden über eine gute Leitung, über VPN und Firewalls. Jetzt hatte ich gerade von der Zweigstelle das gleiche Verfahren auf einem der DCs probiert. Also die gleiche GPO editiert. Dort nach Belieben etwas verändert. Funktionierte super schnell und einwandfrei. Dann dachte ich schon daran, das das Phänomen nur auf einer Seite besteht. Nein, denn ein Nachfolgeversuch auf der Gegenseite war anschließend nicht erfolgreich. Wenn man den Editor öffnet und dort etwas einstellt und anschließend auf OK oder Übernehmen klickt, dann geht das mal superschnell und im Fehlerfall "klemmt" es richtig. Der blaue Mauskreis dreht sich ca. 2 Sekunden. Was mich so stutzig macht: Warum funktionert es bei einem großen Teil der Werte und bei bestimmten Zweigen nicht? es wird doch die gleiche Datei beschrieben. Oder denke ich falsch?

Ich habe nochmal etwas rumprobiert. Eine neues GPO erstellt. Im Zweig Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Zuweisen von Benutzerrechten einiges an Werten verändert. Mal gehts sofort, im gleichen Augenblick danach kann man die Gruppe nicht mehr entfernen. Dann wieder und wieder probieren zu entfernen. Auf einmal funktioniert es. Sieht mir so nach einem Zufallsprinzip aus. Andere Zweige, wie z.B. Computerkonfiguration/Administrative Vorlagen, da gibt es anscheinend keine Probleme. Hier kann man nach Belieben Werte aktivieren und wieder deaktivieren. Das Problem scheint nur in den oberen System-GPOs zu liegen. Jetzt könnte ich natürlich bei der neuen GPO solange probieren, bis alle Einträge sitzen. Das würde dann wahrscheinlich auch später wohl funktionieren. Denn die Einträge in der GptTmpl.inf sind ja korrekt. Die Sicherung aller GPOs hat natürlich auch ohne Fehlermeldungen funktioniert, da ich das GPO mit den unbekannten SIDs bereinigt hatte.

Habe ich gemacht. Funktioniert leider teilweise. Entfernen der unbekannten SIDs hat funktioniert. Allerdings fehlten bei machen Einträgen bestimmte Gruppen. Das hatte ich mit einem funktionierenden DC verglichen. Viele Einträge ließen sich komplett so wiederherstellen, wie es sein soll. Allerdings sind so ca. 5 Einträge vorhanden, wo ich die SIDs herauslöschen konnte. Jedoch die fehlenden Gruppen ließen sich nicht hinzufügen. Es erscheint dann gleiche Fehlermeldung wie im ersten Post. Es kann die Datei GptTmpl.inf nicht beschrieben werden. Irgendwie seltsam: Ganz oben ist "Ändern der Systemzeit". Hier kann ich z.B. die Gruppe Druck-Operatoren hinzufügen und auch wieder entfernen. Bei dem Eintrag "Laden und entfernen von Gerätetreibern" funktioniert das nicht. Es wird irgendwie immer kurioser: Jetzt war ich beim Eintrag "Lokal anmelden zulassen". Da fehlten auch 3 oder 4 Gruppen. Nach ca. 10 Minuten konnte ich dann doch eine weitere Gruppe hinzufügen. Anschließend hatte ich dann eine weitere Gruppe hinzugefügt. Auch das funktionierte. Zum Schluss fehlte noch die Gruppe "Server Operatoren". Nach dem Klick auf OK sieht man auch, dass der Schreibvorgang irgendwie länger dauert. Anschließend erscheint die bekannte Fehlermeldung. Dann hatte ich wieder ca. 10 Minuten verstreichen lassen. Auf einmal ließ sich dann auch noch die letzte fehlende Gruppe dort hinzufügen.

Beim Sichern der GPOs ist mir dann folgendes aufgefallen: In der Standard-GPO "Default Domain Controllers Policy" ist mir aufgefallen, dass dort nicht auflösebare SIDs enthalten sind. Siehe Anhang. Diese hatte ich allerdings nie verändert.

Moin, ich erstelle ein neues GPO. In den Computereinstellungen stelle ich z.B. im Pfad ..\Lokale Richtlien etwas ein. Nachdem ich dann auf OK klicke, erscheint folgende Fehlermeldung. Das ist aber nicht in allen Werten so. Stelle ich z.B. etwas bei der Firewall eine Regel ein, dann funktioniert das. Auch in den Administrativen Vorlagen habe ich stichpunktartig rumprobiert. Dort war auch kein Fehler feststellbar. Die Datei GptTmpl.inf wurde tatsächlich nicht richtig verändert. Der Wert steht zwar in der Datei, jedoch nicht der angegebene User. Die GPO habe ich hier auf einem zentralen Store. Die Ereignisanzeige ist sauber. DCDIAG und repladmin sind auch ohne Fehler. Ich kann mir jetzt nicht so direkt vorstellen, dass bestimmte ADMX-Vorlagen defekt sind. Hat einer eine Idee, wo der Fehler liegen könnte? Wer weiß, wie lange dieser Fehler schon präsent ist, da das ja nur bei bestimmten Werte in einer GPO auffällt.

Habs gefunden. Danke dir.

Moin, ich hatte in einer AD-Umgebung noch mit dem alten LAPS gearbeitet und wollte dort jetzt das neue LAPS nutzen. Damals hatte ich den Befehl Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Clients,DC=firma,DC=de" zur Rechtevergabe verwendet. Kann man das wieder rückgänging machen? Und kann man den Pfad sehen, wo das damals erstellt wurde? Ich denke das ist wohl nicht weiter schlimm, wenn es einfach so bleibt wie ist. Der Befehl Find-LapsADExtendedRights -Identity LapsTestOU ist dazu ja nicht geeignet.

Ehrlich gesagt - ich bin mir noch nicht sicher. Eigentlich reicht mir die Protection Version. Aber ich habe gesehen, dass es etwas für Disclaimer gibt. Ich muss mir das nochmal in Ruhe durchlesen. Die Sache mit dem Disclaimer finde ich garnicht so verkehrt. Ich habe das hier ja mit Bordmitteln im Exchange realisiert. Das hat natürlich so seine Schönheitsfehler. Ich muss mir das nächste Woche mal alles in Ruhe ansehen.

Dann kam das falsch rüber. Ich habe nicht das Produkt gewählt, weil man es testen kann. Hatte einen Bekannten gefragt, der nutzt das auch und ist sehr zufrieden. Daher die Entscheidung.

Erst mal vielen Dank für die Tipps. Ich werde das wie folgt machen: Erst einmal den Reverse-DNS und SPF-Eintrag erstellen/ändern. Um den Popconnector abzulösen, habe ich mich für das folgende Produkt entschieden. Dort gibt es eine 30 Tage Version, wo ich in Ruhe testen kann. https://docs.nospamproxy.com/Server/14/Suite/de-de/Content/intro/Home.htm

Wir haben so ca. 50 Teilnehmer. Cloud kommt nicht in Frage. Den Exchange kann ich ja so nicht einfach ohne Spam-Filter, etc. einfach per https von extern erreichbar machen. Kann schon, wäre aber tödlich. Nun ist es so, dass ich das jetzt mal eben nicht entscheiden kann und dieses Thema natürlich vorher hier besprochen werden muss, da das ja auch mit Kosten verbunden ist. Jetzt stellt sich daher für mich die Frage: Kann ich ab dem o.g Stichdatum diese Konstellation noch so nutzen? Wenn ja, wie? Wir hatten dieses Thema ja schon auf dem Plan, nur das ist recht kurzfristig. Daher wäre mir eine Zwischenlösung erst einmal recht, um dann im Laufe 2024 das richtig zu machen.