Always On VPN - Issues authenticating to on-prem resources from AAD Join machines

Question

We have an issue with our AAD Join W10 devices. This issue does not present itself on our domain joined machines. We have some on-prem applications that use Windows integrated authentication that sit behind an AWS elastic load balancer. While directly connected to the corporate network (wifi or wired LAN), we can authenticate normally with no credential prompts. However, once the client is connected to Always on VPN, you will receive a credential prompt when trying to access one of these websites. There is no event logs on the DC for any kind of failed auth. The traffic actually never gets to the DC. When doing a wireshark capture and filtering the DNS traffic, I simply see a bunch of retransmissions from my client to the web app url, but never a response back.

As I mentioned above, this is only happening on our Azure AD join devices. On-prem domain joined machines work fine. Any apps that aren't behind the load balancer work perfectly normally on AAD joined machines. We are using a split tunnel config and identical configurations for on-prem vs AADJ devices. The AADJ devices only have their configuration from Intune and domain joined machines from a PS script.

*.domain.local is added in trusted intranet zone. But it seems like whenever the client is on AOVPN and is trying to resolve somewebapp.domain.local to --> AWSelb-GUID.elb.eu-central-1.amazonaws.com, it gets kicked over to internet zone which then prompts for creds and doesn't use Windows Integrated Auth. At least that is my assumption at this point. Any suggestions on where to look or anything to change?

For reference, SSO to on-prem resources should work from AAD Joined machines. And it does except for these apps behind the ELB while on AOVPN:
Ref 1: https://learn.microsoft.com/en-us/azure/active-directory/devices/azuread-join-sso
Ref 2: https://msendpointmgr.com/2021/08/15/sso-to-domain-resources-from-azure-ad-joined-devices-the-mega-series/

Answer 1

@Greg Arnold
Thank you for your post! To better understand your situation, I'll summarize what I gathered below to make sure I didn't miss any key details.

Resources:

• On-prem apps are leveraging Windows Integrated Auth.
• Apps sit behind an AWS Load Balancer
• Always on VPN
• AAD Joined Windows 10 devices
• On-prem Domain Joined devices
• Azure AD Join SSO

Summary:

1. When connected directly to your Corp Network, you can authenticate normally, and navigate to your on-prem app's websites with no credential/log-in prompt being displayed.
2. Once your devices connect to your Always On VPN, you'll see a credential/log-in prompt when trying to navigate to your on-prem app's websites.

Issue:

Once your devices are connected to the VPN, and you navigate to one of your on-prem app's websites, only your Azure AD Joined devices will receive a credential/log-in prompt while your on-prem domain joined devices aren't receiving this prompt.

• Apps that are not behind the Load Balancer, won't display a login-in prompt when accessed by Azure AD Joined devices or on-prem domain joined devices.

Troubleshooting:

Azure AD joined devices:
I found some limitations when it comes to Integrated Windows Authentication and SSO with Azure AD joined devices to access on-prem apps, which I'll share below.

• Apps and resources that depend on Active Directory machine authentication don't work because Azure AD joined devices don't have a computer object in AD. And Applications running on your Azure AD joined device may authenticate users. For more info.
• Azure AD joined devices have no knowledge about your on-premises AD environment because they aren't joined to it. However, you can provide additional information about your on-premises AD to these devices with Azure AD Connect. For more info.
• IWA doesn't bypass multi-factor authentication (MFA), if MFA is configured. For more info.

However, as you mentioned in your post, if the app isn't behind the Load Balancer everything is working as expected.

Always On VPN:
As you mentioned, a possible root cause could be related to whenever the client/user is on the VPN and is trying to resolve somewebapp.domain.local to --> AWSelb-GUID.elb.eu-central-1.amazonaws.com, which gets routed over the internet, then prompts the user for credentials and doesn't use Windows Integrated Auth.

Since the issue doesn't start until you connect to the VPN, I'll reach out to our Networking team and add the azure-vpn-gateway tag to this thread, so our Networking community and MVPs can take a look into this. Additionally, since you're using an AWS Load Balancer I'd recommend reaching out to the AWS Community - AWS re:Post, so their experts can look into this as well.

If you have any other questions or would like to work closer with our support team on this, please let me know.
Thank you for your time and patience throughout this issue.

Answer 2

All of the above is a correct summarization.

Actually after a bit of digging around this morning and troubleshooting with some various settings, it appears that modifying the rasphone.pbk file under %appdata%\Microsoft\Network\Connections\Pbk solves the issue. The value inside this file of UseRasCredentials=1 needs to be modified to UseRasCredentials=0. Thanks to Richard Hicks on this one (https://directaccess.richardhicks.com/tag/azure-ad-join/)

I modified his scripts a bit and deployed them as a Proactive Remediation (Detection and Remediation) within Intune. So far the tests are positive.

The reason they should be deployed this way is because, from my understanding, the UseRasCredentials value will default back to 1 anytime there is a new or change in existing VPN connections.