Hey Ruslan,
I actually was able to get the time zone to switch properly for users, I had to install the following two packages:
- Bundle::Apache2
- Apache2::Reload
I also made the following change to /etc/httpd/conf/httpd.conf:
PerlOptions +GlobalRequest
Once the httpd service was restarted I was immediately able to see the change - so thanks for the suggestions they certainly helped.
I have one more issue, I am working on and this is enabling the full SSO (auto-login) function of RT::Authen::LDAP, but I keep running into some issues. AD users are able to authenticated against AD, but the RT interface won’t automatically log them in. I think my RT_SiteConfig.pm (the one located at /opt/rt3/local/plugins/RT-Authen-ExternalAuth/etc) is correct:
less /opt/rt3/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm
Set($ExternalAuthPriority, [ ‘My_LDAP’ ] );
Set($ExternalInfoPriority, [ ‘My_LDAP’ ] );
Set($ExternalServiceUsesSSLorTLS, 0);
Set($AutoCreateNonExternalUsers, 0);
Set($ExternalSettings, {
‘My_LDAP’ => {
'type' => 'ldap',
'server' => 'IP-OF-SERVER',
'user' => 'cvi-mg\ldap', #'cn=ldap,cn=Services,dc=domain,dc=com', <--nw
'pass' => 'userpassword',
'base' => 'dc=domain,dc=com',
'filter' => '(&(ObjectCategory=User)(ObjectClass=Person))',
'd_filter' => '(userAccountControl:1.2.840.113556.1.4.803:=2)',
'tls' => 0,
‘ssl_version’ => 3,
'net_ldap_args' => [ version => 3 ],
'group' => 'cn=RTUsers,ou=Services,dc=cvi-mg,dc=com',
'group_attr' => 'member',
'attr_match_list' => [ 'Name', 'EmailAddress' ],
'attr_map' => { 'Name' => 'sAMAccountName',
'EmailAddress' => 'mail',
'Organization' => 'physicalDeliveryOfficeName',
'RealName' => 'cn',
'ExternalAuthId' => 'sAMAccountName',
'Gecos' => 'sAMAccountName',
'WorkPhone' => 'telephoneNumber',
'Address1' => 'streetAddress',
'City' => 'l',
'State' => 'st',
'Zip' => 'postalCode',
'Country' => 'co'
}
}
}
);
1;
However, when a user who is part of the ‘RTUsersGroup’ within AD attempts to load the main RT page via any browser the following message gets generated by rt.log:
[Tue Apr 26 22:38:24 2011] [debug]: Autohandler called ExternalAuth. Response: (0, No User) (/opt/rt3/local/plugins/RT-Authen-ExternalAuth/html/Elements/DoAuth:26)
[Tue Apr 26 22:38:24 2011] [debug]: Attempting to use external auth service: My_LDAP (/opt/rt3/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:64)
[Tue Apr 26 22:38:24 2011] [debug]: SSO Failed and no user to test with. Nexting (/opt/rt3/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:92)
[Tue Apr 26 22:38:24 2011] [debug]: Autohandler called ExternalAuth. Response: (0, No User) (/opt/rt3/local/plugins/RT-Authen-ExternalAuth/html/Elements/DoAuth:26)
I have looked at the files mentioned above (ExternalAuth.pm, Doauth.pm, etc, etc) and have not been able to pinpoint the problem. My guess is that the credentials are either not being passed from LDAP to RT via the SSO check mentioned in this file ‘/opt/rt3/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm’ starting in line 71:
71 #############################################################
72 ####################### SSO Check ###########################
73 #############################################################
74 if ($config->{'type'} eq 'cookie') {
75 # Currently, Cookie authentication is our only SSO method
76 $username = RT::Authen::ExternalAuth::DBI::GetCookieAuth($config);
77 }
78 #############################################################
79
80 # If $username is defined, we have a good SSO $username and can
81 # safely bypass the password checking later on; primarily because
82 # it's VERY unlikely we even have a password to check if an SSO succeeded.
83 $pass_bypass = 0;
84 if(defined($username)) {
85 $RT::Logger->debug("Pass not going to be checked, attempting SSO");
86 $pass_bypass = 1;
87 } else {
88
89 # SSO failed and no $user was passed for a login attempt
90 # We only don't return here because the next iteration could be an SSO attempt
91 unless(defined($given_user)) {
92 $RT::Logger->debug("SSO Failed and no user to test with. Nexting");
93 next;
94 }
95
96 # We don't have an SSO login, so we will be using the credentials given
97 # on RT's login page to do our authentication.
98 $username = $given_user;
So here is where it gets a bit dicey for me, I am not entirely certain if the value for the $username variable (line 76) is being properly passed by our AD server and fails the SSO check (line 92), and then immediately jumps to line 98 to wait for the authentication to be manually entered (this part works if credentials are entered manually, LDAP authentication goes through normally).
So my question is why is it nexting (as per the rt.log), and not picking up the user name from the operating environment (just as an FYI most of our users are on Windows XP, 7 clients, running IE8 and Mozilla Firefox 3.6+), and automatically picking up on the credentials for the user.
My guess is that I have something probably not set correctly within the RT_SiteCOnfig.pm (for RT::Authen::LDAP), or the issue could be a missing Perl component (probably not being called from httpd.conf) I have not thought of as of yet. But as I said this are just initial guesses - any input anyone can offer would be great.
Thanks,
EliFrom: ruslan.zakirov@gmail.com [mailto:ruslan.zakirov@gmail.com] On Behalf Of Ruslan Zakirov
Sent: Thursday, April 21, 2011 8:51 PM
To: Eli Guzman
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Is a time zone user preference available?
Hello,
Look into logs for additional info about blank page.
You have several options:
- switch over fcgi
- figure out why modperl handler doesn’t work
- find/write patch for RT that uses Env::C in Date.pm