Freeradius - ActiveDirectory - Auth: Login incorrect (rlm chap: Clear text password not available)
Hi zusammen,
ich hab einen Freeradius lt. folgender Anleitung installiert, welcher Useranfragen wiederum gegen eine Gruppe im AD authentifizieren soll.
Link zur Anleitung
Ich würde nun gerne einen MikroTik-Router an den Radius verweisen. Die Einstellungen sind gemacht, jedoch erhalte ich bei einem Login-Versuch auf dem Radius folgende Fehlermeldung:
"Auth: Login incorrect (rlm_chap: Clear text password not available): [User123/<CHAP-Password>] (from client Segment1 port 0 cli 192.168.1.1)
Es gibt zwar mehrere Lösung im Internet, jedoch keine, welche zu meiner Konstellation passt.
Hätte jemand einen Vorschlag, wo ich hier angreifen müsste?
Danke und Grüße
ich hab einen Freeradius lt. folgender Anleitung installiert, welcher Useranfragen wiederum gegen eine Gruppe im AD authentifizieren soll.
Link zur Anleitung
Ich würde nun gerne einen MikroTik-Router an den Radius verweisen. Die Einstellungen sind gemacht, jedoch erhalte ich bei einem Login-Versuch auf dem Radius folgende Fehlermeldung:
"Auth: Login incorrect (rlm_chap: Clear text password not available): [User123/<CHAP-Password>] (from client Segment1 port 0 cli 192.168.1.1)
Es gibt zwar mehrere Lösung im Internet, jedoch keine, welche zu meiner Konstellation passt.
Hätte jemand einen Vorschlag, wo ich hier angreifen müsste?
Danke und Grüße
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 379269
Url: https://administrator.de/forum/freeradius-activedirectory-auth-login-incorrect-rlm-chap-clear-text-password-not-available-379269.html
Ausgedruckt am: 25.04.2025 um 02:04 Uhr
21 Kommentare
Neuester Kommentar
Hallo,
Und? Was ist denn deine Konstellation bzw. gewünschtes?
Gruß,
Peter
Und? Was ist denn deine Konstellation bzw. gewünschtes?
Gruß,
Peter
Hier findest du ebenfalls Grundlagen zur Einrichtiung des FreeRadius:
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
Netzwerk Management Server mit Raspberry Pi
Ist das erledigt solltest du erstmal den Freeradius mit Bordmitteln testen.
Dazu ist das Tool NTRadPing sehr hilfreich:
http://www.novell.com/coolsolutions/tools/14377.html
Das sollte erstmal ein positives feedback geben (Success) erst dann macht es Sinn auf dem MT weiterzumachen.

Leider warst du ja nichtmal in der Lage hier einen Output zu posten mit dem FreeRadius im Debugging Mode
Hättest du diesen mal mit radiusd -X im Debugging Mode gestartet hättest du dir vermutlich diesen Thread sparen können.
In den Debug Message gibt der FreeRadius dir ganz genau aus WAS schief läuft. Das kannst du dann in der Konfig fixen und hast das Problem in 5 Minuten gelöst !
Hilfreich wäre auch das Mikrotik Log gewesen aber auch da leider nix. Da bleibt dann auch uns nur die Glaskugel
Fazit:
Etwas MEHR Input bitte hier, dann können wir die auch schnell und zielgerichtet helfen !
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
Netzwerk Management Server mit Raspberry Pi
Ist das erledigt solltest du erstmal den Freeradius mit Bordmitteln testen.
Dazu ist das Tool NTRadPing sehr hilfreich:
http://www.novell.com/coolsolutions/tools/14377.html
Das sollte erstmal ein positives feedback geben (Success) erst dann macht es Sinn auf dem MT weiterzumachen.
Hast Du die Funktion des Radius, wie in der Anleitung beschrieben getestet?
Vermutlich wohl nicht Leider warst du ja nichtmal in der Lage hier einen Output zu posten mit dem FreeRadius im Debugging Mode
Hättest du diesen mal mit radiusd -X im Debugging Mode gestartet hättest du dir vermutlich diesen Thread sparen können.
In den Debug Message gibt der FreeRadius dir ganz genau aus WAS schief läuft. Das kannst du dann in der Konfig fixen und hast das Problem in 5 Minuten gelöst !
Hilfreich wäre auch das Mikrotik Log gewesen aber auch da leider nix. Da bleibt dann auch uns nur die Glaskugel
Fazit:
Etwas MEHR Input bitte hier, dann können wir die auch schnell und zielgerichtet helfen !
Hallo Looser,
In der users.conf müsste folgender Eintrag stehen:
Damit könnte der User lokal , also auf dem FreeRADIUS, authentifiziert werden. CHAP geht allerdings nicht gegen die Active Directory.
PS. Du solltest auch nicht auf "-XXX" als Debugging-Option verweisen. Das ist etwas für die Entwickler.
BB
Du hast das korrekte Secret aus den Zertifikaten im MikroTik hinterlegt?
Das Password/den Schlüssel (per default "whatever") benutzt FreeRADIUS intern, um Zugriff auf den Private Key zum Zertifikat zu erhalten. Das hat nichts mit dem Secret zu tun, was auf FreeRADIUS (clients.conf) und dem NAS übereinstimmen muss. Das Password sollte den RADIUS-Server nie verlassen.Du hast die ntlm_auth nicht implementiert. Somit funktioniert die Authentifizierung gegen das AD nicht.
Man kann aus dem Log nicht ersehen. ob er ntlm_auth konfiguriert hat oder nicht. Aus dem Log geht hervor, dass der User123 via CHAP authentfiziert werden soll und das in der users.conf kein Eintrag für ihn vorhanden ist. Dafür hat er einen Eintrag "DEFAULT", der auch für den User123 zutrifft. Deshalb schlägt die Authentifizierung fehl.In der users.conf müsste folgender Eintrag stehen:
User123 Cleartext-Password := "XXX"
PS. Du solltest auch nicht auf "-XXX" als Debugging-Option verweisen. Das ist etwas für die Entwickler.
BB
Zitat von @BitBurg:
Hallo Looser,
Hallo Looser,
Du hast das korrekte Secret aus den Zertifikaten im MikroTik hinterlegt?
Das Password/den Schlüssel (per default "whatever") benutzt FreeRADIUS intern, um Zugriff auf den Private Key zum Zertifikat zu erhalten. Das hat nichts mit dem Secret zu tun, was auf FreeRADIUS (clients.conf) und dem NAS übereinstimmen muss. Das Password sollte den RADIUS-Server nie verlassen.Wenn der MikroTik auf den Freeradius zugreifen soll, braucht er das in den Zertifikaten hinterlegte Passwort.
Du hast die ntlm_auth nicht implementiert. Somit funktioniert die Authentifizierung gegen das AD nicht.
Man kann aus dem Log nicht ersehen. ob er ntlm_auth konfiguriert hat oder nicht. Aus dem Log geht hervor, dass der User123 via CHAP authentfiziert werden soll und das in der users.conf kein Eintrag für ihn vorhanden ist. Dafür hat er einen Eintrag "DEFAULT", der auch für den User123 zutrifft. Deshalb schlägt die Authentifizierung fehl.Wäre ntlm konfiguriert, würde es im Log erscheinen.
In der users.conf müsste folgender Eintrag stehen:
Damit könnte der User lokal , also auf dem FreeRADIUS, authentifiziert werden. CHAP geht allerdings nicht gegen die Active Directory.
User123 Cleartext-Password := "XXX"
Für eine Anbindung an das AD muss die Datei users wie in der Anleitung aussehen.
PS. Du solltest auch nicht auf "-XXX" als Debugging-Option verweisen. Das ist etwas für die Entwickler.
In dieser Debug-Ausgabe Option sieht man mehr Details und findet den Fehler auch schneller, als nur mit -X.
BB
SSH Klartext Passwort ?? Wie ist das gemeint. Es liefert ein Klartext Passwort am Radius an zu dem Usernamen oder was meinst du damit ?
Der Debugger oben sagt ja das er den User "User123" nirgendwo finden kann. Komischerweise zeigt er auch nicht die Weitergabe aufs AD an. Gleiches Problem bei NTRadping.
Dadurch das er nirgendwo diesen User findet scheitert das.
Kannst du am AD einen eingehenden Request vom FreeRadius sehen ?
Der Vorgang ist eigentlich recht gut erklärt:
https://mum.mikrotik.com/presentations/PL12/daniel.pdf
Der Debugger oben sagt ja das er den User "User123" nirgendwo finden kann. Komischerweise zeigt er auch nicht die Weitergabe aufs AD an. Gleiches Problem bei NTRadping.
Dadurch das er nirgendwo diesen User findet scheitert das.
Kannst du am AD einen eingehenden Request vom FreeRadius sehen ?
Der Vorgang ist eigentlich recht gut erklärt:
https://mum.mikrotik.com/presentations/PL12/daniel.pdf
Zitat von @Dante2191:
Der Radius läuft auf einem Ubuntu 16.04. Hab bereits gelesen, dass 18.04 nicht unterstützt wird.
Gestern hab ich die komplette Maschine neu aufgesetzt, leider immernoch mit dem selben Ergebnis.
Zum Vergleich:
1. Authentifizierungsversuch mit dem MikroTik:
2. Versuch mit dem Ntrad (CHAP aktiviert)
Wenn ich den Haken bei CHAP herausnehme, funktioniert die Authentifizierung wurderbar. Ich habe am Domain-Controller in den Netzwerkrichtlinien eine neue "Radius-Logins" erstellt und CHAP-Authentifizierung aktiviert. Im Event-Log am Domain-Controller wird auch nichts relevantes angezeigt wenn ich eine Anmeldung versuche.
Scheinbar hakt es zwischen MikroTik und Freeradius wie auch in diesem Forum beschrieben:
https://forum.mikrotik.com/viewtopic.php?t=57743
Ein Login per SSH auf den Router liefert ein Klartext-Passwort welches akzeptiert wird.
Der Radius läuft auf einem Ubuntu 16.04. Hab bereits gelesen, dass 18.04 nicht unterstützt wird.
Gestern hab ich die komplette Maschine neu aufgesetzt, leider immernoch mit dem selben Ergebnis.
Zum Vergleich:
1. Authentifizierungsversuch mit dem MikroTik:
> rad_recv: Access-Request packet from host 172.16.1.1 port 54017, id=17, length=106
> Service-Type = Login-User
> User-Name = "User123"
> CHAP-Challenge = 0xa194fdfbc5dc35e81661c1b2016b07fa
> CHAP-Password = 0x00e2f7ff9586185deb4de85a9650912353
> Calling-Station-Id = "192.168.1.1"
> NAS-Identifier = "Device1"
> NAS-IP-Address = 172.16.1.1
> Tue Jul 10 09:33:40 2018 : Info: # Executing section authorize from file /etc/freeradius/sites-enabled/default
> Tue Jul 10 09:33:40 2018 : Info: +group authorize {
> Tue Jul 10 09:33:40 2018 : Info: ++[preprocess] = ok
> Tue Jul 10 09:33:40 2018 : Info: [chap] Setting 'Auth-Type := CHAP'
> Tue Jul 10 09:33:40 2018 : Info: ++[chap] = ok
> Tue Jul 10 09:33:40 2018 : Info: ++[mschap] = noop
> Tue Jul 10 09:33:40 2018 : Info: ++[digest] = noop
> Tue Jul 10 09:33:40 2018 : Info: [suffix] No '@' in User-Name = "User123", looking up realm NULL
> Tue Jul 10 09:33:40 2018 : Info: [suffix] No such realm "NULL"
> Tue Jul 10 09:33:40 2018 : Info: ++[suffix] = noop
> Tue Jul 10 09:33:40 2018 : Info: [eap] No EAP-Message, not doing EAP
> Tue Jul 10 09:33:40 2018 : Info: ++[eap] = noop
> Tue Jul 10 09:33:40 2018 : Info: [files] users: Matched entry DEFAULT at line 49
> Tue Jul 10 09:33:40 2018 : Info: ++[files] = ok
> Tue Jul 10 09:33:40 2018 : Info: ++[expiration] = noop
> Tue Jul 10 09:33:40 2018 : Info: ++[logintime] = noop
> Tue Jul 10 09:33:40 2018 : Info: [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this.
> Tue Jul 10 09:33:40 2018 : Info: ++[pap] = noop
> Tue Jul 10 09:33:40 2018 : Info: +} # group authorize = ok
> Tue Jul 10 09:33:40 2018 : Info: Found Auth-Type = CHAP
> Tue Jul 10 09:33:40 2018 : Info: # Executing group from file /etc/freeradius/sites-enabled/default
> Tue Jul 10 09:33:40 2018 : Info: +group CHAP {
> Tue Jul 10 09:33:40 2018 : Info: [chap] login attempt by "User123" with CHAP password
> Tue Jul 10 09:33:40 2018 : Info: [chap] Cleartext-Password is required for authentication
> Tue Jul 10 09:33:40 2018 : Info: ++[chap] = invalid
> Tue Jul 10 09:33:40 2018 : Info: +} # group CHAP = invalid
> Tue Jul 10 09:33:40 2018 : Info: Failed to authenticate the user.
> Tue Jul 10 09:33:40 2018 : Info: Using Post-Auth-Type Reject
> Tue Jul 10 09:33:40 2018 : Info: # Executing group from file /etc/freeradius/sites-enabled/default
> Tue Jul 10 09:33:40 2018 : Info: +group REJECT {
> Tue Jul 10 09:33:40 2018 : Info: [eap] Request didn't contain an EAP-Message, not inserting EAP-Failure
> Tue Jul 10 09:33:40 2018 : Info: ++[eap] = noop
> Tue Jul 10 09:33:40 2018 : Info: [attr_filter.access_reject] expand: %{User-Name} -> User123
> Tue Jul 10 09:33:40 2018 : Debug: attr_filter: Matched entry DEFAULT at line 11
> Tue Jul 10 09:33:40 2018 : Info: ++[attr_filter.access_reject] = updated
> Tue Jul 10 09:33:40 2018 : Info: +} # group REJECT = updated
> Tue Jul 10 09:33:40 2018 : Info: Delaying reject of request 0 for 1 seconds
> Tue Jul 10 09:33:40 2018 : Debug: Going to the next request
> Tue Jul 10 09:33:40 2018 : Debug: Waking up in 0.9 seconds.
> Tue Jul 10 09:33:41 2018 : Info: Sending delayed reject for request 0
> Sending Access-Reject of id 17 to 172.16.1.1 port 54017
> Tue Jul 10 09:33:41 2018 : Debug: Waking up in 4.9 seconds.
> Tue Jul 10 09:33:46 2018 : Info: Cleaning up request 0 ID 17 with timestamp +25
> Tue Jul 10 09:33:46 2018 : Info: Ready to process requests.
>
2. Versuch mit dem Ntrad (CHAP aktiviert)
> rad_recv: Access-Request packet from host 192.168.1.10 port 49453, id=12, length=49
> User-Name = "User123"
> CHAP-Password = 0xaf15511e181684c55677917c0dfe4ebaba
> Tue Jul 10 09:35:10 2018 : Info: # Executing section authorize from file /etc/freeradius/sites-enabled/default
> Tue Jul 10 09:35:10 2018 : Info: +group authorize {
> Tue Jul 10 09:35:10 2018 : Info: ++[preprocess] = ok
> Tue Jul 10 09:35:10 2018 : Info: [chap] Setting 'Auth-Type := CHAP'
> Tue Jul 10 09:35:10 2018 : Info: ++[chap] = ok
> Tue Jul 10 09:35:10 2018 : Info: ++[mschap] = noop
> Tue Jul 10 09:35:10 2018 : Info: ++[digest] = noop
> Tue Jul 10 09:35:10 2018 : Info: [suffix] No '@' in User-Name = "User123", looking up realm NULL
> Tue Jul 10 09:35:10 2018 : Info: [suffix] No such realm "NULL"
> Tue Jul 10 09:35:10 2018 : Info: ++[suffix] = noop
> Tue Jul 10 09:35:10 2018 : Info: [eap] No EAP-Message, not doing EAP
> Tue Jul 10 09:35:10 2018 : Info: ++[eap] = noop
> Tue Jul 10 09:35:10 2018 : Info: [files] users: Matched entry DEFAULT at line 49
> Tue Jul 10 09:35:10 2018 : Info: ++[files] = ok
> Tue Jul 10 09:35:10 2018 : Info: ++[expiration] = noop
> Tue Jul 10 09:35:10 2018 : Info: ++[logintime] = noop
> Tue Jul 10 09:35:10 2018 : Info: [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this.
> Tue Jul 10 09:35:10 2018 : Info: ++[pap] = noop
> Tue Jul 10 09:35:10 2018 : Info: +} # group authorize = ok
> Tue Jul 10 09:35:10 2018 : Info: Found Auth-Type = CHAP
> Tue Jul 10 09:35:10 2018 : Info: # Executing group from file /etc/freeradius/sites-enabled/default
> Tue Jul 10 09:35:10 2018 : Info: +group CHAP {
> Tue Jul 10 09:35:10 2018 : Info: [chap] login attempt by "User123" with CHAP password
> Tue Jul 10 09:35:10 2018 : Info: [chap] Cleartext-Password is required for authentication
> Tue Jul 10 09:35:10 2018 : Info: ++[chap] = invalid
> Tue Jul 10 09:35:10 2018 : Info: +} # group CHAP = invalid
> Tue Jul 10 09:35:10 2018 : Info: Failed to authenticate the user.
> Tue Jul 10 09:35:10 2018 : Info: Using Post-Auth-Type Reject
> Tue Jul 10 09:35:10 2018 : Info: # Executing group from file /etc/freeradius/sites-enabled/default
> Tue Jul 10 09:35:10 2018 : Info: +group REJECT {
> Tue Jul 10 09:35:10 2018 : Info: [eap] Request didn't contain an EAP-Message, not inserting EAP-Failure
> Tue Jul 10 09:35:10 2018 : Info: ++[eap] = noop
> Tue Jul 10 09:35:10 2018 : Info: [attr_filter.access_reject] expand: %{User-Name} -> User123
> Tue Jul 10 09:35:10 2018 : Debug: attr_filter: Matched entry DEFAULT at line 11
> Tue Jul 10 09:35:10 2018 : Info: ++[attr_filter.access_reject] = updated
> Tue Jul 10 09:35:10 2018 : Info: +} # group REJECT = updated
> Tue Jul 10 09:35:10 2018 : Info: Delaying reject of request 7 for 1 seconds
> Tue Jul 10 09:35:10 2018 : Debug: Going to the next request
> Tue Jul 10 09:35:10 2018 : Debug: Waking up in 0.9 seconds.
> Tue Jul 10 09:35:11 2018 : Info: Sending delayed reject for request 7
> Sending Access-Reject of id 12 to 192.168.1.10 port 49453
> Tue Jul 10 09:35:11 2018 : Debug: Waking up in 4.9 seconds.
> Tue Jul 10 09:35:16 2018 : Info: Cleaning up request 7 ID 12 with timestamp +115
> Tue Jul 10 09:35:16 2018 : Info: Ready to process requests.
>
Wenn ich den Haken bei CHAP herausnehme, funktioniert die Authentifizierung wurderbar. Ich habe am Domain-Controller in den Netzwerkrichtlinien eine neue "Radius-Logins" erstellt und CHAP-Authentifizierung aktiviert. Im Event-Log am Domain-Controller wird auch nichts relevantes angezeigt wenn ich eine Anmeldung versuche.
Scheinbar hakt es zwischen MikroTik und Freeradius wie auch in diesem Forum beschrieben:
https://forum.mikrotik.com/viewtopic.php?t=57743
Ein Login per SSH auf den Router liefert ein Klartext-Passwort welches akzeptiert wird.
In der Anleitung steht doch, dass der Haken bei MsChap nicht gesetzt werden darf beim Tool Ntradping.
Kannst Du denn mit wbinfo -u die User vom AD abfragen?
Versuch das mal ohne die Richtlinie nur über eine Usergruppe, wie hier beschrieben:
Möchte man hingegen die zugelassenen User auf eine Gruppe, z.B. "WLAN", beschränken dann sieht die Zeile wie folgt aus:
program = "/usr/bin/ntlm_auth --request-nt-key --domain=MYDOMAIN --require-membership-of=MYDOMAIN\\WLAN --username=%{mschap:User-Name} --password=%{User-Password}"
Hallo Dante,
ich schreibe dir zuerst mal etwas zu der Authentifizierungsmethode CHAP, danach etwas zu dem Log und zum Schluss etwas Allgemeines.
CHAP
CHAP (Challenge Authentication Protocol) mit RADIUS funktioniert im Groben folgendermaßen:
1. Das NAS (Mikrotik) sendet eine Zahl (genannt Challenge) zum Client.
2. Der Client berechnet über die Zahl und sein Klartext-Passwort einen Hash (eine Art Prüfsumme) und sendet diesen HASH als Passwort zusammen mit seinem Usernamen zum NAS.
3. Das NAS (Mikrotik) empfängt die Daten und sendet den Usernamen im RADIUS-Attribut "User-Name" und das Password (Hash) im Attribut "CHAP-Password", zusammen mit der Challenge aus Schritt 1, zum RADIUS-Server.
4. Der RADIUS-Server (FreeRADIUS) empfängt diese Daten und sucht in seiner Benutzerdatenbank (users) nach einem Eintrag für den User, den er im Attribute "User-Name" findet. Der Eintrag muss das Klartext-Passwort des Clients enthalten. Findet er das Passwort, berechnet auf die gleiche Art und Weise wie der Client in Schritt 1 einen HASH. Diesen vergleicht er mit dem Inhalt des Attributs "CHAP-Password". Sind die HASHs identisch, so hat der User das richtige Passwort benutzt und die Authentifizierung ist erfolgreich.
Schritt 4 kannst du in dem Log beobachten. Ich habe den gekürzt und nur die relevanten Zeilen kopiert.
LOG
Der erste Eintrag enthält die Attribute, die das NAS zu FreeRADIUS (kurz FR) sendet.
FR geht dann seine "authenticate-section" durch und da es ein Attribut CHAP-Password gibt, setzt das Modul CHAP den AUTH-Type auf CHAP. "Auth-Type" ist ein internes Attribute, welches festlegt, welches Modul in der "authenticate"-section" (in der die Authentifizierung stattfindet) benutzt werden soll.
Danach arbeitet FR das Modul files ab, welches wiederum das users-file nach einem Eintrag für den User im Attribute "User-Name" (User123) durchsucht. Den findet er nicht, dafür aber einen Eintrag DEFAULT in Zeile 49, der für alle Usernamen zutrifft. In diesem Log sieht man NICHT, ob das Modul ntlm_auth überhaupt konfiguriert ist. Es hätte dich mal jemand fragen müssen, was denn in Zeile 49 steht. Auf jeden Fall steht dort keine Eintrag, der den Auth-Type auf "ntlm_auth" umschreibt.
Darum benutzt FR den Auth-Type CHAP und übergibt dem Modul CHAP in der "authenticate-section" den Usernamen User123, aber ohne das erforderliche Klartext-Passwort (siehe Schritt 4 Erklärung). Für CHAP muss FR das Klartext-Passwort des Users kennen. Der Rest ist selbsterklärend.
Deine Datei users auf auf dem FreeRADIUS-Server müsste beispielsweise also folgenden Inhalt haben:
Dann würde mit CHAP/PAP für den User alice lokal funktionieren, jedoch immer noch nicht für User123. FR würde dann zwar das Modul ntlm_auth aufrufen, aber ihm nur den Usernamen übergeben. Selbst wenn man dem Modul das CHAP-Password und die Challenge übergeben würden, könnte der Domänencontroller nichts damit anfangen. Das geht nur mit Authentifizierungsverfahren, die dem FR ein Klartext-Password übermitteln, z.B. PAP/TTLS-PAP.
Mit dem NPS von Windows würde es gehen. Das ist aber keine Schwäche von FreeRADIUS, sondern ist darin begründet, dass der NPS für die Zusammenarbeit mit einer Active-Directory geschrieben wurde. Wenn du den Mikrotik so konfigurierst, dass er den NPS benutzt, dann würde es gehen. Dazu müsstest du im NPS den MT als Client konfigurieren und einen Account User123 mit dem Merkmal "umkehrbare Verschlüsselung" anlegen, damit das Passwort im Klartext verfügbar ist. Die andere Möglichkeit wäre, FreeRADIUS als Proxy für den Mikrotik arbeiten zu lassen. FR würde dann die Authentifizierung an den NPS weiterleiten.
Allgemeines
Ich weiß nicht, ob es dir klar ist, dass FreeRADIUS (siehe Anleitungen von Looser und Aqui) direkt mit dem DC kommuniziert. Du musst dazu nicht noch den NPS installieren. Ich schreibe das deshalb, weil du oben etwas von Netzwerkrichtlinien schreibst.
Der einzige sinnvolle Beitrag bisher, ist der von Pjördorf. Zuerstmal muss man wissen, was du eigentlich willst, bevor man dazu was sagen kann. Beschreibe den IST und den Soll-Zustand und das mit möglichst einfachen Worten. Selbst dann ist es fraglich ob man dir helfen kann, wenn du wenig Vorkenntnisse hast. Vorausgesetzt natürlich, dass der Helfer selber Ahnung hat.
BB
ich schreibe dir zuerst mal etwas zu der Authentifizierungsmethode CHAP, danach etwas zu dem Log und zum Schluss etwas Allgemeines.
CHAP
CHAP (Challenge Authentication Protocol) mit RADIUS funktioniert im Groben folgendermaßen:
1. Das NAS (Mikrotik) sendet eine Zahl (genannt Challenge) zum Client.
2. Der Client berechnet über die Zahl und sein Klartext-Passwort einen Hash (eine Art Prüfsumme) und sendet diesen HASH als Passwort zusammen mit seinem Usernamen zum NAS.
3. Das NAS (Mikrotik) empfängt die Daten und sendet den Usernamen im RADIUS-Attribut "User-Name" und das Password (Hash) im Attribut "CHAP-Password", zusammen mit der Challenge aus Schritt 1, zum RADIUS-Server.
4. Der RADIUS-Server (FreeRADIUS) empfängt diese Daten und sucht in seiner Benutzerdatenbank (users) nach einem Eintrag für den User, den er im Attribute "User-Name" findet. Der Eintrag muss das Klartext-Passwort des Clients enthalten. Findet er das Passwort, berechnet auf die gleiche Art und Weise wie der Client in Schritt 1 einen HASH. Diesen vergleicht er mit dem Inhalt des Attributs "CHAP-Password". Sind die HASHs identisch, so hat der User das richtige Passwort benutzt und die Authentifizierung ist erfolgreich.
Schritt 4 kannst du in dem Log beobachten. Ich habe den gekürzt und nur die relevanten Zeilen kopiert.
LOG
Der erste Eintrag enthält die Attribute, die das NAS zu FreeRADIUS (kurz FR) sendet.
Access-Request packet from host 172.16.1.1 port 54017, id=17, length=106
User-Name = "User123
CHAP-Challenge = 0xa194fdfbc5dc35e81661c1b2016b07fa
CHAP-Password = 0x00e2f7ff9586185deb4de85a9650912353
[chap] Setting 'Auth-Type := CHAP'
++[chap] = ok
[files] users: Matched entry DEFAULT at line 49
++[files] = ok
Found Auth-Type = CHAP
+group CHAP {
[chap] login attempt by "User123" with CHAP password
[chap] Cleartext-Password is required for authentication
Failed to authenticate the user.
Using Post-Auth-Type Reject
alice Cleartext-Password := "passme"
DEFAULT Auth-Type := ntlm_auth
Mit dem NPS von Windows würde es gehen. Das ist aber keine Schwäche von FreeRADIUS, sondern ist darin begründet, dass der NPS für die Zusammenarbeit mit einer Active-Directory geschrieben wurde. Wenn du den Mikrotik so konfigurierst, dass er den NPS benutzt, dann würde es gehen. Dazu müsstest du im NPS den MT als Client konfigurieren und einen Account User123 mit dem Merkmal "umkehrbare Verschlüsselung" anlegen, damit das Passwort im Klartext verfügbar ist. Die andere Möglichkeit wäre, FreeRADIUS als Proxy für den Mikrotik arbeiten zu lassen. FR würde dann die Authentifizierung an den NPS weiterleiten.
Allgemeines
Ich weiß nicht, ob es dir klar ist, dass FreeRADIUS (siehe Anleitungen von Looser und Aqui) direkt mit dem DC kommuniziert. Du musst dazu nicht noch den NPS installieren. Ich schreibe das deshalb, weil du oben etwas von Netzwerkrichtlinien schreibst.
Der einzige sinnvolle Beitrag bisher, ist der von Pjördorf. Zuerstmal muss man wissen, was du eigentlich willst, bevor man dazu was sagen kann. Beschreibe den IST und den Soll-Zustand und das mit möglichst einfachen Worten. Selbst dann ist es fraglich ob man dir helfen kann, wenn du wenig Vorkenntnisse hast. Vorausgesetzt natürlich, dass der Helfer selber Ahnung hat.
BB
Hallo,
Also im AD existieren keine Passwörter sondern nur deren Haschwert. Daher kann man aus dem AD auch keine Passwörter rauskopieren. Und da du ja möchtest das deine AD Benutzer in AD Gruppen eingordnet sich gegen eine Radius Authentifizieren, warum dann nochmals die Passwörter explicit in einer separaten SQL datenbank stecken (Doppeleingabe bei Änderung etc.)
Gruß,
Peter
Also im AD existieren keine Passwörter sondern nur deren Haschwert. Daher kann man aus dem AD auch keine Passwörter rauskopieren. Und da du ja möchtest das deine AD Benutzer in AD Gruppen eingordnet sich gegen eine Radius Authentifizieren, warum dann nochmals die Passwörter explicit in einer separaten SQL datenbank stecken (Doppeleingabe bei Änderung etc.)
Gruß,
Peter
Zitat von @Dante2191:
So wie ich dich verstanden habe, ist es wohl so nicht möglich, es sei denn ich bekomme das CHAP-Verfahren aus dem Spiel.
Genau, RADIUS CHAP gegen die AD funktioniert nicht. Da es ohnehin nicht geht, ändere die users wieder gemäß Anleitung. Du kannst den Inhalt der Datei auch komplett löschen und nur den DEFAULT Eintrag stehen lassen.So wie ich dich verstanden habe, ist es wohl so nicht möglich, es sei denn ich bekomme das CHAP-Verfahren aus dem Spiel.
DEFAULT = ntlm_auth
Wäre die Erweiterung des Radius um eine SQL-Datenbank eine Alternative oder liegen in dieser die Passwörter ebenso unverschlüsselt?
Für FreeRADIUS macht es keinen Unterschied, ob das Klartext-Passwort aus dem users-file oder einer SQL-Datenbank kommt. Diesen Aufwand kannst du dir sparen.Eine mögliche Lösung wäre eine "doppelte Buchführung". Sprich, du müsstest in der users einen Eintrag für User123 mit seinem Passwort machen, genau wie oben in meinem Beispiel. Bevor aber CHAP lokal ausgeführt wird, könntest du die Gruppenmitgliedschaft von User123 in der AD abfragen. Dazu müsstest du den User in der AD mit irgendeinem Passwort anlegen und in eine Gruppe (z.B. winbox) aufnehmen.
Der Nachteil ist eben, dass du die Anmeldeinformationen doppelt führen musst.
BB