Several customers already reported this problems with managed account passwords after installing the MS16-101 August Security updates for Windows.
This security update disables the ability of the Negotiate process to fall back to NTLM when Kerberos authentication fails for password change operations.
Due to this change it is no longer possible to use the options ‘Set account password to a new value’ or ‘Generate new password’ for a Managed Account in SharePoint if MS16-101 is installed on either the SharePoint server or the Domain Controller contacted by SharePoint.
Changing the password in AD and then updating the password using the ‘Use existing password’ option in SharePoint works fine as this step only validates the password but does not change it in AD.
More information about this issue can be found in Trevor Sewards blog post:
Update 2016-11-18: This problem has been resolved with November 2016 CU for SharePoint 2013 and 2016.
Is there a fix for this issue yet? It very painful to change all of our SharePoint passwords. We invested an enormous amount of time to script password changes across our dozens of farms with 20 plus service accounts now this process has become archaic. Will there be a fix with the the security patches this month?
no fix for this has been released yet. The product group is currently testing a fix for SharePoint 2013 and 2016.
we have the same issue…
please let me know, if there is a fix or something.
a fix for this issue has not yet been released.
We have the same problem, but we have another. We think it caused by that update.
If we update each property for example manager in the AD and we start incremental sync most of the sp users (about 90%) moved to the missing from import users.
Has another customer reported similar problem?
I haven’t heard about such an issue till now. If you need assistance in getting this analyzed I would recommend to open a support ticket with Microsoft.
You can use the workaround described in the section “known issues 6” of this KB article https://support.microsoft.com/en-us/kb/3177108 . Adding registry key NegoAllowNtlmPwdChangeFallback and settting it to 1 on the SharePoint server that hosts the Central Administration or where you are doing PS resolved the issue for me, but it is clearly not recommended. Good luck !
FYI: this problem has been resolved with November 2016 CU for SharePoint 2013 and 2016.
This has also been corrected in MS16-137 when applied to all SP servers and DCs.