dante2191
Jul 05, 2018
view6078
view21
0
Goto Top

Freeradius - ActiveDirectory - Auth: Login incorrect (rlm chap: Clear text password not available)

GermanQuestionLinux ToolsLinux
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
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 379269

Url: https://administrator.de/contentid/379269

Printed on: April 25, 2024 at 01:04 o'clock

21 Comments
Latest comment
Goto Top
Member: Pjordorf
Pjordorf Jul 05, 2018 at 14:17:09 (UTC)
Goto Top
Hallo,

Zitat von @Dante2191:
welche zu meiner Konstellation passt.
Und? Was ist denn deine Konstellation bzw. gewünschtes?

Gruß,
Peter
Member: Looser27
Looser27 Jul 05, 2018 updated at 16:38:00 (UTC)
Goto Top
Moin,

Du hast das korrekte Secret aus den Zertifikaten im MikroTik hinterlegt?

Hast Du die Funktion des Radius, wie in der Anleitung beschrieben getestet?

Gruß

Looser
Member: aqui
aqui Jul 05, 2018 updated at 17:55:09 (UTC)
Goto Top
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.
Hast Du die Funktion des Radius, wie in der Anleitung beschrieben getestet?
Vermutlich wohl nicht face-sad

Leider warst du ja nichtmal in der Lage hier einen Output zu posten mit dem FreeRadius im Debugging Mode face-sad
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 face-sad
Fazit:
Etwas MEHR Input bitte hier, dann können wir die auch schnell und zielgerichtet helfen !
Member: Looser27
Looser27 Jul 05, 2018 at 18:02:48 (UTC)
Goto Top
Oder mit

freeradius -XXX

eine komplette Debug-Ausgabe bekommen.

Dann kannst Du jeden Schritt des Freeradius Im Detail verfolgen.
Member: Dante2191
Dante2191 Jul 06, 2018 at 08:30:41 (UTC)
Goto Top
Hallo zusammen und vielen Dank für die schnellen Antworten.
Die Funktion des Raius hab ich über die in der Anleitung angegebenen Befehle getestet. Alle werden erfolgreich durchgeführt.
Eine Anfrage mit NTRadPing wird auch erfolgreich bearbeitet.
@aqui: Meiner Meinung nach ist es sinnvoller abzuwarten, welche Ausgaben für die Erfahrenen benötigt werden. Bringt ja keinem was wenn ich 10 Seiten Logs hier poste, die keinen weiterbringen face-wink

Im Debug-Mode wird der Dienst ohne Fehlermeldungen hochgefahren. Im Anschluss das Log bei einer Anfrage:
rad_recv: Access-Request packet from host 172.16.1.1 port 57983, id=51, length=106
        Service-Type = Login-User
        User-Name = "User123"  
        CHAP-Challenge = 0xc25ad67ca78ae926f48966582ad4c64b
        CHAP-Password = 0x00b7b9903234145565e0cabd68fbbecde1
        Calling-Station-Id = "192.168.1.1"  
        NAS-Identifier = "Device1"  
        NAS-IP-Address = 172.16.1.1
Fri Jul  6 09:58:20 2018 : Info: # Executing section authorize from file /etc/freeradius/sites-enabled/default
Fri Jul  6 09:58:20 2018 : Info: +group authorize {
Fri Jul  6 09:58:20 2018 : Info: ++[preprocess] = ok
Fri Jul  6 09:58:20 2018 : Info: [chap] Setting 'Auth-Type := CHAP'  
Fri Jul  6 09:58:20 2018 : Info: ++[chap] = ok
Fri Jul  6 09:58:20 2018 : Info: ++[mschap] = noop
Fri Jul  6 09:58:20 2018 : Info: ++[digest] = noop
Fri Jul  6 09:58:20 2018 : Info: [suffix] No '@' in User-Name = "User123", looking up realm NULL  
Fri Jul  6 09:58:20 2018 : Info: [suffix] No such realm "NULL"  
Fri Jul  6 09:58:20 2018 : Info: ++[suffix] = noop
Fri Jul  6 09:58:20 2018 : Info: [eap] No EAP-Message, not doing EAP
Fri Jul  6 09:58:20 2018 : Info: ++[eap] = noop
Fri Jul  6 09:58:20 2018 : Info: [files] users: Matched entry DEFAULT at line 51
Fri Jul  6 09:58:20 2018 : Info: ++[files] = ok
Fri Jul  6 09:58:20 2018 : Info: ++[expiration] = noop
Fri Jul  6 09:58:20 2018 : Info: ++[logintime] = noop
Fri Jul  6 09:58:20 2018 : Info: [pap] WARNING! No "known good" password found for the user.  Authentication may fail because of this.  
Fri Jul  6 09:58:20 2018 : Info: ++[pap] = noop
Fri Jul  6 09:58:20 2018 : Info: +} # group authorize = ok
Fri Jul  6 09:58:20 2018 : Info: Found Auth-Type = CHAP
Fri Jul  6 09:58:20 2018 : Info: # Executing group from file /etc/freeradius/sites-enabled/default
Fri Jul  6 09:58:20 2018 : Info: +group CHAP {
Fri Jul  6 09:58:20 2018 : Info: [chap] login attempt by "User123" with CHAP password  
Fri Jul  6 09:58:20 2018 : Info: [chap] Cleartext-Password is required for authentication
Fri Jul  6 09:58:20 2018 : Info: ++[chap] = invalid
Fri Jul  6 09:58:20 2018 : Info: +} # group CHAP = invalid
Fri Jul  6 09:58:20 2018 : Info: Failed to authenticate the user.
Fri Jul  6 09:58:20 2018 : Auth: Login incorrect (rlm_chap: Clear text password not available): [User123/<CHAP-Password>] (from client Netgroup port 0 cli 192.168.1.1)
Fri Jul  6 09:58:20 2018 : Info: Using Post-Auth-Type Reject
Fri Jul  6 09:58:20 2018 : Info: # Executing group from file /etc/freeradius/sites-enabled/default
Fri Jul  6 09:58:20 2018 : Info: +group REJECT {
Fri Jul  6 09:58:20 2018 : Info: [eap] Request didn't contain an EAP-Message, not inserting EAP-Failure  
Fri Jul  6 09:58:20 2018 : Info: ++[eap] = noop
Fri Jul  6 09:58:20 2018 : Info: [attr_filter.access_reject]    expand: %{User-Name} -> User123
Fri Jul  6 09:58:20 2018 : Debug: attr_filter: Matched entry DEFAULT at line 11
Fri Jul  6 09:58:20 2018 : Info: ++[attr_filter.access_reject] = updated
Fri Jul  6 09:58:20 2018 : Info: +} # group REJECT = updated
Fri Jul  6 09:58:20 2018 : Info: Delaying reject of request 1 for 1 seconds
Fri Jul  6 09:58:20 2018 : Debug: Going to the next request
Fri Jul  6 09:58:20 2018 : Debug: Waking up in 0.9 seconds.
Fri Jul  6 09:58:21 2018 : Info: Sending delayed reject for request 1
Sending Access-Reject of id 51 to 172.16.1.1 port 57983
Fri Jul  6 09:58:21 2018 : Debug: Waking up in 4.9 seconds.
Fri Jul  6 09:58:26 2018 : Info: Cleaning up request 1 ID 51 with timestamp +2368
Fri Jul  6 09:58:26 2018 : Info: Ready to process requests.

Fehlerursache würde ich somit auf die Zeile 32 setzen. Frage ist jetzt nur wie ich die Kommunikation zwischen Radius und AD bearbeite, damit die Passwörter nicht im Klartext übertragen werden.
Danke und Grüße
Member: Looser27
Looser27 Jul 06, 2018 at 11:23:37 (UTC)
Goto Top
Du hast die ntlm_auth nicht implementiert. Somit funktioniert die Authentifizierung gegen das AD nicht.
Sicher, dass winbind und samba laufen?`

Du solltest die Anleitung nochmal Schritt für Schritt durchgehen und 1:1 umsetzen. Habe ich gerade nochmal gemacht und der Radius rennt auf anhieb!

Gruß

Looser
Member: BitBurg
BitBurg Jul 07, 2018 at 07:38:49 (UTC)
Goto Top
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.
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"
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
Member: Looser27
Looser27 Jul 07, 2018 updated at 13:15:40 (UTC)
Goto Top
Zitat von @BitBurg:

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:
User123       Cleartext-Password := "XXX"
Damit könnte der User lokal , also auf dem FreeRADIUS, authentifiziert werden. CHAP geht allerdings nicht gegen die Active Directory.


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
Member: Dante2191
Dante2191 Jul 09, 2018 at 13:22:18 (UTC)
Goto Top
Hallo an alle,
ich habe noch den Firewall-Log kontrolliert. Vom Radius gehen keine Anfragen an das ActiveDirectory. Somit muss der Fehler ja innerhalb des Radius liegen.
Zu den offenen Punkten:
- ntlm_auth ist wie in der Anleitung beschrieben konfiguriert
- Samba (smbd) und Winbind laufen
- Die Passwörter sind korrekt hinterlegt
@looser: Welchen Aufbau hast du für deinen Test verwendet? MikroTik->Freeradius->AD?
Grüße
Member: Looser27
Looser27 Jul 09, 2018 updated at 17:19:37 (UTC)
Goto Top
Ich habe den Freeradius erst letzte Woche nach einem Serverumzug genau nach Anleitung gebaut.
APs sind unifi. Ad ist ms Server 2016.

Getestet mit Ntrad Test wie in der Anleitung.

Welches OS hast Du genommen? Mit Ubuntu 18.04 geht die Anleitung nämlich nicht!
Member: Dante2191
Dante2191 Jul 10, 2018 at 12:21:03 (UTC)
Goto Top
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.
Member: aqui
aqui Jul 10, 2018 updated at 13:13:28 (UTC)
Goto Top
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
Member: Dante2191
Dante2191 Jul 10, 2018 at 13:40:09 (UTC)
Goto Top
Ja, "Klartextpasswort" insofern, dass das PW im Radius-Log im Klartext angezeigt wird.
Am DC finde ich in der Ereignisanzeige keine Anmeldeversuche. Es scheint als ob der Radius nicht versteht, was er mit der Anfrage machen soll und sieht lediglich in seiner Users-Datei nach, wo der User nicht zu finden ist, weil ja eine Authentifizierung gegen das AD gewollt ist.
Grüße
Member: Looser27
Looser27 Jul 10, 2018 updated at 15:44:07 (UTC)
Goto Top
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:
> 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?
Member: Dante2191
Dante2191 Jul 11, 2018 at 05:50:55 (UTC)
Goto Top
Ja, die User können abgerufen werden. Generell laufen alle Befehle, die in der Anleitung gelistet sind sauber durch.
Member: Looser27
Looser27 Jul 11, 2018 at 07:24:04 (UTC)
Goto Top
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}"
Member: BitBurg
BitBurg Jul 11, 2018, updated at Jul 12, 2018 at 07:38:51 (UTC)
Goto Top
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.
Access-Request packet from host 172.16.1.1 port 54017, id=17, length=106
User-Name = "User123  
CHAP-Challenge = 0xa194fdfbc5dc35e81661c1b2016b07fa
CHAP-Password = 0x00e2f7ff9586185deb4de85a9650912353
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.
[chap] Setting 'Auth-Type := CHAP'  
++[chap] = ok
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.
[files] users: Matched entry DEFAULT at line 49
++[files] = ok
Found Auth-Type = CHAP
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.
+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
Deine Datei users auf auf dem FreeRADIUS-Server müsste beispielsweise also folgenden Inhalt haben:
alice		Cleartext-Password := "passme"  

DEFAULT		Auth-Type := ntlm_auth
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
Member: Dante2191
Dante2191 Jul 11, 2018 at 13:37:53 (UTC)
Goto Top
Hi BitBurg und danke für den Hammer-Beitrag.
In der Zeile 49 hab ich wie in deinem Beispiel folgende Zeile in der Users-Datei geändert:
Lt. Anleitung:
DEFAULT Auth-Type = ntlm_auth 
...

in
DEFAULT Auth-Type := ntlm_auth 
...

Somit wären wir schon mal einen Schritt weiter:
rad_recv: Access-Request packet from host 172.16.1.1 port 34329, id=28, length=102
        Service-Type = Login-User
        User-Name = "User123"  
        CHAP-Challenge = 0x8bb8a1000999b8ce6abe8c88e5549dcf
        CHAP-Password = 0x0026c2e251c5ba987755c31f6e0dfa17a5
        Calling-Station-Id = "192.168.1.1"  
        NAS-Identifier = "NAS-Device"  
        NAS-IP-Address = 172.16.1.1
Wed Jul 11 13:40:26 2018 : Info: # Executing section authorize from file /etc/freeradius/sites-enabled/default
Wed Jul 11 13:40:26 2018 : Info: +group authorize {
Wed Jul 11 13:40:26 2018 : Info: ++[preprocess] = ok
Wed Jul 11 13:40:26 2018 : Info: [chap] Setting 'Auth-Type := CHAP'  
Wed Jul 11 13:40:26 2018 : Info: ++[chap] = ok
Wed Jul 11 13:40:26 2018 : Info: ++[mschap] = noop
Wed Jul 11 13:40:26 2018 : Info: ++[digest] = noop
Wed Jul 11 13:40:26 2018 : Info: [suffix] No '@' in User-Name = "User123", looking up realm NULL  
Wed Jul 11 13:40:26 2018 : Info: [suffix] No such realm "NULL"  
Wed Jul 11 13:40:26 2018 : Info: ++[suffix] = noop
Wed Jul 11 13:40:26 2018 : Info: [eap] No EAP-Message, not doing EAP
Wed Jul 11 13:40:26 2018 : Info: ++[eap] = noop
Wed Jul 11 13:40:26 2018 : Info: [files] users: Matched entry DEFAULT at line 49
Wed Jul 11 13:40:26 2018 : Info: ++[files] = ok
Wed Jul 11 13:40:26 2018 : Info: ++[expiration] = noop
Wed Jul 11 13:40:26 2018 : Info: ++[logintime] = noop
Wed Jul 11 13:40:26 2018 : Info: [pap] WARNING! No "known good" password found for the user.  Authentication may fail because of this.  
Wed Jul 11 13:40:26 2018 : Info: ++[pap] = noop
Wed Jul 11 13:40:26 2018 : Info: +} # group authorize = ok
Wed Jul 11 13:40:26 2018 : Info: Found Auth-Type = ntlm_auth
Wed Jul 11 13:40:26 2018 : Info: # Executing group from file /etc/freeradius/sites-enabled/default
Wed Jul 11 13:40:26 2018 : Info: +group authenticate {
Wed Jul 11 13:40:26 2018 : Info: [ntlm_auth]    expand: --username=%{mschap:User-Name} -> --username=User123
Wed Jul 11 13:40:26 2018 : Info: [ntlm_auth]    expand: --password=%{User-Password} -> --password=
Wed Jul 11 13:40:26 2018 : Debug: Exec output: NT_STATUS_WRONG_PASSWORD: Wrong Password (0xc000006a)
Wed Jul 11 13:40:26 2018 : Debug: Exec plaintext: NT_STATUS_WRONG_PASSWORD: Wrong Password (0xc000006a)
Wed Jul 11 13:40:26 2018 : Info: [ntlm_auth] Exec: program returned: 1
Wed Jul 11 13:40:26 2018 : Info: ++[ntlm_auth] = reject
Wed Jul 11 13:40:26 2018 : Info: +} # group authenticate = reject
Wed Jul 11 13:40:26 2018 : Info: Failed to authenticate the user.
Wed Jul 11 13:40:26 2018 : Info: Using Post-Auth-Type Reject
Wed Jul 11 13:40:26 2018 : Info: # Executing group from file /etc/freeradius/sites-enabled/default
Wed Jul 11 13:40:26 2018 : Info: +group REJECT {
Wed Jul 11 13:40:26 2018 : Info: [eap] Request didn't contain an EAP-Message, not inserting EAP-Failure  
Wed Jul 11 13:40:26 2018 : Info: ++[eap] = noop
Wed Jul 11 13:40:26 2018 : Info: [attr_filter.access_reject]    expand: %{User-Name} -> User123
Wed Jul 11 13:40:26 2018 : Debug: attr_filter: Matched entry DEFAULT at line 11
Wed Jul 11 13:40:26 2018 : Info: ++[attr_filter.access_reject] = updated
Wed Jul 11 13:40:26 2018 : Info: +} # group REJECT = updated
Wed Jul 11 13:40:26 2018 : Info: Delaying reject of request 5 for 1 seconds
Wed Jul 11 13:40:26 2018 : Debug: Going to the next request
Wed Jul 11 13:40:26 2018 : Debug: Waking up in 0.9 seconds.
Wed Jul 11 13:40:27 2018 : Info: Sending delayed reject for request 5
Sending Access-Reject of id 28 to 172.16.1.1 port 34329
Wed Jul 11 13:40:27 2018 : Debug: Waking up in 4.9 seconds.
Wed Jul 11 13:40:32 2018 : Info: Cleaning up request 5 ID 28 with timestamp +165
Wed Jul 11 13:40:32 2018 : Info: Ready to process requests.

SOLL-Zustand wäre folgender:
1. Eine AD-Gruppe XY wird mit mehreren Usern gefüllt.
2. Ein User aus der Gruppe XY will sich nun an einem Endgerät (z.B. MikroTik) anmelden.
3. Der MikroTik konsultiert den Radius welcher Benutzername, Passwort und Zugehörigkeit zur AD Gruppe XY prüfen soll
4. Wenn die Kriterien erfüllt sind, ist die Anmeldung am Endgerät erfolgreich.
5. Dies soll natürlich möglichst sicher erfolgen. (Keine unverschlüsselte PW-Übertragung, usw...)

So wie ich dich verstanden habe, ist es wohl so nicht möglich, es sei denn ich bekomme das CHAP-Verfahren aus dem Spiel. Wäre die Erweiterung des Radius um eine SQL-Datenbank eine Alternative oder liegen in dieser die Passwörter ebenso unverschlüsselt?
Danke und Grüße
Member: Pjordorf
Pjordorf Jul 11, 2018 at 13:50:14 (UTC)
Goto Top
Hallo,

Zitat von @Dante2191:
liegen in dieser die Passwörter ebenso unverschlüsselt?
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
Member: Dante2191
Dante2191 Jul 12, 2018 at 07:21:03 (UTC)
Goto Top
Hi Pjordorf,
dass die PWs im AD nicht unverschlüsselt hinterlegt sind, ist mir klar.
Mir geht es um den Fall dass wenn das CHAP-Verfahren nicht mit meinem SOLL-Zustand lauffähig ist.
Grüße
Member: BitBurg
BitBurg Jul 12, 2018 updated at 08:11:01 (UTC)
Goto Top
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.
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
GermanQuestionLinux ToolsLinux
Hotly discussed
gleixnerdCheck of ZFW Firewallgleixnerd - 5 CommentsjstrickerWireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments