19th of December, 2014 / / 3 Comments

In this blog I am going to cover some tips and tricks for using Azure AD Sync Services with a proxy… including the specific URLs required for whitelisting, the proxy settings used during the installation, configuration and running of the tool, and a workaround for apps that do not support authenticating proxies.

URL Whitelisting

It is generally recommended to whitelist all the Office 365 URLs to bypass proxy infrastructure as this provides the best performance and avoids issues with applications that are not compatible with an authenticating proxies (OneDrive for Business client installations, Exchange Hybrid services, Azure AD Sync Services and so on…). Although this is the easiest path to adoption and least likely to encounter technical issues, it is not always possible. This is particularly true for security conscious organisations, where whitelisting wildcard addresses may be undesirable.

If you want to be specific with the URLs required for Azure AD Sync Services, the following URLs must bypass proxy authentication:

  • adminwebservice.microsoftonline.com
  • login.microsoftonline.com

Proxy Settings

When you run through the DirectorySyncTool.exe wizard to install and configure Azure AD Sync Services, at the point where you first enter your Azure AD credentials the wizard will use the proxy settings defined for the current logged on Windows user. In this instance, make sure you’ve configured your proxy settings in Internet Options (inetcpl.cpl) for the user running the installation.

In step 8 (Configure), the installation wizard connects to and configures Azure Active Directory. This step of the wizard attempts an outbound HTTPS to login.microsoftonline.com using the proxy settings defined for the Azure AD Sync Services service account. This service account is either the one you specified during the installation (if you ran the DirectorySyncTool.exe with the /serviceAccount* paramater), or the one that was automatically created by the wizard.

I’ve previously written about my recommendations to specify a service account for the installation so that you know the credentials. In this case you can easily configure the proxy settings by launching inetcpl.cpl with the service account. For example:

runas /user:<domain>\<AADSync Service Account> "control.exe inetcpl.cpl"

Once the Azure AD Sync Services installation is complete, all synchronisation events are going to run under the context of the Azure AD Sync Services service account and will rely on the proxy settings defined in inetcpl.cpl.

AADSync with an authenticating Proxy

If for some reason you can’t bypass an authenticating proxy for AADSync, or you’re desperate to get AADSync up and running while you wait for the proxy admin to add the URLs to a whitelist (my scenario), CNTLM to the rescue! I used this recently to get Azure AD Sync Services working with an authenticating proxy and it’s as easy as:

  1. Download and install CNTLM on the AADSync server
  2. Configure the cntlm.ini with the proxy server and authentication details (you can save the account password or an NTLM hash, for those that are concerned about saving credentials in plain text)
  3. Start the CNTLM service
  4. Configure CNTLM as your proxy in Internet Settings (default is 127.0.0.1:3128)
  5. Install and Configure AADSync
Category:
Azure Infrastructure, Communication and Collaboration, FIM, Identity and Access Management, Office 365
Tags:
,

Join the conversation! 3 Comments

  1. Dale Hutton

    Thanks heaps for this blog it has saved my sanity.

  2. Onno

    Hi,

    In case you don’t know the credentials of the service user, like when it’s the auto created user, you can’t set the proxy by running: runas /user:domain\serviceuser “control.exe inetcpl.cpl”
    However, you can edit the registry and manually set the “ProxyServer” entry under: HKEY_USERS\\Software\Microsoft\Windows\CurrentVersion\Internet Settings” and make sure the “ProxyEnable” DWORD is set to 1.

    At least in our case this worked.

    BR
    – Onno

  3. Nonis

    Oh boy, this did save me a lot of headache..however, im only half way there! I entered all the required info, i actually manage to finish the AD connect wizard and got this on the last page: AD connect was successfully configured, password sync cannot be configured. Check event log for more info.

    Going there, i can see some information events (no errors) saying that the sync failed to resolve the name ‘login.windows.net’

    I tried browsing to it – it’s working (this is part of the URL list that the network admin has already whitelisted on the web proxy)

    I then went to powershell: import-module AdSync
    Start-AdSyncSyncCicle -policyType initial

    Received a big big error saying that “user realm discovery failed—>System.Net.WebException: The remote name could not be resolved: ‘login.windows.net’

    My understanding is that the sync is trying to access that fqdn through 443 and is not going through the proxy server.

    Any ideas?

Comments are closed.