Netscaler 12.0 authentication issues with Azure MFA

[Hans Booms]

Hi there,

 

I am having trouble with a Netscaler 12.0 53.13nc authenticating with Azure MFA (NPS Extension).

 

As far as I know, I configured the NPS server and the Netscaler correctly but when I login with a test user and the second authentication is approved, I get the message "Incorrect username and Password".

 

Reviewing the logs I can see the error message 4001 as shown in below screenshot.

 

The strange thing here is, when I check with wireshark, the Netscaler recieves an "Acces-Accept" from the NPS server but still gives an error 4001.

 

 

What am I missing here?

 

The infrastructure is pretty simple:

1x Netscaler Gateway

1x NPS Server

1x Storefront / Controller

 

Grtz,

Hans

 

[Jonathan Clark1709155079]

What is your timeout setting for the NetScaler for the Radius response?  I had issues with this awhile back.  Make sure to check the ENTIRE chain in the network for timeouts.  We had to set it at the NetScaler (60 second is recommend IIRC) AND the Firewall since the firewall was smart enough to detect it as RADIUS and kill the connection after 4 seconds even though the response was being sent back properly.  

[Julian Jakob]

Hi,

 

I have exactly the same issue. Using ADC 12.1 48.13. Wireshark and NPS Logs are saying "Radius accepted" - so everything is good. ADC is saying "4001 invalid credentials". Tested with nFactor (First LDAP with SingleAuth Login Schema followed by RADIUS (NPS) and "normal" behaviour LDAP as first factor and RADIUS (NPS) as second. No difference.

 

Set the RADIUS timeout on the ADC up to 60 Seconds and also in the RADIUS Service at our CheckPoint Firewall up to 120 Seconds (default is 40 seconds) but with no improvement.

 

Very happy for all kind of ideas to get this fixxed.

 

Thanks and Regards

Julian

[vin pathak]

Hi There - just wondering if there was ever a resolution found for this?

 

We're expreiencing the same issue (having changed all timeouts to 60s and/or 120s as well)

 

cheers

[Jochen Hoffmann]

Hi All, 

 

as @jonathanbclark1 said before, check ADC's timeout settings. With Azure MFA and things like Authenticator App Accept or text message or phone call, the default timeout for RADIUS-AUTH of three secs is far too small. And, another (older) finding, especially w/ RADIUS-AUTH: are there any "special" chars, like german umlauts or french accents, in username or password? I've often seen the latter. This, too, will trigger an access-reject condition w/ ADC. 

 

Good luck, 

Jochen.

[vin pathak]

Thanks Jochen, 

 

i managed to get a hold of Citrix support, and working with them atm. 

 

- timeout settings across the board were set at 60s

- in my desperation, i'd previously set the password to use non-special characters (and sticking with that for now). 

- interestingly, even if we disable Azure MFA and switch to PAP to JUST auth against RADIUS, the wireshark logs reflect a jibberish pw token being sent (even when i apply the shared secret). 

- Citrix are forwading it to their devs to interrogate, but have flagged a potential bug. looks like we're upgrading. 

 

i have a different post on this forum for this query, but thought id give an update. i may simply post the outcome on this one when i'm done though - thanks Jochen.

[Wout Vergauwen1709159387]

Did anyone make any progress on this? Or try nFactor?

 

Thanks.

[vin pathak]

On 3/6/2020 at 5:16 AM, Wout Vergauwen1709159387 said:

Did anyone make any progress on this? Or try nFactor?

 

Thanks.

@wvergau34 - the outcomes here with Citrix support was that this was a bug with the OS. 

the config was correct, however with  12.0 53.13, when you configure a RADIUS server, and input the 'shared secret' there is the option to 'test' the connection. 

the feedback i got from Citrix was:

• if you click 'test', it will say 'successful', but the bug kicks in and the connection wont work
• if you DONT click 'test', then the secret saves correctly and the connection works without issue. 

indeed, this resolved the issue for us...

according to support this was fixed in the next OS release...

 

Sorry for the late update!