User Administration and Security

You are reading the Adobe Experience Manager 5.6.1 version of User Administration and Security.
This documentation is also available for the following versions: AEM 5.6  CQ 5.5  CQ 5.4  CQ 5.3 

This chapter describes how to configure and maintain user authorization and also describes the theory behind how authentication and authorization work in AEM.

About Authentication and Authorization

This section describes the process of identifying a user and then determining whether a user can take specific actions.

Authentication

Authentication is the process of identifying, and verifying, a user.

The process of authentication and login can be broken down as follows:

  1. Authentication information is extracted from the request. In Adobe Experience Manager (AEM), this is done by an authentication handler.
  2. The authentication information is then checked to determine whether it is sufficient and/or correct. In AEM, this is performed by the login modules.
  3. The appropriate response is initiated.

Adobe Experience Manager performs initial authentication using a standard HTML-login form in conjunction with the HTTP Header Authentication Handler. The HTML form must contain fields for the user name and password (the same field names must then be used by the HTTP Header Authentication Handler).

You can also use a similar form for controlled access to various areas of your website.

LDAP, Single Sign On and Portals

The various authentication methods can be realized by using different login modules.

For example, AEM can interact with an LDAP server that stores user information centrally, eliminating the need for duplication. This central server is then used to verify login information which can be used to realize Single Sign On, both with other in-house applications and external Portals.

Authorization

Authorization determines whether a user is allowed to take action on specific areas within the system. For example, a user can be authorized to read or update a specific page.

Authorization is managed using a series of entities:

User

Users access a system using their user accounts. A user models either a human user or an external system connected to the system. The user account holds the details needed for accessing AEM; a key purpose of an account is to provide the information for the authentication and login processes - allowing a user to log in.

Groups

A group is a collection of users and/or other groups. A change in the permissions/privileges assigned to a group is automatically applied to all users in that group. All users are members of the Everyone group. In addition, users can belong to several other groups. (Even if the group Everyone is deleted, all users remain part of the group because of the indirect relationship between users/groups and authorization. See Privileges for more info.)

AEM Actions

AEM actions are performed on a resource. For example, a user can read, edit or delete a page, among other actions.

Permissions

A permission allows a user to perform an action on a given resource within the repository. Permissions are stored, and can be seen, at the resource level within the repository.

Privileges

Privileges allow access to functionality available within the application; for example, replication of a specific path, or the ability to update the page hierarchy (including creating new pages). Privileges are always granted or denied to principals rather than to users or groups. The link between users and groups and the authorization is indirect; there is always a principal associated with a user or group.

Resources

Resources define the functionality to be accessed.

Users and Groups in AEM

This section deals with the various entities and related concepts in more detail to help you configure an easy to maintain user management concept.

Users

Users will log in to AEM with their account. Each user account is unique and holds the basic account details, together with the privileges assigned.

Users are often members of Groups, which simplify the allocation of these permissions and/or privileges.

Groups

Groups are collections of users and/or other groups; these are all called Members of a group.

Their primary purpose is to simplify the maintenance process by reducing the number of entities to be updated, as a change made to a group is applied to all members of the group. Groups often reflect:

  • a role within the application; such as someone who is allowed to surf the content, or someone who is allowed to contribute content.

  • your own organization; you may want to extend the roles to differentiate between contributors from different departments when they are restricted to different branches in the content tree.

Therefore groups tend to remain stable, whereas users come and go more frequently.

With planning and a clean structure, the use of groups can reflect your structure, giving you a clear overview and an efficient mechanism for updates.

Built-in Users and Groups

AEM WCM installs a number of users and groups. These can be seen when you first access the Security Console after installation.

The following tables list each item together with:

  • a short description
  • any recommendations about necessary changes

Please change all default passwords (if you do not delete the account itself in certain circumstances).

User ID Type Description Recommendation

admin

Default password: admin

User

System administration account and member of the administrator group, with full access rights.

This account is used for the connection between AEM WCM and CRX.

If you accidentally delete this account, it will be re-created upon repository restart (in the default setup).

Adobe strongly recommends that the password for this user account be changed from the default.

Preferably upon installation, though it can be done afterwards.

Note: This account is not to be confused with the admin account of the CQ Servlet Engine.

anonymous

 

User

Holds the default rights for unauthenticated access to an instance. Per default this holds the minimum access rights.

If you accidentally delete this account, it will be re-created upon startup. It cannot be permanently deleted, but it can be disabled.

Modifying this account has additional security implications. If you have to edit this account, make a backup copy first.

author

Default password: author

User

A author account allowed to write to /content. Encompasses contributor and surfer privileges.

Can be used as a webmaster as it has access to the entire /content tree.

This is not a built-in user, but another geometrixx demo user

Adobe recommends that either the account is deleted completely, or the password changed from the default.

Preferably upon installation, though it can be done afterwards.

administrators Group

Group that gives administrator rights to all its members. Only admin is allowed to edit this group.

Has full access rights.

If you set a 'deny-everyone' on a node, the administrators will
only have access if it is enabled again for that group.
content-authors Group

Group responsible for content editing. Requires read, modify, create and delete permissions.

You can create your own content-author group(s) with project specific access rights, provided you add read, modify, create and delete permissions.
contributor Group

Basic privileges which allow the user to write content (as in functionality only).

Does not allocate any privileges to the /content tree - these must be specifically allocated for the individual groups or users.

 
everyone Group

Every user in AEM is a member of the group everyone, even though you may not see the group or the membership relation in all tools.

This group can be thought of as the default rights as it can be used to apply permissions for everyone, even users that will be created in the future.

Do not modify or delete this group.

Modifying this account has additional security implications.

tag-administrators Group Group that is allowed to edit tags.  
user-administrators Group Authorizes user administration, that is, the right to create users and groups.
 
workflow-editors Group Group that is allowed to create and modify workflow models.  
workflow-users Group

A user participating in a workflow must be member of group workflow-users. This gives him or her full access to: /etc/workflow/instances so that he or she can update the workflow instance.

The group is included in the standard installation, but you must manually add your users to the group.

 

Permissions in AEM

AEM uses ACLs to determine what actions a user or group and can take and where it can perform those actions.

Permissions and ACLs

Permissions define who is allowed to perform which actions on a resource. The permissions are the result of access control evaluations.

You can change the permissions granted/denied to a given user by selecting or clearing the checkboxes for the individual AEM actions. A check mark indicates that an action is allowed. No checkmark indicates that an action is denied.

Where the checkmark is located in the grid also indicates what permissions users have in what locations within AEM (that is, which paths).

Actions

Actions can be performed on a page (resource). For each page in the hierarchy, you can specify which action the user is allowed to take on that page. Permissions enable you to allow or deny an action.

Action Description
Read The user is allowed to read the page and any child pages.
Modify

The user can:

  • modify existing content on the page and on any child pages.
  • create new paragraphs on the page or on any child page.

At the JCR level, users can modify a resource by modifying its properties, locking, versioning, nt-modifications, and they have complete write permission on nodes defining a jcr:content child node, for example cq:Page, nt:file, cq:Asset.

Create

The user can:

  • create a new page or child page.

If modify is denied the subtrees below jcr:content are specifically excluded because the creation of jcr:content and its child nodes are considered a page modification. This only applies to nodes defining a jcr:content child node.

Delete

The user can:

  • delete existing paragraphs from the page or any child page.
  • delete a page or child page.

If modify is denied any subtrees below jcr:content are specifically excluded as removing jcr:content and its child nodes is considered a page modification.  This only applies to nodes defining a jcr:content child node.

Read ACL The user can read the access control list of the page or child pages.
Edit ACL The user can modify the access control list of the page or any child pages.
Replicate The user can replicate content to another environment (for example, the Publish environment). The privilege is also applied to any child pages.

Access Control Lists and how they are evaluated

AEM WCM uses Access Control Lists (ACLs) to organize the permissions being applied to the various pages.

Access Control Lists are made up of the individual permissions and are used to determine the order in which these permissions are actually applied. The list is formed according to the hierarchy of the pages under consideration. This list is then scanned bottom-up until the first appropriate permission to apply to a page is found.

Note

There are ACLs that are included with the samples. It is recommended that you review and determine what is appropriate for your applications. To review the ACLs that are included, go to CRXDE and select the Access Control tab for the following nodes:

/etc/cloudservices/facebookconnect/geometrixx-outdoorsfacebookapp: Allows everyone read access.

/etc/cloudservices/twitterconnect/geometrixx-outdoors-twitter-app: Allows everyone read access.

/home/users/geometrixx-outdoors: Allows everyone read access for */profile* and
*/social/relationships/following/*.


Your custom application may set access for other relationships, such as  */social/relationships/friend/* or */social/relationships/pending-following/*.

When you create ACLs specific to communities, members joining those communities may be granted additional permissions. For example, this could be the case when users join the communities at /content/geometrixx-outdoors/en/community/hiking or /content/geometrixx-outdoors/en/community/winter-sports.

Permission States

Note

For CQ 5.3 users:

In contrast to previous CQ versions, create and delete should no longer be granted if a user only needs to modify pages. Instead, grant the modify action only if you want users to be able to create, modify, or delete components on existing pages.

For backwards compatibility reasons, the tests for actions does not take the special treatment of nodes defining jcr:content into account.

Action Description
Allow (Check mark) AEM WCM allows the user to perform the action on this page or on any child pages.
Deny (No checkmark) AEM WCM does not allow the user to perform the action on this page nor on any child pages.

The permissions are also applied to any child pages.

If a permission is not inherited from the parent node but has at least one local entry for it, then the following symbols are appended to the check box. A local entry is one that is created in the CRX 2.2 interface (Wildcard ACLs currently can only be created in CRX.)

For an action at a given path:

* (asterisk) There is at least one local entry (either effective or ineffective). These wildcard ACLs are defined in CRX.
! (exclamation mark) There is at least one entry that currently has no effect.

When you hover over the asterisk or exclamation mark, a tooltip provides more details about the declared entries. The tooltip is split into two parts:

Upper part

Lists the effective entries.

Lower part Lists the noneffective entries that may have an effect somewhere else in the tree (as indicated by a special attribute present with the corresponding ACE limiting the scope of the entry). Alternatively, this is an entry whose effect has been revoked by another entry defined at the given path or at an ancestor node.
file

Note

If no permissions are defined for a page then all actions are denied.

The following are recommendations about managing access control lists:

  • Do not assign permissions directly to users. Assign them only to groups.

This will simplify the maintenance, as the number of groups is much smaller than the number of users, and also less volatile.

  • If you want a group/user to be able only to modify pages, do not grant them create or deny rights. Only grant them modify and read rights.
  • Use Deny sparingly. As far as possible use only Allow.

    Using deny can cause unexpected effects if the permissions are applied in a different order than the order expected. If a user is a member of more than one group, the Deny statements from one group may cancel the Allow statement from another group or vice versa. It is hard to keep an overview when this happens and can easily lead to unforeseen results, whereas Allow assignments do not cause such conflicts.

    Adobe recommends that you work with Allow rather than Deny see Best Practices.

Before modifying either permission, be sure you understand how they work and inter-relate. See the CRX documentation to illustrate how AEM WCM evaluates access rights and examples on setting up access control lists.

Permissions

Permissions give users and groups access to AEM functionality on AEM pages.

You browse permissions by path by expanding/collapsing the nodes and you can track the permission inheritance up to the root node.

You allow or deny permissions by selecting or clearing the appropriate check boxes.

Note

For CQ 5.3 users:

If you want to provide users with the ability modify the hierarchy, that is create and delete pages, you do this in CQ 5.4 by granting Create and Delete rights to the user at the correct path. Hierarchy modification is no longer global - you are able to specifically grant and deny permission to users to create and delete pages at specific paths.

file

Viewing Detailed Permission Information

Along with the grid view, AEM provides a detailed view of permissions for a selected user/group at a given path. The detail view provides additional information.

In addition to viewing information, you can also include or exclude the current user or group from a group. See Adding Users or Groups while Adding Permissions. Changes made here are immediately reflected in the upper portion of the detailed view.

To access the Detail view, in the Permissions tab, click Details for any selected group/user and path.

file

Details are split into two parts:

Upper part

Repeats the information you see in the tree grid. For each action, an icon shows whether the action is allowed or denied:

  • no icon = no declared entry
  • (tick)  = declared action (allow)
  • (-)     = declared action (deny)
Lower part

Shows the grid of users and groups that does the following:

  • Declares an entry for the given path AND
  • Is the given authorizable OR is a group

Impersonating another User

With the Impersonate functionality a user can work on behalf of another user.

This means that a user account can specify other accounts that can operate with their account. In other words, if user-B is allowed to impersonate user-A, then user-B can take actions using the full account details of user-A.

This allows the impersonator accounts to complete tasks as if they were using the account they are impersonating; for example, during an absence or to share an excessive load short-term.

Caution

If one account impersonates another it is very difficult to see. An entry is made in the audit log when the impersonation starts and ends, but the other log files (such as the access log) hold no information about the fact that impersonation has occurred on the events. So if user-B is impersonating user-A all events will look as if they were performed by user-A personally.

Best Practices

The following describes best practices when working with permissions and privileges:

Rule Reason
Use Groups.

Avoid assigning access rights on a user-by-user basis. There are several reasons for this:

  • You have many more users than groups, so groups simplify the structure.

  • Groups help provide an overview over all accounts.

  • Inheritance is simpler with groups.

  • Users come and go. Groups are long-term.

  • Be Positive.

    Always use Allow statements to specify the group’s rights (wherever possible). Avoid using a Deny statement.

    Groups are evaluated in order, and the order may be defined differently per user.

    In other words: You may have little control over the order in which the statements are implemented and evaluated. If you use only Allow statements, the order does not matter.

    Keep It Simple

    Investing some time and thought when configuring a new installation will be well repaid.

    Applying a clear structure will simplify the ongoing maintenance and administration, ensuring that both your current colleagues and/or future successors can easily understand what is being implemented.

    Test Use a test installation to practice and ensure that you understand the relationships between the various users and groups.
    Default Users/Groups Always update the Default Users and Groups immediately after installation to help prevent any security issues.

    Managing Users and Groups

    Users include people using the system and foreign systems making requests to the system.

    A group is a set of users.

    Both can be configured using the User Administration functionality within the Security Console.

    Accessing User Administration with the Security Console

    You access all users, groups, and associated permissions using the Security console. All the procedures described in this section are performed in this window.

    To access AEM WCM security, do one of the following:

    • From the Welcome screen or various locations in AEM, click the security icon:
    file
    • Navigate directly to http://<server>:<port>/useradmin. Be sure you log into AEM as an administrator.

    The following window displays:

    file

    The left tree lists all the users and groups currently in the system. You can select the columns you want displayed, sort the contents of the columns, and even change the order in which the columns are displayed by dragging the column-header to a new position.

    file

    The tabs provide access to various configurations:

    Tab Description 
    Filter box A mechanism for filtering the users and/or groups listed. See Filtering Users and Groups.
    Hide Users A toggle switch which will hide all users listed, leaving only groups. See Hiding Users and Groups.
    Hide Groups A toggle switch which will hide all groups listed, leaving only users. See Hiding Users and Groups.
    Edit A menu allowing you to create and delete as well activate and deactivate users or groups. See Creating Users and Groups and Deleting Users and Groups.
    Properties Lists information about the user or group that can include email information, a description, and name information. Also allows you to change a user's password. See Creating Users and Groups, Modifying User and Group Properties and Changing a User Password.
    Groups Lists all groups that the selected user or group belongs to. You can assign the selected user or groups to additional groups or remove them from groups. See Groups.
    Members Available for groups only. Lists the members of a particular group. See Members.
    Permissions

    You can allocate permissions to a user or group. Lets you control the following:

    • Permissions related to particular pages/nodes. See Setting permissions.
    • Permissions related to creating and deleting pages and hierarchy modification. ??? lets you allocate privileges, such as hierarchy modification, which lets you create and delete pages, 
    • Permissions related to replication privileges (usually from author to publish) according to a path.
    Impersonators Lets another user impersonate the account. Useful when you need a user to act on behalf of another user. See Impersonating Users.
    Preferences Sets preferences for the group or user. For example, language preferences.

    Filtering Users and Groups

    You can filter the list by entering a filter expression, which hides all the users and groups that do not match the expression. You can also hide users and groups by using the Hide User and Hide Group buttons. 

    To filter users or groups:

    1. In the left tree list, type your filter expression in the space provided. For example, entering admin displays all users and groups containing this string.

    2. Click the magnifying glass to filter the list.

      file
    3. Click the x when you want to remove all filters.

    Hiding Users and Groups

    Hiding users or groups is another way to filter the list of all users and groups in a system. There are two toggle mechanisms. Clicking Hide User hides all users from view and clicking Hide Groups hides all groups from view (you cannot hide both users and groups at the same time). To filter the list by using a filter expression, see Filtering users and groups.

    To hide users and groups:

    1. In the Security console, click Hide Users or Hide Groups. The selected button appears highlighted.

      file
    2. To make either users or groups reappear, click the corresponding button again.

    Creating Users and Groups

    To create a new user or group:

    1. In the Security console tree list, click Edit and then either Create User or Create Group.

      file
    2. Enter the required details, according to whether you are creating a user or a group.

      • If you select Create User, you enter the Login ID, first and last name, e-mail address and a password. By default, AEM creates a path based on the first letter of the last name, but you can select another path.
      file
      • If you select Create Group, you enter a group ID and an optional description.
      file
    3. Click Create. The user or group you created appears in the tree list.

    Deleting Users and Groups

    To delete a user or group:

    1. In the Security console, select the user or group you want to delete. If you want to delete multiple items, Shift+click or Control+click to select them.

    2. Click Edit, then select Delete. AEM WCM asks whether you want to delete the user or group.

    3. Click OK to confirm or Cancel to cancel your action.

    Modifying User and Group Properties

    To modify user and group properties:

    1. In the Security console, double-click the user or group name you want to modify.

    2. Click the Properties tab, make the required changes, and click Save.

      file

    Note

    The path of the user is displayed at the bottom of the user properties. It cannot be modified.

    Changing a User Password

    Use the following procedure to modify a user's password.

    Note

    You cannot use the Security console to change the admin password. To change the password for the admin account, use the Users console that Granite Operations provides. 

     

     

    1. In the Security console, double-click the user name you want to change the password for.

    2. Click the Properties tab (if not already active).

    3. Click Set Password. The Set Password window opens where you can change your password.

      file
    4. Enter the new password twice; as they are not displayed in clear text this is for confirmation - if they do not match, the system shows an error.

    5. Click Set to activate the new password for the account.

    Adding Users or Groups to a Group

    AEM offers three different ways to add users or groups to an existing group:

    • When you are in the group, you can add members (either users or groups).
    • When you are in the member, you can add members to groups.
    • When you are working on Permissions, you can add members to groups.

    Groups - Adding Users or Groups to a Group

    The Groups tab shows you which groups the current account belongs to. You can use it to add the selected account to a group:

    1. Double-click the name of the account (user or group) that you want to assign to a group.

    2. Click the Groups tab. You see a list of groups that the account already belongs to.

    3. In the tree list, click the name of the group you want to add to the account to and drag it to the Groups pane. (If you want to add multiple users, Shift+click or Control+click those names and drag them.)

      file
    4. Click Save to save your changes.

    Members - Adding Users or Groups to a Group

    The Members tab only works for groups and shows you which users and groups belong to the current group. You can used it to add accounts to a group:

    1. Double-click the name of the group you want to add members to.

    2. Click the Members tab. You see a list of members that already belong to this group.

    3. In the tree list, click the name of the member you want to add to the group and drag it to the Members pane. (If you want to add multiple users, Shift+click or Control+click those names and drag them.)

      file
    4. Click Save to save your changes.

    Adding Users or Groups while Adding Permissions

    To add members to a group at in a certain path:

    1. Double-click the name of the group or user that you want to add users to.

    2. Click the Permissions tab.

    3. Navigate to the path you want to add permissions to and click Details. The lower part of the details window provides information about who has permissions for that page.

      file
    4. Select the check box in the Member column for the members you want to have permissions to that path. Clear the check box for member you want to remove permissions for. A red triangle appears in the cell you made changes to.

    5. Click OK to save your changes.

    Removing Users or Groups from Groups

     

    AEM offers three different ways to remove users or groups from a group:

    • When you are in the group profile, you can remove members (either users or groups).
    • When you are in the member profile, you can remove members from groups.
    • When you are working on Permissions, you can remove members from groups.

     

    Groups - Removing Users or Groups from Groups

    To remove a user or group account from a group:

    1. Double-click the name of the group or user account you want to remove from a group.

    2. Click the Groups tab. You see what groups the selected account belongs to.

    3. In the Groups pane, click the name of the user or group you want to remove from the group and click Remove. (If you want to remove multiple accounts, Shift+click or Control+click those names and click Remove.)

      file
    4. Click Save to save your changes.

    Members - Removing Users or Groups from Groups

    To remove accounts from a group:

    1. Double-click the name of the group you want to remove members from.

    2. Click the Members tab. You see a list of members that already belong to this group.

    3. In the Members pane, click the name of the member you want to remove from the group and click Remove. (If you want to remove multiple users, Shift+click or Control+click those names and and click Remove.)

      file
    4. Click Save to save your changes.

    Removing Users or Groups while Adding Permissions

    To remove members from a group at a certain path:

    1. Double-click the name of the group or user that you want to remove users from.

    2. Click the Permissions tab.

    3. Navigate to the path you want to remove permissions to and click Details. The lower part of the details window provides information about who has permissions for that page.

      file
    4. Select the check box in the Member column for the members you want to have permissions to that path. Clear the check box for member you want to remove permissions for. A red triangle appears in the cell you made changes to.

    5. Click OK to save your changes.

    Managing Permissions

    This section describes how to set permissions, including replication privileges.

    Setting Permissions

    Permissions allow users to perform certain actions on resources at certain paths. It also includes the ability to create or delete pages.

    To add, modify, or delete permissions:

    1. In the Security console, double-click the name of the user or group you want to set permissions for or search for nodes.

    2. Click the Permissions tab.

      file
    3. In the tree grid, select a check box to allow the selected user or group to perform an action or clear a check box to deny the selected user or group to perform an action. For more information click Details.

    4. When finished, click Save.

    Setting Replication Privileges

    Replication privilege is the right to publish content, and it can be set for groups and users.

    Note

    • Any replication rights applied to a group apply to all the users in that group.
    • A user's replication privileges supersedes a group's replication privileges.
    • The Allow replication rights have a higher precedence than the Deny replication rights. See Permissions in AEM for more information.

    To set replication privileges:

    1. Select the user or group from the list, double-click to open, and click Permissions.

    2. In the grid, navigate to the path where you want the user to have replication privileges or search for nodes.

    3. In the Replicate column at the path selected, select a check box to add the replication privilege for that user or group, or clear the check box to remove the replication privilege. AEM displays a red triangle anywhere you have made changes that have not yet been saved.

      file
    4. Click Save to save your changes.

    Searching for nodes

    When adding or removing permissions, you can either browse or search for the node.

    There are two different types of path search:

    • Path search - If the search string starts with a "/" then the search will search for the direct sub-nodes of the given path:
    file

    In the search box, you can do the following:

    Right arrow key
    Selects a sub-node in the search result
    Down arrow key Starts the search again.
    Enter (Return) key Selects a subnode and loads it in the treegrid
    • FullText search - If the search string does not start with a "/" then a fulltext search is executed on all the nodes under the path "/content."
    file

    To perform a search on paths or fulltext:

    1. In the Security console, select a user or group and then click the Permissions tab.

    2. In the Search box, enter a term to search for.

    Impersonating Users

    You can specify one or more users that are allowed to impersonate the current user. This means they can switch their account settings to those of the current user and act on behalf of this user.

    Use this function with caution as it may allow users to perform actions that their own user cannot. When impersonating a user, users are notified that they are not logged in as themselves.

    There are various scenarios when you may want to use this functionality, including:

    • If you are out of the office, you can let another person impersonate you while you are away. By using this feature, you can make sure that somebody has your access rights and you do not need to modify a user profile or give out your password.

    • You can use it for debugging purposes. For example, to see how the Web site looks for a user with restricted access rights. Also, if a user complains about technical problems, you can impersonate that user to diagnose and fix the problem.

    To impersonate an existing user:

    1. In the tree list, select the name of the person who you want to assign other users to impersonate. Double-click to open.

    2. Click the Impersonators tab.

    3. Click the user you want to be able to impersonate the selected user. Drag the user (who will impersonate) from the list to the Impersonate pane. The name appears in the list.

      file
    4. Click Save.

    Setting User and Group Preferences

    To set user and group preferences, including language, window management, and toolbar preferences:

    1. Select the user or group whose preferences you want to change in the left-hand tree. To select multiple users or groups, Ctrl+click or Shift+click your selections.

    2. Click the Preferences tab.

      file
    3. Make changes, as necessary to the group or user preferences and click Save when finished.

    Setting users or administrators to have the privilege to manage other users

    To set users or administrators to have the privileges to delete/activate/deactivate other users:

    1. Add the user you want to give privileges to manage other users to the administrator group and save your changes.

      file
    2. In the user's Permissions tab, navigate to "/" and in the Replicate column, select the check box to allow replication at "/" and click Save.

      file

      The selected user now has the ability to deactivate, activate, delete, and create users.

    EXTENDING PRIVILEGES ON A PROJECT LEVEL

    If you plan to implement application-specific privileges, the following information describes what you need to know to implement a custom privilege and how to enforce it throughout CQ:

    The hierarchy-modification privilege is covered by a combination of jcr-privileges. The replication privilege is named crx:replicate that is stored/evaluated along with other privileges on the jcr repository. It is, however, not enforced on the jcr level.

    The definition and registration of custom privileges is officially part of the Jackrabbit API as of version 2.4 (see also JCR-2887). Further usage is covered by JCR Access Control Management such as definedby JSR 283 (section 16). In addition, the Jackrabbit API defines a couple of extensions.

    The privilege registration mechanism is reflected in the UI under Repository Configuration

    The registration of new (custom) privileges is itself protected by a built-in privilege that must be granted on the repository level (in JCR: passing 'null' as the 'absPath' parameter in the ac mgt api, see jsr 333 for details). By default, admin and all members of administrators have that privilege granted.

    Note

    While the implementation takes care of validating and evaluating custom privileges, it cannot enforce them unless they are aggregates of built-in privileges.


    Your comments are welcome!
    Did you notice a way we could improve the documentation on this page?
    Please leave your comments below and we will make the appropriate changes.

    COMMENTS

    • By Kristian Wright - 10:10 PM on Mar 04, 2013   Reply
      I don't see any mention here of how to replicate users and permissions from an author instance to a publish instance. I understand that the rep:policy nodes themselves live with the content they apply to, but these permissions don't seem to be passed to the publishers when replicating a package.

      A section explaining the correct way to replicate permissions from an author instance to publish instances would be great.
      • By Scott Brodersen - 2:25 PM on Mar 05, 2013   Reply
        Hi Kristian, thanks for the suggestion. I have logged an issue accordingly.

        scott
        • By Luis Duarte - 6:42 PM on May 14, 2013   Reply
          Hi Scott, has this documentation been published?
          • By Guillaume Carlino - 5:49 AM on May 15, 2013   Reply
            Hi Luis

            This is still on our to-do list.
            In the meantime, I suggest you post your questions to the Adobe CQ forum (http://forums.adobe.com/community/digital_marketing_suite/cq5), in order to reach a broader audience.

            Hope that helps,
            Guillaume
            • By CQ561 - 6:50 PM on Sep 12, 2013   Reply
              Has this been documented anywhere yet? Specially how to deal with Advanced stuff for creating packages to migrate permissions for users and groups.
              • By alvawb - 3:27 PM on Sep 16, 2013   Reply
                We are still incorporating it into the official documentation; however, this may help: http://forums.adobe.com/thread/1162670 Hope that helps.
      • By Chichi - 1:58 AM on Mar 23, 2013   Reply
        I am really mad riright now I have locked my self out of my email account I hope u can fix it I trust u
        • By Chichi - 2:01 AM on Mar 23, 2013   Reply
          Um how do I fix my email to unlock it
          • By aheimoz - 2:53 PM on Mar 23, 2013   Reply
            You will probably have to contact your system administrator (or provider) about the problems with your actual email account.

            If, after regaining access to your email account, you still have a specific issue with AEM that you need help solving, please feel free to contact Customer Support directly or post your question on our CQ dedicated forum at http://forums.adobe.com/community/digital_marketing_suite/cq5.

            Comments you post here are for documentation feedback - any suggestions you provide to improve our documentation are very welcome.

            Hope that helps.
        • By Krish G - 7:29 PM on Apr 10, 2013   Reply
          Is there a way to apply password policies for the authors other than integrating with LDAP? Seems like CQ cares password being not blank if you are using out of the box password policy.
          • By zumbrunn - 10:32 AM on Apr 13, 2013   Reply
            Hi Kris G, in case you do not get a more helpful answer here, you may want to ask on the AEM forum whether somebody else that has already customized this bahavior can help you with this: http://forums.adobe.com/community/digital_marketing_suite/cq5
          • By Anonymous - 5:26 AM on Jun 18, 2013   Reply
            Major usability issue: the 'save' button on user and group detail forms is almost invisible to most users.
            • By Anonymous - 12:02 PM on Jun 21, 2013   Reply
              The 'Save' button is grayed-out for users that do not have authority to make changes to the settings in question. This is on purpose.
            • By Fernando Goncalves - 6:48 PM on Jan 07, 2014   Reply
              Hi

              Can we have more than one email address registered by user?

              Thanks
              Fernando Goncalves

              • By aheimoz - 2:14 PM on Jan 08, 2014   Reply
                This might depend on what exactly you want to achieve - the following might help:
                http://dev.day.com/docs/en/cq/current/administering/identity_management.html

                We'd suggest that you post the details (exactly what you're trying to achieve, what you've done so far) to our AEM forum:
                http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manager.html

                Hope that helps.
              • By Mahen - 3:27 PM on Feb 17, 2014   Reply
                How do we change ACL's based on workflow state please?
                For example, after a content is approved, the author should lose say...edit rights.
                • By Hans - 5:21 AM on Mar 08, 2014   Reply
                  Hi,

                  some few members granted by us for Admin access for particulate group on website. After given access 10k users got deleted from the particulate group on website exclude latest granted users.


                  Please help on this to look for which logs are required for this?... & Which string required look for this?.

                  Thanks and Regards,
                  Hans

                  ADD A COMMENT

                   

                  In order to post a comment, you need to sign-in.

                  Note: Customers with DayCare user accounts need to create a new account for use on day.com.

                  ***