9
WLAN 802.1X PEAP EAP MSchapv2 IAS Radius Serverzertifikat CN muss mit DNS bzw Hostname des IAS übereinstimmen?
Hallo,
wenn ich auf einem IAS Radius Server für WLAN Authentisierung via PEAP/EAP-MSchap-v2 ein Serverzertifikat verwende, MUSS das CN Attribut im Serverzertifikat mit dem tatsächlichen DNS/Hostnamen des IAS RAdiusservers übereinstimmen?
Wir verwenden hierfür Verisign WLAN Server Zertifikat da das Verisign Root CA Zertifikat bereits auf allen gängigen Clients installiert ist.
Nun will ich für einen Backup Radius nicht nochmal das Verisign Zertifikat kaufen müssen.
Irgendwie klappt es aber nicht, der einzige KOnfigurationsunterschied scheint zu sein dass der Backup-Radius Hostname nicht zum installierten Verisign Zertifikat CN (Common Name) zusammenpasst.
Ansonsten werf ich mal Wireshark an und schaue ob der Client überhaupt versucht den DNS Namen aufzulösen.
Kann er aber eigentlich garnicht, da der Client ja VOR ERFOLGREICHER Authentisierung garkeine IP-Adresse hat und somit auch garkeinen DNS Server abfragen kann.
Wenn ich auf dem Client Endgerät die Option "Serverzertifikat überprüfen" DEAKTIVERE in den WLAN Adapter Einstellungen, KLAPPT die Authentisierung, also scheint der Client dem Radius Serverzertifikat nicht zu trauen, obwohl der Client das Root Zertifikat von Verisign installiert hat und dem Serverzertifikat eigentlich vertrauen müsste.
Gruss, spacyfreak
wenn ich auf einem IAS Radius Server für WLAN Authentisierung via PEAP/EAP-MSchap-v2 ein Serverzertifikat verwende, MUSS das CN Attribut im Serverzertifikat mit dem tatsächlichen DNS/Hostnamen des IAS RAdiusservers übereinstimmen?
Wir verwenden hierfür Verisign WLAN Server Zertifikat da das Verisign Root CA Zertifikat bereits auf allen gängigen Clients installiert ist.
Nun will ich für einen Backup Radius nicht nochmal das Verisign Zertifikat kaufen müssen.
Irgendwie klappt es aber nicht, der einzige KOnfigurationsunterschied scheint zu sein dass der Backup-Radius Hostname nicht zum installierten Verisign Zertifikat CN (Common Name) zusammenpasst.
Ansonsten werf ich mal Wireshark an und schaue ob der Client überhaupt versucht den DNS Namen aufzulösen.
Kann er aber eigentlich garnicht, da der Client ja VOR ERFOLGREICHER Authentisierung garkeine IP-Adresse hat und somit auch garkeinen DNS Server abfragen kann.
Wenn ich auf dem Client Endgerät die Option "Serverzertifikat überprüfen" DEAKTIVERE in den WLAN Adapter Einstellungen, KLAPPT die Authentisierung, also scheint der Client dem Radius Serverzertifikat nicht zu trauen, obwohl der Client das Root Zertifikat von Verisign installiert hat und dem Serverzertifikat eigentlich vertrauen müsste.
Gruss, spacyfreak
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 187283
Url: https://administrator.de/forum/wlan-802-1x-peap-eap-mschapv2-ias-radius-serverzertifikat-cn-muss-mit-dns-bzw-hostname-des-ias-187283.html
Ausgedruckt am: 22.12.2024 um 11:12 Uhr
9 Kommentare
Neuester Kommentar
Moin,
Soweit ich weiß, sucht der IAS im lokalen Zertifikatsspeicher nach einem Zertifikat, dass entweder dem Lokalen Hostname CN oder subjectaltname entspricht (Gross / Kleinschreibung beachten!). IAS Versucht leider nicht, ein anderes Zertifikat zu nutzen.
Gruesse
Soweit ich weiß, sucht der IAS im lokalen Zertifikatsspeicher nach einem Zertifikat, dass entweder dem Lokalen Hostname CN oder subjectaltname entspricht (Gross / Kleinschreibung beachten!). IAS Versucht leider nicht, ein anderes Zertifikat zu nutzen.
Gruesse
Auf dem IAS hab ich in den RAS Policies das installierte VErisign Certificate eingebundne (RAS Policy... Authentication.. EAP Methods..). Wenn das Cert nciht passen würde, könnte ich es hier erst garnicht auswählen..
Die Frage ist - WER prüft ob das CN des Serverzertifikates mit dem DNS/Hostname des Radiusservers übereinstimmt.
Der Radiusserver selbst - oder der WLAN Client?
Der WLAN Client kann es garnicht prüfen da er ja vor erfolgr. 802.1X Auth keine Netzwerkverbindung hat und damit auch keinen DNS Server erreichen kann.
Die Frage ist - WER prüft ob das CN des Serverzertifikates mit dem DNS/Hostname des Radiusservers übereinstimmt.
Der Radiusserver selbst - oder der WLAN Client?
Der WLAN Client kann es garnicht prüfen da er ja vor erfolgr. 802.1X Auth keine Netzwerkverbindung hat und damit auch keinen DNS Server erreichen kann.
Reden wir von IAS im w2k3 oder vom NPS im w2k8?! Da besteht ein Unterschied.
Zitat aus Technet:
http://technet.microsoft.com/de-de/library/cc759575(v=ws.10).aspx#cert_ ...
Gruesse
Zitat aus Technet:
Bei drahtlosen Clients kann PEAP-EAP-MS-CHAPv2 als Authentifizierungsmethode eingesetzt werden. PEAP-EAP-MS-CHAPv2 ist eine kennwortbasierte Methode zur Benutzerauthentifizierung, die TLS mit Serverzertifikaten einsetzt. Während der PEAP-EAP-MS-CHAPv2-Authentifizierung stellt der IAS- oder RADIUS-Server ein Zertifikat zur Überprüfung seiner Identität für den Client bereit (sofern die Option Serverzertifikat überprüfen auf dem Client unter Windows XP Professional konfiguriert wurde). Die Clientcomputer- und Benutzerauthentifizierung wird anhand von Kennwörtern ausgeführt, wodurch Schwierigkeiten bei der Bereitstellung von Zertifikaten für drahtlose Clientcomputer teilweise beseitigt werden.Gruesse
Yo lieber Dani das hab ich natürlich alles schon im Vorfeld gelesen.
Das Serverzertifikat ist schon wichtig, da ich grade beim WLAN sicherstellen MUSS dass die Clients nur an vertrauenswürdige Radius Server ihre Domaincredentials schicken.
Deaktiviere ich auf dem Client "Serverzert überprüfen" klappt die Authentisierung - doch das ist vom Sicherheitsaspekt nicht vertretbar meines Erachtens.
habe an anderer Stelle eine Info gefunden dass der CN im Serverzert mit dem DNS Namen übereinstimmen muss, ist aber auch nur ein Forenbeitrag, finde es schade dass ich weder bei Verisign noch bei Microsoft explizit die Aussage finde ob der CN im Zert tatsächlich mti dem DNS Namen des IAS Servers übereinstimmen MUSS.
NPS hab ich auch schon installiert, der suckt momentan noch was das logging angeht, da scheint ein bug zu bestehen, sodass er gelegentlich erfolglose oder erfolgreiche Anmeldungen nicht protokolliert, was das Troubleshooting erschwert.
Daher bleibe ich derzeit och bei Server2003 IAS, das läuft ganz ok.
Das Serverzertifikat ist schon wichtig, da ich grade beim WLAN sicherstellen MUSS dass die Clients nur an vertrauenswürdige Radius Server ihre Domaincredentials schicken.
Deaktiviere ich auf dem Client "Serverzert überprüfen" klappt die Authentisierung - doch das ist vom Sicherheitsaspekt nicht vertretbar meines Erachtens.
habe an anderer Stelle eine Info gefunden dass der CN im Serverzert mit dem DNS Namen übereinstimmen muss, ist aber auch nur ein Forenbeitrag, finde es schade dass ich weder bei Verisign noch bei Microsoft explizit die Aussage finde ob der CN im Zert tatsächlich mti dem DNS Namen des IAS Servers übereinstimmen MUSS.
NPS hab ich auch schon installiert, der suckt momentan noch was das logging angeht, da scheint ein bug zu bestehen, sodass er gelegentlich erfolglose oder erfolgreiche Anmeldungen nicht protokolliert, was das Troubleshooting erschwert.
Daher bleibe ich derzeit och bei Server2003 IAS, das läuft ganz ok.
Moin,
denk ich mir... aber ich versteh das so, dass der Client das Zertifikat prüft:
Ist für mich eigentlich eindeutig, oder?!
Grüße,
Dani
denk ich mir... aber ich versteh das so, dass der Client das Zertifikat prüft:
Während der PEAP-EAP-MS-CHAPv2-Authentifizierung stellt der IAS- oder RADIUS-Server ein Zertifikat zur Überprüfung seiner Identität für den Client bereitGrüße,
Dani
Ja warum der RAdius bei Einsatz von PEAP EAP-MSchapv2 ein Serverzertifikat braucht ist mir schon klar - er authentisiert sich damit beim Client als vertrauenswürdiger Radiusserver.
Die Überprüfung ob dieses Zertifikat vertrauenswürdig ist macht der Client anhand des Verisign Root CA Zertifikates, das das Radius Server Zertifikat signiert hat - PKI halt. "Das Root CA Zertifikat, das DIESES Radius-Server Zertifikat SIGNIERT hat, ist in meinem Certstore Vertrauenswürdige Stammzertifizierungsstellen, also kann ich diesem Radius-Server Zertifikat vertrauen" - so funktioniert PKI.
Sonst (wenn der Client das Serverzertifikat des Radius NICHT prüfen würde) könnte der Client ja - ohne es zu merken - seine Credentials auch an einen "rouge" Radius senden, wenn ein findiger Hacker z. B. die selbe Firmen-SSID bereitstellt mit seinem eigenen Radius-Server.
Alle Clients die in Nähe des Hacker-Access-Points kämen würden automatisch ihre AD-Credentials bzw. die Hashes ihrer Passwörter zu dem Radius-Server des Angreifers schicken - ist nicht so der Hit in einer Konzern Netzwerkumgebung glaub ich..
Mir ist nur nicht klar ob Serverzertifikat CN Name mit dem DNS Namen des Radiusservers übereinstimmen MUSS.
Sieht jedoch ganz danach aus.
Doch WIE soll ein WLAN Client einen DNS Aufruf machen, wenn er noch garkeine Netzwerkverbindung hat? Die Netzwerkverbindung wird ja erst nach ERFOLGREICHER
Authentisierung freigeschaltet, also KANN der Client beim Authentisierungsvorgang den DNS Namen des RAdiusservers garnicht auflösen!
Die Überprüfung ob dieses Zertifikat vertrauenswürdig ist macht der Client anhand des Verisign Root CA Zertifikates, das das Radius Server Zertifikat signiert hat - PKI halt. "Das Root CA Zertifikat, das DIESES Radius-Server Zertifikat SIGNIERT hat, ist in meinem Certstore Vertrauenswürdige Stammzertifizierungsstellen, also kann ich diesem Radius-Server Zertifikat vertrauen" - so funktioniert PKI.
Sonst (wenn der Client das Serverzertifikat des Radius NICHT prüfen würde) könnte der Client ja - ohne es zu merken - seine Credentials auch an einen "rouge" Radius senden, wenn ein findiger Hacker z. B. die selbe Firmen-SSID bereitstellt mit seinem eigenen Radius-Server.
Alle Clients die in Nähe des Hacker-Access-Points kämen würden automatisch ihre AD-Credentials bzw. die Hashes ihrer Passwörter zu dem Radius-Server des Angreifers schicken - ist nicht so der Hit in einer Konzern Netzwerkumgebung glaub ich..
Mir ist nur nicht klar ob Serverzertifikat CN Name mit dem DNS Namen des Radiusservers übereinstimmen MUSS.
Sieht jedoch ganz danach aus.
Doch WIE soll ein WLAN Client einen DNS Aufruf machen, wenn er noch garkeine Netzwerkverbindung hat? Die Netzwerkverbindung wird ja erst nach ERFOLGREICHER
Authentisierung freigeschaltet, also KANN der Client beim Authentisierungsvorgang den DNS Namen des RAdiusservers garnicht auflösen!
WLAN 802.1X PEAP EAP MSchapv2 IAS Radius Serverzertifikat CN muss mit DNS bzw Hostname des IAS übereinstimmen?
Nein, das ist Schnurz.
Diese Übereinstimmung ist bei Webseiten wichtig, weil so die Gültigkeit vom Zertifikat bestimmt wird.
Bei WLAN hätte man sowas höchstens über die SSID machen können, wird es aber nicht.
Da der Client also den Namen gegen nichts prüfen kann ist er auch egal.
Du kannst am Client lediglich vorgeben, dass er nur Zertifikate mit einem bestimmten Namen und CA für diese SSID akzeptieren soll.
obwohl der Client das Root Zertifikat von Verisign installiert hat und dem Serverzertifikat eigentlich vertrauen müsste.
Sowas passiert gerne mal wenn dir Zertifikate im Chain fehlen.
Das kannst du prüfen indem du auf dem Server mal den IIS installierst und über HTTPS von diesem Client aus ansprichst.
Hast du das Zertifikat auch im Computerspeicher (nicht Benutzerspeicher) importiert?
Sehe ich ebenso.
Ja mit der Trust Chain habe ich geprüft, die notwendigen Root- u. Intermediate Zertifikate sind überall drauf. Ich kann mir keinen Reim drauf machen.
Ja mit der Trust Chain habe ich geprüft, die notwendigen Root- u. Intermediate Zertifikate sind überall drauf. Ich kann mir keinen Reim drauf machen.
Des Rätsels Lösung - das Intermediate Zertifikat von Verisign musste ich exportieren und wieder importieren, dann ging es, obwohl der DNS/Hostname des Radius-Servers nicht mit dem CN im Radius-Server Cert übereinstimmt.
