User Profile connector must prevent attempts to migrate a user to itself

Craig Gilmour 13 years ago in UNIFYBroker/Microsoft SharePoint updated by anonymous 9 years ago 7

This is an item that has been referenced in a couple of other issues but requires its own issue so it can be tracked specifically. I have identified what I believe is a major problem with the Sharepoint Connector with Identity Broker. It relates to the fact that a case difference in the domain name (and perhaps the account name as well - unsure).

For example if the case changes or appears to change from say CN=T00000003539,DC=cad to CN=T00000003539,DC=CAD or the other way around, Identity Broker triggers a migration of the user profile. The result is that the Sharepoint Profile is deleted. We then ended up with what looked like duplicates in ILM - both with the same account name but one entry having the DN as the GUID rather than the correct account name - probably because Broker had the old value but was not able to confirm the new or something similar - not pretty.

Working with Peter Sullivan, we replicated the problem in a vanilla Sharepoint Install by doing the following:

1. Created a user in AD and running a Profile Import from MOSS against AD. Added some profile information against the user
2. Searched for the user and confirmed that they are in fact present
3. Running a profile migration as follows (BTW - you could have any combination of case including the same case):
stsadm -o migrateuser -oldlogin DEV\peter -newlogin dev\peter -ignoresidhistory
4. Searched for the user again - they were no longer present in MOSS
5. Ran another profile import against AD and the user re-appeared but with no profile information against them

Hence it appears as if this could be a major problem. It is no doubt a bug with the Sharepoint API's but it has catastrophic implications for the management of profiles. I managed to destroy over 700 profiles this morning in production when this happenned to occur.

Can you please investigate and attempt to reproduce? In the meantime I may revert the solution back to an account that does not have the priveleges to run a migration in order to stop this ocurring in production from now on, unless you have a tactical recommendation.

I have attached the logfile from Broker as well as the screenshot of the ILM view of things.



This is a good find (subjectively) on behalf of you and Peter, and this is correct - SharePoint's migration functionality deletes the "new" account if it detects one with the same login as the account specified, see here. I have just tested this with no case differences, ie. migrating UNIFYDEMO\7020 to UNIFYDEMO\7020 also deletes the account - the casing of the field is just a moot point. In this case, the unfortunate thing is that it is attempting to migrate the user to itself, so it deletes itself before it can perform the migration. After discussion with the team, we will need to make the SharePoint connector throw an error in this case preventing this from occurring, as ignoring the issue or preventing the migration will result in exported change not reimported errors on the ILM side. The solution in your case is to ensure that the cases match on the solution and Identity Broker configuration sides.

Also to note is that a polling import on the Identity Broker side does not pick up a deletion that has taken place like this, giving a possible explanation for your retrieval of a duplicate entry, whereas a full connector import will.

Updated issue information for relevance to discovered issue

Error message of the following format:

System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: A profile migration attempt was made where target and source account names are the same. This would result in the deletion of the account. Please ensure that the account name is correctly populated, and that casing is consistent. 
Source account name: UNIFYDEMO\2222
Target account name: UNIFYDemo\2222 (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.Exception: A profile migration attempt was made where target and source account names are the same. This would result in the deletion of the account. Please ensure that the account name is correctly populated, and that casing is consistent. 
Source account name: UNIFYDEMO\2222
Target account name: UNIFYDemo\2222
   at Unify.Connectors.MossUserProfileConnector.ModifyAnchor(MultiKeyValue oldKey, MultiKeyValue newKey) in C:\Hg\Connectors\Microsoft.SharePoint\Master\Source\Unify.Connectors.Microsoft.SharePoint\MossUserProfileConnector.cs:line 78
   at Unify.Framework.ConnectorToModifyAnchorConnectorBridge.ModifyAnchor(MultiKeyValue oldKey, MultiKeyValue newKey)
   at Unify.Framework.EventNotifierModifyAnchorConnectorDecorator.ModifyAnchor(MultiKeyValue oldKey, MultiKeyValue newKey)
   at Unify.Framework.Adapter.<>c__DisplayClass34.<CheckAnchorChangeOnSave>b__2f(KeyValuePair`2 keyValue)
   at Unify.Framework.Visitor....).

Connector updated and tested. Issue added to documentation - https://unifysolutions.jira.com/wiki/display/IDBSP305/Profile+migration+blocked+by+the+connector+because+source+and+target+account+names+are+the+same. Please confirm resolution in the next release candidate.

Earlier email from Craig:


I understand. Actually - the resolution for this is something I wanted to talk to you about - i.e. talking about the behaviour. I understand it will throw an error if you attempt to do the rename. However, I am a little concerned about the behaviour of the over-all lifecycle. i.e. will it throw an error and then continue to error? Will it stay as a pending change in ILM / FIM and retry? It is one thing to stop the error (which is critical), but how will it play out over a general lifecycle?

I would have thought that an alternative would be to notice that the accounts are actually the same and then simply not invoke the migration process. This way, no errors and the lifecycle of the over-all solution works out. It is easy to say that you should be careful to make sure the code is entering the correct case. However, in the situation at DET it was correct case. The Connector Space had strange case (refer to recent question I raised https://unifysolutions.jira.com/browse/QDET-96) or between the connector space and IdB generated mismatches. The entry listed below is what was presented to sharepoint in the error:

Modify anchor for entity CN=E00001254260,DC=CAD to CN=E00001254260,DC=cad

As you know from the code snipit, the flow rule had uppercase "CAD", so something within or around IdB decided that it needed to lower case the entry. If, instead of flowing an error, it simply just checked the case and flowed the other attributes that were queued for update I would consider this an ideal behaviour.

This continues the theme of case sensitivity issues throughout Identity Broker and I believe is a major area that needs to be addressed.

Craig Gilmour

Email response to Craig:


The issue with ignoring the migration would be that you would get exported change not reimported errors – ILM would be expecting the account name to have changed.

The issue happening is that the data source and the solution are inconsistent, and due to this behaviour of SharePoint, the result is quite destructive. The Account Name that is sent/provisioned to SharePoint will need to match the account name on the SharePoint side.

Another “gotcha” we have recently encountered is the impact of the container on the resolution and casing of the distinguished name – see https://unifysolutions.jira.com/browse/IDBSP-29, and https://unifysolutions.jira.com/wiki/display/IDBFIM300/An+export+to+Identity+Broker+fails+with+an+ma-extension-error+and+the+Windows+Application+Event+Log+cites+an+InvalidOperationException+as+the+reason. It has seemed that if a container from SharePoint does not match the casing on the solution side, ILM can resolve and create distinguished names differently. In fact, quite recently I saw that the deletion of the only “lower case” account in SharePoint resulted in 15 renames on the ILM side, which were upper case. Perhaps this is a difference between the mirror production and production environments?

At any rate, I believe throwing an error to prevent this behaviour is the most appropriate path that can be taken, without “squashing” FIM’s need to confirm changes. Let us know if you have any other thoughts on the matter.



Updated billing key.