On June 15, 2011 16:41 , "Knox, Thomas" <tk...@umich.edu> wrote: > I can see log entries for /cosign/valid? requests piling up as they get > redirected back to weblogin.umich.edu repeatedly. Eventually their own > browser will detect a redirection loop and stop the madness. They are always > 'coming from' the same IP address at UMHS when this occurs. > > Is there some known issue with UMHS networks or configurations that would > explain this? Is there a recommended setting for CosignCheckIP that I should > be using?
If an organization or ISP uses multiple NAT devices, and which NAT device traffic travels through is determined based on the IP of the destination address, such that all traffic for the cosign-protected web server goes through NAT #1, while all traffic for the central weblogin server goes through NAT #2, and CosignCheckIP is set to either "initial" or "always", then the central weblogin server and cosign-protected web server will never be able to agree on the client's IP address, creating an infinite redirect loop as the cosign protected web server sends the user back to the central weblogin server for reauthentication (because the client's IP address is different from the IP address they last authenticated with), while the central weblogin server redirects the client back to the cosign-protected web server without reauthenticating the user (because the client's IP address and all other session information is OK and no reauthentication is required). This is known as the "multipath NAT" problem. To determine if this is the problem that is affecting you, have the system administrators of the cosign-protected web server check their web server access logs to see what IP address your client/browser is using. Then ask the system administrators of the central weblogin server to do the same thing (and/or have them check in the cosignd log file for the IP address of REGISTER requests). If the two IP addresses are different, your client is being affected by the multipath NAT problem. To fix the problem, contact the persons responsible for the organization's network, and tell them "don't do that!". After this doesn't work :) then contact the system administrators of the cosign-protected web server and ask them to set "CosignCheckIP never" -- basically, they'll be sacrificing some protection in order to compensate for network oddities. If you determine that the IP addresses for your client that the cosign-protected web server and central weblogin servers are the same, then you have a different problem than multipath NAT. The most common problem in this case is that the cosign handler on the cosign-protected web server is not configured or is improperly configured (for example, you don't have "Satisfy Any" set, if this is Apache HTTP Server with mod_cosign). However, if that is the case, then this problem would affect ALL clients, not just one client. Another possible cause of the behavior you are seeing could be if the client/browser is somehow accepting cookies from the central weblogin server but rejecting requests to set cookies from the cosign-protected web server. If you try everything above and the problem still exists, then use the Live HTTP Headers add-on for Mozilla Firefox (or a similar add-on for whatever other browser you choose to use) to capture all of the request and response headers between the browser and all web servers when you try to access the cosign-protected server you're having trouble with. If the full dump does not help you solve the problem, then post the full dump here so we can determine if the problem is with the requests, the post data, the cookies, the URLs, or something else. > This seems like a newish issue - never had any reports of it before, but now > several in the last few weeks. Unless the network administrators made a change to their networking recently, or the administrators of the cosign-protected web server recently set "CosignCheckIP initial" or "CosignCheckIP never", the multipath NAT problem is not a new issue. It was affecting clients behind the UMHS firewalls at the University of Michigan two years ago. I hope this helps. -- Mark Montague m...@catseye.org ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
