Umbrella AD Integration: Local User Accounts

Introduction

 Umbrella on-premise products can synchronize with Active Directory to provide per-user identification, but cannot identify Local (Non-Active Directory) user accounts. 

This article describes the expected behavior, and recommendations on how to apply a more restrictive policy for Local Accounts.

Umbrella Virtual Appliance

The Umbrella Virtual Appliance receives AD Logon information from the Windows Domain Controller(s).  Active Directory users are cached and identified based on their source IP.

However, Local User logon information is not available on the Domain Controller, so these users cannot be tracked.  The impact is as follows:

• If an AD user has recently logged in to the same IP address, the AD user identity may still be used based on our cache.  The Virtual Appliance has no way of knowing the AD user has been replaced with a local account.
• If there is no cached user, local users are typically identified using a default (non-AD) identity. The identity triggered will be either:  Umbrella Site name (eg. Default Site), Internal Network (internal IP address), or Network (external IP address)

Recommendations:

• Restrict access to local accounts and passwords
• Create separate policy for your Umbrella site name (eg. Default Site).  This should exist at a lower priority than your normal 'AD User' policy.  This can be a more restrictive policy that will apply in cases where there is no AD user set.
• If enforcing a different policy for local user accounts is a requirement, consider using the Umbrella Roaming Client

Umbrella Roaming Client

NOTE:  This requires the "Enable Active Directory user and group policy enforcement" setting to be enabled in 'Identities > Roaming Computers'.

 The Roaming Client AD integration feature detects logged on users from the Windows registry.  This method allows us to identify AD users by their unique AD guid.

The Roaming Client is NOT able to identify local usernames for policy purpose, but is able to enforce a different policy when an AD user cannot be detected.

• When a logged on AD user is detected, the AD User is typically used for policy purposes.  This includes AD users who are not on the corporate network and are logged in using cached credentials.
• When an AD user cannot be detected (for example, when a local user is logged on), the Roaming Computer identity will typically be used for policy purposes.

Recommendations:

• Restrict access to local accounts and passwords.
• Create separate policy for 'Roaming Computers'.  This should exist at a lower priority than your normal 'AD User' policy.  This will apply to Roaming Computers that are not members of the Domain, or Local Users.