Hi,

when  a users tries to change thier password using the mpssamplecp site. he  gets the following error.

An error encountered while processing object 'LDAP://ad07.sawtel.org/CN=test@sawtel.com,OU=sawtel,OU=sawtel,OU=Hosting,DC=sawtel,DC=org'./Access is denied./UserSetPassword

but the administrator can reset it with no problems

Users are never allowed to reset their password this is by design in AD. A user can only change his/her password by specifying their old password. The Method to call is UserChangePassword.

That said are you using the Consolidated Server CP or the MPS Sample Web from the HMC 3.5 release?


regards

yes i am using the Consolidated Server CP

Having the same problem . Our setup is also consolidated hmc . Same error user cannot change password but administrator can do it.

remember that AD won't allow users to change their password more than once in a 24-hour period.  This is because it is tracking password history.  So typically the user password change works the first time, and then fails.

Of course, an administrator can reset the password whenever they want.

Still getting the error looks like its not 24 hours thing

 

""
An error encountered while processing object
'LDAP://ad01.x.com/CN=abcdd@abcdd.com,OU=abcdd,OU=X,OU=Hosting,DC=x,DC=com'./A constraint violation
occurred./UserChangePassword""

Where do I look ??? What do I do ?

Someobody please help with this error , where do I look ?

Exactly the same problem. I try to discuss it in Hosted Exchange forum.

It seems that it is not good practice to make doubles. So I only make link to Hosted Exchange topic.

http://forums.asp.net/1307949/ShowThread.aspx#1307949

 

Thank you,

Ilya

Well the first post points to the core issue.  There is a difference between SET and CHANGE password.

An end user (or "Self" as Active Directory defines) is only able to CHANGE a password.  This requires the current password and a new password.

Administrators (or a person with delegated rights such as the Customer Admins in HMC) are able to SET a password which only requires a new password.

The error you have "UserSetPassword " states that the end user is trying to SET the password.  This is not allowed as the end user (again, "SELF" as AD has it defined by default on a user object) does not have this right.

The SampleWeb client is not a good option for production use with customers in an HMC 3.5 envirionment.  You should either use the Sample Control Panel or the eQuest Automation Framework.

I don't think that's the point, really. The error is specifically the MPSSampleCP, and it's a bug or misfeature in the CP, not user error. When you log on to the CP with an ordinary user account, one that's not been given the "IsAdmin" right, you get a menu item (and only that menu item, actually) to "Change Password". It doesn't work. You get the Access Denied error. Arguing about the correct method to call is moot - tell it to the programmer at Microsoft.

The workaround is to delegate an admin user at the organization, and have that admin log in, and reset the user's password. Or, of course, an AD admin can do it, in the CP or ADU&C.

It is obviously intended that the user be able to change their own password, though, else the menu item would not exist, and for the user to even use the CP, their current password must be supplied during logon.

 

Problem still persists. Its in the MPSSampleCP so something is definately wrong , any heads up from Conrad or anyone else here ?

I did some further investigation - unfortunately, the CP's behavior appears to have changed on me during testing, and now I can't be sure I'm testing accurately. I seem to have fixed the problem, but I don't quite understand why.

I got into the CorePlugins project, and edited ChangePassword.ascx.cs, the code-behind for that page. I noticed this section:

if (Utilities.RemoveDCFromLdap(PreferredDC, CurrentUser.LdapPath) == Utilities.RemoveDCFromLdap(PreferredDC, CurrentContext.LDAPPath)) {

pnlChange.Visible = true;

DefaultControl = txtOld;

}

else {

pnlSet.Visible = true;

DefaultControl = txtCPassword;

}

I figured I'd try hard-coding it, so I commented the whole section and copied the pnlChange version below. This affects Submit_Click, so that changePassword is called rather than setPassword. (After that it gets into the HostedExchange namespace, and from thence I'm sure it's further occluded by an MPF call, and I didn't want to mess around with the guts of the thing this time.)

As expected, when I logged on as a restricted user this time I got all three fields on the Change Password page: Old Password, New Password, Confirm. I successfully changed my password *, but this is when things got weird, unfortunately. I uncommented the code above, changing it back to its original state, but when I tried again as the same user, I now get the 3-field version of the form! For some reason, the logic in that if statement has actually changed after just once invoking the 3-field version of the form, albeit doing so very manually. Now it works for all of my users.

Hope this helps someone. I might have to give up on it, as I can't even duplicate the problem, now.

* - Note: If the user does not have rights to change their own password, you'll get the "Constraint violation occurred" error here. This appears wholly unrelated to the original problem, which is the "Access denied" version of the error, that occurs regardless when the user is presented with the two-field version of the form.

 

Aha! I tried one last test. I paid particular attention to everything I was doing in the interest of accuracy, but someone else will need to verify this independently to prove it.

I copied the original CorePlugins.dll back into bin. Guess what? 2-field version of the form.

Then I wiped and copied the entire CorePlugins project (folder) from its original, and recompiled CorePlugins.dll without making any changes. The size of the DLL changed, and I get the 3-field version of the form.

Hypothesis: CorePlugins.dll as distributed in the HMC 3.5 is the wrong build. The developer(s) made 11th hour changes to CorePlugins.asx.cs but did not include the corresponding CorePlugins.dll in the install-package release.

 

dfrauzel:

Aha! I tried one last test. I paid particular attention to everything I was doing in the interest of accuracy, but someone else will need to verify this independently to prove it.

I copied the original CorePlugins.dll back into bin. Guess what? 2-field version of the form.

Then I wiped and copied the entire CorePlugins project (folder) from its original, and recompiled CorePlugins.dll without making any changes. The size of the DLL changed, and I get the 3-field version of the form.

Hypothesis: CorePlugins.dll as distributed in the HMC 3.5 is the wrong build. The developer(s) made 11th hour changes to CorePlugins.asx.cs but did not include the corresponding CorePlugins.dll in the install-package release.

 

 

did it actually work for you now ? Maybe you can post a copy of your dll and ill try on my end . The password changing system does not work yet on my side. Its weird

Yes, it's working for me. I'll still get that very mysterious "constraint violation" error if a user cannot change their own password.

The forum doesn't allow attachments, so I've zipped it up and put it here:

http://tinyurl.com/rjs8f

That ZIP contains CorePlugins.DLL. Copy it (after making a backup of the original) into this folder:

C:\Program Files\Microsoft Hosting\Provisioning\Samples\MPSSampleCP\bin

(Assuming you haven't moved the CP out of that path, of course.)

You shouldn't need to restart the site or IIS, though any current CP logins will be abandoned.

I must stress that I make no warranty of any kind with this DLL, and you must use at your own risk. It's possible to build it on your own entirely with free tools (SharpDevelop) and a little know-how, so if you have the extra time, I'd recommend it. :)

Interested to hear your results, positive or negative.