We are having problems using the Azure MFA server for securing Radius authentication with RDGateway. Things work as expected for some users but others are having massive problems and we think we have narrowed it down to being related to where the user is trying to connect from. If you connect from a computer joined to the same domain as the RDS farm or from a workgroup/Azure AD joined computer things works great. If you however try to connect from a computer joined to another domain (any other domain) you will receive a timeout most of the time.
We have increased the timeouts on the Load Balancing tab of the radius server pointing to the MFA server in the NPS on the RD Gateway so that’s not the problem. When I look through the log files the Radius request is sent to the MFA server which in turn
pass it on to the target Radius server for authentication.
This is what I have in the MFA server log MultiFactorAuthRadiusSvc:
2015-11-26T17:25:36.427939Z|0|3860|4088|prfad|Event 3.
2015-11-26T17:25:36.427939Z|0|3860|4088|prfad|Sock 0x0000000000000110
2015-11-26T17:25:36.427939Z|0|3860|4088|pfrad|Code 1 - ACCESS_REQUEST.
2015-11-26T17:25:36.427939Z|i|3860|4088|pfrad|old id: 8, new id: 123
2015-11-26T17:25:36.427939Z|i|3860|4088|pfrad|Creating a new request_state for client x.x.243.196, port 62151, ID 8
2015-11-26T17:25:41.459265Z|w|3860|4088|pfrad|Timeout expired waiting for response from radius servers for client x.x.243.196, id 123
And then a little later
2015-11-26T17:25:51.428086Z|0|3860|4088|prfad|Event 3.
2015-11-26T17:25:51.428086Z|0|3860|4088|prfad|Sock 0x0000000000000110
2015-11-26T17:25:51.428086Z|0|3860|4088|pfrad|Code 2 - ACCESS_ACCEPT.
2015-11-26T17:25:51.428086Z|w|3860|4088|pfrad|Got response without a pending request. Dropping packet.
2015-11-26T17:25:51.428086Z|e|3860|4088|pfrad|processIncomingPacket failed.
So the request is actually granted it just took some time and the MFA gave up. The timeout is 5 seconds according to the log. According to the Security log on the NPS server it granted the request and the timeline is spot on.
The interesting thing is that looking through the security log at the RD Gateway, where the actual authentication will take place all of the requests that end up with I find 6278 Network Policy Server events where the Client Machine/Account Name is a FQDN.
Connecting with an Azure AD joined computer I get just the machine name.
I ran Wire Shark and it seems that the Radius server is trying to resolve the FQDN name of the computer or connect to an authority and of course it will not be able to do so and after some 10-20 seconds it times out and grants the request. The problem with
this is that the MFA server times out after 5 seconds and this doesn’t seem to be configurable.
The strange thing is that for the FQDN name it works sometimes but fails like 80% of the times. The workgroup computer always succeeds.
We had a ticket with MS in early 2012 about computers from another domain beeing slow connecting to RDS in another domain and they said this is “by design” and that the timeoutvalue in NPS is 20 seconds. Ideealy it would be nice to be able to turn this sort
of nonsense off but I would settle for being able to increase the timeout value on the MFA server.
The setup is all 2012R2
Here's what's going on towards ADDS:
02/24 15:52:37 [MISC] DsIGetDcName: Ignore single label DNS domain name ANYDOMAIN
02/24 15:52:37 [MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c01ffff1
02/24 15:52:37 [MAILSLOT] Sent 'Sam Logon' message to ANYDOMAIN[1C] on all transports.
02/24 15:52:37 [MISC] NetpDcGetName: NetpDcGetNameNetbios returned 121
02/24 15:52:44 [MAILSLOT] Sent 'Sam Logon' message to ANYDOMAIN[1C] on all transports.
02/24 15:52:44 [MISC] NetpDcGetName: NetpDcGetNameNetbios returned 121
02/24 15:52:52 [MISC] DsGetDcName function returns 1355: Dom:ANYDOMAIN Acct:(null) Flags: IP KDC