Did you enable 3rd party cookies in the IE privacy settings?
The steps you took are the same one I do when I try Cookie Auth.
I can't see your rules, but if you start with one of the canned wizard sets of rules, I just insert them right above the URL filtering, below the Global Blacklist, and it just start working after I configure NTLM and cookies in the browser.
What do you see occuring? Any auth dialogs popping?, and traffic blocked? Is it still filtering URLs and malware at all? (just to make sure we cover all the bases.)
Do you have any other authentication enabled also? This should be the only one it hits while you are testing. Disable the Direct proxy auth if it's there.
Other than that, i can't think of anything.
For ease of browsing the community, in the future could you make the title of the discussion a bit more on topic of the issue? This way if someone has the issue you are having they will see it in the title instead of "ahhhh someone help me".
If this is a persistant issue for you with cookie auth, I'd be happy to take the case if you open one up.
Hi Eric and Jon,
Sorry fro the subject at the time I was extremely frustrated. I have reset the device and used the Try-Auth cerating my own NTLM auth method, that works. I then reset again and tried Austhentication Server (time/IP based Session) agaisnt with my own NTLM method, works fine. Then Tried the Cookie Authentication frmo the library using again my NTLM method and it fails.
All I get is a browser error "Internet Explorer cannot display the webpage" and the conenction diagnotics button. This happens on bith XP and Win 7 desktop with IE 8 on both. I get no authentication popups or other errors. I verified that I am allowing 3rd part cookies, I even changed the browser from accept to prompt so i could see if its presenting a cookie but I get no prompt. When I change back to a working proxy it starts prompting me to accept cookies so I donth think its a browser setup.
Also in the logs there is no block entry just a "302" which i have shown below. I also took a tcpdump which appears to show an NTLM exchange but the last line has a 302 and thats it. I can provide this if you need to see.
[10/Oct/2011:01:23:16 +0000] "" 172.20.5.129 302 "GET http://www.checkpoint.com/ HTTP/1.1" "" "-" "" 3137 "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8)" "" "0"
More info on the subject. I rebuilt my V7 image and imported the same Cookie Auth ruleset but this time didnt use NTLM auth and created a user in the local user DB. It prompted me to login which I did and it worked just fine. User name even shows up in the logs.
Now why would it not work for NTLM auth method? If I use the Try-Auth ruleset with NTLM it works just fine. I dont understand.
Id really appreciate any assistance.
i don't know why you are having problems.
I just loaded a fresh MWG 22.214.171.124, imported the Cookie Auth Rule Set from the library, joined my AD domain, and started surfing.
For machines that are not part of the AD domain, i get prompted.
For machines that are joined to the domain, I do not get prompted but I get authenticated and users are in the logs.
I explicitly proxy to the MWG and am not using WCCP or anything like that, but the results should be the same.
From a default workstation (one that has never been logged on and a default profile got created on first logon), I turned on the 3rd party cookies, and added the ip address of the gateway to the local Intranet zone so it doesn't prompt to logon.
The only functional difference between Cookie Auth and Try-Cookie Auth is that if it fails to authenticate, you get a - or "RestrictedUser" in the logs.
If it's purely Cookie Auth, you get authenticated or you don't get in.
Dont know what to tell you erik. I replicated your process (many times now) made sure tihe IP is listed in Intranet and cookies are accepted etc
I spoke to support last night and we went thorugh some packet captures, initial suspicion is the 3rd redirect is not formatted correctly. It redirects to the original requested domain but appends /mgw-internal............ on the end
A case has been opened with feedback, number of packet captuers I took etc so hopefully something will turn up. Im happy to admit its something im doing wrong (if it turns out that way) but I have been messing around with this for weeks now lost count of howmany different combinations of browser settings, proxy settings etc ive tried and i have finally given up and opened a ticket
OK I got some word from support and looks like the issue is cookie size. We have so many AD groups the cookie size was too big and the browsers just rejected them. I lowered the max cookie size in the proxy and it wrks now but I think this has introduced another problem. I want to restrice these users based on their group members ships but seems this group memebership filtering doesnt work, im guessing becuase of the restricted size of the cookie so its not holding the group info?