Wie muss ein Zertifikat für Radius-Anmeldung aussehen?

[hop-sing 0]

Hallo,

 

ich verzweifle an Zertifikaten... und zwar möchte ich einen Raspberry-Pi 2 mit Edimax WLAN-Stick in unser Unternehmensnetzwerk einbinden. Hierzu habe ich in unserer CA ein ID-Zertifikat erzeugt und in die WLAN-Config des Pi eingebunden. Leider klappt es nicht, im Radius-Server Log kommt dieser Fehler:

 

Der Netzwerkrichtlinienserver verweigerte einem Benutzer den Zugriff.

 

Wenden Sie sich an den Administrator des Netzwerkrichtlinienservers, um weitere Informationen zu erhalten.

 

Benutzer:

Sicherheits-ID: FIRMA\raspi

Kontoname: raspi@firma.de

Kontodomäne: FIRMA

Vollqualifizierter Kontoname: firma.de/STAFF/TestUser/Raspi-User

 

Clientcomputer:

Sicherheits-ID: NULL SID

Kontoname: -

Vollqualifizierter Kontoname: -

Betriebssystemversion: -

Empfänger-ID: 00-0B-9B-1A-5A-91:ESS_WLAN_INTERNAL

Anrufer-ID: 80-1F-02-47-32-1A

 

NAS:

NAS-IPv4-Adresse: 10.2.2.132

NAS-IPv6-Adresse: -

NAS-ID: -

NAS-Porttyp: Drahtlos - IEEE 802.11

NAS-Port: 8193

 

RADIUS-Client:

Clientanzeigenname: MERU-WLC

Client-IP-Adresse: 10.2.2.132

 

Authentifizierungsdetails:

Name der Verbindungsanforderungsrichtlinie: Use Windows authentication for all users

Netzwerkrichtlinienname: WLAN-WLAN_INTERNAL

Authentifizierungsanbieter: Windows

Authentifizierungsserver: dc1.firma.de

Authentifizierungstyp: EAP

EAP-Typ: Microsoft: Smartcard- oder anderes Zertifikat

Kontositzungs-ID: -

Protokollierungsergebnisse: Die Kontoinformationen wurden in keinen Datenspeicher geschrieben.

Ursachencode: 16

Ursache: Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch.

-------

 

Mit unseren Firmen-Laptops klappt das wunderbar auf "WLAN_INTERNAL". Die bekommen aufgrund einer GPO ein Computerzertifikat von der CA und nutzen dies in ihrerer WLAN-Configuration um sich mit dem Unternehmensnetzwerk zu verbinden. Ein Benutzername/Kennwort ist nicht notwendig, auch kein PSK.

 

Leider bin ich nicht so sattelfest mit NPS und den zahlreichen Einstellungen und derjenige bei uns, der das mal gemacht hat, ist nicht mehr im Unternehmen. Meine Frage ist nun ob es an den Eigenschaften/Inhalt des Zertifikates liegt, das es nicht klappt, oder daran wie das Regelwerk auf dem NPS eingestellt ist.

Für besagtes WLAN ist in der Netzwerkrichtlinie "WLAN-WLAN_INTERNAL" folgendes definiert:

Bedingunen:

-NAS-Porttyp = Wireless - IEEE 802.11

-Clientanzeigename = MERU-WLC.*

-Empfangs-ID = .*:ESS_WLAN_INTERNAL$

 

Einschränkungen:

-Authentifizierungsmethoden = EAP-Typen: "Microsoft: Smartcard- oder anderes Zertifikat"

(sonst nichts!)

 

Einstellungen:

(nichts)

 

Neben den Netzwerkrichtlinien gibt es noch eine Verbindungsanforderungsrichtlinie (was für ein Wort!). Hier ist nur der Default drin "Use Windows authentication for all users"

 

 

Nun meine Frage, wo muss ich suchen? Was mach ich falsch? Brauch man spezielle Zertifikate um sich ohne Benutzer/Kennwort, rein per ID-Zertifikat, zu authentifizieren?

[daabm 1.187]

Ich hab zwar noch nie ein nicht domänenintegriertes Gerät in ein AD per RADIUS reingelassen, aber da dürfte das Problem liegen - der Raspi hat keinen Computeraccount  im AD... Wenn Dir das als Denkansatz reicht, freut es mich - wenn nicht, müßtest Du auf andere warten, die sich damit besser auskennen...

[Dunkelmann 96]

Moin,

 

Du benötigst für den Client ein Zertifikat mit dem EKU (extended key usage / Erweiterte Schlüsselverwendung) 'Clientauthentifizierung'.

 

Der Radius scheint suboptimal konfiguriert. Es sei denn, die ungewöhnliche Form der MultifaktorAuthentifizierung war gewünscht.

In der Verbindungsanforderungsrichtlinie wird Windows Authentifizierung genutzt und in der Netzwerkrichtline EAP mit Zertifikat. Daher wird schon die Anforderung vom NPS abgelehnt. Der Pi hat kein Domänenkonto und der Vorgang kommt gar nicht bis zur Netzwerkrichtlinie.

 

Du benötigst also zunächst eine zusätzliche Anforderungsrichtlinie mit der Authentifizierungsmethode EAP mit Zertifikat.

 

Um ein wenig Know How Aufbau wirst Du bei dem Thema NPS mit EAP/PEAP nicht herumkommen:

https://technet.microsoft.com/de-de/library/cc772401%28v=ws.10%29.aspx

https://msdn.microsoft.com/en-us/library/cc771696.aspx

bearbeitet 3. April 2015 von Dunkelmann

[hop-sing 0]

Ah, Dunkelmann, das klingt sehr plausibel!!!

 

Du meinst also aufgrund der "Use Windows Authentication bla bla bla" muss für jedes Gerät auf jeden Fall ein AD-Konto da sein? Also egal mit welcher Methode es sich authentifiziert. Damit würden Benutzerkonten gehen aber auch Windows Computerkonten, die haben ja auch ein Kennwort und einen Benutzernamen. Ich glaube die Hosts heißten hinten mit '$', kann das sein? Also z.B. "MeinPC$". Das Kennwort eines Computers wird, glaube ich, automatisch mit dem DC ausgehandelt und von zeit zu zeit auch automatisch erneuert.

 

So gehsehen diente das Zertifikat, welches wir einsetzen, als weitere Authentifizierung und ggf. für die Verschlüsselung (TLS)? Ja, das mit der Zwei-Wege-Authentifizierung kann gut sein, das war damals so im Gespräch. Ich glaube EAP ist von hause aus unverschlüsselt und daher das Zertifikat um daraus EAP-TLS zu machen. Ginge also grundsätzlich auch ohne Zertifikat?!

 

Ok, was ich also wollte ist das der Raspi kein User/Password gespeichert hat, sondern stattdessen ausschließlich ein Zertifikat verwendet. Also wirklich NUR EAP-TLS, kein PEAP. Was mir dazu fehlt ist also eine entsprechende Verbindungsrichtlinie. Diese dürfte aber idealerweise nur für die Raspi's passen. Ich will ja das die PCs weiterhin beides verwenden. Zudem macht der RADIUS noch viel mehr als nur WLAN-Konten. Unser ganzes Netz ist mit Switches und Port-Security (DOT1X) ausgestattet. Jedes Gerät authentifiziert sich hierüber. Das soll auch alles so bleiben.

 

Ich könnte nun den Match gegen die ersten Ziffern der MAC-Adresse machen. Fänd ich aber b***d. Geht das nicht evtl. auch über bestimmte Zertifikatseigenschaften? Oder einen bestimmten Namensteil im Zertifikat? Unsere Geräte haben alle den gleichen Namensprefix und dann eine Nummer, z.B. "RPTB001". Den Inhalt des Zertifikates kann man ja nicht einfach so ändern, von daher wäre das sicher genug.

 

Achja, und wenn ich schonmal nen Zert-Guru hier habe ;-) Kennst Du eine Software unter Linux mit der man Zertifikate automatisch erneuern kann? Ich kenne sowas von unserer MDM-Lösung, die benutzt einen SCEP-Server in unserem Netz dafür. Auch der Macintosh kann sowas wohl. Nur bei Linux find ich nix. Mit OpenSSL könnte man vielleicht auch Zertifikate bei der CA anfordern, anstelle sie aufwendig per Hand zu generieren und aufzuspielen?!

 

Vielen Dank für die Links, ich muss mich da wirklich einarbeiten. Leider gibt es so wahnsinnig viel Infos aber meist nur wenig Howtos, die einen erklären was zu tun ist.

[tesso 360]

Du brauchst wahrscheinlich eine zusätzliche Verbindungsrichtlinie.

 

Für Linux habe gerade autscep entdeckt. klingt als, wenn es dir helfen konnte. Erfahrungen habe ich damit nicht.

http://autosscep.spe.net/

[hop-sing 0]

Hallo,

 

ja, da war ich auch. Hier mal meine bisherige Linksammlung (alles ungetestet):

http://autosscep.spe.net/

http://openscep.othello.ch/

https://github.com/certnanny/sscep

http://manpages.ubuntu.com/manpages/karmic/man8/scepclient.8.html

http://pki.fedoraproject.org/wiki/SCEP_in_Dogtag

http://secadmins.com/index.php/ndes-scep-windows-test-tool/

[Dunkelmann 96]

 

So gehsehen diente das Zertifikat, welches wir einsetzen, als weitere Authentifizierung und ggf. für die Verschlüsselung (TLS)? Ja, das mit der Zwei-Wege-Authentifizierung kann gut sein, das war damals so im Gespräch. Ich glaube EAP ist von hause aus unverschlüsselt und daher das Zertifikat um daraus EAP-TLS zu machen. Ginge also grundsätzlich auch ohne Zertifikat?!

Wikipedia ist Dein Freund.Bei Bedarf kannst Du auch die RFC studieren ;)

https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol

https://en.wikipedia.org/wiki/Protected_Extensible_Authentication_Protocol

 

Ja, EAP geht auch ohne Zertifikat ... nur nicht bei MS. EAP-MD5 ist seit Server 2008 raus.

 

 

Ok, was ich also wollte ist das der Raspi kein User/Password gespeichert hat, sondern stattdessen ausschließlich ein Zertifikat verwendet. Also wirklich NUR EAP-TLS, kein PEAP. Was mir dazu fehlt ist also eine entsprechende Verbindungsrichtlinie. Diese dürfte aber idealerweise nur für die Raspi's passen. Ich will ja das die PCs weiterhin beides verwenden. Zudem macht der RADIUS noch viel mehr als nur WLAN-Konten. Unser ganzes Netz ist mit Switches und Port-Security (DOT1X) ausgestattet. Jedes Gerät authentifiziert sich hierüber. Das soll auch alles so bleiben.

Es braucht eine zusätzliche Anforderungsrichtlinie.

 

Wenn tatsächlich das gesamte Netz per 802.1x geschützt ist und der einzige Admin mit Know How das Unternehmen verlassen hat, sollest Du als erstes sicherstellen, das eine Doku (Konfiguration und Passwörter für Switches etc.) erstellt wird. Eventuell ist es ratsam, die PW bei der Gelegenheit zu ändern.

Ich habe einmal ein total reset mitmachen dürfen, weil weder Netzwerk noch Kennwörter dokumentiert waren ... war ein sehr langes Wochenende.

 

Eine Testumgebung mit äquivalenten Komponenten ist auch keine schlechte Idee.

 

 

Ich könnte nun den Match gegen die ersten Ziffern der MAC-Adresse machen. Fänd ich aber b***d. Geht das nicht evtl. auch über bestimmte Zertifikatseigenschaften? Oder einen bestimmten Namensteil im Zertifikat? Unsere Geräte haben alle den gleichen Namensprefix und dann eine Nummer, z.B. "RPTB001". Den Inhalt des Zertifikates kann man ja nicht einfach so ändern, von daher wäre das sicher genug.

Du kannst ein benutzerdefiniertes EKU Attribut erstellen und am NPS prüfen. Das klingt oberflächlich zwar trivial, kann aber den Aufwand beim Troubleshooting erhöhen.

Dafür wird zusätzlich das Attribut 'Allowed-Certificate-OID' geprüft.

http://blogs.msdn.com/b/mpoulson/archive/2005/01/19/356229.aspx

 

 

Kennst Du eine Software unter Linux mit der man Zertifikate automatisch erneuern kann?

Nö ... und ist das sinnvoll? Wer prüft bei einem Gerät außerhalb der Domäne die Authentizität, wenn es automatisch Zertifikate anfordert und im schlimmsten Fall auch automatisch bekommt?

 

 

Vielen Dank für die Links, ich muss mich da wirklich einarbeiten. Leider gibt es so wahnsinnig viel Infos aber meist nur wenig Howtos, die einen erklären was zu tun ist.

Der NPS und natürlich auch die PKI, aus der die Zertifikate kommen, sind technisch betrachtet relativ simple Systeme. Sie brauchen nur ein durch die Organisation konkret definiertes Umfeld um zielführend eingesetzt werden zu können.

[hop-sing 0]

Zunächst die gute Nachricht: Es klappt :jau: !!!

 

Wie immer im Leben, war die Lösung ansich ganz einfach. Was fehlte war die Zuordnung von Zertifikat zu Identität.

Ohne Identität geht es nicht und diese muss im AD in Form eines Benutzer- oder Computerkontos vorliegen (bei letzterem dran denken hinter dem eigentlichen Namen ein "Dollar" zu platzieren, also z.B. "LINUXBOX$").

Das Kennwort ist dabei völlig egal und muss auch nicht in der Anfrage übergeben werden. Im Kontextmenü des Objektes (rechte Maustaste) findet man den Punkt "Namenszuordnungen...". Den wählt man aus und kann darin das binäre Zeritikat aus der Windows-CA hochladen. Dabei ist es völlig egal was dieses Zertifikat für Namen enthält. Es muss nur gültig sein und die bereits genannte Extended-Key-Usage (EKU) "Clientauthentifizierung" enthalten. Und schwubs... schon ist man drin :-)

 

Letztlich viel Recherche und Versuche, sowie Wireshark und Co. Leider kommt man selten direkt von der Fehlermeldung zum Problem. Auch bleibt immer die Frage ob die Fehlermeldung einen nicht in die Irre führt, weil es zu allgemein ist. In meinem Fall könnte(!) man im Nachhinein betrachtet zwischen Meldung und Problem durchaus parallelen erkennen. Kommt aber stark auf die Meldung an, denn ich habe ich schon welche gesehen die praktisch eine Mini-Howto enthalten was zu tun ist.

 

Du magst recht haben das NPS simpel ist, man kann es aber unglaublich komplex konfigurieren und je mehr man versucht es praktisch zu begreifen umso komplexer wird es. Dabei macht Debugging auf der Clientseite fast keinen Sinn, denn die ist so konzipiert, das sie nur Access or Denied erhält, was aus Security-Sicht wohl auch sinnvoll ist. Die Debugging-Möglichkeiten von NPS habe ich noch nicht so durchschaut. Ausser den Windows-Logs und Wireshark habe ich nichts in der Hand um Problemen auf die Spur zu kommen.

 

Zumindest kann ich nun sowohl per TLS-Zertifikat (und Identität :-) in unser Firmen-WLAN als auch über einen 802.1X-Port ins LAN. Für beides verwende ich auf dem Raspi übrigens den "wpa_supplicant".

 

Nun teste ich gerade "sscep" um in der Rollout-Phase der Raspi's ohne manuellen Aufwand Zertifikate zu erhalten. In Einzelschritten läuft das bereits und ich gehe so vor:

 - In einem Skript erzeuge ich mittels "openssl" einen privaten Schlüssel

 - Dann lade ich mir mittels "sscep" das CA-Stammzertifikat vom SCEP-Server

 - Nun rufe ich mittels wget die SCEP-Admin Seite auf und erhalte ein Challenge-Passwort (Hierfür muss der Admin einmalig eine Anmeldung eingeben)

 - Danach kann ich mit diesen Daten und dem "sscep"-Tool über den SCEP-Server ein ID-Zertifikat anfordern

 - Das resultierende Zertifikat wird zur Laufzeit direkt als PEM-Datei, also für Linux verwendbar, abgelegt und kann verwendet werden

 

So, oder so ähnlich, machen das auch andere die eine SCEP-Schnittstelle anbieten, z.B. Igel.

Das schöne dabei ist: Auch wenn das Gerät nicht in der Domäne ist, hat man volle Kontrolle über den Zugang. Will man ihn verhindern, muss man nur das Konto deaktivieren oder löschen. Schon ist das Zertifikat auf dem Gerät wertlos.

[Dunkelmann 96]

Schön, das es (vorläufig) geklappt hat - das bedeutet aber nicht zwangsläufig, dass der gewünschte Sicherheitsstandard auch eingehalten wird. Wenn man Sicherheitsmechnismen aushebelt oder umgeht, klappt es meistens (siehe: 'Der Benutzer muss Admin sein' oder 'Windows Firewall abschalten,dann geht es')  ;) 

 

Dass es am Client keine verwertbaren Informationen gibt ist vollkommen normal. Jede Information am Endgerät hilft auch einem Angreifer. Der MS Netzwerkmonitor auf dem NPS sollte eigentlich Pflicht sein.

 

Zum Thema 'Namen als Sicherheitsmerkmal': Namen sind Schall und Rauch

So, oder so ähnlich, machen das auch andere die eine SCEP-Schnittstelle anbieten, z.B. Igel.

Das schöne dabei ist: Auch wenn das Gerät nicht in der Domäne ist, hat man volle Kontrolle über den Zugang. Will man ihn verhindern, muss man nur das Konto deaktivieren oder löschen. Schon ist das Zertifikat auf dem Gerät wertlos.

Na und? Dann gebe ich meinem Gerät den Namen eines gültigen Clinets. .. und frag jetzt bitte nicht,wie man die Namen von WLAN Clients ermittelt ...

Bei Deinem Setup werden Gerätename und Identität im Zertifikat nicht gegeneinander geprüft. Das bedeutet, ich benötige nur ein beliebiges Zertifikat mit 'Clientauthentifizierung' und den Namen eines beliebigen Clients und schon bin ich drin. Zweifaktor meint eigentlich ein 'und' und 'kein entweder ... oder ...'