User Profile Service - Active Directory Import issues/debugging

  • Article

You work with a hybrid cloud or a virtualized environment where security is a high priority. If your SharePoint farm has its own domain and leverages a Trusted Identity Provider with Authentication via ADFS to another corporate domain, then you may run into this scenario. You want to sync user profiles to augment information in the remote SharePoint farm. Utilizing the User Profile Service with Active Directory Sync is a good solution.

Requirement #1: Corporate does not want a two-way sync or read and write.

Requirement #2: Corporate AD is extremely large with many objects and legacy schema changes. An Active Directory connection will not suffice.

SharePoint 2013 introduces 3 different ways to sync profiles, with one being 'Active Directory Direct Import (AD DI)'. See Configure profile synchronization by using SharePoint Active Directory Import for more detail. A very neat feature of AD DI is the ability to filter using the standard LDAP syntax; filtering down to specific OU's or users in a specific group. If security is a concern with hybrid cloud or virtualized environments, network traffic will typically be locked down with every port closed except for your exemptions. To sync profiles over AD/LDAP, you should request an exemption for TCP port 636 to be open for SLDAP queries.  Because we are using AD DI, we do not need to run FIM services. For a great write-up on how to setup and configure your environment for AD DI, see Step by Step: Active Directory Import for SharePoint 2013 walk through. Please note: switching your connection settings between 'Use SharePoint Active Directory Import' and 'Use SharePoint Profile Synchronization' will stop the FIM service. If you choose Active Directory Import, the service is not required to run and will not start.

Great: You followed all of the above walk-through documentation and are able to successfully configure the connection. However, you start a full profile sync and immediately see the following in the ULS log:

 ActiveDirectory Import failed for ConnectionForectName 'domain.com', ConnectionSynchronizationOU 'DC=domain,DC=com', ConnectionUserName 'domain.com\sa_appups'. Error message: System.Runtime.InteropServices.COMException (0x8007203A): The server is not operational. at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_AdsObject() at System.DirectoryServices.PropertyValueCollection.PopulateList() at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName) at System.DirectoryServices.PropertyCollection.get_Item(String propertyName) at Microsoft.Office.Server.UserProfiles.ADImport.ProfileConfiguration.GetDomain(LdapConnection ldapConnection, String rootDN, String dcName, String userName, String password, Boolean doNotChaseReferrals) at Microsoft.Office.Server.UserProfiles.ADImport.ProfileConfiguration.SetImportDomain(LdapConnection ldapConnection, String userName, String password) at Microsoft.Office.Server.UserProfiles.ADImport.UserProfileADImportJob.ImportDC(UserProfileADImportMapping mapping, Int32 loopCount, Int64& totalAdded)

The first steps of debugging revolve around: (1. Service Account Permissions; 2. Name Resolution; 3. Firewall rules; )

 

  1. Service Account Permissions: Look to this article and ensure you have requested the appropriate level of permission for your service account.

     

  2. Name Resolution: In a hybrid environment, Domain Name Service or Binding may not be as integrated as you would like. My suggestion is to create a forward looking stub zone in your separate hybrid domain. With a large farm, you will have more than one server and name resolution shouldn't be confined to local host files. This will make DR and other DSC activities worthless. Here is an example of a forward looking Stub Zone:

     

     You'll want to use a stub zone without it being directory integrated. If you choose directory integrated, it will use your separate DNS for name resolution which will make any on-premises DNS undiscoverable.

     

    Notice that I specified the domain controller and a static IP. A good organization will have more than one DC and will use static IP's. You'll want to identify these as it allows name resolution at the domain level.

    Once you have the forward looking zone or host file entries created, go ahead and perform an Ipconfig /flushdns. Then use nslookup or ping to verify IP resolution.

    Note: At this point if you haven't already installed the certificates for the remote forest, you will want to install them. You will need the entire certificate chain and will definitely want to trust the Root CA. If the network is completely locked down, you should cache the CRL locally. It is recommended that you request an exemption or open port 80 so that the servers can perform a Certificate Revocation check.

     

    With name resolution successfully configured and certificates installed and trusted, we can proceed to create the connection. You will be tempted to specify the FQDN to the Domain controller (ex. dc3.shawniq.com) which will connect appropriately. The error you'll then receive is 'No containers to display'. If you have created the forward looking stub zone, then a simple (ex: shawniq.com) will suffice. You could also use the suffix to connect with the service account shawniq\sa_appups, but I've found it easier to use the fully qualified name: shawniq.com\sa_appups. Take note: TCP port 636 and Use SSL-secured connection is required.

     

    Once you have the FQDN in place, the service account with the correct credentials, and TCP port 636 open, you are able to click Populate Containers and will be presented with the AD Tree. Looking at a network trace or a network monitor shows successful connections and TLS handshakes over port 636. Everything is looking great. If you can't establish a connection, ping or nslookup the FQDN to ensure that it resolves. If it resolves, you may want to look at the certificates. It's important that you have exported all the certificates in the chain for the domain controllers that you'll be querying. Install them in the appropriate locations (Trusted Root and Personal Certificate stores). Also install the certificates in the SP Trusted Root Authority New-SPTrustedRootAuthority. Once the certificates are configured and DNS resolves, you should see successful connections.
     
     

     

  3. Firewall rules: After completing step #2 above, you are able to establish a connection and have proven that TCP port 636 is open. If you received the ULS error message identified above and you've walked through #1 and #2, this is the point where it is failing. Group policies on the corporate domain may block all ports. Another issue may be the network between the cloud or virtualized environment which is controlled by an appliance. Traffic is locked down except for explicit exemptions. You have an exception for port 636/SLDAP and Corporate security is satisfied. No open connections and no unencrypted packets. So why is the timer job failing? Let's review our network monitoring again:

     

 

 

  • If you deal with Windows Firewall, look at Firewall Rule Properties Page: Scope Tab for rules or GPO's. I should show the PowerShell output from my Azure Site2Site NSG's locking down ports, but Windows Firewall is easier to configure.
  • Per the screenshot I opened port 80,88,389,443-445, and 636.

 

  •  In the corporate world you'll need to request an exemption on port 389 and whitespace the IP address range of your farm.

 

  • Once you have this port exemption with the IP Address space whitelisted, you can start the full profile sync. Watching the network monitoring software should show profiles starting to import.
  • Note: The handshake during the Timer Job Sync is being asserted over 389 with subsequent connections occurring over 636. This connectivity is different from the Connection Settings UI. It turns out that port 389 needs to be open to establish the handshake.