I installed 4.0.0rc7 for testing. Our production version is 3.8.4.
The 3.8.4 install has “Set($WebExternalAuth , 1);” in the
RT_SiteConfig.pm and Apache2::AuthCAS set up in the Apache config.
This works in 3.8.4, but when I set it up for 4.0.0rc7 and tried to
login I was redirected to our CAS login page as expected and then
redirected back the RT login page that says the login failed and
has the login text box showing (which does not accept text). Is there
something more I need to do for 4.0 or did I forgot some setting?
Thank You,
Scott
I installed 4.0.0rc7 for testing. Our production version is 3.8.4.
The 3.8.4 install has “Set($WebExternalAuth , 1);” in the
RT_SiteConfig.pm and Apache2::AuthCAS set up in the Apache config.
This works in 3.8.4, but when I set it up for 4.0.0rc7 and tried to
login I was redirected to our CAS login page as expected and then
redirected back the RT login page that says the login failed and
has the login text box showing (which does not accept text). Is there
something more I need to do for 4.0 or did I forgot some setting?
Does your apache log show that REMOTE_USER is being set to what you
expect? There have been several changes since 3.8.4 for the login
path, so you may be better off testing if 3.8.9 also fails for you.
I know of a few folks using RT’s External Auth against the 4.0.0
betas, so I suspect a misconfiguration or some weird bug we haven’t
seen yet, rather than a general failure.
-kevin
I installed 4.0.0rc7 for testing. Our production version is 3.8.4.
The 3.8.4 install has “Set($WebExternalAuth , 1);” in the
RT_SiteConfig.pm and Apache2::AuthCAS set up in the Apache config.
This works in 3.8.4, but when I set it up for 4.0.0rc7 and tried to
login I was redirected to our CAS login page as expected and then
redirected back the RT login page that says the login failed and
has the login text box showing (which does not accept text). Is there
something more I need to do for 4.0 or did I forgot some setting?
Does your apache log show that REMOTE_USER is being set to what you
expect?
I don’t see REMOTE_USER in the logs, but I do see this
CAS(95219): setHeader: Setting header: CAS_FILTER_USER = shildret
I installed 4.0.0rc7 for testing. Our production version is 3.8.4.
The 3.8.4 install has “Set($WebExternalAuth , 1);” in the
RT_SiteConfig.pm and Apache2::AuthCAS set up in the Apache config.
This works in 3.8.4, but when I set it up for 4.0.0rc7 and tried to
login I was redirected to our CAS login page as expected and then
redirected back the RT login page that says the login failed and
has the login text box showing (which does not accept text). Is there
something more I need to do for 4.0 or did I forgot some setting?
Does your apache log show that REMOTE_USER is being set to what you
expect?
I don’t see REMOTE_USER in the logs, but I do see this
CAS(95219): setHeader: Setting header: CAS_FILTER_USER = shildret
That isn’t a header that RT matches on, did you have a local
customization to 3.8.4 to handle that?
-kevin
I installed 4.0.0rc7 for testing. Our production version is 3.8.4.
The 3.8.4 install has “Set($WebExternalAuth , 1);” in the
RT_SiteConfig.pm and Apache2::AuthCAS set up in the Apache config.
This works in 3.8.4, but when I set it up for 4.0.0rc7 and tried to
login I was redirected to our CAS login page as expected and then
redirected back the RT login page that says the login failed and
has the login text box showing (which does not accept text). Is there
something more I need to do for 4.0 or did I forgot some setting?
Does your apache log show that REMOTE_USER is being set to what you
expect?
I don’t see REMOTE_USER in the logs, but I do see this
CAS(95219): setHeader: Setting header: CAS_FILTER_USER = shildret
That isn’t a header that RT matches on, did you have a local
customization to 3.8.4 to handle that?
-kevin
There have been several changes since 3.8.4 for the login
path, so you may be better off testing if 3.8.9 also fails for you.
I know of a few folks using RT’s External Auth against the 4.0.0
betas, so I suspect a misconfiguration or some weird bug we haven’t
seen yet, rather than a general failure.
I looked at my 3.8.4 install and there wasn’t any customization. If I
check the apache logs I don’t see REMOTE_USER in that one as well. I
set the log level to debug on the server where I have 4.0 installed, but
I still don’t see REMOTE_USER being set. Would I see that in the log
with debug set? Can I set REMOTE_USER = CAS_FILER_USER in the
httpd.conf?
I installed 4.0.0rc7 for testing. Our production version is 3.8.4.
The 3.8.4 install has “Set($WebExternalAuth , 1);” in the
RT_SiteConfig.pm and Apache2::AuthCAS set up in the Apache config.
This works in 3.8.4, but when I set it up for 4.0.0rc7 and tried to
login I was redirected to our CAS login page as expected and then
redirected back the RT login page that says the login failed and
has the login text box showing (which does not accept text). Is there
something more I need to do for 4.0 or did I forgot some setting?
Does your apache log show that REMOTE_USER is being set to what you
expect?
I don’t see REMOTE_USER in the logs, but I do see this
CAS(95219): setHeader: Setting header: CAS_FILTER_USER = shildret
That isn’t a header that RT matches on, did you have a local
customization to 3.8.4 to handle that?
-kevin
There have been several changes since 3.8.4 for the login
path, so you may be better off testing if 3.8.9 also fails for you.
I know of a few folks using RT’s External Auth against the 4.0.0
betas, so I suspect a misconfiguration or some weird bug we haven’t
seen yet, rather than a general failure.
I looked at my 3.8.4 install and there wasn’t any customization. If I
check the apache logs I don’t see REMOTE_USER in that one as well. I
set the log level to debug on the server where I have 4.0 installed, but
I still don’t see REMOTE_USER being set. Would I see that in the log
with debug set? Can I set REMOTE_USER = CAS_FILER_USER in the
httpd.conf?
Never mind, I was just told that I need to make it work with Tivoli. I
need to parse iv_user out of the header and redirect to the Tivoli
server if a user tries to access the server/rt directly.