AD rename is considered as update, will not apply the provisioing rule

Hi all,

I'm trying to rename my existing accounts in AD to arrange  them in different OU depending on departments.

I configured my environment to have both data flow for dn as persestant flow and initial only for dn value,

for new users created in the forum, the provisioing occur in the right way with the correct ou location, but for existing accounts it considers the dn change as an update and the system tries to flow the value to the dn attribute in the AD account, when reimporting the error msg appears as "exported-chagnge-not-imported"

 

any ideas will greatly help!

thanks

 

June 29th, 2010 1:34pm

For attributes, you want to set during provisioning AND also on a regular basis, you don’t need to configure two attribute flow mappings.
This implementation has been changed.
In other words, for your DN flow, you just need to configure ONE attribute flow mapping without the initial flow flag set.

Each export run must be completed by a following confirming import.
If an update has been staged for an export (e.g.: x = 1), you export it and a following confirming import results in x = 2, you will get an “exported-change-not-imported”.
This is because the values for x in the last export and during the most recent import are not the same.

The error is usually an indicator for a problem in your connected data source – NOT IN FIM.
“Something” in the data source is changing an exported attribute value to a different value.

You need to determine what attribute is causing this and why your data source is changing it.
In case of your DN, I would check prior to an export what the staged value for the attribute is.
 
Cheers,
Markus

Free Windows Admin Tool Kit Click here and download it now
June 29th, 2010 2:11pm

Thanks alot Markus for the reply,

I'm exporting the DN value to active directory, i did check the staged export before the actual export, it updates the value of AD dn (which is empty!) to the value costructed CN=Accountname, OU=xxx, OU=domain,OU=local but once i perform the confirmation import, i recieve the value of DN as empty again, so the user remains in its current location without moving,

I've been working on this for sometime but with no luck, this only happens with existing users in AD, for the newly provisioned users they are placed in the correct OU, am I missing anything??

 

thanks again

June 29th, 2010 4:34pm

Summary:

  1. Initial provisioning works and you can export new objects to AD.
  2. In case of an update, the expected value for DN is staged on the object.

Correct?

Did you run after 1) a confirming import + delta sync on the ADMA (!)?
You always MUST run a confirming import after an export: Export, Delta Import, Delta Synchronization

Your description sounds to me like you haven't.

Cheers,
Markus

Free Windows Admin Tool Kit Click here and download it now
June 29th, 2010 5:16pm

 

Yes, 

1- the initial provisioning works fine.

2- and for the update the DN is staged correctly.

after every export, I did the confirm import + delta sync , but still the problem is there, 

I'm still puzzled with the way the DN is delivered to AD, cause the stage export says an update will occur on DN value (currently blank) with the new populated DN value, I'm afraid this is done as a normal data flow, as far as i know the rename should be triggered as part of the provisioning code, right?

 

Thanks a ton!

June 29th, 2010 5:31pm

This is correct, a DN update is a rename operation - not an attribute flow.
The ADMA should be smart enough to detect that a DN update requires an API call.

One thing you should do is to provision to the new OU to eliminate access issues.
Also, the new OU is not in the same domain as current OU - correct?

Cheers,
Markus

Free Windows Admin Tool Kit Click here and download it now
June 29th, 2010 6:38pm

The day is over around here, I will double check on the access first thing in the morning, 

I'm moving the account from one Ou to another OU in the same domain, its a single domain environment, 

Cheers!

Bilal

June 29th, 2010 7:20pm

I still have no luck with it, the access level is right, I can provision accounts to the same location, 

Just to make things more clear,

 - I'm importing all users from AD to the portal.

- attaching some values from another source (HR system) to the accounts.

- the newly attached values will affect the location of accounts in AD , so the dn will be updated and the users should be moved to different OUs

 

still the dn update is listed as ADD value to the dn (dn current value is empty) , but the confirmation import states changes not reimported, the dn value is still empty.

is there any possibility that the FIM portal is not aware of the current value of AD users when importing? the normal data flow of dn value indicates that the provisioning routine is not considering the new value as rename, only as a normal update to a normal attribute.

 

thanks! 

Free Windows Admin Tool Kit Click here and download it now
June 30th, 2010 3:09pm

I have just done a sanity check in my lab environment.
All, I can tell you is, that it should work as explained.

Your best bet is probably to create a repro of my scenario and to compare it with what you have.

Here is the synchronization rule I've been using:

 As you can see, I'm using the description attribute to make a move decision.
If description is "Test", I'm moving the object to a different OU.

Moving the object to a different OU is correctly indicated as Rename:

This is also what the synchronization statistics reports:

 

I hope this helps...

Cheers,
Markus

June 30th, 2010 4:36pm

It finally worked! I followed your guidlines and it worked right away, Thanks a ton.

I still can't get where did i go wrong, the difference i had in my configuration was the construction of the DN value, I had it done at the import flow out of the HR system, I reconfigured it to be constructed at the Outbound phase of the AD sync rule, and now its working perfectly, 

 

Thanks again, I really appreciate your time

Bilal

Free Windows Admin Tool Kit Click here and download it now
July 4th, 2010 10:30pm

You know our friend Murphy – right :o)
I’m glad to see that it works for you now.

Cheers,
Markus

July 5th, 2010 1:01am

Hi,

I had the exact same problem and this post was very helpful in solving it.

In my case, I had a custom attribute in FIM where I was storing the whole dn. I was then just doing a direct attribute to attribute mapping in my outbound sync rule.

When I changed it to a CustomExpression in the outbound sync rule, it worked.

Does the dn attribute have to be set via a custom expression? Seems a little odd.

Thank you again for the helpful post. I'm just being curious now.

Many thanks,

Sami
Free Windows Admin Tool Kit Click here and download it now
August 8th, 2010 11:00pm

There is no need to set the dn by using a custom expression.
You can use whatever method works for you.

Cheers,
Markus

August 8th, 2010 11:19pm


When I changed it to a CustomExpression in the outbound sync rule, it worked.

I know this thread is way old, but I just ran across the same thing. A flow rule of dn=>dn is treated as an attribute flow. A flow rule of CustomExpression(dn+"")=>dn is treated as a rename.

I am on a fairly recent build (3508).

Rex

Free Windows Admin Tool Kit Click here and download it now
October 3rd, 2014 7:13pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics