OK, more testing ensued tonight... Looping is still going on, cookie not getting stored in /var/cosign/filter which is 755 and owned by apache:apache (I'm running CentOS). I've checked the certs six ways to Sunday and don't see any issues with them, perhaps I'm missing something. I'm going to send a link to a zip of my config to you guys (not the list), would you mind having a look and seeing if I've done something stupid?
Do you have access to the cosign3 server config running at UMich? If so, could you post it or send it so I can use it for reference? Some of the client configs are up at: http://www.itcs.umich.edu/itcsdocs/s4364/ but some server configs would be hugely helpful. Thanks again - I think I'm very close. Josh -----Original Message----- From: Andrew Mortensen [mailto:[email protected]] Sent: Thursday, June 04, 2009 11:18 AM To: Josh Campbell Cc: [email protected]; [email protected] Subject: Re: [Cosign-discuss] Cosign Apache Help On Jun 3, 2009, at 11:56 PM, Josh Campbell wrote: > Gents, > > Thanks for the responses, I've been trying to get a basic directory > block > working but I've been having the same loop errors. I think there's > something going on with cosign and its cookies, it appears that it's > issuing > a cookie but when the client is trying to verify it cosign can't > perform the > validation. > > I have a large number of cookies showing up under /var/lib/cosign/ > daemon > (owned by cosign user with RW permissions) on the CAS server and on > the > client I seem to have nothing showing up under the filter directory > (which > is owned by apache). Why wouldn't Cosign be creating the cookies > locally in > the filter directory? If the cookie isn't getting set in the browser (which I asked you about earlier), that means validation of the cookie at /cosign/valid failed, which can subsequently cause browser looping. It can fail for a number of reasons, but the most common one we saw during our upgrade was of a certificate not allowed to ask cosignd about the particular service name you're using. If this validation fails, mod_cosign will NOT create a locally cached cookie because cosignd refused to give out the information about the user. > There's not much in the Apache logs on the client server Yes, a long-standing shortcoming of mod_cosign. We're hoping to address that in a future release. > but on the CAS > server I see entries like the following - note the time stamps seem > to match > when my browser is looping while trying to authenticate: > > Jun 3 20:18:35 auth04 monster[12928]: read_cookie: > cosign=d6Xv8T5W-s1ONMsfaVpZPvewkncHI5jN5UKLN46jt5uZpJN-8ytvd9es > +z22Ob0Yk5mRk > KdiwvwWi0DCKcPsu4RWgX40Re99VyQPSDuXGNlPUOiI0vMEm-q7PngN: Permission > denied This "permission denied" error suggests that the directory isn't owned by the right user, or has permissions otherwise incorrectly set, but since three hours pass between this error and what appears to be a successful monster pass, it appears you've already addressed this. andrew ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Cosign-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
