0
Fixed

Adapter RDN - DN Formatting Issue

Richard Green 9 years ago in UNIFYBroker/Microsoft SharePoint updated by anonymous 8 years ago 7

Hi Gents,

I've run into an issue with the DN formatting on an Adapter for my SharePoint Connector.

The usual DN configuration for a SharePoint adapter is an RDN configured on the AccountName field. (This is always in the format - CN=<acctname>,DC=<domain>)

I have configured my dn template as AccountName as shown in the attached screenshots. However on import into FIM, the DN format is incorrect - the commas in the DN have been replaced with plus characters.

ie. 'CN=xs-sp-setup,DC=tafe' is imported as 'CN=xs-sp-setup+DC=tafe'

I've attached screenshots showing the Connector values, DN configuration and FIM import values, along with the LDIF file output from the Adapter Full Import.

Is this possibly a mis-configuration?


Adapter Values.PNG
FIM Objects.PNG
RDN Config.PNG
Unify.Framework.IO.LDIF.dll
UNIFYFull.txt

Hi Shane,

I've assigned this to you as Adam is on leave :S
Are you able to re-assign within the product team as appropriate?

Hi Richard,

You'll notice that the AccountName and DN are different fields in this case.

In your LDIF file, AccountName is showing the same data as the Entity Search.

I'd suggest checking your Adapter DN generator.

Hi Shane,

Yes its the Adapter DN Generator that's at question here. Currently it's configured as '[AccountName]' which if I'm reading the DN Generator Doco correctly, should use the contents of the AccountName field as the DN for the entity. However when it arrives in the LDIF file, the DN format is corrupted with plus characters instead of commas.

The LDIF should have the same value for DN and AccountName.

PS, I'm not sure I read that DN template documentation the same way you did.

Hi Richard,

What do other sites do? Could you look at SSICT configuration?

I'm not entirely sure what you mean by it's configured as AccountName - I wasn't aware that you could just pass on a value like that.

Here is a DLL that should fix this issue.

Fixed in IDB-1175. Please confirm.