Unexpected error when re-enabling an AD account

Hi,

I am receiving an "unexpected-error" when exporting a previously disabled account to AD as a re-enabled account.

Here's the scenario:

User is returned to the delta view, which should move them back to the Active Accounts OU (from the Inactive Accounts OU).

The export does move the user to the Acitve Accounts OU, however, the user is disabled, and the export reports "unexpected-error".

A subsequent sync will change the user to enabled without any errors.

The event viewer reports this error, that baffles me a bit:

 "BAIL: MMS(1848): tower.cpp(3855): 0x80004005 (Unspecified error)

BAIL: MMS(1848): csobj.cpp(2112): 0x80004005 (Unspecified error)

BAIL: MMS(1848): expcall.cpp(864): 0x80004005 (Unspecified error)

ERR: MMS(1848): expbase.cpp(2902): PutAnchorWithDnInternal failed on CS object {CB0DE8C8-15F4-48CC-8A67-3214E4D3DE85} with 0x80004005 (pass 1 of 5)

Forefront Identity Manager 4.0.3576.2"

All my searches say a hotfix addressed this in ILM, but I'm unsure if that would be an appropriate approach for FIM.

Any ideas or suggestions are appreciated.

Thank you for any help.

 

Sami

August 7th, 2011 3:59pm

Sami - can you confirm that the disabled account you are seeing there is not one that has been re-provisioned?  A straight rename (mod dn) has always worked OK for me, so I am thinking the "PutAnchorWithDnInternal" part of the exception is the clue here.  It indicates to me that the FIM sync engine might be trying to overwrite the AD anchor (the AD guid) with something that was previously stored in FIM.

I presume you are using declarative sync rules here?  If so, what are you using as the relationship for the join?  What are your attribute flows out to (and back in) from AD for the following atts:

  • dn
  • objectSID
  • objectGUID
Free Windows Admin Tool Kit Click here and download it now
August 8th, 2011 3:16am

Hi Bob,

I am using declarative sync rules.

For the join relationship, I'm comparing:

objectSid=objectSid

employeeID=employeeID

accountName=sAMAccountName

I have two outbound attribute flows to dn, one for Initial Flow Only, both with this custom expression:

IIF(IsPresent(SQL_Connector_Flag),"CN="+Customer_ID+",OU=Sharepoint_Users,DC=DOMAIN,DC=org","CN="+Customer_ID+",OU=Inactive Accounts,DC=DOMAIN,DC=org")

I have an inbound attribute flow of objectSid to objectSid.

I just did another test and the objectSid is not changing when the account is re-enabled, so I'm assuming that means it wasn't re-provisioned.

Does anything I have in the sync rule look suspicious?

Thank you for your help and ideas.

 

Sami

 


August 8th, 2011 3:53pm

Out of curiousity, I set the attribute flow for userAccountControl to "Initial sync only".

This obviously means the account didn't get re-enabled, but I also didn't get the error.

The object's userAccountControl is definitely 514 before the attempt to change it to 512.

I'm using this code to set the UAC value:

IIF(IsPresent(SQL_Connector_Flag),512,514)

Maybe that is the problem? (I've used this code before and it's been OK.)

Thanks,

Sami

Free Windows Admin Tool Kit Click here and download it now
August 8th, 2011 4:08pm

The SR looks good, but are you trying to activate an account that may not have an initial password?  You can't enable an account without at least setting an initial password - I usually check the pwdLastSet value to determine this.

August 8th, 2011 5:14pm

I think the password is already set because I am able to manually set the account to enabled in ADUC when the user is in the state right before the Export that causes the error.

However, you have maybe hit on something.... If I remove the attribute flow to set the password, the error doesn't appear. With the password attribute flow enabled, the preview doesn't show it being affected with any change, so I'm not sure if this is relevant or not.

I'm still not sure what's going on, but will work on the password angle some more.

Thank you again for your help.

 

Sami

Free Windows Admin Tool Kit Click here and download it now
August 8th, 2011 9:02pm

Cool - password flows should always be initial flow only, as you don't want these appearing in your metaverse in clear text, and if you do it the correct way it remains hidden.
August 9th, 2011 2:37am

Thank you for the help. The Initial Flow only worked. The customer has a password flow requirement and isn't using PCNS, so I'm doing something different for password attributes.

Thanks,

Sami

Free Windows Admin Tool Kit Click here and download it now
August 9th, 2011 6:36pm

Hi,

I am receiving the same unexpected error when I try to reset password when reactiving an account.

You said: "password flows should always be initial flow only". How can I do reset password with AD management agent?

Thanks,

Serge

December 6th, 2012 8:07pm

Hi Serge,

It's been a while but I think the approach we took was just to re-run a delta sync since the second sync picked up the password and enabled the account.

Now that more clients are using SSPR, the approach I am taking is to just re-enable the account and then the user is required to reset his password via SSPR. (Or an administrator sets the user's password if the user never registered for SSPR.)

Perhaps not the most elegant solution, of course.

Thanks,

Sami

Free Windows Admin Tool Kit Click here and download it now
December 6th, 2012 11:14pm

Hi Sami,

I found it necessary to launch 3 times the cycle export-deltaImport-deltaSync before the password synchronisation run. It looks like your solution, isn't it? I will try to reset the password in the metaverse extension instead of the connector rule extension, maybe I won't receive this unexpected error anymore.

I will investigate on SSPR solution too.

Thank you for your help.

Serge

December 7th, 2012 2:22pm

You're welcome. Let us know how the password extension works if you can please. I'm curious. :)

Free Windows Admin Tool Kit Click here and download it now
December 7th, 2012 8:45pm

When I tried to synchronize password with metaverse extension I receive the following error: "attribute unicodePwd is read only".

December 10th, 2012 4:48pm

I get this same error consistently when I re-enable (and rename) an account.

There are four things I do when re-enabling an account:

  • I set the UAC to 512.
  • I set the pwdLastSet to 0 to force a change at next logon.
  • I reset the password through an EAF, using a randomly generated value.
  • I move it from a 'Disabled Accounts' OU to a new OU that is determined based upon the user's role.

This error is something new in FIM.  I did a straight migration from ILM to FIM, using the same flows and code that NEVER gave me a problem in ILM.  The errors occur only on Export and only on existing accounts that are being re-enabled.

Free Windows Admin Tool Kit Click here and download it now
April 26th, 2013 9:16pm

What is the FIM version number you are using? I know what you are doing is supposed to work with FIM and so have you isolated the problem to the password flow?
April 27th, 2013 5:09am

Frankly, I haven't isolated it to anything except for the fact that it only occurs when I am re-enabling a 'disabled' account.  So it is one or more of the things I previously mentioned:

  • Changing the UAC to 512.
  • Setting the pwdLastSet to 0 to force a change at next logon.
  • Resetting the password through an EAF.
  • Renaming the object to move it from a 'Disabled Accounts' OU to a new OU.

Or it is the one I failed to note:

  • Linking the re-enabled user to their manager by populating the 'manager' attribute with their manager's DN.

I think we need someone knowledgable to explain what the "PutAnchorWithDnInternal" function does and why it might fail in this circumstance.

Free Windows Admin Tool Kit Click here and download it now
May 1st, 2013 10:18pm

Oh, and I am on 4.1.3419.0.

May 1st, 2013 10:20pm

I don't know what PutAnchorWithDnInternal does, but I gather this showed up in your troubleshooting?  If so, how are you setting the manager DN - direct reference attribute flow or constructing it in a rules extension?  Reason I ask is that if you're constructing it in code then it may not be resolving in the AD connector space - you can easily check this by searching the CS for the DN of the manager and seeing if it turns up a real object or just a placeholder.  If it's a placeholder you either have an incorrectly constructed DN or the object doesn't exist - although in this case FIM should really just ignore the placeholder not throw an error.  What's the exact text of the error?
Free Windows Admin Tool Kit Click here and download it now
May 2nd, 2013 2:42am

Two events show in the Application Event Log: 6301 & 6401. The text is pretty much the same as was reported by the originator of this thread.  Here is an example of mine:

The server encountered an unexpected error in the synchronization engine:

"BAIL: MMS(460): d:\bt\800\private\source\miis\shared\entry\tower.cpp(3753): 0x80004005 (Unspecified error)

ERR_: MMS(460): d:\bt\800\private\source\miis\shared\entry\tower.cpp(11786): BAIL: MMS(460): d:\bt\800\private\source\miis\server\sqlstore\csobj.cpp(1815): 0x80004005 (Unspecified error)

BAIL: MMS(460): d:\bt\800\private\source\miis\server\sync\expcall.cpp(911): 0x80004005 (Unspecified error)

ERR_: MMS(460): d:\bt\800\private\source\miis\server\sync\expbase.cpp(2954): PutAnchorWithDnInternal failed on CS object {5A0701B5-71A9-E211-A91C-005056B75280} with 0x80004005 (pass 1 of 5)

Forefront Identity Manager 4.1.3419.0"

To get the manager's DN, I use the employee ID of the manager, which I get from my data feed.  I do a MV lookup on the empID then grab the DN of the returned object.  I then set 'manager' in an EAF.

Like I mentioned earlier, this is all part of a configuration I carried over from ILM -- none of this has been changed and it always worked flawlessly in ILM (and MIIS before that.)

May 2nd, 2013 3:13am

Hotfix rollup package (build 4.1.3441.0) is available at http://support.microsoft.com/kb/2832389 so it would be good to eliminate the FIM version as the culprit for a possible bug (but I don't know if anything is mentioned in any of the release notes since 4.1.3419.0 on this).  Do you know if the manager DN on the failing object resolves to a placeholder or not in the CS?
Free Windows Admin Tool Kit Click here and download it now
May 2nd, 2013 3:22am

The manager DN is not the problem.  After export, all of the expected changes are made except for the 'userAccountControl' value for a 'disabled' account remains unchanged -- the 'manager' reference DN is set and works; the 'must change password at next logon' box is checked; the account is renamed and moved to the target OU -- but the account remains in a 'disabled' state.

I have opened a ticket with Microsoft for this as I need to get it resolved.

May 8th, 2013 6:40pm

I have opened a ticket with Microsoft for this as I need to get it res

Free Windows Admin Tool Kit Click here and download it now
May 8th, 2013 6:53pm

Hi Ed,

I am experiencing exactly the same symptoms as described here by you. Is there any resolution/fix available?

We are upgrading from FIM (4.0.3531.2) to FIM R2 (4.1.3114.0). Everything else looks good except for this issue when Exporting to AD, just for accounts that become Active: they get moved to the right OU but they are left disabled.

We did not change any code but the rule extension DLLs were re-compiled to target .Net Framework 3.5 instead of 2.0.

The old FIM version worked fine for the past almost 2 years ...

I am able to reproduce this in our QA environment, hence I rolled back the upgrade to FIM R2 until we have a proper solution.

Thanks,

Radu

July 2nd, 2013 10:08am

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

Other recent topics Other recent topics