Adobe Experience Manager Sites & More

ClintLundmark · 10/15/15

In AEM 6.1 when a new user is created the node name for the user appears to be a random alphanumeric string. The user is placed in the repository based on the first character of the string. The same happens for groups. For example, a user created with the ID of oscar might get created at:

/home/users/A/Av1DJBJvjDKqRWn0d4OT

In AEM 6.0 and prior the same user account would get created at:

/home/users/o/oscar

Is this intentional or a bug? If intentional why? Is there a configuration somewhere that can be set to name the node after the user id?

...
clint

Jörg_Hoh · 10/15/15

Hi Clint,

I don't think, that this change has been done for the sake of obfuscation. My personal belief is that is has been done for the reason of scalability (to get a more balanced tree). I do think, that you can still create the users and groups as you like (especially when you do it by API or content packages).

Jörg

View solution in original post

smacdonald2008 · 10/15/15

This is how AEM 6.1 stores users:

[img]usersGUID.png[/img]

If your concern is to query names from the JCR (or other JCR operations) - you can still search/select nodes under the GUID value. For example - under the GUID node - there is a profile node whose properties reflect typical values such as First name, and so on. (as shown above)

As far as configuration, there is no documentation that suggests you can configure AEM to replace a GUID with name. I doubt you can do that.

Jörg_Hoh · 10/15/15

HI,

this change is intentional. In earlier versions the behaviour was convenient, but there was never a guarantee. I assume that it was changed for scalability reasons.

kind regards,
Jörg

Permalink · 10/15/15

I've checked on this, and the difference is due to the new RandomAuthorizableNodeName class [0][1].

I confirmed that this change was made to enhance security. (It's not in any way related to improving performance/scalability.)
Presumably, with the AuthorizableID no longer in the node name (and thus the path), it is more difficult for a malicious user to compromise the system.

We have an open request internally to have details of this documented. If you would like to see this documentation completed sooner rather than later, please open a DayCare ticket and ask to have the priority of DOC-4881 raised.

- Carey

[0] https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/security/user/RandomAuthori...

[1] http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/s...

ClintLundmark · 10/15/15

Thanks smacdonald8 and Jörg for the quick response.

It's mostly a nuisance issue.

I have configured LDAP many times and this time I thought I had something misconfigured. I spent quite a bit time determining it was configured properly and the system changed.
I will be "importing," via package, many groups and possibly users. They are coming from CQ 5.5. The package will work fine, but the old users and groups will be different than any new users and groups making an inconsistency.
Manually browsing for a user in the repository is more difficult now, Search will essentially be required.
Obfuscating something for no apparent reason is generally just a nuisance.

Regardless I can work around it if that's the way it going to be.

Thanks again for the responses.

...
clint

Jörg_Hoh · 10/15/15

Hi Clint,

I don't think, that this change has been done for the sake of obfuscation. My personal belief is that is has been done for the reason of scalability (to get a more balanced tree). I do think, that you can still create the users and groups as you like (especially when you do it by API or content packages).

Jörg