Dunkelmann

Moin, Option 41 steht für EDNS (Extended DNS). Bei einem MS DNS Server ist diese Option standardmäßig aktiviert und nutzt DNS Pakete > 512 byte. Manche Firewalls/Router haben damit Probleme. Bei einigen kann die Inspection Rule ('strict DNS' o.s.ä) entsprechend angepasst werden. Alternativ kann am MS DNS extended DNS deaktiviert werden. https://technet.microsoft.com/de-de/library/cc772069%28v=ws.10%29.aspx

Moin, ganz so trivial ist es nicht. Eine PKI wird auf 10 oder mehr Jahre geplant. Es sollte vorher genau überlegt werden, welche Teilnehmer aktuell und zukünftig die PKI nutzen sollen bzw. nutzen werden. Ein falscher Hashalgorythmus der Root CA ist schnell gewählt und in ein paar Wochen oder Jahren sitzt man da und darf noch mal von vorne anfangen. Bei der Laufzeit sollten auch Migrationen von Hardware und OS betrachtet werden. Wenn es nur um ein Zertifikat für den Exchange geht, würde ich das Thema lassen und einfach ein paar Euros für ein kommerzielles Zertifikat ausgeben. Die Betriebskosten einer PKI liegen deutlich über den € 30,- bis € 60,- p.a.

Mit ein bischen lesen und etwas experimentieren ist es nicht getan. Eine PKI besteht zu 95% aus Organisation und nur zu 5% aus Technik. Was Du mit welchen Zertifikaten anstellst bzw. anstellen kannst, sollte vor der Inbetriebnahme durch ein CPS (Certificate Practice Statement) definiert werden. Ergänzend können ggf. technische Hilfsmittel zur Erzwingung eingesetzt werden. (Z.Bsp. HSM, Rollentrennung) Grundsätzlich sollte das CA Zertifikat - egal ob Root CA oder Policy/Issuing CA - nur zur Signatur anderer Zertifikate verwendet werden. Der Private Schlüssel des CA Zertifikats sollte nur für CA-spezifische Aufgaben und nicht für allgemeine Anwendungen/Dienste eingesetzt werden. Für allgemeine Dienste sollten entsprechende Zertifikate mit dem geeigneten Verwendungszweck ausgestellt werden. (Serverauthentifizierung, IPSec Tunnelabschluss usw. usf.)

Dann weist Du jetzt warum man sich bei Übergabe eine Dokumentation aushändigen lässt ;) Erst mal die schlechte Nachricht: Ohne Zertifikat kein 802.1x und ohne PKI wird es noch viel lästiger und aufwändiger. Jetzt sollte überlegt werden: PKI oder weiter frickeln (Bedenken: die nächste Migration kommt bestimmt) Egal wie es weitergeht: die Clients müssen vermutlich alle mindestens ein mal per Kabel verbunden werden ... Nun gilt herauszufinden, wie das Zertifikat vom alten Radius an die Clients verteilt wurde. (z.Bsp. GPO, Skript, manuell) Das Zertifikat vom alten Radius sollte auf jeden Fall als nicht vertrauenswürdig eingestuft werden. Der Radius benötigt ein eigenes Zertifikat (für Serverauthentifizierung) - selbstsigniert oder aus einer PKI Ist es selbstsigniert, muss das Zertifikat des neuen Radius an alle Clients verteilt werden; kommt es aus einer PKI reicht es das Root Zertifikat zu verteilen - am einfachsten übers AD Vielleicht geht es schneller, wenn ihr euch einen Dienstleister sucht. Eine PKI stampft man nicht so eben aus dem Boden; selbstsignierte Zertifikate sind nur eine quick and dirty Lösung und verursachen am Ende nur mehr Aufwand.

Moin, es gibt von MS ein TLG für eine kleine PKI. https://technet.microsoft.com/en-us/library/hh831348.aspx Das ist allerdings nur ein Funktionsmuster zum spielen und kann nicht zwangsläufig 1:1 in einer Produktivumgebung umgesetzt werden. Das Buch 'PKI & Certificate Security' von Brian Komar bietet etwas mehr Hintergrund. Bei einer Lebensdauer von 10 oder mehr Jahren, sollte eine PKI sorgfältig geplant und getestet werden. Es gibt auch Dienstleister, die man für diesen Zweck anheuern kann ;)

Moin, das Serverzertifikat kommt idealerweise von der einer Unternehmens CA. Woher stammt das Zertifikat des alten Radius/NPS?

Suchmaschinen werden überbewertet :cry: https://technet.microsoft.com/de-de/library/cc733145%28v=ws.10%29.aspx

Moin, ich würde noch den Switch '/zb' hinzufügen.

Mit 802.1x ist es wie mit fast jeder Technik - wenn es läuft ist alles toll, wenn es Probleme gibt, sollte das notwendige Know How kurzfristig verfügbar sein. Eine vernünftige 802.1x Implementierung benötigt eine funktionierende und ggf. hochverfügbare PKI. Es kann im Support schon lustig werden wenn ein paar hundert oder ein paar tausend Clients sich nicht verbinden können, weil jemand vergessen hat das Radius/NPS Zertifikat zu erneuen oder der CDP offline ist.

Moin, die allseits beliebte Frage: Welche Anforderungen sind umzusetzen? MAC Filter und dhcp fallen mMn grundsätzlich durch. Hier kann der sogenannte Sicherheitsmechanismus am Endgerät ausgehebelt werden und disqualifiziert sich damit. Bei 802.1x (inkl. WiFi PEAP) und IPSec gibt es eine höhere Hürde. Support und Troubleshooting können dafür deutlich anspruchvoller werden. Das sollte bei der Implementierung beachtet werden.

Moin, zur Netzwerkkennung gehören auch die passenden Firewallregeln. Geht natürlich auch per GPO; unter Windows Einstellungen/Sicherheit. PS: gpedit.msc liefert keine Ergebnisse angewendeter Gruppenlichtlinien, sondern konfiguriert lokale Richtlinien

Moin, damit ich es richtig verstehe: Du hast einen Client als DFS-N Ordnerziel eingerichtet?

Man kann die Root CA samt crl schon im AD veröffentlichen; durch die AD Replikation gibt es damit für Interne einen hochverfügbaren CDP ohne viel Arbeit. Ein AD unabhängiger CDP, möglichst intern und extern erreichbar, sollte natürlich existieren. certutil -dspublish kommuniziert mit einem DC und nicht mit der CA. Hier solltest Du ansetzen und mal die DCs prüfen (DNS, Replikation usw. - nicht die Firewall auf dem DC abschalten ;) ) Ich hoffe Du hast bei der Root CA daran gedacht, die CDP im ldap einzurichten.

Bei einer eigenständigen Root CA muss die Anforderung manuell eingereicht werden. Ganz grob sieht es so aus: Anforderung (CSR) als Datei speichern und auf die Root übertragen auf der Root über das mmc Zertifizierungsstelle eine neue Anforderung einreichen genehmigen Zertifikat der Sub CA speichern und die Datei auf die Sub CA übertragen Auf der Sub CA über das mmc Zertifizierungsstelle die Anforderung abschließen Fertig

Wenn nur die lästige Arbeitssicherheit nicht wäre, könnte IT noch mehr Spass machen :cool:

Moin, ist die Root CA eine Enterprise oder eigenständige? PS: Firewall richtig konfigurieren anstatt abschalten ;)

Moin, eventuell mal den 5nine Manager for Hyper-V ausprobieren. http://www.5nine.com/5nine-manager-for-hyper-v-free.aspx

Moin, Brian Komar: PKI & Certificate Security wäre für's Selbststudium ein guter Einstieg.

Moin, welche Rollen und Features benötigt werden, kann der jeweiligen Programmdokumentation entnommen werden. Off-Topic: Bist Du Dir sicher, dass Du das Thema beherrscht?Falls es immer noch um die Arztpraxis gehen sollte, empfehle mal einen Blick in die Empfehlungen der Bundesärztekammer zum Thema Schweigepflicht, IT und Datenschutz. http://www.bundesaerztekammer.de/richtlinien/empfehlungenstellungnahmen/schweigepflichtdatenschutz/ ab Seite 7

Moin, wenn die Lizenz ein Downgraderecht beinhaltet, kannst Du Dich an das Activation Center wenden. https://www.microsoft.com/en-us/licensing/existing-customer/activation-centers.aspx

Moin, warum noch SQL 2012 und nicht gleich SQL 2014?

Der Downloadbereich des Hökers sieht auch sehr seriös aus. https://www.pos-outlet.de/downloads

Kann man doch ;) Eine Root CA gehört weder auf einen DC noch auf ein Member. Eine Root CA gehört offline.

Moin, darf der Benutzer Zertifikate auf Basis der gewünschten Vorlage anfordern?

Moin, ich werf mal einen Stratus ftServer in die Runde. http://www.stratus.com/solutions/platforms/ftserver/