The Unique ID Attribute has been left blank

[jialu song]

I'm trying Confluence.

in "Test Remote Directory Connection"

If I test the connection I see these results:

Test basic connection : Succeeded

  Test retrieve user : Succeeded

 Test user rename is configured and tracked : The Unique ID Attribute has been left blank. We recommend you set this to the attribute for the UUID of the user.

  Test get user's memberships : Succeeded, 1 groups retrieved

  Test retrieve group : Succeeded

  Test get group members : Succeeded, 2 users retrieved

  Test user can authenticate : Succeeded

I'm not sure what to do.

[Mallmann]

Hello Jialu,

Can you let us know which LDAP directory you are using on your Confluence?

The User Unique ID Attribute field is the attribute objectGUID on Active Directory and is located under the User Schema Settings of your LDAP configuration on Confluence.

However, it depends on your LDAP to exist and it also might be a different attribute.

I hope it helps. 

Eduardo

[James Rogers]

what if we are not connected to LDAP? Using Atlassian Crowd internal directory.

[James Rogers]

Not connected to LDAP.  Using Atlassian Crowd and getting this error.  So, why isn't crowd configured properly?

[Julian Green (KMIS)]

Doesn't work with JIRA either. You would think that Atlassian could make their own products mutually compatible.

[Mallmann]

Hey guys, JIRA and Crowd do not use this field to rename users, thus you guys are seeing this message. So, there's no need to worry about this warning. :) The warning appears because the tests are the same ones run against the LDAP or any other directory type. I hope it clarifies. Eduardo

[Anton Iskandiarov]

Why can't Atlassain care about such things and not bother user with false warnings? As mentioned above "why can't you get work your own products products together?".

[Jason Murray]

I agree. Can we please get a fix if using Jira or Crowd directories to authenticate? Having a false positive has obviously wasted a lot of administrators time already

[Alexander List]

False positive warnings that are irrelevant are an unnecessary distraction and will cause more harm than good. If a directory doesn't provide a particular field, don't test for it.

[Academy of the Hebrew Language]

It shouldn't be a problem to add a pre-stage to the test, checking the type of directory, then test for the uid field only if relevant.

An even easier solution and still acceptable in my opinion would be to simply add to the error message a short line: "if not using LDAP disregard this message" or something like that.

[Robert Klebes]

Also comes up if you mount the directory read only; assuming the settings were preserved it's not a huge deal, but it's definitely off-putting. 

[Ad Min]

This problem now seems to block the Crowd sync between crucible, confluence, Bitbucket and Jira, where JIRA is the Crowd server.

This error appears in the error log:

java.lang.IllegalArgumentException:
Multiple entries with same key:
10000:5360752e4d34544788412f7c1833cb07=
com.atlassian.crowd.model.user.InternalUser@28ee7bd3[id=1204,

It is actually the same user, created date is the same, however the loginname changed (for as far as i can see). In JIRA the issue not there, the user is only visible once, but in crusible 2 seem to exist. Please help because the problem is blocking!

[FreeSoftwareServers]

This error has also caused me grief and looks bad on the company in my opinion, almost as bad as this thread. Starting to remind me of a Google or Microsoft forum, where nobody responds. How about, "we understand your input and are looking to resolve this in a future release"? Make a JIRA ticket and get er done!

[Mallmann]

We already have a ticket open to report and track this behaviour right here: https://jira.atlassian.com/browse/CONF-39854

Feel free to comment on that ticket.

Eduardo

[V. Lipper]

just stepped over this funny task here as this message is still wasting administrators time. 2 years after opening a ticket on it....

[Deleted user]

still the same 4 years later

[Jaedo Aum]

And in 2021, we're still gonna be...