AD Connector Communication Flow and Troubleshooting

The Cisco Secure Access Active Directory (AD) Connector communicates with Secure Access and AD domain controllers, syncing required AD user and group attributes. The following information describes the communication flow between AD Connectors and AD domain controllers and how to troubleshoot AD Connectors.

Table of Contents

• Communication Flow
• Troubleshooting

Communication Flow

The Secure Access AD Connector first attempts to communicate to the AD domain controller over LDAPS. If unsuccessful, the AD Connector falls back to communicating over LDAP using first Kerberos and if that does not succeed, NTLM over LDAP.

The AD Connector retrieves the AD users, groups, and computer details only. The required attributes are stored from each object, including the sAMAccountName, dn, userPrincipalName, memberOf, objectGUID, primaryGroupId (for users, groups and computers), and primaryGroupToken (for groups). Passwords or password hashes are not retrieved. This data is then uploaded to Secure Access for use in policy configuration and reporting. This data is also required for per-user or per-computer filtering.

Note: The objectGUID is sent in hashed form.

If there are changes, the connector sends the AD data every five to seven minutes using an HTTPS connection on TCP port 443. However, it can take an hour or longer for changes to reflect in Secure Access.

The AD Connector stores this data locally and in .ldif files contained within C:\Program Files\OpenDNS\OpenDNS Connector\ADSync. To find out exactly what is synchronized to Secure Access, look at these files. At install time, you have the option to turn off the local storage of .ldif files.

Troubleshooting

Recommendations for troubleshooting communications with AD Connectors.

Firewall or Access Control Requirements

The following firewall or access control (ACL) requirements ensure that AD Connectors can communicate with Secure Access and domain controllers.

Note: The Digicert domains resolve to various IP addresses based on a CDN and are subject to change.

If you experience any issues communicating with Secure Access, we recommend that you check for any Layer-7 application proxies, which may block or drop data sent to Secure Access. A common case is the inspect feature on Cisco devices that act on protocols such as DNS, HTTP, or HTTPS. For more information, see Cisco Security Appliance Command Line Configuration Guide, Version 7.2.

You can restart the AD Connector by restarting the OpenDNS Connector service on the connector server. Restarting the AD Connector triggers a full synchronization of AD objects (and not only the changes from the previous sync) to Secure Access.

If your AD Connector is not in the Okay state, contact Support.

---

Change the Connector Account Password < AD Connector Communication Flow and Troubleshooting > Configure Integrations with SAML Identity Providers