When you first connect EmpowerID to an account store like Active Directory, EmpowerID discovers the topology of the Active Directory and registers the EmpowerID equivalents of that topology in the EmpowerID Identity Warehouse. These EmpowerID equivalents include:

A Security Boundary object to represent the AD forest
An Account Store object to represent the AD domain
A Resource System object to represent the account store
A Resource System object to represent the Exchange Organization if the Active Directory has Microsoft Exchange
A Resource System object to represent the Lync Pool if the Active Directory has Microsoft Lync
A Directory Server object to represent each Domain Controller

Once these objects have been added to the Identity Warehouse, populating the tables of the EmpowerID Identity Warehouse with resource objects like accounts, mailboxes, and groups is handled by specific EmpowerID Windows services and the processes or "EmpowerID Jobs" hosted by those services. For account stores like Active Directory, the relevant services and jobs are the EmpowerID Worker Role Windows service, the Inventory Job hosted by the EmpowerID Worker Role, and the LDAP Management Web Service hosted by IIS.

The EmpowerID Worker Role schedules and dispatches the Inventory Job for each connected account store, based on the user-defined settings for that schedule and account store. When the scheduled time arrives, the EmpowerID Worker Role instructs the Inventory Job to execute the Inventory method for the account store in question. In the case of an Active Directory account store with an Exchange resource system, the Inventory Job responds by looking for the LDAP Management Web Service in IIS. Once the Job has reached the LDAP Management Web Service, the service makes an LDAP call to the Active Directory account store, retrieving each new user account discovered in the account store (step 2 below). The LDAP Management Web Service then returns that information to the EmpowerID Worker Role (step 3 below), which processes the accounts, writing each one as a record to the Account table of the Identity Warehouse (step 4a below). Simultaneously, the Worker Role creates mailbox objects for each account discovered to have a mailbox and writes those objects to the ExchangeMailbox table (step 4b below). Once this initial inventory is complete, the process repeats itself, discovering any new accounts added to the account store and adding them to the appropriate Identity Warehouse tables in accordance with the inventory schedule.

Inventorying User Accounts

While the above process holds true for all resource objects, user accounts receive more treatment than other types of inventoried objects because of their relationship to EmpowerID Persons, user identities, and system resources. As mentioned in the EmpowerID RBAC Overview topic, EmpowerID Person objects are objects in the EmpowerID Identity Warehouse that link together the user accounts, the permissions assignments, the audit history, and the management policies associated with users in whatever directories their user accounts may be located. Thus when EmpowerID inventories a resource system with user accounts, it evaluates those accounts using certain "Join" and "Provision" filters to determine whether they are owned by users, and based on that evaluation it does one of the following three things:

It ignores them;
It joins them to existing EmpowerID Persons;
It provisions new EmpowerID Persons, joining those new Persons to the accounts.

From a high level, this can be represented by the following image.

The inventory process is initiated by the end user and executed by the Inventory Job hosted by the EmpowerID Worker Role. This can be an initial inventory of a newly connected account store or it can be a repeat inventory of an existing account store. EmpowerID treats newly discovered accounts the same regardless of the inventory count.
The LDAP Management Web Service retrieves all newly discovered accounts and passes them back to the EmpowerID Worker Role, which processes those accounts to determine whether or not they are valid user accounts
Valid accounts are written to the Accounts table of the EmpowerID Identity Warehouse.
Any new accounts in the Accounts table are evaluated to determine how EmpowerID should treat those accounts with respect to the Person object. EmpowerID does this by first executing the Join Filter to see whether the newly discovered accounts can be joined to any existing EmpowerID Persons currently in the EmpowerID Identity Warehouse. If a corresponding EmpowerID Person(s) exists, the account is joined to that Person. The Join Filter looks for specific attributes to ensure a correct match between a newly discovered account and an EmpowerID Person. If an attribute match occurs between an account and an EmpowerID Person, the account is joined to the Person; if EmpowerID finds no matches, EmpowerID executes the Provision rule to create a new EmpowerID Person object, and then joins the account to the new Person object.
EmpowerID adds each new Person object created to the Person table of the Identity Warehouse. The Person object then becomes the base user identity in EmpowerID.

Once this process has completed, EmpowerID repeats the tasks above on a scheduled basis to ensure that each new user account discovered in an account store is joined to the right EmpowerID Person. The logic of the Join Filter always ensures that the right user accounts are joined to the right EmpowerID Persons.

The mechanism by which EmpowerID processes user accounts is known as the Account Inbox. The Account Inbox is comprised of the above mentioned Join and Provision filters. For a greater discussion of the Account Inbox, see Understanding the Account Inbox.

Inventorying Groups and Group Memberships

As mentioned in the EmpowerID RBAC Overview topic, a group is a collection of user accounts residing in a directory outside of EmpowerID. In EmpowerID, these user accounts are linked to the EmpowerID Person objects that own them, which makes groups collections of accounts that resolve to people. When EmpowerID inventories a resource system with groups and memberships, it does the following:

Creates group objects and adds them to the specified account store;
Creates object relationships between user accounts and groups (group membership or group account);
Flags the group accounts as CreatedFromAccountStore;
Updates any changes in groups and memberships.

When there is an RBAC policy for group enforcement (other than full enforcement), another flag marks any affected group accounts as RBACAssigned. If the group account later loses the policy, the RBACAssigned flag gets set back to false but the group membership remains in place to prevent the accidental removal of valid memberships when someone is testing policies and then removing them.

Since many companies do want to remove the membership once policies are removed, we added a new date field called RbacAssignmentConfirmationDate. This date is only set for group accounts that are flagged as CreatedFromAccountStore and are subsequently flagged as RBACAssigned. The date field is set to seven days after the RBACAssigned flag is set to true, and it represents the time until the RBAC-assigned group account becomes fully managed by EmpowerID.

If the RBAC policy that flags the group account as RBACAssigned is rolled back before the seven days expires, then the RBACAssigned flag is set to false, the date is cleared, and the group account remains.
If the RBAC policy that flags the group account as RBACAssigned is rolled back after the confirmation date, then the group account is removed, the same as any other policy assignment.

Concepts

Overview of the EmpowerID Identity Warehouse

Tasks

Connecting to Directory Systems

Browser not supported