Definition of UNSAccount.CN has been changed in ver 9.0 LTS

The change has been made in 8.2 to correct inconsistencies between the display pattern and the UNS mapping for some objects. These inconsistencies led to search-related issues during the attestation / re-certification.

The definition itself cannot be changed.

The change has been made in 8.2 to correct inconsistencies between the display pattern and the UNS mapping for some objects. These inconsistencies led to search-related issues during the attestation / re-certification.

The definition itself cannot be changed.

Hallo Markus, thank you for the fast response.

In our installation, records in UNSAccountB table have different values in CN and DisplayName.

It's strange that this change was made to correct inconsistencies. In our case it actually brings inconsistency in attestation / re-certification, as well as it brings inconsistency in business-critical reporting.

We really need to change this behavior and make UNSAccountB.cn -> UNSAccount.cn. Please help

Hi Sargay,

I am unable to share all the details for this change, but without it, the search will not find every attestation case if you search for the displayed name of the user account using provided recertification procedure. Thing is, that the DisplayPattern of UNSAccountB is not %CN%, to ensure that the very likely duplication of names in different target systems (Adminstrator is one example) does not lead to misinterpretation in lists and reports.

I currently do not know any supported way to change the UNSAccount mapping, and even if it would be possible, you might see issues popping up in other areas if you do.

You can of course contact support about this matter.

Hallo Markus,
thank you once again for descriptive answer.

To be honest, I don't think the change solves the problem you have described. 

It uses UNSAccountB.DisplayName for UNS but stiil use ADSAccount.cn for ADS where can be the same non-uniqueness in case of multiple AD domains

Yes, there can be duplication of CN attribute in UNSAccuntB table because if keeps data from multiple UNS systems.
And yes, there can be duplication of CN attribute in UNSAccountB table event they belong to a single UNS system because multiple objects can have the same CN if they are in different containers.

So, re-certification procedure must just ensure the fact that CN is non-unique attributes across all the systems and even within single system.

AND.. the change breaks a BASE RULE: "CN is a part of DistinguishedName"

In our case we have in UNSAccount proxy-table such records (see example below)

UNSAccount.cn = 'system1\container2\container1\user1(system1)'
UNSAccount.DistinguishedName = 'CN=user1,CN=container1,CN=container2,DC=system1'

As I have said. I am unable to discuss all the details here and still, all I know is, that you cannot change the UNS Mapping.

Again, feel free to contact support about this matter.