1

I want to enable users to reset their AD passwords on our Windows Server 2012 through our Jira server. In order to make this happen, I added an AD user group with delegated control from the top-level OU for the following permissions:

  • change password
  • reset password
  • read userAccountControl
  • write userAccountControl
  • read pwdLastSet
  • write pwdLastSet

I added the AD account used by Jira to this group and enabled LDAP over SSL. The Jira AD connection seems to work fine this way. Unfortunately, when I try to change a user password, AD returns an error code 50 with problem 4003, indicating insufficient rights.

When I inspect the advanced security settings of the Jira AD user, the delegated permissions from the user group seem to be correctly inherited. As far as I understand this should be sufficient. However, I only can get it to work by adding the Jira AD user to the Built-in Administrators group.

I was under the impression that delegating control like I did would prevent me from needing to add the user to the Administrators group. Is that right or does the user have to be an administrator in order to be able to change passwords. If that is not necessary, any ideas on how to make the delegation work?

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
mojoritty
  • 21
  • 3
  • What error occurs when using AD Users and Computers? – Greg Askew Nov 04 '19 at 11:54
  • There is no error. Users can log in normally without any error codes. I only get the error 50 problem 4003 code when trying to change the password of a user through the Jira user. – mojoritty Nov 04 '19 at 13:48
  • To clarify, what is the error when using an account with these delegated permissions to reset a password. – Greg Askew Nov 04 '19 at 14:12
  • Ah, sorry, misunderstood. This is the error received: "The password could not be changed by the credentials provider. org.springframework.ldap.NoPermissionException: [LDAP: error code 50 - 00000005: SecErr: DSID-031A1256, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 ]; nested exception is javax.naming.NoPermissionException: [LDAP: error code 50 - 00000005: SecErr: DSID-031A1256, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 ]; remaining name 'cn=myusername,cn=users,dc=internal,dc=domain,dc=com'" – mojoritty Nov 04 '19 at 14:28
  • That is not an AD Users and Computers error message. Also, what security principal did you delegate permissions to? – Greg Askew Nov 04 '19 at 14:34
  • I created a security group called Password Admins to which I delegated the permissions. The Jira user is a member of this group. Unfortunately, I can't generate the error from within Windows, I only get it from Jira. When I use the Jira user to log into Windows 2012 and try to go to Users and Computers to change a user's password, I have to provide Admin credentials to open the window. When I enter the Administrator credentials, I can reset passwords just fine. – mojoritty Nov 04 '19 at 15:23
  • 1
    This will likely fail if you're attempting to reset a password of an administrative account -- one that has an attribute of adminCount with a value of 1. You can't directly delegate this permission on highly-priviledged accounts; you would have to modify the AdminSDHolder object (which you probably should not do, anyway -- or at least, not for this purpose). – Semicolon Nov 04 '19 at 15:53
  • `Unfortunately, I can't generate the error from within Windows, I only get it from Jira.`. Sounds like the delegated permissions are working. Perhaps the LDAP code is executing under a different account. – Greg Askew Nov 04 '19 at 16:14
  • @Semicolon it might be something like this. It seems the issue occurs with my own account, which I was using for testing purposes (and has an adminCount of 1). Other accounts don't seem to encounter the issue. Strangely enough, when I try creating a new account that has the same memberships as I do, it seems to work fine. At least this seems to be a path to a solution. – mojoritty Nov 04 '19 at 16:43
  • @mojoritty, if your account is not highly priviledged it could be that it was at one point (hence adminCount=1) - this value gets set automatically by SDProp, but it does not get UNset. If it is highly priviledged, it could be that the SDProp process had not run since you created the user - so the adminCount would still be null. – Semicolon Nov 04 '19 at 16:54
  • That would be the expected behavior. Accounts with adminCount=1 have inherited permissions removed. No issue here. – Greg Askew Nov 08 '19 at 13:10

0 Answers0