This is a quick post noting the minimum steps required to get a network load balanced website in IIS accessible through Azure AD Application Proxy. I’ve recently set this up for Deltek iAccess, and after a bunch of minor issues and mis-configurations (which took me hours to find, of course) I thought it worthwhile to compile the information in one spot.
Note, when troubleshooting this process, many different items can be cached which causes problem solving to go down incorrect paths and assumptions. This was perhaps the most challenging part of getting this set up. You’ll likely need to use the following commands regularly, in addition to waiting for AD and DNS sync intervals, and re-testing some minutes after changes are made in the Azure portal.
- net stop dnscache && net start dnscache
- ipconfig /flushdns
- klist purge
Assumptions in this post are that NLB is already configured and working, and the website (or at least a portion of it) uses integrated Windows Authentication (otherwise many of these steps are unnecessary).
- Determine your DNS records. We have split dns and so used the same name internally and externally: “webapp.domain.com”
- Create a CNAME in internal DNS for “webapp.domain.com” to point to your NLB cluster name
- Create a CNAME in external DNS for ‘webapp.domain.com” to point to the provided Azure Application Proxy name; likely something like app-domain.msappproxy.net
- In IIS on each web host, set “UseAppPoolCredentials” to True using Configuration Editor (or web config directly) for the path: system.webServer/security/authentication/windowsAuthentication
- In IIS on each web host, configure the application pool identity to a domain user service account
- Create an SPN delegation in AD to match your DNS name and this service account:
- SetSPN -S HTTP/webapp.domain.com domain\username
- Use this SPN “HTTP/webapp.domain.com” within the configuration of your Azure AD Application Proxy.
- Add this SPN entry on the Delegation tab of the Azure AD proxy connector object in AD. You would search for the domain user service account, and select the HTTP entry matching webapp.domain.com
Things you don’t have to do, discovered after some trial and error:
- Use a CNAME vs A record for internal DNS; both should work properly
- Configure “DisableStrictNameChecking” or “BackConnectionHostNames”, as these apply to NTLM only, not Kerberos
- Grant NTFS permissions to the domain user service account on the web application files
- Specify a specific hostname within IIS binding configuration
- Add the NLB cluster server names to your proxy connector delegation tab
