Best practice approach: Write account attribute (e.g. SAPUser) after assigning eset to person

Hi,

To fully understand the case: You need to modify an attribute of an account assigned to a person if that person has an entitlement of type eset ?

Maybe a custom process on personhaseset could do the job. You could locate the corresponding linked account for the person then modify the account's attribute for the assign/delete events.

Or write a template on the accounts attribute, but that will require more customizations and other objects involved. So I guess the custom process is simpler. 

Hi Juancarlos,

you have fully understood the case.

I thought of creating a custom porcess on PersonHasEset as well and it would work.

This approach has IMO one big disadvantage: You can't be sure that the account already exists, if the eset is assigned. So you have to work with exists steps in the process and retries.

If on the other hand you could use a QERAssign on Eset via EsetHasEntitlement, One Identity would take care of waiting for the account and then calculate the things that have to be done (probably still with some customization necessary).

Hi Juancarlos,

you have fully understood the case.

I thought of creating a custom porcess on PersonHasEset as well and it would work.

This approach has IMO one big disadvantage: You can't be sure that the account already exists, if the eset is assigned. So you have to work with exists steps in the process and retries.

If on the other hand you could use a QERAssign on Eset via EsetHasEntitlement, One Identity would take care of waiting for the account and then calculate the things that have to be done (probably still with some customization necessary).

Alright, so the ESET has the account definition included? If it does , then your process can wait until the account creation processes end (in v92 see the ADSAccount Update process, as an example). Then update the attribute.

If the account does not exist, then there's nothing to do. This step is simple, too.

Anyhow, I feel I'm missing something :) 

Not to but in, but when I need to manage the attributes of an account on a more fine-grained level as offered by the IT operating data.
Create 'dummy group' in the target system that represent the attribute you want to manage.

Custom attribute: CCC_IsAdmin@UNSAccountB

UNSGroupB = Administrator attribute
GroupType or Container = Attribute groups

Now you put the AccountDef and 'Administrator attribute' (unsroupb) in the System role.
The Person is assigned to System role

- The provision order of the account and group assigment is handled OOTB.
- It's transparent from Person/Identity perspective.
- You do need to exclude these groups from provisioning/sychronization

On the UNSAccountBinGroupB you could have a proces that does the following:
HandleObjectComponent - ExecuteTemplates only for column: CCC_IsAdmin@UNSAccountB
Template on CCC_IsAdmin@UNSAccountB

'P.s. code need updating v7 syntax
Dim account As ISingleDbObject = Connection.CreateSingle("UNSAccountB", $CCC_UID_UNSAccountB:String$)
Dim accountInGroup As IMemberRelation = account.GetMR("UNSAccountBInUNSGroupB", "UID_UNSAccountB")
Dim [group] As ISingleDbObject

Dim groups As New MultiValueProperty()
For Each assignment As IColElem In accountInGroup.Members
               [group] = assignment.Create()
               groups.Add(group.GetValue("CN").String)
Next
              
If groups.Contains("Adminstrator attribute") Then
               Value = True
Else
               Value = False
End If

Hi Niels,

very interesting proposal!

This is a feature that OI is lacking IMO, but you rebuilt it in a quite painless way.

Think i will go for this.