Month: June 2010

Here are some guidelines to follow to choose the most appropriate store for placing directory information (usually requested as a schema extension, with additions of attributes and/or classes)

If a schema change is required for an enterprise-wide application, such as Exchange Server that has a major integration (effect’s most objects in the forest) and required interaction with security principals the change probably has to take place in the main forest. However, if the schema change is required for an application that a small population of the organization will use, You should determine whether deploying a such global change to satisfy the needs of this small population of the organization is warranted, in addition you should analyze whether the schema change is a long-term or short-term requirement, also if the data to be hosted in the directory is frequently changing, or is already hosted in a different format with in the forest,

You should consider an alternative directory store, such as a specific application directory using Active Directory Lightweight Directory Services (AD LDS) to support applications that depend on schema extensions that are not desirable in the AD DS directory— for one or more reasons such as schema extensions that only are useful to a single application or only required on a short-term basis.

The following table supports the process to determine the most appropriate directory information store for a particular application/schema extension.

If the schema extension qualifies for more than 3 points above, I advised to choose Active Directory Lightweight Directory Services (AD LDS) as the directory information store over Active Directory Domain Services (AD DS).

I recommend most customers to implement an identity Life-Cycle Management process to provision and de-provision identities where those identities and it’s associated data on a best effor will automatically flow in from an authoritative data source with the ability for approved managers to use an manual process to fill in missing data (there is usally no way to fully automate all scenarios in large enterprises) in existing identities or request new ones outside the automated flow. I also believes that providing Self-Service into the flow, so that end-users can complement any missing data will enhance the overall identity quality. 

Here is some general ideas and recommendations :

·        FTE – Full Time Employees. On best effort HR-driven provision and de-provision with the ability for approved managers to request an identity before it becomes available in the HR system, once the identity appear in the HR system it will merge with the one requested on forehand by the manager.

FTE’s should be able to some extent modify/correct the data about their own identity(s) using a Self-Service Portal, such as adding a cell-phone number. Security mechanisms, compliance management and approved managers should have the ability to quarantine identities and keep them on hold.

The de-provisioning process should be HR-driven and identities should be archived up on unemployment so that tracking possibilities remain and approved managers should be able to access/transfer remaining work associated with the identity(s).

·        Vendors and Contractors. On best effort Sponsor-driven provisioning and de-provisioning where the sponsor (the person responsible for contracting the vendor/contractor) approves and provide a central repository with required information for external users, the end date for the contract should also be defined.

Vendors and Contractors should have limited access to modify/correct the data about their own identity(s) using a Self-Service Portal, such as perform a reset of their passwords, Security mechanisms, compliance management and the sponsor should have the ability to quarantine identities and keep them on hold.

The de-provisioning process should be Sponsor-driven and/or expire date-driven, identities should be archived so that tracking possibilities remain and the sponsor should be able to access/transfer remaining work associated with the identity(s).
 

·        Temporary Accounts. Temporary accounts should be provisioned by approved managers which are required to provide a central repository with required information about the identity that will gain temporary access, defining an end date for the temporary account should be required.

Temporary Accounts should not have access to modify data using a Self-Service Portal, Security mechanisms, Compliance management and the managers should have the ability to quarantine identities and keep them on hold.

The de-provisioning process should be expire date-driven, identities should be archived so that tracking possibilities remain and approved managers should be able to access/transfer remaining work associated with the identity(s).

·        Administrative Accounts. Administrative Accounts Administrative Accounts should be driven by an already existing identity that controls provisioning and de-provisioning where an approved manager after that the identity has been validated either by a board or/and in conjunction with security responsibilities approves and provide a central repository with required information for an administrative account.

Administrative Accounts should have limited access to modify/correct the data about their own identity(s) using a Self-Service Portal, such as perform a reset of their passwords, Security mechanisms, compliance management and approved managers should have the ability to quarantine identities and keep them on hold.

The de-provisioning process should be driven by an already existing (regular) identity and/or expire date-driven, identities should be archived so that tracking possibilities remain and approved managers should be able to access/transfer remaining work associated with the identity(s).