Problems with RT::Authen::ExternalAuth::LDAP after upgrade to 4.4

I’m hoping a second (or more) set of eyes can help me out here.

I upgraded from 4.2.12 to 4.4.0 and somehow broke LDAP authentication.
For background. this particular installation went live 10 years ago and has
been carried over (mostly flawlessly I might add) from version to version
over that 10 years; I try to stay on the most recent stable version.

Things I have done to test so far:

  1. Tested with my existing config carried over from the working 4.2.12
    install – NO GOOD

  2. I changed my settings to exactly what is in the documentation – NO GOOD

  3. I installed ldap-utils and tested my filters with success. I’m sure
    they work. I have also confirmed that my ldap user is binding correctly
    and can pull permissions.

Interestingly, I have the exact same settings on LDAPImport and it IS
working correctly.

The frustrating thing is that, even with debugging turned on (logging to
syslog), I can get no detailed error message on LDAP under either syslog or
the apache log. All I get is the following message:

Feb 9 23:00:15 rt RT: [21718] FAILED LOGIN for andersjp from 172.28.160.152

Internal auth is working. Here is my LDAP config. Any ideas? Happy to
provide any troubleshooting info I have.

Also for what it’s worth, the odd-looking ldap filter is a way to filter
out some unwanted data and has been working for years. I also attempted
adding the ‘(&(…’ to the beginning of the filters (which LDAP Auth seems
to infer automatically for some reason). Again, still wouldn’t work.

Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);

Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);

Set( $ExternalServiceUsesSSLorTLS, 0);

Set( $AutoCreateNonExternalUsers, 1);

Set($ExternalSettings, {

    'LDAP_DIR3'       =>  {


            'type'          => 'ldap',

            'server'        => 'dir3.sch.ad',

            'user'          => 'ldapbind@sch.ad',

            'pass'          => '*censored*',

            'base'          => 'dc=sch,dc=ad',


            # ALL FILTERS MUST BE VALID LDAP FILTERS ENCASED IN

PARENTHESES!

            # YOU **MUST** SPECIFY A filter AND A d_filter!!


            # The filter to use to match RT-Users

            'filter'        =>  '(mail=*)(sAMAccountType=805306368)',

            #'filter'       =>  '(objectClass=*)',


            # The filter that will only match disabled users

            'd_filter'      =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            #'tls'          =>  0,

            #'ssl_version'  =>  3,

            'net_ldap_args' => [    version =>  3   ],

            #'group'        =>  'GROUP',

            #'group_attr'   =>  'GROUP_ATTR',


            'attr_match_list'       => [    'Name',

                                            'EmailAddress'

            ],


            # The mapping of RT attributes on to LDAP attributes

            'attr_map'      =>  {   'Name'                  =>

‘sAMAccountName’,

                                    'EmailAddress'          => 'mail',

                                    'Organization'          =>

‘company’,

                                    'RealName'              => 'cn',

                                    'WorkPhone'             =>

‘telephoneNumber’,

                                    'MobilePhone'           => 'mobile',

            }

    }

}

);

For some added information, here is the WORKING LDAPImport config:

LDAPImport Settings

Set( $LDAPHost, ‘dir3.sch.ad’ );

Set( $LDAPUser, ‘ldapbind@sch.ad’ );

Set( $LDAPPassword, ‘censored’ );

Set( $LDAPBase, ‘ou=SCH Users,dc=sch,dc=ad’ );

Set( $LDAPFilter, ‘(&(mail=*)(sAMAccountType=805306368))’ );

Set( $LDAPDisabledFilter,
‘(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))’
);

Set( $LDAPSkipAutogeneratedGroup, 1 );

Set( $LDAPUpdateUsers, 1 );

Get groups from LDAP too

Set( $LDAPGroupBase, ‘ou=SCH Groups,dc=sch,dc=ad’ );

Set( $LDAPGroupFilter, ‘(objectClass=group)’ );

Set( $LDAPGroupMapping, { Name => ‘cn’,

                            Member_Attr             => 'member',

                            Member_Attr_Value       => 'dn'

} );

Set( $LDAPMapping,

{

    'Name'                  =>      'sAMAccountName',

    'EmailAddress'          =>      'mail',

    'Organization'          =>      'company',

    'UserCF.Department'     =>      'department',

    'RealName'              =>      'cn',

    'WorkPhone'             =>      'telephoneNumber',

    'MobilePhone'           =>      'mobile'

}

);

I’d be grateful for any ideas or pointers!

Thank you,

John

Hi John,

For background. this particular installation went live 10 years ago and has
been carried over (mostly flawlessly I might add) from version to version
over that 10 years; I try to stay on the most recent stable version.

I’m very happy to hear that RT has been running smoothly for you for so long!

Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {

);

Could you try adding this as well?

Set( $ExternalAuth, 1 );

I’d be grateful for any ideas or pointers!

Please let us know if that gets you back up and running. We’ll do a better job about this in 4.4.1.

Thank you,
John

Thanks!
Shawn

Thank you for the response Shawn. I had rolled back to 4.2.12 but I threw
up a test server based on my current production server and ran through the
upgrade again, this time with your suggestion. Same result. What is
maddening is that there don’t seem to be any errors or anything. Other
than telling me “FAILED LOGIN” I can’t find anything in the logs that would
point me in the right direction. In syslog I simply get:

Feb 10 21:02:27 rt RT: [5018] FAILED LOGIN for andersjp from 70.199.131.228

My LDAP config now looks like this:

Set($ExternalSettings, { # SCH LDAP Settings
‘LDAP_DIR3’ => { ## GENERIC SECTION

            'type'          =>  'ldap',
            'server'        =>  'dir3.sch.ad',
            'user'          => 'ldapbind@sch.ad',
            'pass'          =>  '********',
            'base'          =>  'dc=sch,dc=ad',


            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',
            'd_filter' =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            'tls'                       =>  0,
            'ssl_version'               =>  3,
            'net_ldap_args'             => [    version =>  3   ],
            #'group'                     =>  'GROUP',
            #'group_attr'                =>  'GROUP_ATTR',

            'attr_match_list'       => [    'Name',
                                            'EmailAddress'
            ],

            # The mapping of RT attributes on to LDAP attributes
            'attr_map'      =>  {   'Name' => 'sAMAccountName',
                                    'EmailAddress' => 'mail',
                                    'Organization' => 'company',
                                    'RealName' => 'cn',
                                    'WorkPhone' => 'telephoneNumber',
                                    'MobilePhone' => 'mobile',
            }
    }

}
);

-JohnOn Wed, Feb 10, 2016 at 9:20 AM, Shawn Moore shawn@bestpractical.com wrote:

Hi John,

On 2016年2月10日 at 2:11:18, John Andersen (john@yvig.com) wrote:

For background. this particular installation went live 10 years ago and
has
been carried over (mostly flawlessly I might add) from version to version
over that 10 years; I try to stay on the most recent stable version.

I’m very happy to hear that RT has been running smoothly for you for so
long!

Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {

);

Could you try adding this as well?

Set( $ExternalAuth, 1 );

I’d be grateful for any ideas or pointers!

Please let us know if that gets you back up and running. We’ll do a better
job about this in 4.4.1.

Thank you,
John

Thanks!
Shawn


RT 4.4 and RTIR Training Sessions (
http://bestpractical.com/services/training.html)

  • Hamburg Germany March 14 & 15, 2016

Sorry, forgot to include the relevant part of the config. Here is is again:

Set( $WebExternalAuth, 1 );

Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);

Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);

Set( $ExternalServiceUsesSSLorTLS, 0);

Set( $AutoCreateNonExternalUsers, 1);

Set($ExternalSettings, {

    'LDAP_DIR3'       =>  {


            'type'          =>  'ldap',

            'server'        =>  'dir3.sch.ad',

            'user'          => 'ldapbind@sch.ad',

            'pass'          =>  '**********',

            'base'          =>  'dc=sch,dc=ad',



            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',

            'd_filter' =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            'tls'                       =>  0,

            'ssl_version'               =>  3,

            'net_ldap_args'             => [    version =>  3   ],

            #'group'                     =>  'GROUP',

            #'group_attr'                =>  'GROUP_ATTR',


            'attr_match_list'       => [    'Name',

                                            'EmailAddress'

            ],


            # The mapping of RT attributes on to LDAP attributes

            'attr_map'      =>  {   'Name' => 'sAMAccountName',

                                    'EmailAddress' => 'mail',

                                    'Organization' => 'company',

                                    'RealName' => 'cn',

                                    'WorkPhone' => 'telephoneNumber',

                                    'MobilePhone' => 'mobile',

            }

    }

}

);On Wed, Feb 10, 2016 at 9:07 PM, John Andersen john@yvig.com wrote:

Thank you for the response Shawn. I had rolled back to 4.2.12 but I
threw up a test server based on my current production server and ran
through the upgrade again, this time with your suggestion. Same result.
What is maddening is that there don’t seem to be any errors or anything.
Other than telling me “FAILED LOGIN” I can’t find anything in the logs that
would point me in the right direction. In syslog I simply get:

Feb 10 21:02:27 rt RT: [5018] FAILED LOGIN for andersjp from 70.199.131.228

My LDAP config now looks like this:

Set($ExternalSettings, { # SCH LDAP Settings
‘LDAP_DIR3’ => { ## GENERIC SECTION

            'type'          =>  'ldap',
            'server'        =>  'dir3.sch.ad',
            'user'          => 'ldapbind@sch.ad',
            'pass'          =>  '********',
            'base'          =>  'dc=sch,dc=ad',


            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',
            'd_filter' =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            'tls'                       =>  0,
            'ssl_version'               =>  3,
            'net_ldap_args'             => [    version =>  3   ],
            #'group'                     =>  'GROUP',
            #'group_attr'                =>  'GROUP_ATTR',

            'attr_match_list'       => [    'Name',
                                            'EmailAddress'
            ],

            # The mapping of RT attributes on to LDAP attributes
            'attr_map'      =>  {   'Name' => 'sAMAccountName',
                                    'EmailAddress' => 'mail',
                                    'Organization' => 'company',
                                    'RealName' => 'cn',
                                    'WorkPhone' => 'telephoneNumber',
                                    'MobilePhone' => 'mobile',
            }
    }

}
);

-John

On Wed, Feb 10, 2016 at 9:20 AM, Shawn Moore shawn@bestpractical.com wrote:

Hi John,

On 2016年2月10日 at 2:11:18, John Andersen (john@yvig.com) wrote:

For background. this particular installation went live 10 years ago and
has
been carried over (mostly flawlessly I might add) from version to
version
over that 10 years; I try to stay on the most recent stable version.

I’m very happy to hear that RT has been running smoothly for you for so
long!

Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {

);

Could you try adding this as well?

Set( $ExternalAuth, 1 );

I’d be grateful for any ideas or pointers!

Please let us know if that gets you back up and running. We’ll do a
better job about this in 4.4.1.

Thank you,
John

Thanks!
Shawn


RT 4.4 and RTIR Training Sessions (
http://bestpractical.com/services/training.html)

  • Hamburg Germany March 14 & 15, 2016

One more thing I should note is that I’m quite sure there is not even an
attempt to talk to the LDAP (Active Directory) server. I log all auth
attempts to the domain controllers and no attempts are showing in the logs.
I don’t believe the requests are ever leaving the RT server.On Wed, Feb 10, 2016 at 9:27 PM, John Andersen john@yvig.com wrote:

Sorry, forgot to include the relevant part of the config. Here is is
again:

Set( $WebExternalAuth, 1 );

Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);

Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);

Set( $ExternalServiceUsesSSLorTLS, 0);

Set( $AutoCreateNonExternalUsers, 1);

Set($ExternalSettings, {

    'LDAP_DIR3'       =>  {


            'type'          =>  'ldap',

            'server'        =>  'dir3.sch.ad',

            'user'          => 'ldapbind@sch.ad',

            'pass'          =>  '**********',

            'base'          =>  'dc=sch,dc=ad',



            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',

            'd_filter' =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            'tls'                       =>  0,

            'ssl_version'               =>  3,

            'net_ldap_args'             => [    version =>  3   ],

            #'group'                     =>  'GROUP',

            #'group_attr'                =>  'GROUP_ATTR',


            'attr_match_list'       => [    'Name',

                                            'EmailAddress'

            ],


            # The mapping of RT attributes on to LDAP attributes

            'attr_map'      =>  {   'Name' => 'sAMAccountName',

                                    'EmailAddress' => 'mail',

                                    'Organization' => 'company',

                                    'RealName' => 'cn',

                                    'WorkPhone' => 'telephoneNumber',

                                    'MobilePhone' => 'mobile',

            }

    }

}

);

On Wed, Feb 10, 2016 at 9:07 PM, John Andersen john@yvig.com wrote:

Thank you for the response Shawn. I had rolled back to 4.2.12 but I
threw up a test server based on my current production server and ran
through the upgrade again, this time with your suggestion. Same result.
What is maddening is that there don’t seem to be any errors or anything.
Other than telling me “FAILED LOGIN” I can’t find anything in the logs that
would point me in the right direction. In syslog I simply get:

Feb 10 21:02:27 rt RT: [5018] FAILED LOGIN for andersjp from
70.199.131.228

My LDAP config now looks like this:

Set($ExternalSettings, { # SCH LDAP Settings
‘LDAP_DIR3’ => { ## GENERIC SECTION

            'type'          =>  'ldap',
            'server'        =>  'dir3.sch.ad',
            'user'          => 'ldapbind@sch.ad',
            'pass'          =>  '********',
            'base'          =>  'dc=sch,dc=ad',


            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',
            'd_filter' =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            'tls'                       =>  0,
            'ssl_version'               =>  3,
            'net_ldap_args'             => [    version =>  3   ],
            #'group'                     =>  'GROUP',
            #'group_attr'                =>  'GROUP_ATTR',

            'attr_match_list'       => [    'Name',
                                            'EmailAddress'
            ],

            # The mapping of RT attributes on to LDAP attributes
            'attr_map'      =>  {   'Name' => 'sAMAccountName',
                                    'EmailAddress' => 'mail',
                                    'Organization' => 'company',
                                    'RealName' => 'cn',
                                    'WorkPhone' => 'telephoneNumber',
                                    'MobilePhone' => 'mobile',
            }
    }

}
);

-John

On Wed, Feb 10, 2016 at 9:20 AM, Shawn Moore shawn@bestpractical.com wrote:

Hi John,

On 2016年2月10日 at 2:11:18, John Andersen (john@yvig.com) wrote:

For background. this particular installation went live 10 years ago
and has
been carried over (mostly flawlessly I might add) from version to
version
over that 10 years; I try to stay on the most recent stable version.

I’m very happy to hear that RT has been running smoothly for you for so
long!

Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {

);

Could you try adding this as well?

Set( $ExternalAuth, 1 );

I’d be grateful for any ideas or pointers!

Please let us know if that gets you back up and running. We’ll do a
better job about this in 4.4.1.

Thank you,
John

Thanks!
Shawn


RT 4.4 and RTIR Training Sessions (
http://bestpractical.com/services/training.html)

  • Hamburg Germany March 14 & 15, 2016

Set( $WebExternalAuth, 1 ); to Set( $ExternalAuth, 1 );> On 11 Feb 2016, at 3:44 PM, John Andersen john@yvig.com wrote:

One more thing I should note is that I’m quite sure there is not even an attempt to talk to the LDAP (Active Directory) server. I log all auth attempts to the domain controllers and no attempts are showing in the logs. I don’t believe the requests are ever leaving the RT server.

On Wed, Feb 10, 2016 at 9:27 PM, John Andersen john@yvig.com wrote:
Sorry, forgot to include the relevant part of the config. Here is is again:

Set( $WebExternalAuth, 1 );
Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);

Set($ExternalSettings, {
‘LDAP_DIR3’ => {

            'type'          =>  'ldap',
            'server'        =>  'dir3.sch.ad',
            'user'          => 'ldapbind@sch.ad',
            'pass'          =>  '**********',
            'base'          =>  'dc=sch,dc=ad',


            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',
            'd_filter' =>  '(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)',

            'tls'                       =>  0,
            'ssl_version'               =>  3,
            'net_ldap_args'             => [    version =>  3   ],
            #'group'                     =>  'GROUP',
            #'group_attr'                =>  'GROUP_ATTR',

            'attr_match_list'       => [    'Name',
                                            'EmailAddress'
            ],

            # The mapping of RT attributes on to LDAP attributes
            'attr_map'      =>  {   'Name' => 'sAMAccountName',
                                    'EmailAddress' => 'mail',
                                    'Organization' => 'company',
                                    'RealName' => 'cn',
                                    'WorkPhone' => 'telephoneNumber',
                                    'MobilePhone' => 'mobile',
            }
    }

}
);

On Wed, Feb 10, 2016 at 9:07 PM, John Andersen john@yvig.com wrote:
Thank you for the response Shawn. I had rolled back to 4.2.12 but I threw up a test server based on my current production server and ran through the upgrade again, this time with your suggestion. Same result. What is maddening is that there don’t seem to be any errors or anything. Other than telling me “FAILED LOGIN” I can’t find anything in the logs that would point me in the right direction. In syslog I simply get:

Feb 10 21:02:27 rt RT: [5018] FAILED LOGIN for andersjp from 70.199.131.228

My LDAP config now looks like this:

Set($ExternalSettings, { # SCH LDAP Settings
‘LDAP_DIR3’ => { ## GENERIC SECTION

            'type'          =>  'ldap',
            'server'        =>  'dir3.sch.ad',
            'user'          => 'ldapbind@sch.ad',
            'pass'          =>  '********',
            'base'          =>  'dc=sch,dc=ad',


            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',
            'd_filter' =>  '(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)',

            'tls'                       =>  0,
            'ssl_version'               =>  3,
            'net_ldap_args'             => [    version =>  3   ],
            #'group'                     =>  'GROUP',
            #'group_attr'                =>  'GROUP_ATTR',

            'attr_match_list'       => [    'Name',
                                            'EmailAddress'
            ],

            # The mapping of RT attributes on to LDAP attributes
            'attr_map'      =>  {   'Name' => 'sAMAccountName',
                                    'EmailAddress' => 'mail',
                                    'Organization' => 'company',
                                    'RealName' => 'cn',
                                    'WorkPhone' => 'telephoneNumber',
                                    'MobilePhone' => 'mobile',
            }
    }

}
);

-John

On Wed, Feb 10, 2016 at 9:20 AM, Shawn Moore shawn@bestpractical.com wrote:
Hi John,

On 2016年2月10日 at 2:11:18, John Andersen (john@yvig.com) wrote:

For background. this particular installation went live 10 years ago and has
been carried over (mostly flawlessly I might add) from version to version
over that 10 years; I try to stay on the most recent stable version.

I’m very happy to hear that RT has been running smoothly for you for so long!

Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {

);

Could you try adding this as well?

Set( $ExternalAuth, 1 );

I’d be grateful for any ideas or pointers!

Please let us know if that gets you back up and running. We’ll do a better job about this in 4.4.1.

Thank you,
John

Thanks!
Shawn


RT 4.4 and RTIR Training Sessions (http://bestpractical.com/services/training.html)

  • Hamburg Germany March 14 & 15, 2016

This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com



RT 4.4 and RTIR Training Sessions (http://bestpractical.com/services/training.html)

  • Hamburg Germany — March 14 & 15, 2016

Oh man! Thanks for that catch! I see now that Shawn told me exactly that
and I saw what I expected to see instead.On Wed, Feb 10, 2016 at 9:55 PM, Julian De Marchi jdemarchi@pivit.com.au wrote:

Set( $WebExternalAuth, 1 ); to Set( $ExternalAuth, 1 );

On 11 Feb 2016, at 3:44 PM, John Andersen john@yvig.com wrote:

One more thing I should note is that I’m quite sure there is not even an
attempt to talk to the LDAP (Active Directory) server. I log all auth
attempts to the domain controllers and no attempts are showing in the
logs. I don’t believe the requests are ever leaving the RT server.

On Wed, Feb 10, 2016 at 9:27 PM, John Andersen john@yvig.com wrote:
Sorry, forgot to include the relevant part of the config. Here is is
again:

Set( $WebExternalAuth, 1 );
Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);

Set($ExternalSettings, {
‘LDAP_DIR3’ => {

            'type'          =>  'ldap',
            'server'        =>  'dir3.sch.ad',
            'user'          => 'ldapbind@sch.ad',
            'pass'          =>  '**********',
            'base'          =>  'dc=sch,dc=ad',


            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',
            'd_filter' =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            'tls'                       =>  0,
            'ssl_version'               =>  3,
            'net_ldap_args'             => [    version =>  3   ],
            #'group'                     =>  'GROUP',
            #'group_attr'                =>  'GROUP_ATTR',

            'attr_match_list'       => [    'Name',
                                            'EmailAddress'
            ],

            # The mapping of RT attributes on to LDAP attributes
            'attr_map'      =>  {   'Name' => 'sAMAccountName',
                                    'EmailAddress' => 'mail',
                                    'Organization' => 'company',
                                    'RealName' => 'cn',
                                    'WorkPhone' => 'telephoneNumber',
                                    'MobilePhone' => 'mobile',
            }
    }

}
);

On Wed, Feb 10, 2016 at 9:07 PM, John Andersen john@yvig.com wrote:
Thank you for the response Shawn. I had rolled back to 4.2.12 but I
threw up a test server based on my current production server and ran
through the upgrade again, this time with your suggestion. Same result.
What is maddening is that there don’t seem to be any errors or anything.
Other than telling me “FAILED LOGIN” I can’t find anything in the logs that
would point me in the right direction. In syslog I simply get:

Feb 10 21:02:27 rt RT: [5018] FAILED LOGIN for andersjp from
70.199.131.228

My LDAP config now looks like this:

Set($ExternalSettings, { # SCH LDAP Settings
‘LDAP_DIR3’ => { ## GENERIC SECTION

            'type'          =>  'ldap',
            'server'        =>  'dir3.sch.ad',
            'user'          => 'ldapbind@sch.ad',
            'pass'          =>  '********',
            'base'          =>  'dc=sch,dc=ad',


            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',
            'd_filter' =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            'tls'                       =>  0,
            'ssl_version'               =>  3,
            'net_ldap_args'             => [    version =>  3   ],
            #'group'                     =>  'GROUP',
            #'group_attr'                =>  'GROUP_ATTR',

            'attr_match_list'       => [    'Name',
                                            'EmailAddress'
            ],

            # The mapping of RT attributes on to LDAP attributes
            'attr_map'      =>  {   'Name' => 'sAMAccountName',
                                    'EmailAddress' => 'mail',
                                    'Organization' => 'company',
                                    'RealName' => 'cn',
                                    'WorkPhone' => 'telephoneNumber',
                                    'MobilePhone' => 'mobile',
            }
    }

}
);

-John

On Wed, Feb 10, 2016 at 9:20 AM, Shawn Moore shawn@bestpractical.com wrote:
Hi John,

On 2016年2月10日 at 2:11:18, John Andersen (john@yvig.com) wrote:

For background. this particular installation went live 10 years ago
and has
been carried over (mostly flawlessly I might add) from version to
version
over that 10 years; I try to stay on the most recent stable version.

I’m very happy to hear that RT has been running smoothly for you for so
long!

Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {

);

Could you try adding this as well?

Set( $ExternalAuth, 1 );

I’d be grateful for any ideas or pointers!

Please let us know if that gets you back up and running. We’ll do a
better job about this in 4.4.1.

Thank you,
John

Thanks!
Shawn


RT 4.4 and RTIR Training Sessions (
http://bestpractical.com/services/training.html)

  • Hamburg Germany March 14 & 15, 2016

This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com



RT 4.4 and RTIR Training Sessions (
http://bestpractical.com/services/training.html)

  • Hamburg Germany — March 14 & 15, 2016

BINGO! That nailed it. Thanks again Shawn and Julian. I will try to read
responses more carefully in the future! :)On Wed, Feb 10, 2016 at 9:59 PM, John Andersen john@yvig.com wrote:

Oh man! Thanks for that catch! I see now that Shawn told me exactly that
and I saw what I expected to see instead.

On Wed, Feb 10, 2016 at 9:55 PM, Julian De Marchi jdemarchi@pivit.com.au wrote:

Set( $WebExternalAuth, 1 ); to Set( $ExternalAuth, 1 );

On 11 Feb 2016, at 3:44 PM, John Andersen john@yvig.com wrote:

One more thing I should note is that I’m quite sure there is not even
an attempt to talk to the LDAP (Active Directory) server. I log all auth
attempts to the domain controllers and no attempts are showing in the
logs. I don’t believe the requests are ever leaving the RT server.

On Wed, Feb 10, 2016 at 9:27 PM, John Andersen john@yvig.com wrote:
Sorry, forgot to include the relevant part of the config. Here is is
again:

Set( $WebExternalAuth, 1 );
Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);

Set($ExternalSettings, {
‘LDAP_DIR3’ => {

            'type'          =>  'ldap',
            'server'        =>  'dir3.sch.ad',
            'user'          => 'ldapbind@sch.ad',
            'pass'          =>  '**********',
            'base'          =>  'dc=sch,dc=ad',


            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',
            'd_filter' =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            'tls'                       =>  0,
            'ssl_version'               =>  3,
            'net_ldap_args'             => [    version =>  3   ],
            #'group'                     =>  'GROUP',
            #'group_attr'                =>  'GROUP_ATTR',

            'attr_match_list'       => [    'Name',
                                            'EmailAddress'
            ],

            # The mapping of RT attributes on to LDAP attributes
            'attr_map'      =>  {   'Name' => 'sAMAccountName',
                                    'EmailAddress' => 'mail',
                                    'Organization' => 'company',
                                    'RealName' => 'cn',
                                    'WorkPhone' =>

‘telephoneNumber’,

                                    'MobilePhone' => 'mobile',
            }
    }

}
);

On Wed, Feb 10, 2016 at 9:07 PM, John Andersen john@yvig.com wrote:
Thank you for the response Shawn. I had rolled back to 4.2.12 but I
threw up a test server based on my current production server and ran
through the upgrade again, this time with your suggestion. Same result.
What is maddening is that there don’t seem to be any errors or anything.
Other than telling me “FAILED LOGIN” I can’t find anything in the logs that
would point me in the right direction. In syslog I simply get:

Feb 10 21:02:27 rt RT: [5018] FAILED LOGIN for andersjp from
70.199.131.228

My LDAP config now looks like this:

Set($ExternalSettings, { # SCH LDAP Settings
‘LDAP_DIR3’ => { ## GENERIC SECTION

            'type'          =>  'ldap',
            'server'        =>  'dir3.sch.ad',
            'user'          => 'ldapbind@sch.ad',
            'pass'          =>  '********',
            'base'          =>  'dc=sch,dc=ad',


            'filter'   =>  '(mail=*)(sAMAccountType=805306368)',
            'd_filter' =>

‘(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)’,

            'tls'                       =>  0,
            'ssl_version'               =>  3,
            'net_ldap_args'             => [    version =>  3   ],
            #'group'                     =>  'GROUP',
            #'group_attr'                =>  'GROUP_ATTR',

            'attr_match_list'       => [    'Name',
                                            'EmailAddress'
            ],

            # The mapping of RT attributes on to LDAP attributes
            'attr_map'      =>  {   'Name' => 'sAMAccountName',
                                    'EmailAddress' => 'mail',
                                    'Organization' => 'company',
                                    'RealName' => 'cn',
                                    'WorkPhone' =>

‘telephoneNumber’,

                                    'MobilePhone' => 'mobile',
            }
    }

}
);

-John

On Wed, Feb 10, 2016 at 9:20 AM, Shawn Moore shawn@bestpractical.com wrote:
Hi John,

On 2016年2月10日 at 2:11:18, John Andersen (john@yvig.com) wrote:

For background. this particular installation went live 10 years ago
and has
been carried over (mostly flawlessly I might add) from version to
version
over that 10 years; I try to stay on the most recent stable version.

I’m very happy to hear that RT has been running smoothly for you for so
long!

Set( $ExternalAuthPriority,[‘LDAP_DIR3’]);
Set( $ExternalInfoPriority,[‘LDAP_DIR3’]);
Set( $ExternalServiceUsesSSLorTLS, 0);
Set( $AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {

);

Could you try adding this as well?

Set( $ExternalAuth, 1 );

I’d be grateful for any ideas or pointers!

Please let us know if that gets you back up and running. We’ll do a
better job about this in 4.4.1.

Thank you,
John

Thanks!
Shawn


RT 4.4 and RTIR Training Sessions (
http://bestpractical.com/services/training.html)

  • Hamburg Germany March 14 & 15, 2016

This email has been scanned by the Symantec Email Security.cloud
service.
For more information please visit http://www.symanteccloud.com



RT 4.4 and RTIR Training Sessions (
http://bestpractical.com/services/training.html)

  • Hamburg Germany — March 14 & 15, 2016

Could you try adding this as well?

Set( $ExternalAuth, 1 );

I’d be grateful for any ideas or pointers!

Please let us know if that gets you back up and running. We’ll do a better job about this in 4.4.1.

We’re the same here. Running RT with upgrading since 2003. Very few
gotchas along the way, i.e. not reading release notes.

Hit this today (should have waited for 4.4.1 :slight_smile: ) via fetchmail (that
subroutine is there):

RT server error.

The RT server which handled your email did not behave as expected. It
said:

Undefined subroutine
&RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo called at
/opt/rt4/sbin/…/lib/RT/User.pm line 787.

Stack:
[/opt/rt4/sbin/…/lib/RT/User.pm:786]
[/opt/rt4/sbin/…/lib/RT/User.pm:699]
[/opt/rt4/sbin/…/lib/RT/User.pm:134]
[/opt/rt4/sbin/…/lib/RT/User.pm:531]
[/opt/rt4/sbin/…/lib/RT/Interface/Email/Auth/MailFrom.pm:100]
[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:338]
[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:224]
[/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway:61]

After adding Set( $ExternalAuth, 1 ); all our stuck mails are now
creating tickets for sales/support that haven’t emailed us before.

I can’t see Set( $ExternalAuth, 1 ); in RT_Config.pm as an example?

Thanks.

http://www.suretecsystems.com/services/openldap/
http://www.surevoip.co.uk

Hi Gavin,On 2016年2月11日 at 10:20:44, Gavin Henry (gavin.henry@gmail.com) wrote:

Undefined subroutine
&RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo called at
/opt/rt4/sbin/…/lib/RT/User.pm line 787.

Could you try loading that module in that bit of code, near /opt/rt4/lib/RT/User.pm line 787. Changing:

if($config->{'type'} eq 'ldap'){
    ($found, %params) = RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo($service,$key,$value);
} elsif ($config->{'type'} eq 'db') {

to:

if($config->{'type'} eq 'ldap’){
    require RT::Authen::ExternalAuth::LDAP;
    ($found, %params) = RT::Authen::ExternalAuth::LDAP::CanonicalizeUserInfo($service,$key,$value);
} elsif ($config->{'type'} eq 'db') {

Please let us know if that makes it any better.

Thanks,
Shawn

This solution works for me but I’m wondering if there’s a better solution
than doing this for each installations? I don’t want to have to manually
edit a file every single time I need to init a database.

View this message in context: http://requesttracker.8502.n7.nabble.com/Problems-with-RT-Authen-ExternalAuth-LDAP-after-upgrade-to-4-4-tp61327p61492.html