Radtest returning "Expected Access-Accept got Access-Reject"

[NSimpraga]

Hi,

I managed to set up the Azure AD application and did all the configuration for the RADIUS server which I am running in a Ubuntu VM just for testing purposes for now. Thing is, my Azure AD freeradius app is showing successful sign-ins for the radtests I tried, but nevertheless radtest is returning: "Expected Access-Accept got Access-Reject"

One peculiar behaviour: When I restart radius and run a radtest, it gets a "No reply" message ONLY THE FIRST TRY, and the debug from freeradius -X says "Sent Access-Accept ID 119 from ... to...". When I try a second radtest, I get a Access-Reject from radtest and debug from freeradius -X also says a reject was sent.

No other error messages appear in the freeradius -X debug log, it seems like it just can't authorize for some reason.

Other noteworthy point: we have MFA enabled for our directory users, so radtests with MFA protected accounts fail with a message saying that MFA is preventing authorization, so I tested with a service account which does not have MFA enabled. This produces the above described scenario.

Any ideas here? Any other info you need?

[jimdigriz]

Going to need some of that radiusd -X debugging output goodness to look into this.

The troubleshooting section covers the peculiar behaviour of the first request timing out (this is expected) but the second request resulting in an Access-Reject is unexpected. The debugging output will shine light here; FreeRADIUS should strip sensitive data out of the output but do have a quick check to make sure.

FYI, I am pretty sure the MFA accounts will not work with this module so it may be a dead end for you. I'll add a note to the README.md to stop others being lured in under false pretence.

[NSimpraga]

Thank you for such a fast reply, godlike support! :)

Actually did a bit of digging on the output, not sure why but after disabling password caching in the proxy config it works properly!

I think after it successfully logs in the first time, the password gets cached badly and then it fails after that. Getting accepts from radtest after setting caching to no.

For the MFA, I turned off MFA in our directory just for the freeradius enterprise app and it works like a charm ;)

On to the 802.1x testing!

[jimdigriz]

Actually did a bit of digging on the output, not sure why but after disabling password caching in the proxy config it works properly!

Sounds like a bug, can you provide me with the debugging output as caching should work, and actually make things better.

[NSimpraga]

Hmm I am looking at the output but there is A LOT of internal info. Not just my credentials which are visible, but also internal group names and such. I'd like to help but don't feel comfortable posting this online. Is there an option or flag which turns off this sensitive info, or just gives less debug output? I am using freeradius -X command

[jimdigriz]

You okay with emailing me privately this information? You can pull my email address out from the commit log (via 'git log' on the CLI). Alternatively access to the system its-self?

[salihzett]

Regarding MFA, conditional access for MFA and setting this enterprise application as exception can resolve this.

[jimdigriz]

@NSimpraga and @salihzett, I have been able to replicate the problems you where having, it is described in https://github.com/jimdigriz/freeradius-oauth2-perl/issues/13

Can you pull the latest version of the code and retry it for me, thanks

[jimdigriz]

Oh, because of a bug in FR you need to compile from source :-/

Fortunately a workaround so you can continue to use 3.0.21 is to set the environment LC_ALL=C:

export LC_ALL=C
freeradius -X

When 3.0.22 is released (hopefully within the month), this will not be necessary.

[jimdigriz]

Closing as duplicate of https://github.com/jimdigriz/freeradius-oauth2-perl/issues/13 so any conversation about this should be moved there.