WLAN, Radius Zugang für Computer geht nicht mehr

german
problem

#1

Hallo!
Hab hier ein Problem mit unserem Radius. Der lässt meiner bisher gut funktionierenden Computer-Accounts auf einmal nicht mehr durch. Normale Benutzer funktionieren nach wie vor. An den Computern Clients hat sich nichts geändert. Zertifikate sind gültig. Den Clients ist der Zugang gestattet…

/var/log/freeradius/radius.log gibt folgenden Fehler aus:

Thu Aug  1 15:12:50 2019 : ERROR: (108) mschap: ERROR: Program returned code (1) and output 'Logon failure (0xc000006d)'
Thu Aug  1 15:12:50 2019 : Auth: (108)   Login incorrect (mschap: Program returned code (1) and output 'Logon failure (0xc000006d)'): [host/MEINHOST/<via Auth-Type = eap>] (from client MEINAP port 0 via TLS tunnel)
Thu Aug  1 15:12:50 2019 : Info: (109) eap_peap:   The users session was previously rejected: returning reject (again.)
Thu Aug  1 15:12:50 2019 : Info: (109) eap_peap:   This means you need to read the PREVIOUS messages in the debug output
Thu Aug  1 15:12:50 2019 : Info: (109) eap_peap:   to find out the reason why the user was rejected
Thu Aug  1 15:12:50 2019 : Info: (109) eap_peap:   Look for "reject" or "fail".  Those earlier messages will tell you
Thu Aug  1 15:12:50 2019 : Info: (109) eap_peap:   what went wrong, and how to fix the problem
Thu Aug  1 15:12:50 2019 : Auth: (109) Login incorrect (eap: Failed continuing EAP PEAP (25) session.  EAP sub-module failed): [host/MEINHOST/<via Auth-Type = eap>] (from client MEINAP  port 0 cli F8-63-3F-51-59-7D)

Während /var/log/univention/radius_ntlm_auth.log dazu folgendes sagt:

2019-08-01 15:15:16,967 - radius-ntlm -      DEBUG: [pid=16916; user=meinhost$; mac=f8:63:3f:51:59:7d] Given username: "host/meinhost.meine.domäne.de"
2019-08-01 15:15:16,967 - radius-ntlm -      DEBUG: [pid=16916; user=meinhost$; mac=f8:63:3f:51:59:7d] Given stationId: "F8-63-3F-51-59-7D"
2019-08-01 15:15:16,967 - radius-ntlm -      DEBUG: [pid=16916; user=meinhost$; mac=f8:63:3f:51:59:7d] UCS@school RADIUS support is not installed
2019-08-01 15:15:16,968 - radius-ntlm -      DEBUG: [pid=16916; user=meinhost$; mac=f8:63:3f:51:59:7d] Checking LDAP settings for user
2019-08-01 15:15:16,968 - radius-ntlm -      DEBUG: [pid=16916; user=meinhost$; mac=f8:63:3f:51:59:7d] ALLOW 'cn=MEINHOST,ou=eineOU,dc=meine,dc=domäne,dc=de'
2019-08-01 15:15:16,969 - radius-ntlm -      DEBUG: [pid=16916; user=meinhost$; mac=f8:63:3f:51:59:7d] -> DENY 'cn=Windows Hosts,cn=groups,dc=meine,dc=domäne,dc=de'
2019-08-01 15:15:16,970 - radius-ntlm -      DEBUG: [pid=16916; user=meinhost$; mac=f8:63:3f:51:59:7d] -> -> DENY 'cn=Authenticated Users,cn=Builtin,dc=meine,dc=domäne,dc=de'
2019-08-01 15:15:16,970 - radius-ntlm -       INFO: [pid=16916; user=meinhost$; mac=f8:63:3f:51:59:7d] Login attempt permitted by LDAP settings
2019-08-01 15:15:16,970 - radius-ntlm -      DEBUG: [pid=16916; user=meinhost$; mac=f8:63:3f:51:59:7d] MAC filtering is disabled by radius/mac/whitelisting.
2019-08-01 15:15:16,970 - radius-ntlm -       INFO: [pid=16916; user=meinhost$; mac=f8:63:3f:51:59:7d] User is allowed to use RADIUS

Bis vor kurzem lief es. Ich muss da gerade so wage bleiben, da wir nur ein paar Clients mit Computer-Authentifizierung im WLAN haben und die werden selten benutzt. Wenn ich argwöhnen müsste, dann würde ich sagen seit dem Update auf 4.4 geht es nicht mehr.

Hab ich was im Changelog übersehen? Kann ich Infos nachliefern die hilfreicher sind?

Steh gerade recht ratlos da…


#2

In der Regel würde ich in jetzt schreiben: “freeradius stoppen, im Debugmodus mit “freeradius -X | tee /tmp/radius-debug” starten, Anmeldung versuchen, output pasten”. Ich vermute anhand der radius.log, dass /usr/bin/univention-ntlm-auth der Grund für den reject von FreeRADIUS ist. (Mit ‘tee’ leitest die Ausgabe zusätzlich in eine Datei um, was für die Analyse hilfreich ist.)

Versuche es einmal und such in der Ausgabe nach ACCESS-REJECT. Bei dem Punkt angekommen spulst du die Logs rückwärts und müsstest an einer Stelle finden, wo und warum FreeRADIUS genau rejectet hat. Du müsstest in dessen Nähe auch den Text aus radius.log finden:

 mschap: ERROR: Program returned code (1) and output 'Logon failure (0xc000006d)'

Etwas weiter oben in den Debuglogs solltest du eine Meldung bekommen, dass univention-ntlm-auth mit bestimmten Parametern aufgeführt wurde (du solltest sogar sehen, mit welchen Optionen genau)

Was passiert hier nun? UCS prüft die Zutrittsberechtigung anhand des Scripts univention-ntlm-auth. Es führt dabei nicht nur die MSCHAPv2 challenge durch, die der Client schickt, sondern prüft anhand der Attribute im LDAP auch, ob das System Netzwerkzugriff haben soll.

Du solltest /usr/bin/univention-radius-ntlm-auth mit den genauen Optionen aufrufen können, wie es FreeRADIUS gem. Debuglog dir anzeigt und ebenfalls “Logon failure (0xc000006d)” bekommen. - Damit bist du dir sicher, dass es wirklich daran scheitert, deine Logs zeigen aber in diese Richtung.

radius_ntlm_auth.log sagt eigentlich, dass die LDAP-basierte Abfrage für die Berechtigung OK ist, aber nicht, ob die MSCHAPv2 challenge erfolgreich war. Ich vermute, dass es bei der Prüfung der Challenge jetzt noch umfällt, aber das ist jetzt ohne weitere Infos an der Stelle eher noch eine Vermutung.

Das Script bindet zwei Python-Module ein, die du ebenfalls auf deinem System, aber auch auf Github finden kannst.

Über networkaccess.py liest es aus dem LDAP das sambaNTPassword der Maschine in OpenLDAP aus und führt die Challenge über pyMsChapv2.py durch und vergleicht, ob das Passwort und das “gesendete Passwort” (es ist eine MSCHAPv2 challenge), gleich sind.

Vermutlich hapert es da jetzt noch. Du kannst das sambaNTPassword auch über univention-ldapsearch -LLL cn=meinhost sambaNTPassword auslesen.


#3

Hey,
erstmal vielen Dank für die Antwort!

Ich hab mich mal durch deine Hinweise/Anweisungen gehangelt:

Im in der Ausgabe von freeradius -X findet sich:

mschap: ERROR: Program returned code (1) and output 'Logon failure (0xc000006d)'
(8) mschap: External script failed
(8) mschap: ERROR: External script says: Logon failure (0xc000006d)
(8) mschap: ERROR: MS-CHAP2-Response is incorrect

Kurz darüber ist zwar nicht “univention-radius-ntlm-auth” sondern:

ntlm_auth = "/usr/bin/univention-radius-ntlm-auth-suidwrapper --request-nt-key --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00} --station-id=%{outer.request:Calling-Station-Id}"

Aber den Befehl erneut mit entsprechend ersetzten Parametern ausgeführt gibt bei mir in der Tat ein:

Logon failure (0xc000006d)

Ist damit die Vermutung bestätigt das die Prüfung der Challenge schief läuft?

Den Punkt mit den beiden Python Skripten (networkaccess.py und pyMSChapv2.py hab ich nicht verstanden. Das ausgelesene sambaNTPassword über univention-ldapsearch -LLL cn=meinhost sambaNTPassword kann ich nirgends in den Logs finden. Sollte es da als MSCHAPv2 Challenge auftauchen und passend sein?

Schöne Grüße!


#4

Ich hatte gestern kein Testsetup vor mir. Du müsstest in den debuglogs so etwas ähnliches finden, mein Testuser hat das Passwort “Aa123456”

(8) eap: Calling submodule eap_mschapv2 to process data
(8) eap_mschapv2: # Executing group from file /etc/freeradius/3.0/sites-enabled/inner-tunnel
(8) eap_mschapv2:   Auth-Type MS-CHAP {
(8) mschap: Found NT-Password
(8) mschap: Creating challenge hash with username: bob
(8) mschap: Client is using MS-CHAPv2
(8) mschap: Executing: /usr/bin/univention-radius-ntlm-auth-suidwrapper --request-nt-key --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00} --station-id=%{outer.request:Calling-Station-Id}:
(8) mschap: EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}}
(8) mschap:    --> --username=bob
(8) mschap: Creating challenge hash with username: bob
(8) mschap: EXPAND --challenge=%{%{mschap:Challenge}:-00}
(8) mschap:    --> --challenge=7cc54071023a1e4e
(8) mschap: EXPAND --nt-response=%{%{mschap:NT-Response}:-00}
(8) mschap:    --> --nt-response=0cd23d4ce06fccbb86f44182ab50424af883c83b2aa5bcb2
(8) mschap: EXPAND --station-id=%{outer.request:Calling-Station-Id}
(8) mschap:    --> --station-id=02-00-00-00-00-01
(8) mschap: Program returned code (0) and output 'NT_KEY: 677E605BFEB3EEB361E94F63C1EB5F6B'
(8) mschap: Adding MS-CHAPv2 MPPE keys
(8)     [mschap] = ok
(8)   } # Auth-Type MS-CHAP = ok
(8) MSCHAP Success

Daraus baust du dann den Befehl, der dann im Beispiel so aussehen würde:

 /usr/bin/univention-radius-ntlm-auth-suidwrapper  \
 --request-nt-key --username=bob --challenge=7cc54071023a1e4e \
 --nt-response=0cd23d4ce06fccbb86f44182ab50424af883c83b2aa5bcb2 \
 --station-id=02-00-00-00-00-01

Challenge, Response und Station-ID müsstest du anpassen. Aber klappt es so nicht, wäre die Vermutung effektiv bestätigt.

univention-radius-ntlm-auth-suidwrapper führt letztlich /usr/bin/univention-radius-ntlm-auth:

Das sambaNTPassword wirst du nicht in den Logs finden, nur die Challenge und Response*. Wenn es nicht klappt, wäre wohl das Maschinenpasswort zwischen UCS und der Maschine nicht gleich.

Das kann dann bedeuten, dass die Replikation zwischen S4 und OpenLDAP probleme hat. Die Domain-jointen Maschinen erneuern ihr Passwort selber regelmässig, und schicken es dann an den S4. Von dort kümmert sich dann der S4 connector darum, dass das Attributt sambaNTPassword im OpenLDAP aktualisiert wird.

Wenn du dich über das LAN verbindest, kannst du dich dann als Domänenuser anmelden? Kannst du gpupdate /force ohne Fehler ausführen?

Optional: Wenn du die berechnete response mit der übermittelten sehen willst, kannst du in einer Kopie von univention-radius-ntlm-auth gerade vor “if PasswordHash and…” folgendes einfügen:

print 'Response: %s' % (pyMsChapV2.ChallengeResponse(options.Challenge, PasswordHash).encode('hex'))

Wenn du diese veränderte Kopie mit gleichen Parametern ausführst, müsstest du die errechnete response sehen. Die gelieferte und die errechnete response müssen gleich sein.

(*) MSCHAPv2 benutzt unter der Haube noch DES, darum ist der äussere TLS-Tunnel bei Protected EAP (PEAP) leider so wichtig.


#5

Hey,
nochmals - vielen Dank für die Hilfe!

Lösender Hinweis war der Punkt, die Clients mal ins LAN zu holen. Nach dem Anstöpselns in LAN, anmelden, ‘gpupdate /force’ und anschließendem Neustart verband sich das WLAN wieder von ganz alleine. Offenbar haben die Rechner ihr Maschinenpasswort erneuert und beim Transport zu S4 ging was in die Hose.

Mir ist zwar noch nicht klar warum die Aktualisierung nicht stattgefunden hat - aber ich hab mal wieder was gelernt :wink: Danke.

Schöne Grüße!