browse
Overview
This KBA is targeted at clarifying and exploring the two different methods of integrating Active Directory with the Umbrella Dashboard. Currently, AD users may be applied to policy and reporting via the Umbrella virtual appliances or the Umbrella roaming client.
Prerequisites
Prerequisites differ between the two implementations significantly. Please refer to the specific implementation for full prerequisites. This section will define the requisite components.
- AD Connector: Syncs the AD tree of a single Active Directory domain to the dashboard. For the VA implementation, it will also actively sync the login events from the DCs on the same Umbrella site to the VAs. The AD tree for the organization is synced to the Umbrella cloud by the AD Connector, pulling this data from the registered DC. Tree updates are detected and the Umbrella cloud is updated within several hours.
- Domain Controller (AD Server): DCs are registered to the dashboard via the registration configuration .wsf script as downloaded from the dashboard. This adds its name, domain, and internal IP to the Dashboard to inform the Connector which IPs to attempt to sync with. Can't run the script? Manual registration is also possible, contact us at umbrella-support@cisco.com.
- Virtual Appliance: The Umbrella on premise DNS forwarder. Applies (optional) AD identity on network as well as internal IPs on reports. Will trigger all roaming clients behind it to disable DNS protection and defer to "Behind VA protection" mode.
- Roaming Client: The Umbrella on premise software service which provides DNS encryption as well as user identification to Windows and MacOS. Also comes as an AnyConnect module.
Roaming Client Implementation
Prerequisites: One AD Connector, one DC on the Dashboard. OpenDNS_Connector user must have Read Only Domain Controller permission. Roaming client minimum versions for the standalone client (AnyConnect Module): Windows: 2.1.0 (4.5.01044) OSX: 2.0.39 (4.5.02033).
How it works: The currently logged in AD user is determined directly at the local computer by the roaming client reading the local registry. Supports a maximum of one concurrently logged in user on the workstation. Two concurrent users will result in no AD user applying. The AD user GUID and internal IP are attached via EDNS0 within the roaming client's DNS proxy to the DNS query sent to the Umbrella resolvers, uniquely identifying the AD user. All policies are applied on the resolver side.
No active connector is required; however, AD user and group policy application will reflect the most recent successful AD tree sync.
Where it works: Any network globally. Does not work behind an Umbrella virtual appliance as the DNS layer is disabled to defer to the local VAs.
Limitations:
- Requires endpoint agent active and enabled on the workstation.
- Does not support server OSes.
- Cannot apply policy based on internal network IP.
- Cannot apply policy or reporting for AD Computer (use roaming hostname instead!).
- Cannot apply AD policy on network, roaming policy off network.
- Roaming computer must be registered to the organization where the connector belonging to the AD user's domain is registered.
Connector will still attempt to pull AD login events from the one DC registered and may result in a Dashboard error which is not relevant to roaming client based AD integration. To remove errors with permissions related to pulling login events without actually pulling any events, disable login event auditing (if not otherwise used) via the reverse of the auditing instructions from here.
Virtual Appliance Implementation
How it works: The VAs receive AD user mappings based on the Windows DCs' security login event logs. Each workstation login is logged to the login server DC's security event log as a unique login event, with the AD username or AD computer name and the internal IP of the workstation. The connector parses these events in real time via a WMI subscription, and syncs these events to each VA on the Umbrella site via TCP 443. The VA builds a live user mapping between the internal IP of an AD user/computer and the username of the AD user/computer.
The VA only has visibility in to the internal source IP of a DNS query, and utilizes the above mapping file created by the connector-synced events. The VA has no direct visibility into who is currently logged into a machine. This attaches the AD user GUID and internal IP via EDNS0 to the DNS query sent to the Umbrella resolvers by the VA, uniquely identifying the AD user. The AD computer hash is applied in the same way. All policies are applied on the resolver side.
A connector must be functional and active on the organization to receive an AD user, and login events must be current. The user must be the last AD user to authenticate to this machine as seen in the event logs.
Limitations:
- Computer may not point to a VA belonging to a different AD domain or Umbrella site (large deployments on multiple domains will not see AD application off their base network).
- Large deployments may require subdivision into Umbrella sites with separate VAs.
- AD User exceptions may be needed for service AD users.
- There exists a maximum login events per second throughput for the connector above which will delay user application - a factor of network latency and number of VAs.
Where it works: On the local corporate network where all DNS is pointed at an Umbrella virtual appliance belonging to the same Umbrella site as the DC the user has authenticated to.