0
Answered

SID Mapping errors

Matthew Woolnough 2 years ago in UNIFYBroker/Microsoft SharePoint • updated by anonymous 2 years ago 28

This is a pre-existing issue, so could very well be environmental.  We're not meant to be fixing pre-existing issues, but if it's something simple it should be addressed.  

Any idea what might be causing this?


IdB5.x

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)
...).


IdB3.x

System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Invalid Property Value: Could not find SID corresponding to input account name. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
Microsoft.Office.Server.UserProfiles.PropertyInvalidValueException: Invalid Property Value: Could not find SID corresponding to input account name.
   at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.ValidatedPerson(Object value, UserFormat userFormat, UserProfileApplicationProxy userProfileApplicationProxy, Guid partitionID)
   at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.ValidatedSingleValue(Object value, ProfileSubtypeProperty prop, PropertyDataType propDataType, UserFormat userFormat, UserProfileApplicationProxy userProfileApplicationProxy, Guid partitionID, SiteContext si)
   at Microsoft.Office.Server.UserProfiles.UserProfileGlobal.ValidatedValue(Object value, ProfileSubtypeProperty prop, PropertyDataType propDataType, UserFormat userFormat, UserProfileApplicationProxy userProfileApplicationProxy, Guid partitionID, SiteContext si)
   at Microsoft.Office.Server.UserProfiles.ProfileValueC...).


Affected Versions:
Fixed by Version:

Answer

Answer
Answered

I'd recommend speaking with the SharePoint and/or sys admin, as this error is pretty low down in the SharePoint stack and is calling into native API's (advapi32.dll LookupAccountName).

Under review

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

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.

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.  

Answer
Answered

I'd recommend speaking with the SharePoint and/or sys admin, as this error is pretty low down in the SharePoint stack and is calling into native API's (advapi32.dll LookupAccountName).

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.