06-25-2018 11:03 AM - edited 03-12-2019 05:24 AM
Hi-
Anyone here able to configure group-lock for Office 365 MFA-enabled users? I've seen several articles here on steps how to configure group-lock/tunnel-group-lock on Microsoft Radius server and steps works fine but not for Office 365 users that has MFA enabled.
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension-vpn
I suspect Radius attributes are not being sent to ASA as there is a second authentication that goes to Azure MFA.
Anyone experienced this?
Solved! Go to Solution.
06-27-2018 06:59 AM
Ok, are you using the OTP mechanism via mobile-app or one-way-text? If so, the Radius-challenge is sent back to the ASA so that the Anyconnect client can prompt you to enter the OTP. If you use the Mobile-app notification (no OTP required), then the ASA does not receive the challenge message and only receives the Access-Accept with all the attributes.
My theory is that the ASA takes the attributes from the Access-Challenge message instead of the final Access-Accept message that you receive. The Challenge message does not contain the Class (Group-Policy) attribute, so the ASA does not lock it to that group-policy.
Can you try two way text or Mobile app notification as secondary authentication in your environment?
06-25-2018 06:03 PM
What does the output of "debug radius all" show on the ASA when you connect? I have not done this, but the document mentions that Radius is used for authorization, so I can't think of how they would enforce that if they do not return something back to the NAS.
06-26-2018 11:55 AM
Hi Rahul,
I've attached the output for the user without MFA and the one with MFA. What's weird is that whenever I tried to run it on a user with MFA the putty session disconnects with an error "Incoming packet was garbled on decryption". Already tried below but no luck.
Go to Connection -> SSH -> Protocol options. Set “Preferred SSH protocol version:” to SSH version 2.
Go to Connection -> SSH -> Encryption options. Promote Blowfish to the top of the list of “Encryption cipher selection policy:”
BTW as you can see on the output, the one without MFA works fine. ASA was able to assign it on a certain group policy.
Thanks,
06-26-2018 05:53 PM
From your output, it looks like the Radius Challenge is sent back to the ASA instead of being sent to the client for the secondary auth.
ADIUS packet decode (response) -------------------------------------- Raw packet data (length = 98)..... 0b dc 00 62 d4 78 e1 16 c0 7b a8 b2 5f cb 9b 16 | ...b.x...{.._... b0 23 7f 5f 12 28 45 6e 74 65 72 20 59 6f 75 72 | ._.(Enter Your 20 4d 69 63 72 6f 73 6f 66 74 20 76 65 72 69 66 | Microsoft verif 69 63 61 74 69 6f 6e 20 63 6f 64 65 18 26 63 35 | ication code.&c5 34 34 63 32 62 65 2d 64 66 63 34 2d 34 33 62 62 | 44c2be-dfc4-43bb 2d 39 65 39 62 2d 34 62 32 33 33 66 32 38 30 37 | -9e9b-4b233f2807 31 34 | 14 Parsed packet data..... Radius: Code = 11 (0x0B) Radius: Identifier = 220 (0xDC) Radius: Length = 98 (0x0062) Radius: Vector: D478E116C07BA8B25FCB9B16B0237F5F Radius: Type = 18 (0x12) Reply-Message Radius: Length = 40 (0x28) Radius: Value (String) = 45 6e 74 65 72 20 59 6f 75 72 20 4d 69 63 72 6f | Enter Your Micro 73 6f 66 74 20 76 65 72 69 66 69 63 61 74 69 6f | soft verificatio 6e 20 63 6f 64 65 | n code Radius: Type = 24 (0x18) State Radius: Length = 38 (0x26) Radius: Value (String) = 63 35 34 34 63 32 62 65 2d 64 66 63 34 2d 34 33 | c544c2be-dfc4-43 62 62 2d 39 65 39 62 2d 34 62 32 33 33 66 32 38 | bb-9e9b-4b233f28 30 37 31 34 | 0714 rad_procpkt: CHALLENGE radius mkreq: 0x25e5 old request 0x25e5 --> 221 (0x00002aaad4dd1948), state 3 wait pass - pass '***'. make request RADIUS_REQUEST radius.c: rad_mkpkt rad_mkpkt: ip:source-ip=68.111.123.9
Are you getting the text/phone call for the secondary authentication ? The ASA should only receive the Access-Accept or Access-Reject in the end which has the attributes for the user from what the flow shows.
06-26-2018 08:20 PM
we've use the "mobile app" for the secondary authentication. This is how it looks like since I capture it also on wireshark.
10.50.16.3(internal) is the ASA and the other IP is for the Radius.
Here is the actual screenshot,(sorry I tried to change IP for security reasons but anyway here it is.:
112.199.74.38 is the IP where I tried to connect to VPN.
Thanks,
06-27-2018 06:59 AM
Ok, are you using the OTP mechanism via mobile-app or one-way-text? If so, the Radius-challenge is sent back to the ASA so that the Anyconnect client can prompt you to enter the OTP. If you use the Mobile-app notification (no OTP required), then the ASA does not receive the challenge message and only receives the Access-Accept with all the attributes.
My theory is that the ASA takes the attributes from the Access-Challenge message instead of the final Access-Accept message that you receive. The Challenge message does not contain the Class (Group-Policy) attribute, so the ASA does not lock it to that group-policy.
Can you try two way text or Mobile app notification as secondary authentication in your environment?
06-27-2018 07:04 AM - edited 06-27-2018 07:07 AM
We're using the verification code from mobile app for the secondary authentication. Okay, we'll try the other verification options. I'll let you know. Thanks
06-27-2018 07:12 AM
Try using the notification through mobile app method described below:
This should be the same from the ASA perspective as using no MFA.
06-27-2018 10:25 AM
Thanks Rahul. That did the trick. :)
03-06-2019 01:31 PM
I am having the same issue but in my case 90% on people prefer to use txt messages. Any workaround for this issue to make it work with TXT messages. The phone call and APP notification method work fine.
03-06-2019 01:32 PM
I am having the same issue but in my case 90% on people prefer to use txt messages. Any workaround for this issue to make it work with TXT messages. The phone call and APP notification method work fine.
01-29-2021 04:43 PM
I just spent an afternoon re-discovering this bug in NPS. The NPS server is the problem here; it is not actually respecting the settings and sending the attributes back down to the RADIUS client. If you take a close look at the logs on the NPS server, you'll see that when the MFA authentication succeeds, the log does NOT contain the name of the NPS policy---this is a signal that the NPS server has somehow lost the context surrounding the MFA authentication. It still has the right policy in its little MicroHead, but it does not follow through on the other parts of the policy. You can try complaining to Microsoft about it---this is very clearly a bug in NPS that is triggered by the MFA.
Joel Snyder
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide