I am seeing an interesting behavior with the sync engine and I am not sure if it is a bug or a feature.
I have a situation where a user created in the FIM Service may or may not have a user-assigned AD account name. If an account name is specified I need to use the specified name, otherwise I need to generate an account name for the person.
My solution is to have an optional “Account Name Requested” attribute in the FIM Service that when specified is used as the account name during provisioning (and later in synchronization to handle account name changes).
The native “Account Name” attribute in the FIM Service contains the actual account name in AD and is not editable by the user.
My setup is:
- In the FIM Service, I have AccountName and AccountNameRequested
- In the Sync engine, I have the same attributes.
- On the FIM MA:
- AccountNameRequested flows from the FIM MA to the Sync engine.
- AccountName flows from the Sync engine to the FIM MA
- On the AD MA:
- AccountNameRequested flows out to sAMAccountName if AccountNameRequested has a value (via a rules extension)
- sAMAccountName flows in to AccountName
- Provisioning code uses the value for AccountNameRequested if it is present; otherwise, it generates an account name.
Provisioning works properly.
The issue is when an account name needs to be changed: A user updates the Account Name Requested attribute in the FIM Service. It flows properly to the sync engine and it flows out to sAMAccountName in AD. The following confirming delta import shows the update to sAMAccountName as applied in AD. Unfortunately, the delta import (containing the change in AD) is not recognized as a delta, so a subsequent delta sync does not process the record (and does not flow the new value for sAMAccountName back into the AccountName attribute in the metaverse.) A full import will properly flow the sAMAccountName back in from AD.
So the question is: If in the metaverse you have attribute A that flows outbound to attribute B in a connected directory and that same attribute B in the connected directory also flows inbound to attribute C in the metaverse, should a change in attribute A that is exported to B and successfully imported back from B be considered a delta change in the connector space so that a subsequent delta sync flows B into C?
If the answer to the above is “Yes, it should be considered a delta”, then I need to open a support case, otherwise it is a “feature” and I need to solve the problem another way (probably by having workflow reach out directly to AD, which I would prefer not to do.)
Thanks,
Rex