User Management
If you are using Confluence or Jira Software and you have users in an external user directory, then when reviewing the run logs for any User Management action you may encounter a failure message.
User Management cannot modify a user in an external directory if it has not been granted read/write permissions. Changes may be required on the directory side (for example Atlassian Crowd or Microsoft Active Directory) or on the application side (Confluence or Jira Software).
If you running User Management inside Bitbucket it is impossible to configure external directories as read/write. This is a limitation with Bitbucket itself.
Step 1 - Update user directory in Atlassian host application to Read/Write
When a external user directory is added to Confluence or Jira Software, it may be set to Read Only or Read/Write. This applies to all directory types except Internal with LDAP authentication. Login via a different user directory (e.g. "local-admin" in the built-in Internal Directory) and edit your external user directory's settings. The "Read/Write" radio button needs to be selected. Changing this setting alone may be enough to resolve errors relating to directory permissions.
Example with an Atlassian Crowd directory
Example with an LDAP directory
Step 2 - Update directory permissions externally
Even if the Atlassian host application is set to Read/Write, it is still possible for the permissions on the external directory to block modifications coming from Confluence or Jira Software. The settings that need to be changed vary depending on the external directory software you are using. The following example applies to Atlassian Crowd.
Be cautious when modifying other types of user directories such as Active Directory backed directories. This is not recommended unless you really know what you are doing and what the impact on other applications using those directories may be.
Updating Atlassian Crowd Permissions
Important: If users in Crowd are coming from Active Directory backed sources configured in "connector" mode (as opposed to Delegated), the LDAP user configured in Crowd must have ability to write back to LDAP.
Note: If you are using Atlassian Crowd there may be other Atlassian applications in the picture so use caution. For example a Scheduled User Action running inside Confluence could be configured to deactivate users after 6 months of inactivity. A user who is inactive in Confluence may be actively using Jira Software but User Management for Confluence will be unaware the user is active in Jira Software and deactivate them in Crowd preventing them from continuing to log in to Jira Software. In this scenario using the Remove application groups would be a good solution to effectively only disable the user in Confluence.