Session destruction relative to loadbalancer setting?

[Russell Beall]

Been a while getting this fixed ,but the department finally rearranged the application pools and got the log to be writable.

Now the native.log clearly indicates that the session is being destroyed because the IP address sometimes appears to be that of the loadbalancer and sometimes appears to be that of the actual client workstation.

This is strange because it should always just appear to be coming from the loadbalancer.  Something in .NET or something else they have installed on the system must be rewriting the X-Forwarded-For header into REMOTE_ADDR.

I tried to get them to fix the filter so that it would always show one or the other IP address, but this hasn't seemed to work, so the only other option is to disable the IP address check that the SP does.

I thought there was an easy config setting to disable that check, but now I can't find it.  Is there such an option?  Is this safe to do, or does that open the door to man-in-the-middle, or some other attack?

Thanks,
Russ.

On Jan 4, 2013, at 12:36 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> On 1/4/13 3:29 PM, "Russell Beall" <beall at usc.edu> wrote:
>> 
>> They sent me the native log for both modes, and surprisingly enough, it
>> looks the same for both cases.  The one thing that stands out is that it
>> appears to be mapping requests to "default" instead of the relevant
>> applicationId.  However, for some reason, the requests are still indeed
>> using the correct settings from the correct ApplicationOverride blocks.
> 
> That's not possible, and there's nothing in the log you posted that I can
> make sense of, it's missing what I would expect to see. That probably
> means it's not logging whatever the error is, which is possible I guess.
> 
>> Below is a copy of the native.log for the Active Cookie mode.  The other
>> mode looks exactly the same except for having more lines with the
>> "mapped" message.  The "mapped" message never includes more than the
>> scheme:host/ even though subpaths are being used in the requests.
> 
> Definitely not possible. If it's not logging the full URL then the web
> server is not processing requests for such a URL, or I should say the SP
> isn't at least. Run it yourself, you'll see it create such entries for
> /Shibboleth.sso/SAML/POST, etc.
> 
> What comes to mind is that the requests are handled by app pools without
> rights to create log entries.
> 
> -- Scott
> 
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net