In my event log I see ASP.Net 1315 logged many times. It mentions "Forms authentication failed for the request Reason: The ticket supplied was invalid" I don't understand this message. Can somebody tell me what this means? I have searched but did not find an answer.

Event Type: Information
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1315
Date:  9-12-2005
Time:  21:57:13
User:  N/A
Computer: SERVER
Description:
Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid.
Event time: 12/9/2005 9:57:13 PM
Event time (UTC): 12/9/2005 8:57:13 PM
Event ID: 5b36362fed1d4ccd8a09a8ae93b35dc2
Event sequence: 168
Event occurrence: 12
Event detail code: 50201
 
Application information:
    Application domain: /LM/W3SVC/178108102/Root-1-1277863 
    Trust level: Full
    Application Virtual Path: /
    Application Path: D:\Dotnetnuke\
    Machine name: SERVER
 
Process information:
    Process ID: 2116
    Process name: w3wp.exe
    Account name: NT AUTHORITY\NETWORK SERVICE
 
Request information:
    Request URL: http://www.smallbizserver.net/Default.aspx?PageContentID=444&tabid=236
    Request path: /Default.aspx
    User host address: 141.151.236.225
    User: 
    Is authenticated: False
    Authentication Type: 
    Thread account name: NT AUTHORITY\NETWORK SERVICE
 
Name to authenticate: 
 
Custom event details:

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I wish you had some feedback on this. My application log is flooded with them.

I had to reinstall Windows 2003 on my server. When I got my website back up, the flood gates opened!

I create an encrypted AuthTicket and save it to the User's cookies. Every time they request a page, the ticket is decrypted to get their credentials.

The best I can figure is that all my user's tickets are invalid now. When they try to log in, some of the users are getting duplicate Cookies. It seems that if the cookie is determinded to be invalid, it will not get added to the Reques.Cookies collection. This it hard to expire them- because you can't detect if they exist. I'm not sure if you can get it from ServerVariables["HTTP_COOKIE"].

I found a work around for my situation:

void Application_AuthenticateRequest(Object sender, EventArgs e)
{
    // Extract the forms authentication cookie
    string cookieName = FormsAuthentication.FormsCookieName;
    HttpCookie authCookie = Context.Request.Cookies[cookieName];

    if (authCookie == null)
    {
        //if they can't authenticate, they should't
        //have an AuthCookie. This should stop Duplicate tickets
        Context.Response.Cookies["AuthCookie"].Expires
            = DateTime.Now.AddYears(-30);
        return;
    }

    //Try to decrypt the cookie
    FormsAuthenticationTicket authTicket = null;
    try { authTicket = FormsAuthentication.Decrypt(authCookie.Value); }
    catch { authTicket = null; }

    //the cookie failed to decrypt.
    if (authTicket == null) return;

    string[] Roles = authTicket.UserData.Split(',');

    FormsIdentity id = new FormsIdentity(authTicket);
    GenericPrincipal principal = new GenericPrincipal(id, Roles);
    Context.User = principal;
}

Maybe this will help someone else. Cheers! -Will

Are you using either multiple .NET 1.1 / 2.0 applications or a webfarm/cluster?

Does anyone have a fix for this problem?  I am experiencing the same message whenever a user comes back to my site after a ~30 minute delay. Instead of having the cookie remember who they are, they get sent to the login page and I see this event message in Event Viewer.

I am not using a cluster or webfarm, just a single server running IIS5 on XP Pro x64.

I just installed 4.0.3 and this still happens.

Mike_Zandvliet_:

Does anyone have a fix for this problem?  I am experiencing the same message whenever a user comes back to my site after a ~30 minute delay. Instead of having the cookie remember who they are, they get sent to the login page and I see this event message in Event Viewer.

I am not using a cluster or webfarm, just a single server running IIS5 on XP Pro x64.

By the way, I am not using DotNetNuke - and still don't have a resolution for this. I have narrowed down the timeout to be 20 minutes. I have inspected my web.config and increased all timeout values to 240 minutes, but no change in behaviour. The core of the problem here is that ASP.NET does not like the cookies that it created when it comes time to verify them.

From my observations so far, it's possible that I am seeing this behaviour more often when the users browser is Firefox, as opposed to IE - but that's just a suspicion at this point.

If anyone gets a fix for this, please speak up.   :)

Mike

I believe this error is related to the encryption and/or timeout of the session cookie, although the fact that Mike altered all of his timeouts and is still seeing it is strange. I don't have a resolution for this, but I'll share our findings so far.

We experienced the error very frequently across our web farm, and narrowed it down to a couple of things. Firstly, we were running an ASP.NET 1.1 application on 'www.domain.com', with an ASP.NET 2.0 application running underneath at 'www.domain.com/application2/'.

The initial problem that we ran into was the user visiting 'www.domain.com' would have an ASP.NET_SessionId cookie value set and encrypted in 3DES. Should that user then visit the .NET 2 app, it would by default try and set the same ASP.NET_SessionId cookie value, but this time encrypting it using AES. The long and the short of this error, whilst it doesn't seem explicitly relevant here, is that you have to manually step down the encryption in the .NET 2 web.config. There's a full explanation here:

http://weblogs.asp.net/scottgu/archive/2005/12/10/432851.aspx

If it's not imperative that the session is shared between both apps, it's possible to rename the session ID value in web.config.

The second problem that we came across was, once again, with the encryption. This time, however, it related to running the web app in a cluster. Something we hadn't come across before switching to a full SSL site (due to hardware load balancing) was that we needed to explicitly set a machine key to be the same across all the nodes of the cluster. This is almost exactly the same mechanism as to share between applications described above.

Taking these two steps almost wholly eradicated the 'invalid' error from the health monitoring for us, although we are still left with a raft of incorrectly/non-gracefully handled 'expired' errors which are almost identical.

This may or may not be of use to you guys in chasing down your problems.

I have read the blog but it does not fix my problem. It had the “decryption” attribute set to 3DES already. I guess the only to get this fixed is to use only .Net 2.0 apps.

Mariette,

Do you have both 1.1/2.0 apps running on the server then? Could you explain the architecture of the applications on the web server?

There is one site on IIS that runs DNN. On that DNN instance I have several modules running. I know the majority is written for DNN 3.x. Only one is specifically made for DNN 4.x. Does this answer your question?

Hi Mariette,

Sorry, another question has sprung to mind - do you know if you're using any encrypted domain cookies (not session cookies) that, say, support returning user logins or personalisation?

I'm not quite sure why this should happen - I'm beginning to think that it sounds like there were 1.1 encrypted cookies set with DNN3x (is this assumption wrong?) which are now being parsed by the DNN4x app. Theoretically, setting the decryption to 3DES should have fixed it.

You could try looking at what cookies your site sets, what the expiries are, and whether the site works if you delete all your domain, session and path cookies.

If it was a problem with legacy cookies, deleting all existing ones should clear the problem (if indeed you're seeing one yourself). You may then be able to remedy this by writing code specifically to overwrite the offending encrypted cookie value so that it decrypts correctly in future.

If it's not a legacy issue, this gets even more involved, as it's possible your one app is not encrypting and decrypting correctly.

I am having this problem on a Windows 2003 Server. I have two ASP.NET 2.0 sites using forms authentication. I also have some ASP.NET 1.1 pages but they do not use forms authentication so I don't think they are doing anything to the cookies.

I have set the cookie timeout to 365 days but it seems to timeout after about 20 minutes and I get "The ticket supplied was invalid" in the application log. It doesn't seem to matter if I am accessing the 1.1 pages. I do have session timeout set to 20 minutes.

Ok, I guess the cause of my problem was just not definining the machineKey in my machine.config file. Everytime my worker process would recycle the authentication cookie would become invalid. I assume ASP.NET was generating new keys? I entered both validation and decryption keys into my machine.config file and I think the problem is solved.

Jeremy - it sounds like you and I are having the same problem.  I think that after 20 minutes ASP.NET is trying to verify the cookie, but cannot decrypt it for some reason. For me I do not have any ASP 1.1 sites on my DEV server. Also, I only have 3 test users that access the site - and the behaviour is consistent - after 20 minutes the error occurs and the users get prompted to login.

I did just notice that this behaviour in occuring only on my DEV server, but not on my PRD server. Weird!

DEV - Windows XP Pro x64 with SP2, running IIS5.1, ASP.NET 2.0, SQL 2005, everything fully patched

PRD - Windows 2003 Server 32 bit, running IIS6, ASP.NET 1.1 and 2.0, SQL 2005, everything fully patched

As you and others are experiencing the problem on Windows 2003, we can assume it's not a difference between IIS5.1 and IIS6. As I am not experiencing the problem on my PRD server, I don't think that it's because of ASP.NET 1.1.

My only lead at this point is that the idea that the perhaps the cookie encryption is different from the decryption.

Also noticed that I seem to have 2 cookies when I visit my site. One is called ITM_AUTH_COOKIE, and it's the one that I create and set the cookie timeout of 14 days on. The other is called ASP_NET.Session_ID, and I don't know how it gets created. It's timeout is set to the end of the session. Perhaps that is a clue?

Cheers,
Mike

I rebooted the server this morning and now I get the following error in the DNN event log:

AssemblyVersion: 04.00.03
Method: System.Web.Configuration.MachineKeySection.GetDecodedData
FileName:
FileLineNumber: 0
FileColumnNumber: 0
PortalID: 0
PortalName: Smallbizserver.Net
UserID: -1
UserName:
ActiveTabID: 53
ActiveTabName: Forum
AbsoluteURL: /Default.aspx
AbsoluteURLReferrer: http://www.smallbizserver.net/Default.aspx?tabid=53&forumid=26&postid=1619&view=topic
ExceptionGUID: 18473ee5-73b4-46a9-bdb6-68a21ffecb24
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
InnerException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
Message: DotNetNuke.Services.Exceptions.PageLoadException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. ---> System.Web.HttpException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. ---> System.Web.UI.ViewStateException: Invalid viewstate. Client IP: 202.173.141.226 Port: 3714 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 ViewState: 8QH/M28X3GTlQ0CCHoopO4esbVf95UAlHJVJKKCeOc7VSXouzQHDHVgnHdmaKp+ptdp8QWu4qUZVuBW/MYO663RXs/1ZmVnlIm76OtUrxA93nzE6oQVgfApMwqQZzgFcCEDgicDGbXQY4RjurH1sLY4VRwz1jAXxfa+MPkcA5VblwNCf6huzb0NmN007usEJp4mILvYSvS15Da3W66hCNOguwzvWhPDIn5jHOS1bHxS/MmQlla1NTyH8bZX8YJqNynFTsN/T3DxMkLPaiZkse3JCiylhLpld7J7x1Arwh3ebf9MDsGhuF+w9J9oa/HDMcvklObjisIYJsh+1jv+qZHnQ6sr1YVmg/7QbXZjh6wj5SiNNTn24ZFzahV+Khu68PO+JvxyiKYlX6kCmCcn7B26TfXREeDWJrhyjqAq6MxH9+FczSqrT3vfelJRs+4ORtfzNVa3DsuPdXYAaf+Invq2et+XXBKo51z/KKkLQuC4nHl1sl6P3TFmBYCuGBa4qgdA8Mq0x0nz/BiCYC8KrX5d3CMTRWeUxeSXdQm8snq6oTKRh/1BhaKq5ylGhfU3nMHE4PyG1F30h1UlJNc23qAqyoD03K6RDzASxgcU86Tka9FLOgOAjEzohYzDozQy1yFtzZu3s/njIpQAyesyd8LhlvaaOzR+WzI4/oNb3A5eEZbM7QRhtrO3//XrrBpnOODbmCGeqJRqOfmlAWHGuSicaby24FLSSWRY/PPgPFt8DgCGGEE0j3JWf5/1dlKn75tOtjCu4jNr7+Tk55vPC3o7kix1TirAo/tFG61QcNtmOiV1bKlFighXrPOs9xLK9JMR/I3TBHgmV7IXcuck04X5kJ+BD... ---> System.Web.HttpException: Unable to validate data. at System.Web.Configuration.MachineKeySection.GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength) at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) --- End of inner exception stack trace --- --- End of inner exception stack trace --- at System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState) at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState) at System.Web.UI.HiddenFieldPageStatePersister.Load() at System.Web.UI.Page.LoadPageStateFromPersistenceMedium() at System.Web.UI.Page.LoadAllState() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) --- End of inner exception stack trace ---
StackTrace:
Source:
Server Name: SERVER

I don't know if this is related to the other issue...