14
EAP-TLS Problem mit Zertifikat
Server Rejected Identiy. Verstehe nicht wieso.
Hi ihr lieben Leute,
ich bin zur Zeit daran eine Versuchsumgebung aufzubauen.
Habe auf dem Windows Server 2003 IIS, IAS (als Radiusserver), CA und AD installiert.
Eine Domäne angelegt, Benutzer angelegt, Richtlinien festgelegt.
Switch ist von Cosco Catalyst 6509. auch Schon konfiguriert für 802.1x.
Alles so wie es sein sollte.
Mit meinem Supplicanten (Notebook) (den ich auch auf tls eingestellt habe kann ich mich aber nicht am netzwerk anmelden.
Ich habe über ein anderes Vlan ein Zertifikat erteilen lassen und es installiert. ( natürlich ert nach anmeldung des benutzers wie ich ihn unter AD angelegt hatte) (indiesem fall Karlheinz) also als Karl heinz habe ich mir ein Benutzerzertifikat austellen lassen. es installiert. das root zertifikat des servers habe ich zuvor exportiert und auf meinem supplicanten installiert.
hat jemand ne idee was ich falsch gemacht haben könnte?
paralel hierzu habe ich einen 2ten Server als Radius-Server konfiguriert...aber mit Cisco ACS 3.1 als Radius-Server. (also ohne AD und IAS)...hier bei komme ich um 4 schritte weiter als mit dem IAS-Radiusserver.
der Switch verlangt die identity des Clients (gemeint ist supplicant) um sie während er den client warten lässt an den server weiterzuleiten.
der client (supplicant) schickt dies.
aber die identyity schmeckt dem Server nicht. und daher rejectedt er die identy und somit ist der zugang versperrt.
bei der variante mit dem cisco acs akzeptiert er die identy der bittsteller (supplicanten) akzeptiert aber das zertifikat beim handshake später nicht.
wäre super wenn jemand ne idee haben könnte.
Danke im voraus an alle.
musa
Hi ihr lieben Leute,
ich bin zur Zeit daran eine Versuchsumgebung aufzubauen.
Habe auf dem Windows Server 2003 IIS, IAS (als Radiusserver), CA und AD installiert.
Eine Domäne angelegt, Benutzer angelegt, Richtlinien festgelegt.
Switch ist von Cosco Catalyst 6509. auch Schon konfiguriert für 802.1x.
Alles so wie es sein sollte.
Mit meinem Supplicanten (Notebook) (den ich auch auf tls eingestellt habe kann ich mich aber nicht am netzwerk anmelden.
Ich habe über ein anderes Vlan ein Zertifikat erteilen lassen und es installiert. ( natürlich ert nach anmeldung des benutzers wie ich ihn unter AD angelegt hatte) (indiesem fall Karlheinz) also als Karl heinz habe ich mir ein Benutzerzertifikat austellen lassen. es installiert. das root zertifikat des servers habe ich zuvor exportiert und auf meinem supplicanten installiert.
hat jemand ne idee was ich falsch gemacht haben könnte?
paralel hierzu habe ich einen 2ten Server als Radius-Server konfiguriert...aber mit Cisco ACS 3.1 als Radius-Server. (also ohne AD und IAS)...hier bei komme ich um 4 schritte weiter als mit dem IAS-Radiusserver.
der Switch verlangt die identity des Clients (gemeint ist supplicant) um sie während er den client warten lässt an den server weiterzuleiten.
der client (supplicant) schickt dies.
aber die identyity schmeckt dem Server nicht. und daher rejectedt er die identy und somit ist der zugang versperrt.
bei der variante mit dem cisco acs akzeptiert er die identy der bittsteller (supplicanten) akzeptiert aber das zertifikat beim handshake später nicht.
wäre super wenn jemand ne idee haben könnte.
Danke im voraus an alle.
musa
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: 95713
Url: https://administrator.de/forum/eap-tls-problem-mit-zertifikat-95713.html
Ausgedruckt am: 23.12.2024 um 01:12 Uhr
14 Kommentare
Neuester Kommentar
Hat denn der Radiusserver das Stammzertifikat der ausstellenden Root CA im Certstore "vertrauenswürdige Stamm-ertifizeriungsstellen" ? Was sagt der System Eventlog auf dem IAS Server?
Vielleicht probierst erstmal das (einfachere) PEAP (EAP-MSCHAP-v2) und wenn das klappt dann weitermachen.
Vielleicht probierst erstmal das (einfachere) PEAP (EAP-MSCHAP-v2) und wenn das klappt dann weitermachen.
Ja das Root-Zertifikat ist unter "Vertrauenswürdige Stammzertifizierungsstellen"
Ich weiss leider nicht wie ich auf den Eventlog vom IAS Server komme.
meinst du etwa im folgenden Verzeichnis? :
C:\WINDOWS\system32\LogFiles die protokoll dateien?
da steht nichts dazu.
Über Whireshark erhalte ich meine einzigen Anhaltspunkte.
Ich bin schon soweit gekommen mit dem TLS, meinst du wirklich ich sollte nun das zur Seite schieben und peap machen?
Wenn ich bloss hier jemanden hätte der sich das mal anschauen könnte vor ort...im raum frankfurt...hier ist aber niemand
drehe noch durch.
Ich weiss leider nicht wie ich auf den Eventlog vom IAS Server komme.
meinst du etwa im folgenden Verzeichnis? :
C:\WINDOWS\system32\LogFiles die protokoll dateien?
da steht nichts dazu.
Über Whireshark erhalte ich meine einzigen Anhaltspunkte.
Ich bin schon soweit gekommen mit dem TLS, meinst du wirklich ich sollte nun das zur Seite schieben und peap machen?
Wenn ich bloss hier jemanden hätte der sich das mal anschauen könnte vor ort...im raum frankfurt...hier ist aber niemanddrehe noch durch.
Ich Versuche grad logdateien mit IAS Log Viewer zu erstellen.
Aber das Programm rall ich nicht...wie soll ich denn da die Events mitschneiden?
Also in der Ereignisanzeige von Windows habe ich nun folgendes gefunden:
"
Von der ungültigen RADIUS-Client-IP-Adresse 192.168.1.1 wurde eine RADIUS-Meldung empfangen.
"
jetzt frage ich mich wieso der meint die radiusclientadresse 192.168.1.1 sei ungültig??
hmm...ich habe den radius client angelegt mit der ip adresse 192.168.1.1...ich schau mal nochmal drüber.
Aber das Programm rall ich nicht...wie soll ich denn da die Events mitschneiden?
Also in der Ereignisanzeige von Windows habe ich nun folgendes gefunden:
"
Von der ungültigen RADIUS-Client-IP-Adresse 192.168.1.1 wurde eine RADIUS-Meldung empfangen.
"
jetzt frage ich mich wieso der meint die radiusclientadresse 192.168.1.1 sei ungültig??
hmm...ich habe den radius client angelegt mit der ip adresse 192.168.1.1...ich schau mal nochmal drüber.
Ok Leute,
Sorry
aber einer meiner Kollegen hat die Konfig auf dem testswicth umgespielt und ich muss jetzt alles auf dem switch neue konfigurieren.
das ist das blöde wenn ein switch zum testen für mehrer bereitsteht und man so doof ist wie ich und keine sicherung gemacht hat
also...bis montag mach ich das...und hoffe es funktioniert dann.
Der Radius client wird dadurch nicht aufgelöst, nicht erkannt.
ich schreibe Montag wie es voranging.
danke an alle
Sorry
aber einer meiner Kollegen hat die Konfig auf dem testswicth umgespielt und ich muss jetzt alles auf dem switch neue konfigurieren.
das ist das blöde wenn ein switch zum testen für mehrer bereitsteht und man so doof ist wie ich und keine sicherung gemacht hat
also...bis montag mach ich das...und hoffe es funktioniert dann.
Der Radius client wird dadurch nicht aufgelöst, nicht erkannt.
ich schreibe Montag wie es voranging.
danke an alle
Die IAS Logs die ich meine findest du in der Ereignisanzeige deines Radiusservers! Unter System protokolliet der Radiusdienst erfolgreiche oder erfolglose Auth-Versuche sowie Fehler.
rechtsklick auf "Arbeitsplatz", "Verwalten", "Ereignisanzeige". Die hast du doch bestimmt schonmal gesehen, oder?
IAS-Logviewer ist ein super Tool. Du musst im IAS unter Logging einfach den Pfad angeben, z. B. auf den Desktop des Radiusservers, wo die Logs abgelegt werden sollen.
Mit IAS-Logviewer kannst du diese Textdatei dann öffnen und siehst total übersichtlich wer sich wann erfolgreich oder eben nicht erfolgreich anmelden konnte.
Ich würd dir gern bei dem Probl helfen, hab jedoch grad viel Arbeit. Grübel.
rechtsklick auf "Arbeitsplatz", "Verwalten", "Ereignisanzeige". Die hast du doch bestimmt schonmal gesehen, oder?
IAS-Logviewer ist ein super Tool. Du musst im IAS unter Logging einfach den Pfad angeben, z. B. auf den Desktop des Radiusservers, wo die Logs abgelegt werden sollen.
Mit IAS-Logviewer kannst du diese Textdatei dann öffnen und siehst total übersichtlich wer sich wann erfolgreich oder eben nicht erfolgreich anmelden konnte.
Ich würd dir gern bei dem Probl helfen, hab jedoch grad viel Arbeit. Grübel.
Hi Spacyfreak,
zunächst mal danke
Also bei meinem versuchsaufbau mit IAS als Radius-Server habe ich durch deinen tip die Ereignisanzeige von Windows anzusehen am samstag ja schon gesehen dass der Radius Server den Radius-Client (also den switch bzw.Authenticator) nicht auflöste.
Ich hatte den Namen und änderte es indem ich die IP Adresse direkt nannte. Dadurch war eine Verifizierung des Authenticators möglich.
Also Akzeptiert der Server nun die eingehenden Daten weil er den Authenticator als Radius-Client versteht.
Nun Habe ich aber ein anderes Problem.
Und zwar Kommunizieren der Supplicant (mein Notebook) und der Server zwecks der Authentifizierung.
Das TLS protokoll läuft vim ersten Schritt bist zum SUCCESS -Signals des Servers einwandfrei.
Die Erignisanzeige auf dem Server gibt folgendes aus: "Benutzer "Yilmaz@Radius0.Diplom.de" wurde Zugriff gewährt."
Unter Whireshark ebenfalls ein finales "accept" bzw ein "success".
also müsste mein Notebook den server oder switch doch eigentlich anpingen können da der port nun freigeschaltet sein müste?! oder täusch ich mich da?
ich kann aber niemanden anpingen.
Hat da einer ne idee wieso ?
Ich bin so froh gewesen dass ich ein success am ende lesen konnte und dennoch kommt auf dem notebook die meldung "diese verbindung verfügt über keine bzw. eingeschränkte konnektivität...."
zunächst mal danke
Also bei meinem versuchsaufbau mit IAS als Radius-Server habe ich durch deinen tip die Ereignisanzeige von Windows anzusehen am samstag ja schon gesehen dass der Radius Server den Radius-Client (also den switch bzw.Authenticator) nicht auflöste.
Ich hatte den Namen und änderte es indem ich die IP Adresse direkt nannte. Dadurch war eine Verifizierung des Authenticators möglich.
Also Akzeptiert der Server nun die eingehenden Daten weil er den Authenticator als Radius-Client versteht.
Nun Habe ich aber ein anderes Problem.
Und zwar Kommunizieren der Supplicant (mein Notebook) und der Server zwecks der Authentifizierung.
Das TLS protokoll läuft vim ersten Schritt bist zum SUCCESS -Signals des Servers einwandfrei.
Die Erignisanzeige auf dem Server gibt folgendes aus: "Benutzer "Yilmaz@Radius0.Diplom.de" wurde Zugriff gewährt."
Unter Whireshark ebenfalls ein finales "accept" bzw ein "success".
also müsste mein Notebook den server oder switch doch eigentlich anpingen können da der port nun freigeschaltet sein müste?! oder täusch ich mich da?
ich kann aber niemanden anpingen.
Hat da einer ne idee wieso ?
Ich bin so froh gewesen dass ich ein success am ende lesen konnte und dennoch kommt auf dem notebook die meldung "diese verbindung verfügt über keine bzw. eingeschränkte konnektivität...."
Na ganz einfach - deine 802.1X Authentisierung klappt schon mal - schön.
Der Switchport wird für den Client also freigeschaltet.
Die Frage ist - bekommt der client dann eien IP vom DHCP Server nachdem er Zugriff aufs Netz bekommen hat?
Der Client muss dann freilich einen DHCP Discover aussenden damit er eien IP bekommen kann.
Ich denke mich zu erinnern dass es da u. U. Probleme mit Switches (802.1X im LAN) geben kann, genau mti der DHCP Thematik. Ist ansonsten in dem Netz in das der Client kommt ein DHCP Server, ein DHCP Relay Agent oder ein "IP-Helper" auf dem Rotuerinterface konfiguriert?
Ja, aus Sicht des Radiusservers ist der "Client" nicht etwa der PC, sondern der Switch oder der Access Point.
Der Radius kommuniziert ja NIE direkt mit dem PC der sich authentisieren will, sondern IMMER mit einem zwischengeschalteten RAdiusclient wie VPN Server, Switch, Access Point, RAS-Einwahl-Server, NAS, PAC usw. Die Kommunikation zw. PC und "Authenticator" dagegen läuft stets mit anderen Protokollen, z. B. EAP oder PAP. Diese Protokolle werden zum Radius gesendet - jedoch immer schön in "Radius-Pakete" eingekapselt und nie direkt.
Der Switchport wird für den Client also freigeschaltet.
Die Frage ist - bekommt der client dann eien IP vom DHCP Server nachdem er Zugriff aufs Netz bekommen hat?
Der Client muss dann freilich einen DHCP Discover aussenden damit er eien IP bekommen kann.
Ich denke mich zu erinnern dass es da u. U. Probleme mit Switches (802.1X im LAN) geben kann, genau mti der DHCP Thematik. Ist ansonsten in dem Netz in das der Client kommt ein DHCP Server, ein DHCP Relay Agent oder ein "IP-Helper" auf dem Rotuerinterface konfiguriert?
Ja, aus Sicht des Radiusservers ist der "Client" nicht etwa der PC, sondern der Switch oder der Access Point.
Der Radius kommuniziert ja NIE direkt mit dem PC der sich authentisieren will, sondern IMMER mit einem zwischengeschalteten RAdiusclient wie VPN Server, Switch, Access Point, RAS-Einwahl-Server, NAS, PAC usw. Die Kommunikation zw. PC und "Authenticator" dagegen läuft stets mit anderen Protokollen, z. B. EAP oder PAP. Diese Protokolle werden zum Radius gesendet - jedoch immer schön in "Radius-Pakete" eingekapselt und nie direkt.
Ja der Switchport ist freigeschaltet.
Eine IP-Adresse bekommt er auch. Das DHCP Discover wird ausgesendet und er erhält eine IP-Adresse.
Ich habe nur diese drei Komponenten. Supplcient (notebook), Authenticator (Cisco 6509) und einen Radius Server(Windows Server 2003 mit IAS als Radius)
Die IP-Vergabe funktioniert.
Ich kann vom Notebook aus den Server anpingen.
Jedenfalls ging es eben.
wieso kann ich nach authentifizierung nicht am netzwerk teilnehmen ??
Ich kann den Switch auch nicht anpingen ??
Ja der Authenticator ist mittelsmann zwischen supplicanten und server. und wie ich über whireshark sehe läuft alles prima. vom ersten request/identy bis zur success meldung (access-request).
Eine IP-Adresse bekommt er auch. Das DHCP Discover wird ausgesendet und er erhält eine IP-Adresse.
Ich habe nur diese drei Komponenten. Supplcient (notebook), Authenticator (Cisco 6509) und einen Radius Server(Windows Server 2003 mit IAS als Radius)
Die IP-Vergabe funktioniert.
Ich kann vom Notebook aus den Server anpingen.
Jedenfalls ging es eben.
wieso kann ich nach authentifizierung nicht am netzwerk teilnehmen
??Ich kann den Switch auch nicht anpingen
??Ja der Authenticator ist mittelsmann zwischen supplicanten und server. und wie ich über whireshark sehe läuft alles prima. vom ersten request/identy bis zur success meldung (access-request).
ok,
ich habe nun auf meinem supplicanten eine feste ip-vergeben und ich kann nun den switch als auch den server anpingen.
aber wie bekomm ich das mit automatischer ip-adressierung (dhcp) hin?
im falls von mehreren hundert clients kann ich ja nicht jedem eine ip fest vergeben
vom server aus kann ich den client dennoch nicht anpingen. ist das normal bei eap-tls?
ich habe nun auf meinem supplicanten eine feste ip-vergeben und ich kann nun den switch als auch den server anpingen.
aber wie bekomm ich das mit automatischer ip-adressierung (dhcp) hin?
im falls von mehreren hundert clients kann ich ja nicht jedem eine ip fest vergeben
vom server aus kann ich den client dennoch nicht anpingen. ist das normal bei eap-tls?
Mal so ganz nebenbei - hast du keinen GRÖSSEREN Authenticator gefunden als nen fetten 6509er? Hehe.
Aber egal, ist ja eh alles das selbe, nur halt grösser.
Weiss ja nicht wie dein dhcp eingerichtet ist. eventuell gibt er was falsches raus?
Gateway korrekt usw?
Prinzipell bist du doch quasi schon auf der Zeilgerade!
EAP-TLS und das ganze drum rum is ja nur die Authentisierung - wenn mal erfolgreich authentisiert ist dann verhält sich der Switchport wie ein hundsnormaler Switchport. Das 802.1X hast du also erfolgreich geschafft.
Mir fällt grad kein Grund ein warum es nun mit dhcp nicht klappen sollte. Check nochmal den dhcp ordentlich durch.
Der Client bekommt also vom DHCP, kann jedoch nicht aufs netz zugreifen? Da ist doch garkein unterschied, ob man die iip statisch vergibt oder per dhcp - IP ist IP. Ausser der dhcp gibt was falsches raus was nicht passt.
Grübel.
Aber egal, ist ja eh alles das selbe, nur halt grösser.
Weiss ja nicht wie dein dhcp eingerichtet ist. eventuell gibt er was falsches raus?
Gateway korrekt usw?
Prinzipell bist du doch quasi schon auf der Zeilgerade!
EAP-TLS und das ganze drum rum is ja nur die Authentisierung - wenn mal erfolgreich authentisiert ist dann verhält sich der Switchport wie ein hundsnormaler Switchport. Das 802.1X hast du also erfolgreich geschafft.
Mir fällt grad kein Grund ein warum es nun mit dhcp nicht klappen sollte. Check nochmal den dhcp ordentlich durch.
Der Client bekommt also vom DHCP, kann jedoch nicht aufs netz zugreifen? Da ist doch garkein unterschied, ob man die iip statisch vergibt oder per dhcp - IP ist IP. Ausser der dhcp gibt was falsches raus was nicht passt.
Grübel.
hey spacyfreak,
ich danke dir ist echt nett und lieb von dir!
also dhcp ist ja eigentlich auch egal. brauch ich für den versuch nicht. dann arbeite ich eben mit einer festen ip auf dem supplicanten.
wie die ip-vergabe über einen dhcp-server funktioniert werde ich eben nur theoretisch behandeln
hauptpunkt ist ja 802.1x und das funktioniert jetzt.
ich hab also zwei kleine kratzer an meiner arbeit, der eine ist der fall wieso es mit automatischer ip-vergabe nicht funktioniert (stichwort dhcp)
und der andere wieso ich vom server aus den supplicanten nicht anpingen kann. besser gesagt ich kann ein ping request abschicken und es auf dem supplicanten sehen, der supplicant schickt aber kein ping-reply an den server.
die zwei kratzer werde ich vor mich hin versuchen die nächste zeit zu lösen.
jetzt kommt meine nächste aufgabe. drucker und eap-tls wie beantrage ich ein zertifikat für einen drucker der 802.1x unterstützt? wie installiere ich den dadrauf
ich danke dir
ist echt nett und lieb von dir!also dhcp ist ja eigentlich auch egal. brauch ich für den versuch nicht. dann arbeite ich eben mit einer festen ip auf dem supplicanten.
wie die ip-vergabe über einen dhcp-server funktioniert werde ich eben nur theoretisch behandeln
hauptpunkt ist ja 802.1x und das funktioniert jetzt.
ich hab also zwei kleine kratzer an meiner arbeit, der eine ist der fall wieso es mit automatischer ip-vergabe nicht funktioniert (stichwort dhcp)
und der andere wieso ich vom server aus den supplicanten nicht anpingen kann. besser gesagt ich kann ein ping request abschicken und es auf dem supplicanten sehen, der supplicant schickt aber kein ping-reply an den server.
die zwei kratzer werde ich vor mich hin versuchen die nächste zeit zu lösen.
jetzt kommt meine nächste aufgabe. drucker und eap-tls
wie beantrage ich ein zertifikat für einen drucker der 802.1x unterstützt? wie installiere ich den dadraufjetzt kommt meine nächste aufgabe. drucker und eap-tls wie
beantrage ich ein zertifikat für einen drucker der 802.1x
unterstützt? wie installiere ich den dadrauf
wiebeantrage ich ein zertifikat für einen drucker der 802.1x
unterstützt? wie installiere ich den dadrauf
Aua! Hehe. Das kannste wohl vergessen.
Ich denke in der "Praxis" würd ich den Drucker (der ja eh meist 99 Jahre am selben Port hängt) einfach an nen switchport hängen und dort "port-security" konfigurieren und den port aus dem 802.1X nehmen. Geht schnell, macht kein dreck und man kann sich schöneren dingen widmen (z. b. dem studium des kantinen-menues).
das ist ne gute idee
daran habe ich ehrlich gesagt nicht gedacht.
aber nur der theoriehalber müsste das auch mit zertifikaten machbar sein für drucker die 802.1x unterstützen
aber wo wir schon dabei sind: wie würdest du thin clients und fat clients behandeln?
die hängen ja auch immer an den selben ports fest.
MAC Authentication Bypass
ich denk das ist besser als von vorne herein port-security.
"Das ganze funktioniert wie folgt: die LAN Ports
für Endgeräte verhalten sich zunächst wie 802.1X Ports, d.h. sie erfordern
eine Authentifizierung, bevor Netzwerkzugang erlaubt wird. Reagiert
das angeschlossene Gerät offensichtlich nicht auf die entsprechenden
Protokollanforderungen und ist für diese Ports zusätzlich die Option
MAC Authentifizierung aktiviert, so führt der Switch dann alternativ im
Namen des Endgerätes eine 802.1X-Authentifizierung durch. Als Identität
wird dabei die MAC Adresse des Endgerätes benutzt."
Quelle: http://rt-solutions.de/upload/0_1164022039.pdf?PHPSESSID=81922b6602ad33 ...
ich denk das ist besser als von vorne herein port-security.
"Das ganze funktioniert wie folgt: die LAN Ports
für Endgeräte verhalten sich zunächst wie 802.1X Ports, d.h. sie erfordern
eine Authentifizierung, bevor Netzwerkzugang erlaubt wird. Reagiert
das angeschlossene Gerät offensichtlich nicht auf die entsprechenden
Protokollanforderungen und ist für diese Ports zusätzlich die Option
MAC Authentifizierung aktiviert, so führt der Switch dann alternativ im
Namen des Endgerätes eine 802.1X-Authentifizierung durch. Als Identität
wird dabei die MAC Adresse des Endgerätes benutzt."
Quelle: http://rt-solutions.de/upload/0_1164022039.pdf?PHPSESSID=81922b6602ad33 ...
