> Thanks once again for all of the input, IE is indeed the primary browser > here, but we do have users using Mozilla Firefox 4 as well. I have tried > logging in within FF4, and I get the same errors as I do in IE. I think > that there is some basic link not taking place between IE(FF4) and RT > (RT::Auth*), which is interesting (or rather odd) since as I mentioned > before, I am able to login using LDAP directly (though unable I may be > of passing the SSO check itself). I read on a previous message that > RT::Auth* was now at 0.08_02 (not sure if this is correct)? Perhaps I > should use this version with RT 3.89 and see if this fixes the issue. > > You mentioned mod_auth_kerb, and I actually do have mod_auth_kerb > installed for Apache2, so I'm thinking this could be another likely way > to go (would this work for FF4 as well?). I've also used Likewise Open > to physically join the server to our primary domain controller, but this > has not made much of a difference (yet) - although I am sure that a > separate connector has to probably be setup within Likewise for RT (but > I am at the moment not familiar with this option). As another feasible > option for SSO, would it be better to just use an AD synchronized > OpenLDAP server, using something like a DBI Authentication module?
RT::Authen::ExternalAuth does not provide transparent SSO using spnego What you're seeing in the logs is the support for cookie based SSO If you want to tie IE or a kerberized FF to an AD server using windows SSO, you want mod_auth_kerb -kevin
pgpJMLLeCVQ4f.pgp
Description: PGP signature