we have a problem with our sharepoint sites.
the users are able to access the site using their previous passwords and the new (current) password!!!!
from the tests I made, the problem didn't occurs on the same server but on an IIS site which is not a sharepoint site.
and the user cannot access anything else using the old password (RDP to a server failed, UNC accesses failed etc...)
using the basic or windows authentication as the same result.
and the domain where the sharepoint is is standalone, so its not the current user credential used, but really the foreign credentials.
so what could explain this???
and how to solve it?
This KB article was written for Outlook Web Access, but I just tested it, and the concept applies to SharePoint as well, since the issue is due to IIS caching the user's access token for a default of 15 minutes to prevent increased load on both IIS and AD due to excessive authentication requests over to AD.
In my test, I created a new user, gave it access to a site collection, and then logged in with it. I then reset the password in AD and confirmed that I was still able to log in with the old password and not with the new. Once I issued an iisreset (clearing the access token cache), I was only able to log in using the new password. Keep in mind that IIS is not caching the user's actual credentials, just the access token that gets generated from their initial authentication request.
I'll test this.
in our case the problem occurs for more than 15 minutes... we talk about days! (we are able to use a password changed there is 10 days...)
and the problem doesn't impact IIS as a non-sharepoint site do not suffer the issue.
but I'll test the KB. I know we are very late in a lot of patches...
Did you use NTLM or Negotiate(Kerberos) authentication?
Did you use local account or domain account?
Do you have domain controller? If I am right, standalone doesn’t need a domain.
I suggest you clear your IE’s cache, disable automatically logon in IE, and reboot your SharePoint server, then test again.
Rock Wang TechNet Community Support
I'm using the negotiate (kerberos) mode.
domain account for all services
yes, there is a DC
the problem occurs on the server, restarting IE didn't change anything, and we test using 2 different client computers, and with new user account etc... we reproduct the problem all the time.
I have not tested the reboot, because the problem occus on both dev/QA env. but also in our production servers.
rebooting isshould be the latest option, but if the behavior is not solved, we can't reboot the server everytime we change a user password...
There is something to think about - which is why I don't believe it's a SharePoint issue (though you may be finding it only in the SharePoint web application). SharePoint does not actually perform any authentication. SharePoint defers authentication to an authentication provider (be it Active Directory, LiveID, SQL database, etc.)
Once the user has been authenticated, SharePoint will leverage an implementation of authorization to determine which resources the user has access to. The fact that the credentials are being validated, and the user is getting a session, or a cookie, or what have you has to come from something external.
That being said, something like fiddler or a netmon may be useful in tracking this issue down if you're able to look at the authentication packets.
Premier Field Engineer, SharePoint
Note: My posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.
We are using SPF right out of the box, default authentication settings, NTLM and Windows authentication. It is an intranet only so no website extensions, no "extranet" settings.
I am thinking that the Domain Controller may be the issue here. I have found some Knowledge base on this issue:
Patrick S. Murphy