Hello Jarod (and anyone who might be able to help),
In all honesty, I don't know how it behaves yet - I have trouble getting
the module working at all (that's why I'm looking for the 20-step
walkthrough by Shannon Johnson).
I configure the module (assuming that the <crypto/> element sets the
common name of the certificate to be used by the module to connect to
the cosign server) with protected status off (for the whole server), but
as soon as I use appcmd to install the module, any attempt to connect to
sites hosted on the server invariably ends with a 503 and the relevant
application pool stopping. This happens for every site on the server,
despite the fact that cosignProtected is set to "off" in
applicationHost.config. The event log contains only the following error:
Application pool 'Cosign' is being automatically disabled due to a
series of failures in the process(es) serving that application pool.
This error is preceded by several instances of the following warning:
A listener channel for protocol 'Http' in worker process '2544' serving
application pool 'Cosign' reported a listener channel failure. The data
field contains the error number.
The error number in question is 90040780 and my searches for relevant
information regarding this have turned up empty.
At first I thought the reason for my troubles was the absence of Visual
C++ 2008 redist (which Shannon Johnson mentioned "just by the way" in
the afforementioned message from Nov 08), but installing it didn't
change the situation at all. Is the redistributable still required? If
so, it should probably be mentioned in the README file that comes with
the module.
Then I suspected the certificates to be at fault, but running wireshark
on our cosign server and listening for communication from the IIS server
turned up zero traffic - which to me indicates the module crashes before
even getting around to initiating a connection. Any ideas as to what
could the case for this behavior?
Thanks,
Peter
On Thu, 2010-06-03 at 11:57 -0400, Jarod Malestein wrote:
>
> Hello, Peter,
>
> On Jun 3, 2010, at 4:57 AM, Kopáč Peter wrote:
>
> > Hi all,
> >
> > Apologies for the previous message, I mis-clicked the "send" button
> before finishing completely - here's my point #2 in its entirety:
>
> >
> > 2) This one will need a little context, so I better explain our
> > architecture:
> >
> >
> > We don't have a single central weblogin server, instead we have one
> > machine (login.uniba.sk) running the web-front, while another
> > (cosign.uniba.sk) runs the cosign daemons. Hence, our Apache module
> > cosign.conf on a protected service looks like this:
> >
> > ...
> > CosignHostname cosign.uniba.sk
> > CosignRedirect https://login.uniba.sk/
> > ...
> >
> >
> > Looking at Cosign_Schema.xml, I got the impression that the IIS7
> module
> > might not support this. More specifically the following section
> seems to
> > indicate that the web-front and the daemon need to be on the same
> > server:
> >
> > <element name="webloginServer">
> > <attribute name="name" type="string"/>
> > <attribute name="loginUrl" type="string"/>
> > <attribute name="port" type="int" defaultValue="6663"/>
> > <attribute name="postErrorRedirectUrl" type="string"/>
> > </element>
> >
> > Am I correct in assuming that the module will redirect a user's
> browser
> > to <loginUrl> and attempt to validate a user's session by consulting
> the
> > daemon it expects to find at <name>:<port>? Will it behave as
> expected
> > with the following settings?
> >
> > <Cosign>
> > <webloginServer name="cosign.uniba.sk"
> > loginUrl="https://login.uniba.sk/?"; port="6663"
> > postErrorRedirectUrl="https://login.uniba.sk/post_error.html"; />
> > ...
> > </Cosign>
> >
>
>
> What happens when you try this configuration? Does it behave as
> expected? What you describe above is the correct behavior. If the
> IIS 7 cosignmodule does not do this, it is a bug.
>
>
> Jarod
>
>
>
> > ?
> >
> > Thanks in advance!
> >
> > Mgr. Peter Kopáč
> > CIT UK
> > e-mail: [email protected]
> > tel: 02/592 44 965 voip: 11965
> >
> >
> >
> ------------------------------------------------------------------------------
>
> > ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit. See the prize list and enter to win:
> >
> http://p.sf.net/sfu/thinkgeek-promo_______________________________________________
>
> > Cosign-discuss mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
>
> ------------------------------------------------------------------------------
>
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Cosign-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
>
> __________ Informacia od ESET NOD32 Antivirus, verzia databazy 5169
> (20100603) __________
>
> Tuto spravu preveril ESET NOD32 Antivirus.
>
> http://www.eset.sk
>
>
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Cosign-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cosign-discuss
