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
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.
Port and Protocol | Source | Destination | Note |
---|---|---|---|
443/TCP | AD Connector | api.opendns.com (for syncing) disthost.sse.com |
|
80/TCP | AD Connector | ocsp.digicert.com crl3.digicert.com crl4.digicert.com |
|
389/TCP 636/TCP | AD Connector | Domain controller or domain |
|
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 > AD Integration with Virtual Appliances
Updated 3 days ago