Geht niemanden was an
Nicht notwendig, wenn der Router korrekt konfiguriert ist (Schlagwort Router Advertising)
Windows blockiert Ping-Anforderungen durch eine entsprechende Konfiguration der Firewall. Diese Einstellung lässt sich auf mehrere Arten ändern, entweder über die grafische Konsole der Firewall, über die Kommandozeile sowie PowerShell oder zentral über Gruppenrichtlinien.
Der Grund für das abweisende Verhalten von Windows gegenüber Ping-Requests sind Sicherheitsbedenken von Microsoft. Schließlich wird der Dienst gerne für Angriffe missbraucht, bevorzugt für Denial-of-Service-Attacken.
Nichtsdestotrotz hat Ping nach wie vor seine Berechtigung als Diagnosewerkzeug bei Netzwerkproblemen, so dass man diese strikte Konfiguration der Firewall meistens lockern wird. In Firmennetzen kann man die damit verbundenen Risiken reduzieren, indem man die vordefinierte Firewall-Regel nur für das Profil Domäne aktiviert oder zulässige Anfragen auf bestimmte IP-Adressen beschränkt.
Für diesen Zweck stehen mehrere Werkzeuge zur Verfügung. Während Standardbenutzer die vorhandenen Einstellungen mit den Kommandozeilen-Tools ansehen können, setzt die Aktivierung von Firewall-Regeln grundsätzlich administrative Rechte voraus.
Das gängigste Programm zur Aktivierung der Firewall-Regeln für eingehende Pings ist die grafische Oberfläche Windows-Firewall mit erweiterter Sicherheit. Hier muss man sich als Administrator anmelden, um überhaupt die Einstellungen angezeigt zu bekommen.
Dort wechselt man in der linken Spalte zu Eingehende Regeln und sucht anschließend im Hauptfenster nach Datei- und Druckerfreigabe (Echoanforderung – ICMPv4 eingehend). Diese Regel existiert in Ausprägungen für die Profile Domäne sowie für Öffentlich und Privat. Je nach Bedarf aktiviert man sie für ein bestimmtes oder für mehrere Profile (siehe dazu: Windows-Firewall: Regeln für Profile konfigurieren).
Öffnet man den Dialog Eigenschaften aus dem Kontextmenü dieser Regel, dann kann man dort unter Bereich => Remote-IP-Adresse die Clients, von denen Ping-Anfragen erlaubt sind, weiter einschränken. Existieren auf dem Rechner mehrere NICs, dann besteht zudem die Möglichkeit, über Lokale IP-Adressen jene festzulegen, zu denen Requests durchgelassen werden.
PowerShell verfügt über eine Reihe von Cmdlets, mit denen sich die Firewall vollständig konfigurieren lässt. Für das Management der Regeln eignen sich Get-NetFirewallRule und Set-NetFirewallRule. Ersteres hilft dabei, den Status von Regeln zu ermitteln, Zweiteres kann diesen ändern.
Möchte man sich anzeigen lassen, welche Regeln für Ping zuständig sind, dann filtert man sie nach dem Begriff ICMP4:
Get-NetFirewallRule -name *ICMP4* | select name, DisplayName, Profile, Enabled | fl
Dieser Befehl gibt eine relative kurze Liste aus und zeigt unter anderem auch, für welches Firewall-Profil die Regeln gelten und ob sie aktiviert sind. Für eingehende Ping-Anforderungen in Domänen-Netzwerken ist demnach FPS-ICMP4-ERQ-In-NoScope zuständig, für die Profile Öffentlich und Privat hingegen FPS-ICMP4-ERQ-In.
Nun kann man im nächsten Schritt die gewünschte Regel aktivieren, beispielsweise mit dem Befehl
Set-NetFirewallRule -name FPS-ICMP4-ERQ-In-NoScope -Enabled True -RemoteAddress 192.168.0.66
Er ändert nicht nur den Status der Regel FPS-ICMP4-ERQ-In-NoScope, so dass Ping-Anforderungen durchgelassen werden, sondern grenzt zusätzlich die zulässigen Hosts auf die IP-Adresse 192.168.0.66 ein. Vom Erfolg der Maßnahme kann man sich durch
Get-NetFirewallRule -name FPS-ICMP4-ERQ-In-NoScope | select name, enabled
überzeugen.
Wie schon in früheren Versionen von Windows steht auch weiterhin das Kommandozeilen-Tool netsh.exe für diese Aufgabe zur Verfügung. Zu seinen Nachteilen gehört nicht nur eine eigenwillige Syntax, sondern auch ein Mix aus übersetzten Namen für die Regeln und englischsprachigen Werten für die meisten Parameter.
Das netsh-Äquivalent zum obigen Aufruf von Set-NetFirewallRule würde so aussehen:
netsh advfirewall firewall set rule profile=Domain name=“Datei- und Druckerfreigabe (Echoanforderung – ICMPv4 eingehend)“ new enable=yes remoteip=192.168.0.66
Möchte man Anfragen von allen Rechnern zulassen, dann verzichtet man auf den Parameter remoteip. Will man hingegen die Regel für die Profile Öffentlich und Privat aktivieren, dann ändert man den Wert für profile auf Private,Public.
In zentral verwalteten Umgebungen wird man die Firewall-Einstellungen wahrscheinlich über GPOs konfigurieren wollen, beispielsweise für alle Rechner in einer bestimmten OU. Diese Möglichkeit bestand ebenfalls schon unter Windows 7 / 8.1, das Vorgehen ist dabei gleich geblieben. Siehe dazu meine Anleitung Ping mittels GPO erlauben in Windows 7 / 8.x und Server 2012 (R2).
Content retrieved from: https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gui-powershell-netsh-gpo.
Jeder Domänencontroller in einem Windows-Netzwerk besitzen eine Ordnerfreigabe namens SYSVOL. Diese dient zur Replikation von Skripten und Gruppenrichtlinien zu anderen Domänencontroller. Der zugrunde liegende Replikationsmechanismus basiert ab Windows Server 2008 auf dem File Distributed File Replication Service (DFRS). Bis Windows Server 2016 wurde auch der ältere Replikationsmechanismus File Replication Service (FRS) unterstützt.
Wer bisher Windows Server 2016 (oder älter) als Domänencontroller im Einsatz hatte, dessen Replikation basiert unter Umständen noch auf FRS. Wer nun einen Windows Server 2019 oder 2022 als sekundären Domänencontroller hinzufügen möchte, der bekommt eine fette Meldung präsentiert, dass das so nicht geht, da der eigene Server kein FSR unterstützt.
In diesem Fall bleibt uns nichts weiter übrig, als den Replikationsmechanismus auf DFRS zu migrieren.
Das Werkzeug zur Durchführung der Migration hört auf den Namen Dfsrmig.exe.
Mit Dfsrmig.exe kannst Du die Migration in drei Schritten bei laufendem Betrieb durchführen:
Prepared: In diesem Status wird DFSR parallel zu FRS aktiviert. DFSR legt eine eigene Kopie des SYSVOL-Ordners unter SYSVOL_DFRS an, macht sonsts aber erstmal gar nichts.Redirected: In diesem Status beginnt DFSR mit der Arbeit und nimmt Replikationsanfragen entgegen. SYSVOL_DFRS wird zum Hauptordner. FRS bleibt aber noch aktiv und arbeitet parallel mit seinem alten SYSVOL-Ordner.Eliminated: In diesem Status geht DFSR weiter seiner Arbeit nach. FRS wird jedoch deaktiviert und der alte SYSVOL-Ordner gelöscht.Die Aufteilung in drei separate Schritte erlaubt eine Rollback-Migration im Fall eines Fehlers.
Soweit zur Theorie, wir wollen jetzt die Migration in der Praxis sehen. Wir gehen dabei von folgender Beispielkonfiguration aus:
intranet.beispiel.atDC01DC02Als erstes prüfen wir, ob die aktuelle Replikation unter FSR in Ordnung ist.
Dazu auf dem Server DC01 die Eingabeaufforderung als Administrator starten und folgendes eintippen:
net share
Die Ausgabe sollte in etwa wie folgt aussehen:
Name Ressource Beschreibung
-------------------------------------------------------------------------------
C$ C:\ Standardfreigabe
IPC$ Remote-IPC
ADMIN$ C:\Windows Remoteverwaltung
NETLOGON C:\Windows\SYSVOL\sysvol\intranet.beispiel.at\SCRIPTS
Ressource für Anmeldeserver
SYSVOL C:\Windows\SYSVOL\sysvol Ressource für Anmeldeserver
Der Befehl wurde erfolgreich ausgeführt.
Das sieht gut aus, die Netzwerkfreigabe SYSVOL ist wie gewünscht vorhanden.
Ein weitere Prüfung:
dfsrmig /getglobalstate
Die Ausgabe sollte wie folgt aussehen:
Die DFSR-Migration wurde noch nicht initialisiert. Legen Sie den
globalen Status auf den gewünschten Wert fest, um die Migration zu starten.
Wir haben dfsrmig gestartet und den aktuellen Status der Migration abgefragt. Die Antwort ist wie erwartet, eine Migration wurde also noch nicht durchgeführt.
Jetzt starten wir den Migrationsprozess, in dem wir den Status auf 1 (Prepared) setzen:
dfsrmig /setglobalstate 1
Die Ausgabe sollte wie folgt aussehen:
Aktueller globaler DFSR-Status: "Starten"
Neuer globaler DFSR-Status: "Vorbereitet"
Die Migration wechselt in den Status "Vorbereitet". Der DFSR-Dienst
kopiert den Inhalt von SYSVOL in den Ordner SYSVOL_DFSR.
Falls die Migration von einem Domänencontroller nicht gestartet werden kann, versuchen Sie es mit einem manuellen Abruf.
Alternativ können Sie den Befehl mit der Option "/CreateGlobalObjects" ausführen.
Die Migration kann in einem beliebigen Zeitraum
zwischen 15 Min. und 1 Stunde gestartet werden.
Erfolgreich
Unmittelbar danach überprüfen wir den Migrationsstatus:
dfsrmig /getmigrationstate
Es dauert eine Weile, bis alle Domänencontroller den Status übernommen haben. Daher sieht die Ausgabe wahrscheinlich wie folgt aus:
Die folgenden Domänencontroller haben den globalen Status (""Vorbereitet"") nicht erreicht:
Domänencontroller (lokaler Migrationsstatus) - Domänencontrollertyp
===================================================================
DC01 ("Starten") - Primary DC
DC02 ("Starten") - Writable DC
Die Migration hat noch nicht auf allen Domänencontrollern einen konsistenten Status erreicht.
Möglicherweise sind die Statusinformationen aufgrund der Wartezeit der Active Directory-Domänendienste veraltet.
Diese Abfrage können wir beliebig oft wiederholen. Irgendwann bekommen wir diese Ausgabe:
Alle Domänencontroller wurden erfolgreich zum globalen Status (""Vorbereitet"") migriert.
Die Migration hat auf allen Domänencontrollern einen konsistenten Status erreicht.
Erfolgreich
Mit Schritt 1 sind wir fertig.
Jetzt wollen wir den Status auf 2 (Redirected) setzen:
dfsrmig /setglobalstate 2
Die Ausgabe sollte wie folgt aussehen:
Aktueller globaler DFSR-Status: "Vorbereitet"
Neuer globaler DFSR-Status: "Umgeleitet"
Die Migration wechselt in den Status "Umgeleitet". Die Freigabe "SYSVOL"
wird zum Ordner "SYSVOL_DFSR" geändert,
der mithilfe von DFSR repliziert wird.
Erfolgreich
Wir prüfen wieder den Migrationsstatus:
dfsrmig /getmigrationstate
Zunächst bekommen wir folgende Ausgabe:
Die folgenden Domänencontroller haben den globalen Status (""Umgeleitet"") nicht erreicht:
Domänencontroller (lokaler Migrationsstatus) - Domänencontrollertyp
===================================================================
DC01 ("Vorbereitet") - Primary DC
DC02 ("Vorbereitet") - Writable DC
Die Migration hat noch nicht auf allen Domänencontrollern einen konsistenten Status erreicht.
Möglicherweise sind die Statusinformationen aufgrund der Wartezeit der Active Directory-Domänendienste veraltet.
Wenn alle Domänencontroller den Migrationsstatus übernommen haben, dann diese Ausgabe:
Alle Domänencontroller wurden erfolgreich zum globalen Status (""Umgeleitet"") migriert.
Die Migration hat auf allen Domänencontrollern einen konsistenten Status erreicht.
Erfolgreich
Mit Schritt 2 sind wir fertig.
Zu guter Letzt wollen wir den Status auf 3 (Eliminate) setzen:
dfsrmig /setglobalstate 3
Die Ausgabe sollte wie folgt aussehen:
Aktueller globaler DFSR-Status: "Umgeleitet"
Neuer globaler DFSR-Status: "Entfernt"
Die Migration wechselt in den Status "Entfernt". Es ist nicht möglich,
diesen Schritt rückgängig zu machen.
Verwenden Sie die Option "/DeleteRoNtfrsMembers", wenn ein schreibgeschützter Domänencontroller
zu lange im Status "Wird entfernt" verbleibt.
Erfolgreich
Wir prüfen wieder den Migrationsstatus:
dfsrmig /getmigrationstate
Und auch hier, erst so:
Die folgenden Domänencontroller haben den globalen Status (""Entfernt"") nicht erreicht:
Domänencontroller (lokaler Migrationsstatus) - Domänencontrollertyp
===================================================================
DC01 ("Umgeleitet") - Primary DC
DC02 ("Umgeleitet") - Writable DC
Die Migration hat noch nicht auf allen Domänencontrollern einen konsistenten Status erreicht.
Möglicherweise sind die Statusinformationen aufgrund der Wartezeit der Active Directory-Domänendienste veraltet.
Später dann so:
Alle Domänencontroller wurden erfolgreich zum globalen Status (""Entfernt"") migriert.
Die Migration hat auf allen Domänencontrollern einen konsistenten Status erreicht.
Erfolgreich
Mit dem letzten Schritt 3 sind wir fertig.
Werfen wir wieder einen Blick auf unsere Netzwerkfreigaben:
net share
Die Ausgabe sollte in etwa wie folgt aussehen:
Name Ressource Beschreibung
-------------------------------------------------------------------------------
C$ C:\ Standardfreigabe
IPC$ Remote-IPC
ADMIN$ C:\Windows Remoteverwaltung
NETLOGON C:\Windows\SYSVOL_DFSR\sysvol\intranet.beispiel.de\SCRIPTS
Ressource für Anmeldeserver
SYSVOL C:\Windows\SYSVOL_DFSR\sysvol Ressource für Anmeldeserver
Der Befehl wurde erfolgreich ausgeführt.
Der Name der Netzwerkfreigabe ist gleich geblieben, aber der verknüpfte Ordner lautet nun SYSVOL_DFSR. So war es ja geplant, also alles ok.
Eine abschließende Prüfung soll sicherstellen, dass der Dienst für FSR deaktiviert ist.
sc query NtFrs
Die Ausgabe sollte so aussehen:
SERVICE_NAME: NtFrs
TYPE : 10 WIN32_OWN_PROCESS
STATE : 1 STOPPED
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
Content retrieved from: https://blog.stueber.de/posts/sysvol-dfsr-migration/.
Entpacken Sie die Ihnen zugesandte ZIP Datei auf Ihrem Server.
Öffnen Sie die Exchange Management Shell und führen Sie den folgenden Befehl aus, um das Server-, Root- und Zwischenzertifikat in die entsprechenden Zertifikatsspeicher zu installieren:
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\Zertifikate\IhrZertifikat.cer -Encoding byte -ReadCount 0))
Anmerkung: Sollten Sie .crt Dateien anstelle von .cer erhalten haben, dann vergewissern Sie sich, dass IhrZertifikat.cer Ihre_Bestellnummer.crt oder www_ihredomain_de.crt lautet.
Es kann sein, dass Sie aufgrund des Formates Ihr Root und Zwischenzertifikat auf Ihrem Server manuell installieren müssen.
Vergewissern Sie sich, dass sich keine Leerzeichen in Ihrem Pfad befinden. Als Abschluss des Befehls sollten Sie den Thumbprint angezeigt bekommen (sollten Sie diesen verlieren, können Sie ihn aus dem MMC Certificates Snap-In kopieren).
Um die Dienste zu aktivieren, führen Sie folgenden Befehl aus:
Enable-ExchangeCertificate -Thumbprint $your_thumbprint -Services "POP,IMAP,SMTP,IIS"
(Immer in der Annahme, Sie nutzen alle genannten Dienste aktiv. Passen Sie diesen Aufruf entsprechend Ihrer eigenen Konfiguration an)
Alternativ können Sie den folgenden Befehl ausführen und den Import und Dienststart in einer Zeile kombinieren:
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\Zertifikate\IhrZertifikat.cer -Encoding byte -ReadCount 0)) | Enable-ExchangeCertificate -Services „IIS,POP,IMAP,SMTP
Um also mehrere Server- bzw. Dienstnamen in einem Zertifikat einzubinden, erstellt man ein spezielles Zertifikat, welches um das Datenfeld Subject Alternative Names erweitert wird. Öffentliche Zertifizierungsstellen (Certificate Authority, CA) bieten u.a. Webformulare an, in denen man alle benötigten Namen angibt. Die CA erstellt aus den Angaben den Certificate Signing Request (CSR) sowie den Private Key und signiert das neue Zertifikat. Der private Schlüssel ist streng vertraulich, da mit diesem die Entschlüsselung von Daten erfolgt.
In diesem Szenario besitzt die Zertifizierungsstelle sowohl den öffentlichen als auch den privaten Schlüssel des Zertifikats. Die Sicherheit und Vertraulichkeit ist dadurch nicht mehr gewährleistet. Der private Schlüssel ist vor Zugriffen Dritter, also auch vor Zugriffen öffentlicher Zertifizierungsstellen, zu schützen.
Vertraulichkeit und hohe Sicherheitsansprüche sind gute Gründe den CSR, und damit den privaten Schlüssel, selbst zu erstellen. Betreibt man eine eigene, interne PKI, bspw. mithilfe Microsofts AD CS, wird man gelegentlich CSR für interne Dienste bzw. Server erstellen müssen. Im Folgenden wird beschrieben, wie man diese CSR zum Ausstellen neuer Zertifikate mit Windows Bordmitteln recht einfach erstellt. Das Verfahren ist nicht ausschließlich auf SAN-Zertifikate beschränkt, sondern kann auch zum Beantragen von Wildcard- und Single Name-Zertifikaten angewandt werden.
Der Zertifikatsspeicher des lokalen Computers.
Zertifikate werden in unterschiedlichen Bereichen aufbewahrt. Es gibt den zentralen Zertifikatsspeicher des Computer. Die in diesem Speicher abgelegten Zertifikate können sowohl von Programmen, Diensten sowie von allen Benutzern des Computers genutzt werden. Zum Verwalten dieser Zertifikate sind jedoch Administratorberechtigungen erforderlich. Die Management Konsole des Computer Certificate Store ruft man über Start –> Ausführen –> certlm.msc auf.
Der Zertifikatsspeicher des angemeldeten Benutzers.
Jeder Benutzer besitzt seinen eigenen Certificate Store. Auf den benutzerspezifischen Zertifikatsspeicher hat nur der jeweilige Anwender Zugriff. Für die Verwaltung der eigenen Zertifikate sind keine administrativen Berechtigungen erforderlich. Die Management Konsole des eigenen Zertifikatsspeicher startet man über Start –> Ausführen –> certmgr.msc auf.
Um den CSR direkt auf dem Windows Gerät zu erstellen, auf dem das neue Zertifikat eingesetzt werden soll, verwendet man idealerweise die Zertifikatsverwaltung des Computers: certlm.msc. Generiert man den CSR stellvertretend, um das Zertifikat nach Erstellung zu exportieren und weiterzugeben, reicht die eigene, benutzerbezogene Zertifikatsverwaltung, da sie keine erhöhten Rechte anfordert: certmgr.msc
Für ein SAN-Zertifikat muss eine benutzerdefinierte Anforderung (Custom Request) erstellt werden.
Nach dem Start des Assistenten, führt man den Vorgang ohne Registrierungsrichtlinie fort. Active Directory-Registrierungsrichtlinien werden über Gruppenrichtlinien (GPO) verwaltet und stellen in der Regel einfache Benutzer- oder Computerzertifikate aus. Diese Richtlinie ist für unsere Zwecke nicht ausreichend.
Sowohl die Wahl der Crypto Engine CNG, als auch das Format PKCS sind vorausgewählt.
Den CSR konfiguriert man über Eigenschaften, die durch einen Klick auf Details erscheinen.
Sowohl Anzeigename als auch Beschreibung dienen der besseren Übersicht, haben üblicherweise keine technische Relevanz und können frei gewählt werden.
Es gibt vereinzelt Anwendungen die den Anzeigenamen nutzen, um Zertifikate zu identifizieren. Beispielsweise greift der Office Online Server auf dieses Feld zurück, um ein Wildcard-Zertifikat einzubinden. Der VMware Connection Server erfordert gar den vordefinierten Wert vdm als Anzeigename, um das richtige Zertifikat zu erkennen, was bei einem Zertifikatswechsel zu beachten ist.
Diese Eigenschaften lassen sich jederzeit nachträglich in der Zertifikatsverwaltung anpassen.
Jetzt sind alle relevanten Daten einzugeben. Üblicherweise gibt man als Common Name (Allgemeiner Name) den DNS-Namen an, unter dem der Dienst öffentlich erreichbar ist. Hinzu kommen Angaben zum Ort bzw. Stadt (L=Location), Land/Region (C=Country), was nicht zu verwechseln ist mit (Bundes)Land (S=State). Des Weiteren sind die Angaben Organisation (O), die verantwortliche Organisationseinheit (OU), in der Regel die IT-Abteilung, und die E-Mail-Adresse eines Kontakts. Übliche Kürzel, bspw. Länderkennungen, sind erlaubt.
Die alternativen Namen werden im unteren Abschnitt eingetragen. Neben DNS kann man auch die IP-Adressen eintragen.
Welchen Zweck ein Zertifikat erfüllt, gibt man im Reiter Erweiterungen unter Erweiterte Schlüsselverwendung (Anwendungsrichtlinien) an. Für ein Serverzertifikat ist die Option Serverauthentifizierung auszuwählen. Oftmals wird Zertifikaten zusätzlich die Option Clientauthentifizierung hinzugefügt, über die sich ein Server anderen gegenüber als Client authentifiziert. Diese Option ist aber nicht erforderlich.
Bei der Angabe Schlüsselverwendung handelt es sich um Einschränkungen der Verwendung des Zertifikats auf die ausgewählten Optionen. Typischerweise erforderlich für ein Serverzertifikat ist Digitale Signatur, oft in Kombination mit Schlüsselverschlüsselung, was bedeutet, dass der Schlüsselaustausch nur mit Schlüsselverschlüsselung zugelassen ist. Diese Angabe ist optional und wird ggf. durch die signierende CA gesetzt.
Die Auswahl und Konfiguration der Cipher Suite erfolgt im Reiter Privater Schlüssel. Je nach Verwendungszweck und Laufzeit des Zertifikats, ist ein geeigneter Algorithmus mit entsprechender Schlüssellänge zu wählen. Nach wie vor häufig im Einsatz ist RSA. Bei Verwendung von RSA sollte der Schlüssel mindestens 2048, besser 4096 Bit lang sein. Neuere Alghorithmen, bspw. auf Basis elliptischer Kurven wie ECDH, kommen mit kleineren Schlüsseln aus.
Der Kryptografieanbieter, per default RSA, kann ausgewählt bleiben. Damit verstehen sich die meisten Programme. Möchte man die Sicherheit hochschrauben, greift man zu neueren Cipher Suiten mit Elliptic Curve Cryptography (ECC). Das Perfect Forward Secrecy Verfahren stellt sicher, dass verschlüsselte Kommunikation nicht zu entschlüsseln ist, da sich mit jeder neuen Session der Session Key ändert.
Der Hashalgorithmus sollte unbedingt auf SHA-2 basieren, SHA-1 und MD5 sind unsicher, auf sie sollte man komplett verzichten. In der Praxis werden die Algorithmen SHA-256, SHA-384 und SHA-512 verwendet, aktuelle Browser und Geräte unterstützen SHA-2. Muss das Zertifikat exportiert werden, ist der private Schlüssel als exportierbar zu kennzeichnen.
Nach der Angabe aller Daten, schließt und speichert man die Anforderung ab.
Den CSR schickt man nun der CA. Der CA Administrator prüft und signiert den Request, um diesen in Form eines Zertifikates zurückzusenden. Dieses Zertifikat muss auf dem Gerät importiert werden, auf dem der CSR erstellt wurde. Und der Import erfolgt in den zuvor genutzten Zertifikatsspeicher. Denn nur dort liegt der generierte private Schlüssel des Zertifikats.
Windows ordnet den privaten Schlüssel automatisch dem zugeordneten Zertifikat zu. Ob ein Schlüsselpaar komplett ist, zeigt sich in den allgemeinen Informationen des Zertifikats durch ein Schlüsselsymbol.
Offene, nicht abgeschlossene Anforderungen sind in der Zertifikatsverwaltung im Abschnitt Zertifikatregistrierungsanforderungen zu finden.
Als Verwalter einer internen PKI oder als Berechtigter zur Ausstellung von Zertifikaten, geht man mittels Browser auf das Web Interface der eigenen CA (https://ca-server/certsrv/). Auf der Webseite klickt man auf Request a certificate.
Anschließend navigiert man zur Anforderungseite über den Link Submit a certificate request[…].
Den kompletten Inhalt des CSR, die Datei kann mit jedem Texteditor geöffnet werden, überträgt man in das Formular, wählt die gewünschte Zertifikatsvorlage aus und schickt die Anfrage ab.
War der Vorgang erfolgreich, wird das signierte Zertifikat zum Download angeboten, welches dann an den Anforderer zurückgeschickt oder importiert werden kann.
Alternativ zum Web Enrollment, können CSR direkt über die CA Managenment Konsole oder mittel certreq.exe signiert werden.
Content retrieved from: https://www.privalnetworx.de/create-san-certificate.
If you try to convert / upgrade Windows Server Evaluation to a licensed full edition using the normal command line or the CHANGE KEY GUI, you will see errors like: The product key you entered didn’t work, Check the product key and try again or enter a different one
Fortunately, there is an easy fix. You have to change Windows Server Eval editions to a production licensed versions of Standard or Data Center:
The most obvious reason for converting to Core is performance: you get more bang for your buck on the same hardware by reducing unused operating-system components from running. Performance benefits include:
For Fastvue Reporter running as a syslog server, the uptime is vital because messages can be missed and only caught much later when the historical log archive rolls over at midnight. The more stable and robust your platform is, the lower the potential for lost log data.
The additional performance gains and improved uptime is nice, but even without these benefits, some still prefer to run Core from a security perspective. Having less code and tools on a system makes it harder to attack, and once compromised, it makes it less useful to the attacker.
Security benefits of this switch include:
There are many compelling reasons to switch from Full GUI to Core, but the question that comes up most often involves management. „How would I manage the switch to Core?“. This is normally followed closely by „My staff only know how to use the GUI. What if we need need it for some reason?“.
Back in Windows Server 2008, you selected whether you want Core or Full GUI. It was a one-way trip.
But now in Windows Server 2012, you have the option of switching between modes. Depending on how you switch, your experience is either simple, or requires a bit more time and effort.
I am going to show you how to switch between Windows Server Core Mode and the full GUI mode the easy way, Based on my several years of experience to figuring out the „best way“ of doing it.
The steps include:
I am going to configure my Fastvue Reporter Server as a Hyper-V Virtual Machine with dynamic RAM in order to take advantage of the reduced requirements of Windows Core Mode.
Fastvue Reporter is a good candidate for virtualisation and running Windows Core Mode because of its predictable CPU and RAM requirements. It is also more resource-hungry when other servers are typically not because Fastvue Reporter generates reports on a schedule at midnight each day, week, and end of the month.
This works best on host and guest OS of Windows Server 2012 R2. To configure your server:
You may also like to see our article on Understanding Hyper-V Dynamic Memory (Dynamic RAM).
Don’t worry. Switching from the full GUI to Windows Core Mode is a reversible step. You can always bring the GUI back.
There are two ways to remove the GUI and switch to Core Mode:
I recommend using PowerShell, as when you use the ‚Remove Roles and Features‘ wizard, it also removes all the binary components instead of simply disabling them. This makes switching back to the full GUI version much more difficult as you need to provide the installation source media.
To switch to Windows Core Mode using PowerShell, open a PowerShell Console as Administrator and execute these two commands
Uninstall-WindowsFeature Server-Gui-Shell Uninstall-WindowsFeature Server-Gui-Mgmt-Infra –Restart
The server will reboot and everything will look normal until you log on. When you log on, you get a command shell, nothing more. Welcome to Windows Server Core!
You should be using this method for administering your servers already. If you are not, here is a quick intro to using the Windows Remote Server Administration Tools (RSAT). Various RSAT snap-ins can be added to a machine at any stage.
You can also elect to use a Windows client machine as your management station. If so, download and install the RSAT tools for Windows.
If you ever need to restore the GUI onto the server, simply reverse the commands we issued earlier at any stage. This works because we did not explicitly use the –Remove flag, like the GUI method would have.
You can do this remotely or by logging onto the server and using the following steps:
To switch back to Full FUI mode, open a PowerShell Console as Administrator and execute these commands:
Install-WindowsFeature Server-Gui-Shell, Server-Gui-Mgmt-Infra –Restart
Then wait for reboot.
Your machine will now boot back with the full Windows GUI.
Using Windows Server Core for back-end infrastructure without requiring a user to login on a console is a great way to maximise your performance on a shared infrastructure. Thanks to the tools available now, it is easier than ever to manage Core through PowerShell or remotely via RSAT.
Using the PowerShell method in this article makes switching back and forth between Core and GUI simple.
To convert a PFX file to a PEM file that contains both the certificate and private key, the following command needs to be used:
# openssl pkcs12 -in filename.pfx -out cert.pem -nodes
We can extract the private key form a PFX to a PEM file with this command:
# openssl pkcs12 -in filename.pfx -nocerts -out key.pem
Exporting the certificate only:
# openssl pkcs12 -in filename.pfx -clcerts -nokeys -out cert.pem
Removing the password from the extracted private key:
# openssl rsa -in key.pem -out server.key
enable ping requests on Windows.
CMD als Admin:
netsh advfirewall firewall add rule name=“ICMP Allow incoming V4 echo request“ protocol=icmpv4:8,any dir=in action=allow
There are a couple of ways to open the blocked ping request in Windows 10 by configuring a firewall. It can be using the graphical user interface or via the command line PowerShell or centrally via group policies. By default, Windows 10 not allows other computers in the network to ping due to security concerns. After all, the service is often misused for attacks, preferably for denial-of-service attacks, thus Microsoft decided to turn it off, out of the box.
Well, still many times we need the pining facility to solve the network connectivity problems and for that newbies usually turn off the Firewall completely. However, we can manually allow Windows 10 Ping in its firewall, whereas those who concern about security risks they can mitigate it by activating the predefined firewall rule only for the domain profile or by restricting permissible requests to certain IP addresses.
One of the easiest ways to allow ping is by activating the pre-configured firewall in Windows via a graphical user interface with the help of the Advanced Security option. However, you should have admin access to enable or disable firewall rules. Here are the steps to follow:
Furthermore, if you want to secure pining by restricting it to some particular IP address then after enabling the rule, again right-click on the same and select Properties.
In the Properties dialog select the Scope Tab and to restrict all clients from sending ping requests, click on the Add button and mentioned the Remote IP Address of the only those machines that you want to allow to ping your Windows 10 PC. If there are several NICs on the computer, it is also possible to use local IP addresses to specify those to which requests are allowed.
Those who don’t want to use the GUI method because of the multiple steps involved to allow Ping on Windows can go for command-line one. In which, we just need to run Powershell or Command prompt with Administrative right and after that copy-paste the command given here.
netsh advfirewall firewall add rule name=“ICMP Allow incoming V4 echo request“ protocol=icmpv4:8,any dir=in action=allow
In the same way, if you want to disable Windows 10 Ping then use this command:
netsh advfirewall firewall add rule name=“ICMP Allow incoming V4 echo request“ protocol=icmpv4:8,any dir=in action=block
Content retrieved from: https://www.how2shout.com/how-to/allow-windows-10-ping-through-firewall-gui-powershell-netsh-command.html.
Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.