Thomas,
Here is the RT-Authen-ExternalAuth. As you can see, some of this
information is re-used for multiple RT Extensions. Is there an PERL/RT
approved way of creating variables that can be passed to these Set()
statements? Is it as simple as declaring the variables and passing them
into the Set() statements like in a normal script?
Set($WebExternalAuth, 1);
Set($WebExternalAuto, 1);
Set($AutoCreate, {Privileged=>1});
Set($ExternalAuthPriority, ['Lingua_LDAP']);
Set($ExternalInfoPriority, ['Lingua_LDAP']);
Set($ExternalServiceUsesSSLorTLS, 0);
Set($AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {
'Lingua_LDAP' => {
'type' => 'ldap',
'server' => 'OURLDAPS.linguamatics.com',
'port' => '636',
'ca_path' => '/etc/openldap/cacerts/',
'user' =>
'uid=OURSYSTEMACCOUNT,dc=linguamatics,dc=com',
'pass' => 'OURSYSTEMACCOUNTPW',
'base' =>
'ou=OURUSERTREE,dc=linguamatics,dc=com',
'filter' =>
'(|(objectClass=posixAccount)(objectClass=account))',
'tls' => 0,
'net_ldap_args' => [ version => 3 ],
'attr_match_list' => [ 'EmailAddress',
'ExternalAuthId' ],
'attr_map' => { 'Name' => 'uid',
'EmailAddress' => 'mail',
'RealName' => 'cn',
'ExternalAuthId' => 'uid',
'Gecos' => 'gecos'
}
}
});
I'm surprised that our LDAP server is throwing critical errors,
because I believe that the information has been set up properly.
Having a "Disabled: , " is a bit confusing, but if that's valid as
designed ok.
I'm not having trouble finding the users in the web view, I'm
having trouble with the web view at all. But this is an internal
reverse proxy issue, not related to RT. Interrogating the SQL tables RT
creates shows the users with all the fields I wanted to check, but I
don't see a quick way to tell from the SQL data whether a user is
Privileged or not. If you want to pass me a clue I'd like to have that
crib note for when looking at the raw SQL data. Otherwise I can wait
until I get our internal issue cleared out.
-Scott
On 4/9/2012 4:58 PM, Thomas Sibley wrote:
On 04/09/2012 04:50 PM, Scott Pestana wrote:
[Mon Apr 9 19:51:49 2012] [critical]:
RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo : Search for
(&(|(objectClass=posixAccount)(objectClass=account))([email protected]))
failed: LDAP_NO_SUCH_OBJECT 32
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:232)
[Mon Apr 9 19:51:49 2012] [critical]:
RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo : Search for
(&(|(objectClass=posixAccount)(objectClass=account))(uid=USERID))
failed: LDAP_NO_SUCH_OBJECT 32
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:232)
You'll note these errors are from RT-Authen-ExternalAuth, not
RT-Extension-LDAPImport. Please show us the config for ExternalAuth.
For each user we get the above two "critical" errors, and the below
"info" message (which I don't mind aside from the "Disabled" part):
Those critical errors are passed along from your LDAP server.
[Mon Apr 9 19:51:49 2012] [info]:
RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Disabled: ,
EmailAddress: [email protected], ExternalAuthId: USERID, Gecos:
USERFULLNAME, Name: USERID, Privileged: 1, RealName: USERFULLNAME
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:651)
This is just an informational message. Disabled: is blank, so that's fine.
When I inspected the MySQL tables that were created, I found that
all the users appeared to be created as I wanted. I am having trouble
with the Web view at the moment, so I need to verify them through that
view as well.
This is probably because you're only looking at privileged users in the
admin interface and LDAPImport creates unprivileged users. You can
search for them using the form on the admin page.
Thomas
--
N. Scott Pestana
IT Infrastructure
Linguamatics
275 Grove Street, Suite 2-400
Newton, MA 02466
Tel: +1-774-571-7135
US Tel: +1-617-674-3256
UK Tel: 011-44-1223-421360
UK Fax: 011-44-1223-421361
Web: www.linguamatics.com
