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:
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.
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:
From a high level, this can be represented by the following image.
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.
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:
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.