AD Admin account to be disabled when employee quits

Hei Timo,

In the AD created admin accounts need to read into the One Identity Manager. Then they need to mapped against the correct persons. The accounts do not need to be mapped with an TSBAccountDef. The Configuration parameter QER\Person\TemporaryDeactivation takes care that the active directory accounts are disabled when the person quits.

Hei Timo,

In the AD created admin accounts need to read into the One Identity Manager. Then they need to mapped against the correct persons. The accounts do not need to be mapped with an TSBAccountDef. The Configuration parameter QER\Person\TemporaryDeactivation takes care that the active directory accounts are disabled when the person quits.

Hi,

How I can prevent account definition from mapping to these admin accounts? As account definition need to be there for normal AD accounts. They are both in same domain.

One option is to use the IsPrivilegedAccount flag on the accounts. You find more information about the different account types and the mapping of administrative user accounts in the documentation.

https://support.oneidentity.com/de-de/technical-documents/identity-manager/8.1.1/administration-guide-for-connecting-to-active-directory/20#TOPIC-1245015

https://support.oneidentity.com/de-de/technical-documents/identity-manager/8.1.1/administration-guide-for-connecting-to-active-directory/26#TOPIC-1245063

Have in mind, also the use of the configuration parameter TargetSystem\ADS\PersonExcludeList. This prohibits automatic employee assignment.

These are personal admin accounts, like adm_jdoe when person's normal AD account is jdoe.

I just want to map them with person and disable when person has left, but I would not llike to have these admin account updated by other information from person. 

Identify somehow how the admin accounts are named. Then add to the TargetSystem\ADS\PersonExcludeList the naming conventions for example adm_.*. Then these users will not get a TSBAccountDefinition and they will not update the data of the linked person. Link the persons manually to these admin accounts or create a custom mapping rule. Then activate the configuration parameter QER\Person\TemporaryDeactivation.

That could make sense, I thnk I will try that. Thank you!

Humm... that excluding will exclude those accounts from mapping with person?

Custom mapping rule, where that should be created? Custom process for it?

if I modify the domain search criteria it will add the account defition to ad account, or if I exclude those accounts then it does not even map the person with account.

The excluding will exclude those accounts from the mapping with the person done triggered through the configuration parameters. This is why the persons should be mapped manually to the accounts or through a custom mapping rule created in the synchronization editor. 

I don't know how I can map AD account to person with Synchronization editor. Could you please open this a bit more?

I was also considering using some custom process to do the mapping, is there some process task which could be used to for this?

Open the mapping of the user. The mapping rule could have custom "Key resolution by reference"-property on the OneIM side. This should point to the base property UID_Person. Then you need to use some property as the search property. The search property is used to search the corresponding person from the person table. 

Then you map this custom property with the property that gives the value for the search property from active directory. Here might be needed some parsing depending on which property used as the search property.

Your goal is to use this mapping only for the administrative accounts. Therefore a condition is needed. It could be something like Right.cn like 'adm_%'.

Then everything is set and synchronizing the environment will fill the UID_Person fields of the administrative accounts.

I would not encourage the custom process option, because it is quite straightforward with the Synchronization editor.