SID Mapping errors

I did find this which suggested a code change might fix it.

https://social.msdn.microsoft.com/Forums/en-US/62d5c57b-09f0-4400-b19b-77097e2e62e2/how-to-update-person-type-field-in-user-properties-programmatically?forum=sharepointdevelopmentprevious

Do you have the stack trace from the Identity Broker side?

UnifyLog20170627.zip

I've improved the error logging (it should report the failed entities back to FIM properly). Unify.Connectors.Microsoft.SharePoint.dll

If it's a specific entity that's failing it's likely an issue with the specific account (e.g. corrupted somehow - hard to tell as it's fairly embedded into the SharePoint API). If all accounts are failing to add then it might be the way we're coming up with the account name.

Actually, hold off on that for a minute, I need to merge another fix into this one otherwise the export won't work at all.

Please try Unify.Connectors.Microsoft.SharePoint.dll

Where should the additional logs appear? I'm not seeing the error in the IdB logs any more, but still present in MIM. 

System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: No mapping between account names and security IDs was done (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.ComponentModel.Win32Exception: No mapping between account names and security IDs was done
   at Microsoft.Office.Server.Utilities.Win32.AdvApi.LookupAccountName(String lpSystemName, String lpAccountName, IntPtr Sid, Int32& cbSid, StringBuilder ReferencedDomainName, Int32& cchReferencedDomainName, SID_NAME_USE& peUse)
   at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.GetSidFromAccount(String strAccountName, SID_NAME_USE[] IntendedAccountType, SID_NAME_USE& sidUse)
   at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.GetSidFromAccount(String strAccountName, Int32 nMaxLengh)
   at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.GetSidFromAccount(UserProfileApplicationProxy proxy, Guid partitionID, String strAccountName, Boolean isWindowsAccount)
   at Microsoft.Office.Server.UserProfiles.UserProfile..ctor(UserProfileManager objManager, String strAccountName, String strPreferredName)

...).

it should report the failed entities back to FIM properly

It's the result that's returned to FIM, it's against the specific entity that failed.

OK. Is this one still under review, or is this one for the too hard basket?

Waiting on you:

If it's a specific entity that's failing it's likely an issue with the specific account (e.g. corrupted somehow - hard to tell as it's fairly embedded into the SharePoint API). If all accounts are failing to add then it might be the way we're coming up with the account name.

OK.  I'm exporting 7 users and they're all failing.  

FYI this is documented here.

Is the Connector exporting the fully qualified account name?

Use fully qualified account names (for example, domain_name\user_name) instead of isolated names (for example, user_name). Fully qualified names are unambiguous and provide better performance when the lookup is performed.

It depends, if your account name field is a dn then it'll take the CN component as the account name and the DC component as the domain name, and optionally the O component as the authentication schema. It'll then be converted to FQDN format.

If the account name is a string, it's passed straight through, so the format is whatever you're exporting.

I've updated the WCF service to include the account name when it fails, hopefully that helps Unify.Connectors.SharePoint.SharePoint2010WCFService.wsp

OK, So currently it's using the following as accountName:

CN=<samaccountName>,OU=SPUsers,DC=IdentityBroker

If I'm understanding you correctly, the connector will be constructing the following fully qualified account name:

IdentityBroker\<sAMAccountName

I need it to be:

DEV\<sAMAccountName>

Does IdB use the first DC it encounters? 

CN=<samaccountName>,DC=DEV,OU=SPUsers,DC=IdentityBroker

This approach is a little problematic as it means the config of IdB needs to be changed for each of the 3 environments:

• DEV
• TST
• PROD

I can see this being an even bigger problem for Multi-Domain environments.

How is that your account name? That can't be the value that is imported.

I don't understand your concern with the domain name or multi-domain, are you saying it's too difficult to export the right account name?

I'm just saying that it's strange to use a DN to represent that information when using the actual string would be better:

Instantly recognisable as an account name:

DEV\<sAMAccountName>

Not so much:

CN=<samaccountName>,DC=DEV

They're just different ways of representing the same thing.

They are both valid options anyway (as mentioned earlier), you just have change the field type to string and use the FQDN format if you want to do it that way.

Ah-ha. In 5.1, does AccountName be of type DistinguishedName for this to work?

What is it set to now? You should change it to string and use FQDN if you want it to work the way you mentioned earlier. If you want to keep using the dn format, make sure it's set to distinguished name.

In 3.x, it was a string type, but being pushed out in a DN format.

This is not working in 5.1.  I'll switch the type to DN & re-test. 

Ah, well that's a different problem. I'll investigate why it's coming through in a dn format.

The code only appears to do a conversion from FQDN to DN if you have the field set as a DN.

Odd. after a fresh full Import, looking in the IdB connector:

3.x presents AccountName as CN=<samaccountName>DC=Dev. 

5.1 presents AccountName as DEV\<samaccountName>

Is this a change in functionality? 

It's a change in the default, you're free to change it if you'd like the DN format.

How is this done? The attribute is set to DN already & it's still showing up in the DN format.

Is a full import required? I can't run one right now due to a data issue. 

Yes, it's calculated on import.