Radius Server Zertifkat

[Gast new_guy04]

Moin,

ich habe ein Problem zwecks Radius, besser gesagt beim Import des Zertifikats auf dem DC.

Wir haben am Standort zwei DCs (2008R2) und einen aktuellen Radius-Server (2012R2). Alle Server befinden sich im selben Subnetz. Im Rahmen eines Projekt wird der Radius-Server durch einen 2019er abgelöst.

Auf der neuen Umgebung (SAN,ESX) haben wir einen Server anhand einer Vorlage eingerichtet, sysprep, die entsprechenden Rollen hinzugefügt und ihn in die Domäne gehoben. Die Netzwerkrichtlinie wurde vom alten Radius-Server 1 zu 1 übernommen, ein neuer geheimer Schlüssel angelegt und auch auf der Sonic Wall hinterlegt. Ebenso wurde auf der Sonic Wall der neue Radius-Server hinterelgt, damit die Kommunikation zu ihm stattfindet.

Die Kommunikation zwischen Sonic Wall und dem neuen Radius funktioniert bereits einwandfrei, dies ist in den Logs ersichtlich Auf dem neuen Radius haben wir ein Zertifikat für 801.X erstellt, das hierzu genutzt wird und es exportiert. Das Zertifikat nutzt RSA 4096 Bit. Natürlich muß die GPO auf einem der DCs dementsprechend angepasst werden, sodass der neue Radius und das neue Zertifikat genutzt wird. 

Das auf dem neuen Radius erstellte und exportierte Zertifikat habe ich auf einem der DCs importiert, der Vorgang wird auch als erfolgreich zurückgemeldet. Jedoch taucht das Zertifikat in der Konsole nicht auf, und daher kann ich es auch in der GPO nicht hinzufügen. Das ist aktuell der Knackpunkt warum die Clients sich mit dem WLAN nicht verbinden können. Ich habe bereits nach KB Artikeln gesucht, konnte jedoch keine Informationen finden. Läuft der exportierte Schlüssel nicht, weil der Sprung zwischen 2019 und 2008R2 zu groß oder wegen 4096 bit?

 

[Gast new_guy04]

Noch ein Hinweis:

 

Auf dem alten Radius-Server habe ich das Zertifikat gefunden,das bisher genutzt wurde. Dieses läuft Ende Mai aus und ist durch einen der DC für den alten Radius-Server ausgestellt worden. Vielleicht ist das auch schon der Fehler.

[Maniska]

vor 11 Stunden schrieb Gast new_guy04:

Wir haben am Standort zwei DCs (2008R2) und einen aktuellen Radius-Server (2012R2). Alle Server befinden sich im selben Subnetz. Im Rahmen eines Projekt wird der Radius-Server durch einen 2019er abgelöst.

Ich würde im ersten Schritt die beiden DCs auf Server 2019 wuppen und danach von einem der neuen DCs das Zertifikat für den neuen RADIUS erstellen.

Bzw für "schön" eine anständige PKI Infrastruktur basteln...

vor 11 Stunden schrieb Gast new_guy04:

Auf der neuen Umgebung (SAN,ESX) haben wir einen Server anhand einer Vorlage eingerichtet, sysprep, die entsprechenden Rollen hinzugefügt und ihn in die Domäne gehoben.

Wenn die Template Geschichte unter vmWare anständig konfiguriert ist, muss man weder Sysprep ausführen noch das Ding in die Domäne jucken, das macht der alles beim Erstellen der VM automatisch (wenn man das möchte).

[Gast new_guy04]

Vielen Dank für deine Antwort. Auch wenn auf die zentrale Frage keine Vorschläge oder Hinweise erfolgten.

 

Zwecks PKI-Infrastruktur gebe ich dir aus technischer Sicht vollkommen recht. Doch im Rahmen des Projekts, neue Server-Infrastruktur und Erneuerung der Server (2008R2 und 2012) auf 2019 anzuheben ist PKI vorerst nicht vorgesehen gewesen. Zumal der eine Kunde aktuell noch sein eigenes WLAN nutzt. Zukünftig ist jedoch geplant im Verbund mit anderen Schwestern-Firmen das an allen Standorten die gleichen SSIDs vorhanden sind (Hamburg, München, Frankfurt) und PKI im Einsatz sein wird. Das setzt aber eine einheitliche Infrastruktur voraus, an der wir aktuell arbeiten. Es muß alles kaufmännisch und ressourcentechnisch eingeplant werden, nicht meine Baustelle.

Zu meiner ursprünglichen Frage gab es deinerseits keine Antwort, denn es ging ja prinzipiell um das Zertifikat. Der Fehler wurde behoben und wie schon von mir vermutet war die Ausstellung des Zertifikats falsch. Ich habe dieses daher gelöscht.

Ich habe auf dem neuen Radius-Server einen CSR angefordert (RSA 2048 bit, SHA256) und diesen auf einem DC entsprechend bestätigt und ein Zertifikat erstellt. Dieses Zertifikat habe ich dann auf dem Radius-Server importiert und in NPS entsprechend eingebunden. Nun war es auch möglich die GPO entsprechend anzupassen, sodass das korrekte Zertifikat genutzt und an die Clients verteilt wird.

Ein Test-Zugriff von einem Client auf das WLAN nach einem GPUPDATE lief erfolgreich durch. Eine Hürde gab es jedoch beim CSR auf dem DC (Denied by Policy Module 0x80094801). Das Template mußte meinerseits unter Subject angepasst werden. MMC Zertifikats-Template EAP/PEAP. Das Thema kann damit als Gelöst betrachtet werden.