[RADIATOR] Cannot process multiple AuthBy sections during authentication request
S.Schwarz at lumc.nl
S.Schwarz at lumc.nl
Fri Sep 29 17:04:19 UTC 2017
Hi,
I hope someone can help me with the problem I'm having while trying to configure our new RADIUS environment.
I've attached my config file, it doesn't contain any shared secret or password.
Additional info:
Old servers: Windows 2008R2 - Radiator 4.14
New servers: Windows 2016 - Radiator 4.19
In our old configuration we have something like this:
<Handler Identifier=LUMCusers>
Identifier LUMCusers_AD
<AuthBy GROUP>
AuthByPolicy ContinueWhileReject
<AuthBy LSA>
EAPType MSCHAP-V2
DefaultDomain lumcnet
UsernameMatchesWithoutRealm
Group eduroam-wireless
AddToReply Tunnel-Type=1:VLAN,Tunnel-Medium-Type=1:Ether_802,Tunnel-Private-Group-ID=1:420
</AuthBy>
<AuthBy LSA>
EAPType MSCHAP-V2
DefaultDomain lumcnet
UsernameMatchesWithoutRealm
Group lumc-wireless-1
AddToReply Tunnel-Type=1:VLAN,Tunnel-Medium-Type=1:Ether_802,Tunnel-Private-Group-ID=1:281
</AuthBy>
</AuthBy>
</Handler>
Which actually works fine, if a user doesn't belong to the first group the next AuthBy LSA header will be called and checked. So I figured I'd reuse this part of the config file to keep things working as they are right now.
The reason we use that AuthBy GROUP with multiple AuthBy LSA sections is to distribute users across different VLAN's.
However using this construction on the new servers for the inner authentication requests to validate the user credentials actually fails.
In the logfiles I see something like this:
Fri Sep 29 18:44:47 2017: DEBUG: Handling request with Handler 'TunnelledByPEAP=1', Identifier 'Handler_PEAP'
Fri Sep 29 18:44:47 2017: DEBUG: Deleting session for testuser at lumc.nl<mailto:testuser at lumc.nl>, 10.250.88.245, 8
Fri Sep 29 18:44:47 2017: DEBUG: Handling with Radius::AuthHANDLER:
Fri Sep 29 18:44:47 2017: DEBUG: AuthBy HANDLER is redirecting to Handler 'Auth_ActiveDirectory2'
Fri Sep 29 18:44:47 2017: DEBUG: Handling request with Handler 'Identifier=^(Handler_PEAP|Handler_TTLS)$', Identifier 'Auth_ActiveDirectory2'
Fri Sep 29 18:44:47 2017: DEBUG: Deleting session for testuser at lumc.nl<mailto:testuser at lumc.nl>, 10.250.88.245, 8
Fri Sep 29 18:44:47 2017: DEBUG: Handling with Radius::AuthGROUP:
Fri Sep 29 18:44:47 2017: DEBUG: Handling with Radius::AuthLSA:
Fri Sep 29 18:44:47 2017: DEBUG: Handling with EAP: code 2, 9, 75, 26
Fri Sep 29 18:44:47 2017: DEBUG: Response type 26
Fri Sep 29 18:44:47 2017: DEBUG: Radius::AuthLSA looks for match with testuser [testuser at lumc.nl]
Fri Sep 29 18:44:47 2017: DEBUG: Checking LSA Group membership for \\LUMC-DC01<file://LUMC-DC01>, eduroam-wireless, testuser
Fri Sep 29 18:44:47 2017: DEBUG: Radius::AuthLSA REJECT: AuthBy LSA User is not a member of any Group: testuser [testuser at lumc.nl]
Fri Sep 29 18:44:47 2017: DEBUG: EAP Failure, elapsed time 0.044654
Fri Sep 29 18:44:47 2017: DEBUG: EAP result: 1, EAP MSCHAP V2 failed: no such user testuser
Fri Sep 29 18:44:47 2017: DEBUG: Radius::AuthGROUP: result: REJECT, EAP MSCHAP V2 failed: no such user testuser
Fri Sep 29 18:44:47 2017: DEBUG: Handling with Radius::AuthLSA:
Fri Sep 29 18:44:47 2017: DEBUG: Handling with EAP: code 2, 9, 75, 26
Fri Sep 29 18:44:47 2017: DEBUG: Response type 26
Fri Sep 29 18:44:47 2017: INFO: EAP Response type 26 in unexpected state. NAS did RADIUS server failover for an ongoing EAP authentication?
Fri Sep 29 18:44:47 2017: DEBUG: EAP Failure, elapsed time 0.000006
Fri Sep 29 18:44:47 2017: DEBUG: EAP result: 1, EAP Response type 26 in unexpected state. NAS did RADIUS server failover for an ongoing EAP authentication?
Fri Sep 29 18:44:47 2017: DEBUG: Radius::AuthGROUP: result: REJECT, EAP Response type 26 in unexpected state. NAS did RADIUS server failover for an ongoing EAP authentication?
Fri Sep 29 18:44:47 2017: DEBUG: AuthBy GROUP result: REJECT, EAP Response type 26 in unexpected state. NAS did RADIUS server failover for an ongoing EAP authentication?
Fri Sep 29 18:44:47 2017: DEBUG: AuthBy HANDLER result: REJECT, EAP Response type 26 in unexpected state. NAS did RADIUS server failover for an ongoing EAP authentication?
Fri Sep 29 18:44:47 2017: INFO: Access rejected for testuser at lumc.nl<mailto:testuser at lumc.nl>: EAP Response type 26 in unexpected state. NAS did RADIUS server failover for an ongoing EAP authentication?
Fri Sep 29 18:44:47 2017: DEBUG: Returned PEAP tunnelled packet dump:
Code: Access-Reject
I don't understand why it stops processing other AuthBy headers and returns a result that the user doesn't exist, since that's not the case.
I'be tried different AuthByPolicy settings all with the same result, I've tried it by not defining it at all, or by using ContinueWhileIgnore, ContinueWhileReject or ContinueUntilAcceptOrChallenge.
So then I tried something else to see if that works, which apparently does work. If I remove all additional AuthBy sections, I get a successful authentication
<Handler Identifier=^(Handler_PEAP|Handler_TTLS)$>
Identifier Auth_ActiveDirectory2
<AuthBy GROUP>
<AuthBy LSA>
# eduroam override
EAPType MSCHAP-V2
DefaultDomain lumcnet
UsernameMatchesWithoutRealm
Group eduroam-wireless
Group lumc-wireless-0
AddToReply Tunnel-Type=1:VLAN,Tunnel-Medium-Type=1:Ether_802,Tunnel-Private-Group-ID=1:420
</AuthBy>
</AuthBy>
</Handler>
This way I'd still be able to check whether users are part of a certain user group, but I cannot assign a different VLAN ID to specific user groups.
So not entirely desired, but at least I know that the validation part works.
The weird thing is that the whole AuthBy GROUP -> multiple AuthBy sections actually works for a different kind of request I process.
Our WLAN controllers usually forward their requests to another device (qmanage) which actually terminates the PEAP tunnel and then forwards the authentication request to me in order to validate it.
But I need this same configuration to work when the WLAN controllers are configured to forward their requests to my RADIUS servers when there's maintenance on that other system.
I've added some attachments, the old and new configurations along with log files showing the different results.
Hopefully this somewhat makes sense!
Kind regards,
Stephan Schwarz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.open.com.au/pipermail/radiator/attachments/20170929/a8232ecd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Radiator-Eduroam_2017-09-29 - qmanage example.log
Type: application/octet-stream
Size: 8842 bytes
Desc: Radiator-Eduroam_2017-09-29 - qmanage example.log
URL: <http://lists.open.com.au/pipermail/radiator/attachments/20170929/a8232ecd/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Radiator-Test_2017-09-29 - failure.log
Type: application/octet-stream
Size: 79200 bytes
Desc: Radiator-Test_2017-09-29 - failure.log
URL: <http://lists.open.com.au/pipermail/radiator/attachments/20170929/a8232ecd/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Radiator-Test_2017-09-29 - success.log
Type: application/octet-stream
Size: 43513 bytes
Desc: Radiator-Test_2017-09-29 - success.log
URL: <http://lists.open.com.au/pipermail/radiator/attachments/20170929/a8232ecd/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Config-DICT-TEST.CFG
Type: application/octet-stream
Size: 6756 bytes
Desc: Config-DICT-TEST.CFG
URL: <http://lists.open.com.au/pipermail/radiator/attachments/20170929/a8232ecd/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radius-old config.cfg
Type: application/octet-stream
Size: 11719 bytes
Desc: radius-old config.cfg
URL: <http://lists.open.com.au/pipermail/radiator/attachments/20170929/a8232ecd/attachment-0009.obj>
More information about the radiator
mailing list