Details
-
Bug
-
Resolution: Fixed
-
High
-
3.4.9
-
Linux
Description
We have a new instance, with data restored from a Confluence 2.10 instance. We integrated Crowd authenticated based on AD user groups.
We have an AD group called crowd-confluence-administrators (so named to differentiate it in Confluence from the restored legacy confluence-administrators group), which I can see in Crowd and in Confluence. In confluence this is the only group in Global permissions with System Admin and Confluence Admin rights.
We have logging into Confluence working for our users with their AD password, so I know we have at least some part of the Crowd authentication right.
When those users in the crowd-confluence-administrators group click on Browse, Confluence Admin, they are prompted for a password again. I see this as an extra security measure, and I'm not logging that as a problem.
What happens at this stage however is that their AD password is not accepted. They must enter their old Confluence user password to get admin access. When their AD password changes, the password they use to get admin rights does not - it's just not looking to Crowd/AD for the password at that point. Why not? Is this a bug or a config issue?
Attachments
Issue Links
- relates to
-
CONFSERVER-20958 Confluence features that require password confirmation (websudo, captcha) do not work with custom authentication
-
- Closed
-
-
CONFSERVER-22421 websudo does not work with Confluence when it's integrated with Crowd SSO
-
- Closed
-
-
CONFSERVER-22875 Support web sudo and other password confirmation features with custom authenticators
- Closed