Slow Authentication using RADIUS 2FA and custom UPN suffixes

[CloudOffice]

I have a multi-tenant view implementation that uses a RADIUS based 2FA and custom UPN suffixes for each tenant.  If logging in with the old style DOMAIN\SAMAccountName, authentication is instant and the user is passed through to their VDI pool without issue.  If logging in with the custom UPN suffix (user@mycompany.com) the 2FA authentication is instant (verified with the 2FA provider and logging), but there is about a 45 second delay before the user is authenticated against view and passed through to the pool.

I've read several posts that reference a general issue with custom UPN suffixes, and am looking for direction to try to sort the issue out or a workaround for the time being (that will still use the custom UPN suffix)

TIA

[CloudOffice]

I should add that if I disable the 2FA, logging in with the custom UPN suffix is instant as well.  With the 2FA enabled, but logging in using DOMAIN\Username the full auth is instant.  The only case where it breaks is 2FA enabled, using custom UPN suffix.

[mpryor]

Can you attach the connection server debug log, so that we can see where the delay is coming from?

[markbenson · Accepted solution]

Is the 45 second delay before or after the subsequent username password prompt?

RADIUS delays can be caused by setting a non zero accounting port for a RADIUS server that doesn't support RADIUS accounting. If your RADIUS server does not support accounting on the specified port, set it to zero to disable it.

If the delay is after the username password prompt it is probably something else.  Is mycompany.com resolvable in DNS? If you disable RADIUS authentication is UPN login also slow?

As Mike says, the logs should also help.

Mark

[CloudOffice]

Indeed, digging through the log bundle, I see a timeout on accounting (strange that it only happens in this specific use case.)

I've attached the debug, I'm checking the accounting settings now

[CloudOffice]

That was completely it!  Set accounting port to 0 and I pass through instantly now.

Thanks for the help - I'm not going to dwell on why it wasn't an issue when not using the UPN

[gmtx]

Thanks for posting this Mark! I've had the same issue using Symantec VIP Access and just didn't have time to troubleshoot. Setting the Accounting Port to 0 fixed it for me as well. (might be something VMware adds to the install docs.)

Geoff

[markbenson]

Glad it solved it for you as well. Thanks for posting!

This info is in the View docs, but I appreciate that you have to go through the RADIUS setup documentation to find it. It's in the View Admin Guide on page 43.

It says:

Set Accounting port to 0 unless you want to enable RADIUS accounting. Set this port to a nonzero number only if your RADIUS server supports collecting accounting data. If the RADIUS server does not support accounting messages and you set this port to a nonzero number, the messages will be sent and ignored and retried a number of times, resulting in a delay in authentication.

Hope this helps.

Mark

[gmtx]

Quite right - I totally missed that paragraph in the docs when I set up 2FA. Thanks for pointing it out.

Geoff