none
UserPrincipal.ChangePassword stops working after windows updates 3177108 and 3167679 (2) RRS feed

  • Question

  • I'm having the same problem as in this post:

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/77dc733e-a13d-4349-9088-8065b85d5c3f/userprincipalchangepassword-stops-working-after-windows-updates-3177108-and-3167679?forum=netfxbcl

    but the accepted solution is not working for me. 

    The gist is using user.ChangePassword in the using System.DirectoryServices.AccountManagement namespace. 

    I'm sure it must be related to the updates referred to in the other article, but apparently, it is possible to fix. 

    I have verified the upn of my principal user, but still no luck. 

    My code: 

    using (var context = GetPrincipalContext())
    {
      string sUserName = GetUserName();
      string oldPassword = GetPassword();
      string newPassword = GetNewPassword();
      using (var user = UserPrincipal.FindByIdentity(context, IdentityType.UserPrincipalName, sUserName))
      {
        try
          {
            user.ChangePassword(oldPassword, newPassword);
            Console.WriteLine("Password Changed");
          }
          catch (Exception e)
          {
            Console.WriteLine("Change password failed:        {0}", e.Message);
          }
        }
      }
    }
    
    //My GetPrincipalContext Method returns oPrincipalContext: 
    
    oPrincipalContext = new PrincipalContext(
              ContextType.Domain,
              (ADLocations[ADLocation]).Domain,
              (ADLocations[ADLocation]).OU,
              ContextOptions.Negotiate,
              (ADLocations[ADLocation]).ServiceUser,
              (ADLocations[ADLocation]).ServicePassword);

    Does anyone have an suggestions? 




    • Edited by jp.tahoe Wednesday, August 24, 2016 12:59 AM typo
    Wednesday, August 24, 2016 12:56 AM

Answers

  • Hi jp.tahoe,

    According to your description, it seems that you use the solution which pass user principal name instead of SAM account name, could you please provide the detail error message?

    In addition, if you remove the windows updates 3177108 and 3167679, does it work?

    Best regards,

    Cole Wu


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    • Marked as answer by jp.tahoe Wednesday, August 31, 2016 1:52 AM
    Wednesday, August 24, 2016 7:48 AM
    Moderator

All replies

  • Hi jp.tahoe,

    According to your description, it seems that you use the solution which pass user principal name instead of SAM account name, could you please provide the detail error message?

    In addition, if you remove the windows updates 3177108 and 3167679, does it work?

    Best regards,

    Cole Wu


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    • Marked as answer by jp.tahoe Wednesday, August 31, 2016 1:52 AM
    Wednesday, August 24, 2016 7:48 AM
    Moderator
  • I can also confirm that this issue only occurs after the installation of update KB3167679. We have a web-based product that allows users to change their password. This has stopped working since the installation of update 3167679.

    The current version of this product is based on .NET and uses the 'ChangePassword' method on the 'System.DirectoryServices.AccountManagement.UserPrincipal' class. Calling this method now raises a 'PrincipalOperationException' with the message below.

    The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you. (Exception from HRESULT: 0x800704F1).

    A previous version of the product performs the same operation using the ADSI COM interface (IADsUser::ChangePassword). This also fails with the same HRESULT.

    I have tried to bind to the identity using a UPN but this makes no difference.

    Yet again, Windows update has unexpectedly broken something...

    Wednesday, August 24, 2016 12:45 PM
  • cole wu, 

    The error message is: 

    "The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you. (Exception from HRESULT: 0x800704F1)"

    Yes, uninstalling KB3167679 allows ChangePassword to work again. KB3177108 was not installed on the machine running this code. 



    • Edited by jp.tahoe Wednesday, August 24, 2016 5:37 PM
    Wednesday, August 24, 2016 5:17 PM
  • Hi jp.tahoe,

    Please configure the network firewall so that TCP port 88 and UDP port 88 are not blocked for either domain. For more information, please refer to:

    https://support.microsoft.com/en-sg/kb/938457

    In addition, If the issue is still exist, please remove KB3167679. you could also post a feedback on the following link.

    https://connect.microsoft.com/VisualStudio/Feedback 

    Best regards,

    Cole Wu


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, August 26, 2016 6:16 AM
    Moderator
  • Hi cole wu, 

    Yes, both ports are open: 

    PORT      STATE SERVICE            VERSION

    88/tcp    open          kerberos-sec       Windows 2003 Kerberos (server time: 2016-08-26 18:34:35Z)

    88/udp    open          kerberos-sec       Windows 2003 Kerberos (server time: 2016-08-26 18:34:33Z)

    Also, KB3167679 is not installed. 

    I'll post feedback on the Visual Studio link

    Thanks

    Friday, August 26, 2016 7:18 PM
  • I am in the same boat as jp.tahoe and hhh575 when trying to change passwords after KB3167679:

    The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you. (Exception from HRESULT: 0x800704F1)

    The changes recommended in the related thread also does not resolve the issue.  I have also tried invoking ChangeUserPassword in netapi32.dll but get 0x000004F1 (ERROR_DOWNGRADE_DETECTED).

    I will add that (in my situation) the computer running the code is joined to a different domain than that which the user/password I'm trying to change belongs. Here is the code I am using which errors on the call to ChangePassword:

    var pc = new PrincipalContext(ContextType.Domain, "domain", "user@domain", "currentpassword");
    var up = UserPrincipal.FindByIdentity(pc, "user@domain");
    up.ChangePassword("currentpassword", "newpassword");
    up.Save();

    I continue to search for a solution other than removing 3167679.

    • Edited by btimd Monday, August 29, 2016 5:43 PM
    Monday, August 29, 2016 5:42 PM
  • I am in the same boat here.

    If you've managed to find a work around please let me know ASAP.


    Thanks!


    Tyler

    Tuesday, August 30, 2016 8:45 PM
  • I have resolved the issue for now for my specific situation. 

    I had KB3167679 removed from the application server with the application that uses the SDS.AccountManagement .NET framework library. 

    I have a console application that I use to connect to various Active Directories and test out code written using these SDS libraries. So removing that first KB allowed the change password to work again, at least from this console app. I thought the issue was over, but when testing out the actual application, the change password workflow gave a new error: 

    "The system cannot contact a domain controller to service the authentication request. Please try again later. (Exception from HRESULT: 0x800704F1"

    After removing the second patch,KB3177108, the code run from within the application is now working again. 

    The patches were uninstalled, then after re-downloading the updates list, the patches were identified and set to be hidden from future updates. 

    Wednesday, August 31, 2016 1:51 AM
  • BTW, the only reason I am using ChangePassword from System.DirectoryServices.AccountManagement was that it was the only .NET framework based lib that will actually change the password of a user AFTER it has expired. 

    Most of the custom stuff was using the older System.DirectoryServices library, but the ChangePassword in that library won't work when the user's password expires. 

    We are using a delegated user over the application's OUs (this delegated user is NOT in domain admin group.) 

    I never figured out why that was the case (i.e. ChangePassword in the older library will not work if the user pass is expired, but it will in the newer.) 

    Wednesday, August 31, 2016 1:57 AM
  • Unfortunately I cannot remove those patches as they are not administered by me. I have confirmed though on a machine without the KB3167679 patch my application does work and does reset the password.

    I will continue to search for a way to allow the users to change there own password.


    Tyler

    Wednesday, August 31, 2016 9:00 PM
  • JEEZ, I don't know what the heck is going on. Yesterday, I removed those patches, tested the application, and I was successful. Today, I test again, and everytime I use change password I get: 

    The password does not meet the password policy requirements. Check the minimum password l
    ength, password complexity and password history requirements. (Exception from HRESULT: 0x800708C5)

    I know the policy: 

    MinPasswordLength 8
    MaxPwdAge -90.00:00:00
    MinPwdAge 00:00:00
    PwdHistoryLength 24
    LockoutThrehold 5
    LockoutDuration (minutes) -00:30:00
    LockoutObservationWindow (minutes) -00:30:00

    and I know I've never used this password before: 

    9UlIR7d4Exxo1#

    I am just completely baffled at this point!

    Thursday, September 1, 2016 12:20 AM
  • Hi jp:

    In addition to removing those updates, can you make sure you have one of these updates installed (depending on your operating system):

    https://support.microsoft.com/en-us/kb/3139921
    for 2012R2
    or
    https://support.microsoft.com/en-us/kb/3140410
    for 2008R2

    In my experience with the error that you're receiving it's possible the password is getting changed but there is another underlying problem.

    Thursday, September 1, 2016 8:16 PM
  • Jigme2, 

    Thanks for responding. Yes, 3139921 was/is installed on all machines for this issue. 

    I made a mistake in my previous post: 

    1) I missed removing KB3167679 from another server; there were multiple machines running different instances of the application. 

    2) The System.DirectoryServices lib I used to query stuff about active directory was not giving me the full picture about the security policy. The security policy details in my previous post is for some reason not attached to the OU correctly, so, the  security policy actually being used was defaulting to the domain security policy which has a MinPwdAge of 1 day.  Everytime I was trying to test the change password used in the application, I was using the same user account and so was failing the MinPwdAge.

    Today, I found two users with an expired password, and had them use the app, and it was successful in changing password.

    One other thing for anyone else, using SamAccountName below definitely lead to failure, even though that property is populated in the corresponding AD user profile. Switching to "UserPrincipleName" worked. 

     UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, sUserName))

    Also, not specifying the identity type appears to be working (I understand that not specifying IdentityType will enumerate and check different attributes.) Although, I notice that if you do not specify the @domain when adding a user using System.DirectoryService, @domain will not be stored ( vs adding a user on a Windows AD GUI, will append it on the UPN even if you don't specify it) In my case, the FindByIdentity does not specify the domain in the username. 

    var up = UserPrincipal.FindByIdentity(pc, "user@domain");

    Thanks...I think I'm good for now (fingers crossed)

    Friday, September 2, 2016 12:51 AM