AEM users, groups and permissions aem-users-groups-and-permissions
Adobe Experience Manager builds on Adobe IMS users, user groups, and product profiles in order to provide users customizable access to AEM. Learn how to define AEM groups and permissions, that build upon AEM’s provided user groups, and how they work in concert with Adobe IMS abstractions to provide seamless and customizable access to AEM.
AEM Assets permissions and access control assets-permissions-and-access-control
Access to Adobe Experience Manager (AEM) Assets is controlled by two independent layers that must be configured correctly:
- Adobe Admin Console product profiles: grants the technical entitlement to reach an AEM environment, for example, Power User, Collaborator, Limited User, and Administrators.
- AEM-local group membership and ACLs: controls what you can actually do once inside that environment, for example, upload, edit, delete, approve, and configure.
Assigning a product profile in Admin Console is necessary but not sufficient: a user can be a fully licensed Power User in Admin Console and still be blocked from every asset operation if they are not also placed in the correct AEM-local group. Conversely, correct AEM-local group membership has no effect if the user was never granted an Admin Console product profile for the environment.
Permissions required for common operations permissions-required-for-common-operations
Operation
Required permission or group
Notes
Upload an asset to /content/dam
rep:write on the target /content/dam path
Group membership alone does not guarantee that this is inherited at the user level. If uploads fail for specific users while others in the same group succeed, verify rep:write is actually present on the user’s effective ACL and not just assumed from group membership.
Search or view assets in the Digital Asset Management (DAM) UI
Read access to /content/dam (typically through dam-users) and jcr:read on /conf/global/settings/dam/adminui-extension/metadataschema.
The Assets UI resolves the metadata schema definitions from /conf to render results. If a group has full /content/dam access but no read access to the schema configuration path, the UI throws a NullPointerException and search/browse silently fails. This is not a /content/dam permission problem even though it looks like one.
Create or edit a Folder Profile
Membership in the local administrators group.
An Admin Console Administrator assignment is not the same thing, the Create button for folder profiles is only rendered for accounts that are also members of AEM’s local administrators group.
Create or edit a custom metadata schema
Recursive jcr:read on /conf, /conf/global/settings/dam/adminui-extension/metadataschema, and jcr:write on /conf/global/settings/dam/adminui-extension and its metadataschema subnode.
Write access to the metadataschema node alone is not enough; the schema editor also needs to read the parent /conf tree to render correctly.
Edit asset metadata fields (for example, review status on Content Hub-ingested assets)
dam-users group membership.
Applies even to assets ingested through Content Hub. The underlying edit permission is still AEM’s standard DAM group model.
Use Share Link action
jcr:modifyAccessControl on the folder, and the group must not be excluded from Allow only for groups
Configured under Tools > Assets > Assets Configurations > Link Share. This has been observed to differ between environments (for example, it is present in the dev server, but missing in the production server) even with identical code, so you must check both the ACL and this configuration screen per environment.
License and save an Adobe Stock asset
Membership in both the Stock licensing group and the base DAM authoring group (for example, dam-users)
Membership in the Stock group alone is not sufficient for the License & Save workflow to complete.
View Bandwidth and Storage in Dynamic Media Classic
System administrator privileges.
Insufficient privileges surface as Scene7 error #2046 rather than a standard permission-denied message.
API access through a JSON Web Token (JWT) bearer token or technical account
The technical account’s underlying AEM user must be explicitly added to the required AEM group (for example, a view-only group).
Provisioning a product profile or service in the administrator console creates the technical account user. This does not automatically grant it every AEM group needed for complete API responses, for example, full rendition lists. The account’s AEM group membership still needs separate configuration.
Group inheritance and permission evaluation group-inheritance-and-permission-evaluation
- Permissions applied to a parent folder cascade to the child folders and assets by default.
- Explicit deny rules take precedence over allow rules. You can be a member of a group that has allowed access, but if you (directly or through another group) are also subject to a jcr:read (or other) deny rule on that path or an ancestor path, the deny wins — even when both the cases appear to have identical group memberships in the administrator console.
- When two users with seemingly identical permissions behave differently, compare their effective ACLs (Tools > Security > Permissions, or the Repository Browser), not just their group membership lists. You must look specifically for deny rules scoped to one of the groups.
Distinguishing group types distinguishing-group-types
AEM does not visually separate group types in Tools > Security > Groups, which makes large permission audits difficult. Use these rules to classify a group:
- Out-of-the-box (OOTB) groups have fixed, well-known group IDs, for example, administrators, dam-users, and content-authors.
- IMS-synced groups that are created automatically from the administrator console user groups carry a rep:externalId property ending in ;ims.
- Custom groups created directly in AEM have no rep:externalId property.
Adobe’s guidance is to treat OOTB and custom local groups as the primary building blocks for permissions, and treat IMS-synced groups purely as entry points that map administrator console assignments into AEM, not as a place to layer additional ad hoc ACLs.
Content Hub and Brand Portal specific behavior content-hub-brand-portal-specific-behavior
- Content Hub access is not controlled by dedicated Content Hub groups. It is controlled by environment-specific administrator console product profiles, typically named AEM Assets Limited Users - delivery - Program - Environment .
- ContentHub access is granted only through the Limited User product profile. The Power User profile does not grant ContentHub access on its own. Assigning both the Power User and Limited User to the same account does not double-consume licenses.
- Content Hub administrator rights require membership in specific product profiles (AEM Assets Limited Users – delivery and AEM Administrators – production author). The visibility of the Admin tab in the UI is not itself proof of administrator rights.
- Attribute-Based Access Control (ABAC) rules, when enabled, are configured self-service through the AI assistant or governance agent inside Content Hub; there is no separate dedicated ABAC permissions screen. If specific groups cannot see any assets in Content Hub despite correct-looking group or profile assignments, check whether ABAC policies are enabled and whether user attributes or asset metadata satisfy those policies before assuming a group misconfiguration.
- Changes made to users or groups in the administrator console are not reflected in Brand Portal in real time. A background synchronization job runs roughly every 8 hours, so allow 5–10 hours before troubleshooting a changes not appearing report report as a bug.
- A collection marked public in Brand Portal is still inaccessible to the guest users if the underlying Digital Asset Management (DAM) folder is not public and the assets are not published from AEM Assets. Collection-level visibility does not override the folder-level visibility.
- A Closed User Group (CUG) applied to a DAM path can block publisher-side visibility per environment even after a successful replication. A missing cq:lastReplicated property is a useful diagnostic signal that the asset was never actually published (as distinct from being blocked by CUG after publishing).
Troubleshooting permission-denied errors troubleshooting-permission-denied-errors
- Confirm the administrator console product profile assignment for the correct environment (author versus delivery or Content Hub instance are configured separately; the Limited Users profile in particular lives under a separate delivery instance, not the main author instance).
- Confirm the corresponding AEM-local group membership, not just the administrator console profile since both are required.
- Check whether you are logging in with your organization or company Adobe account rather than a personal Adobe ID; access assigned to the organization account does not appear if you are signed in personally. Whitelisting may also be required.
- Inspect the effective ACL on the specific path in the repository browser or Security or Permissions UI for deny rules that override an otherwise-correct group’s allow rule.
- For DAM search or browse failures with what looks like correct /content/dam access, check the read access to /conf/global/settings/dam/adminui-extension/metadataschema specifically. This is a common, non-obvious blocker.
- For folder profile or metadata-schema editing failures, confirm the local administrators group membership (folder profiles) or the full /conf recursive read and write combination. Narrower grants that look right are frequently incomplete.
- Administrator console assignment alone never grants in-application capabilities, always verify the matching AEM-local group or ACL exists.
Additional resources
recommendation-more-help
experience-manager-learn-help-cloud-service