MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

Does Sharepoint 2007 cache user credentials?

  Asked By: Tyrel    Date: Feb 02    Category: MOSS    Views: 5231

We have noticed that after a domain pwd is changed, the user can login
in a site with the old pwd and with new pwd for period of about 2 hrs.
Does sharepoint 2007 cache the user's credentials? Is there a setting to
change this behavior?



20 Answers Found

Answer #1    Answered By: Brianna Olson     Answered On: Feb 02

I suspect it is IE that is caching.

Answer #2    Answered By: Selena Glenn     Answered On: Feb 02

Or even more likely, ISA - which does cache  users credentials  - are you
using ISA and are you by-passing it as a proxy to get to your intranet ?

Answer #3    Answered By: Anila Bhuva     Answered On: Feb 02

We are not using ISA in our deployment. Even IE caching does not seem to
be the culprit.
Other ideas?

Answer #4    Answered By: Alisha Itagi     Answered On: Feb 02

I think by default the cookie will expire after you
close the session or after the cookies session time
out, the setting is in IIS. But if we want to
overwrite the session timeout of IIS we can give the
session time out in web.config which will superceed
the session time out setting of IIS.

Answer #5    Answered By: Faith Delgado     Answered On: Feb 02

Are you using Windows Authentication? If not, the comments below may not

SharePoint does not cache  the user's credentials. The security token
attached to the browser window is cached on the client computer. It
remains unchanged until you close the browser or sign on as a different
user. (In IE7, the credentials  are shared across tabs as well). So, you
don't need to re-authenticate as long as your browser stays open. Active
Directory group membership remains unchanged until you sign off and on
as well.

Changes to the user  in Active Directory take effect as soon as they
propagate to the domain controller that the client PC contacts when you
log in (or change users). There may be some delay in this Active
Directory propagation.

Note that the token attached to the browser window can be different than
the credentials attached to the client desktop, so you could
concurrently have different credentials in the browser than in Office
applications and/or Windows Explorer if you change things in Active
Directory and don't log off and back on to your PC.

Answer #6    Answered By: Kristy Hicks     Answered On: Feb 02

We are using forms authentication based on ldapmembershipprovider with
AD as the source.
We do try to login and log out for every site access.
Still, the caching seems to be happening. The fact that we are able to
authenticate using both the old and new password is pretty confusing.

Answer #7    Answered By: Amanda Brown     Answered On: Feb 02

Forms Based authentication is based on having a valid cookie. If a user
logs in before the password change they will get an authentication cookie.
That is what allows them to access SharePoint. For the lifetime of that
cookie they will be able to access SharePoint without having to
re-authenticate. I suspect the lifetime of your authentication cookie is
set to 2 hours. Changing the password in AD will have no effect on an
Authentication cookie that has already been handed out. Again, closing the
browser should I think delete the cookie and force re-authentication through
AD when you go back to the site.

Answer #8    Answered By: Caleb Gordon     Answered On: Feb 02

So on a side note to this conversation, consider it a forked process or a
branch in the source repository, but with regard to forms based
authentication - if using it to authenticate users that are sitting outside
of the domain that your server farm resides within, are they prompted for
user name and password, or does the cookie that provides for their
authentication do that for them in the background (assuming that the
computer that they are accessing the site from is not a member computer

Answer #9    Answered By: Anuj Lakhe     Answered On: Feb 02

Forms based authentication, even using an LDAP connection to AD, doesn't see
the logged in user  as a member of the domain. When requesting a page it
looks for an authentication cookie. If it doesn't find one it redirects to
the login.aspx page to get one. If it has a valid cookie it doesn't go to
login it goes to the requested page. This is standard ASP.net functionality
and doesn't operate any differently in SharePoint. The Domain membership of
the computer has no effect on the process.

Answer #10    Answered By: Micheal Knight     Answered On: Feb 02

Thanks for the information. In WSS v2/v3 when you've got a domain account,
but accessing from outside the domain, you get prompted for username and
password when attempting to access Word docs, etc. so I was curious if the
behavior was different. Sounds like it is.

Answer #11    Answered By: Aditiya Kapale     Answered On: Feb 02

Still prompted when you open a doc. Pressing NEW is part of Client
Integration and normally turned off when using FBA because it won't work
without a Windows Identity in SharePoint. It will treat you as though you
were always outside the domain.

Answer #12    Answered By: Cristopher Gould     Answered On: Feb 02

The issue could be IIS caching tokens...

Will let you know if this is the issue.

Answer #13    Answered By: Selena Glenn     Answered On: Feb 02
Answer #14    Answered By: Jonathon Palmer     Answered On: Feb 02

I don't think this is the problem. This is strictly in reference to forms
of Windows Authentication. The original question was about Forms Based
Authentication using Access. IIS does not cache  a Windows user  Token for
FBA users even if the backend is LDAP access to AD.

Answer #15    Answered By: Vinay Thakur     Answered On: Feb 02

Also, I tested the credentails with different browsers, different client
machines, after deleting cookies .. I get the same result.

Also, domain membership of the client computer has no effect, if cookie
is not found, it always displays the login page.

One more interesting find is, another applicaiton which is based on
weblogic is also showing a similar behavior. It lets users login with
old pwds.
So, I am looking at the AD settings.. AD policies, AD sync latency etc.

More ideas ?

Answer #16    Answered By: Akshay Gupta     Answered On: Feb 02

Okay, so to clarify, with FBA (sorry for beating the dead horse), but if I'm
using FBA and there's a cookie, I will not get prompted when opening /
modifying documents?

Answer #17    Answered By: Trinity Scott     Answered On: Feb 02

If cookies aren't involved, you might want to look at session state
timeouts. Some of it is configurable in SharePoint at CA > Application
Management > (Office SharePoint Server Shared Services section) >
Configure session state.

Answer #18    Answered By: Constance Guerrero     Answered On: Feb 02

Solved at last :-)

This behavior is due to an AD setting. It started with win 2003 SP1.
Refer to http://support.microsoft.com/?id=906305

Answer #19    Answered By: Chandrabhan Konwar     Answered On: Feb 02

Only one problem. If you are using Forms based authentication via LDAP you
aren't using NTLM authentication. You are authenticating against AD as
though it were a database. Did this actually solve the issue?

Answer #20    Answered By: Tina Owens     Answered On: Feb 02

Yup. This configuration solved the issue.
Except for kerberos auth, all other forms of AD auth were showing this
behavior... I dont have an explanation why...

Didn't find what you were looking for? Find more on Does Sharepoint 2007 cache user credentials? Or get search suggestion and latest updates.