RT-Extension-SaltedPasswords Not Playing Nice with LDAP

So, I just installed the RT-Extension-SaltedPasswords extension on two
RT 3.6.x installations (3.6.5 and 3.6.7) to protect against the
announced vulnerability. I followed the directions, and, upon adding
the line:

use RT::Extension::SaltedPasswords;

in my RT_SiteConfig.pm file, found that LDAP logins no longer work. If
I comment out the above line, LDAP logins work fine (but, obviously, my
recently-updated salted passwords for local users do not work), if I
leave it enabled, LDAP logins fail. Turning on debug logging, it looks
like the LDAP server is contacted and everything goes as expected until
the very last step of actually authenticating the user, as which time it
kicks out a failure. Last couple of lines of log file look like this:

[Fri Jan 21 03:40:09 2011] [debug]: UPDATED user Nick Couchman from LDAP
(/opt/rt3/local/lib/RT/User_Local.pm:628)
[Fri Jan 21 03:40:09 2011] [error]: FAILED LOGIN for Nick Couchman from
2.0.183.98 (/opt/rt3/share/html/autohandler:251)

Can someone help me figure out what’s going on?

Thanks,
Nick

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

So, I just installed the RT-Extension-SaltedPasswords extension on two
RT 3.6.x installations (3.6.5 and 3.6.7) to protect against the
announced vulnerability. I followed the directions, and, upon adding
the line:

use RT::Extension::SaltedPasswords;

in my RT_SiteConfig.pm file, found that LDAP logins no longer work.

That’s not the right line to put in your config file. What
documentation made you think it was?

You need to add it to your @Plugins line.

Thomas

So, I just installed the RT-Extension-SaltedPasswords extension on two
RT 3.6.x installations (3.6.5 and 3.6.7) to protect against the
announced vulnerability. I followed the directions, and, upon adding
the line:

Sorry, I missed the part where you said version 3.6 above. The use line
below is correct.

Thomas

[Fri Jan 21 03:40:09 2011] [debug]: UPDATED user Nick Couchman from LDAP
(/opt/rt3/local/lib/RT/User_Local.pm:628)

Looks like you’re using an old extension that clobbers IsPassword.
You’re going to need to merge that code with the IsPassword in
SaltedPasswords to handle both cases.

-kevin

[Fri Jan 21 03:40:09 2011] [debug]: UPDATED user Nick Couchman from LDAP
(/opt/rt3/local/lib/RT/User_Local.pm:628)

Looks like you’re using an old extension that clobbers IsPassword.
You’re going to need to merge that code with the IsPassword in
SaltedPasswords to handle both cases.

-kevin

Well, I’m getting closer. I decided to remove the old LDAP method and
install the RT-Authen-ExternalAuth extension, version 0.05, instead.
Now the log output looks like this:

[Fri Jan 21 17:14:07 2011] [debug]: LDAP Search === Base: dc=seakr,dc=com == Filter: (&(objectClass=posixAccount)(cn=Nick Couchman)) == Attrs: l,cn,st,mail,cn,co,physicalDeliveryOfficeName,postalCode,telephoneNumber,cn,o,cn (/opt/rt3/local/lib/RT/User_Vendor.pm:850)
[Fri Jan 21 17:14:07 2011] [debug]: LDAP Search === Base: dc=seakr,dc=com == Filter: (&(objectClass=posixAccount)(isDisabled=true)(cn=Nick Couchman)) == Attrs: uid (/opt/rt3/local/lib/RT/User_Vendor.pm:890)
[Fri Jan 21 17:14:07 2011] [info]: ENABLED user Nick Couchman per External Service (0, That is already the current value) (/opt/rt3/local/lib/RT/User_Vendor.pm:957)
[Fri Jan 21 17:14:07 2011] [debug]: RT::User::CanonicalizeUserInfo called by RT::User /opt/rt3/local/lib/RT/User_Vendor.pm 966 with: Name: Nick Couchman (/opt/rt3/local/lib/RT/User_Vendor.pm:400)
[Fri Jan 21 17:14:07 2011] [debug]: Attempting to get user info using this external service: eDirectory1 (/opt/rt3/local/lib/RT/User_Vendor.pm:408)
[Fri Jan 21 17:14:07 2011] [debug]: Attempting to use this canonicalization key: Name (/opt/rt3/local/lib/RT/User_Vendor.pm:417)
[Fri Jan 21 17:14:07 2011] [debug]: LDAP Search === Base: dc=seakr,dc=com == Filter: (&(objectClass=posixAccount)(cn=Nick Couchman)) == Attrs: l,cn,st,mail,cn,co,physicalDeliveryOfficeName,postalCode,telephoneNumber,cn,o,cn (/opt/rt3/local/lib/RT/User_Vendor.pm:538)
[Fri Jan 21 17:14:07 2011] [info]: RT::User::LookupExternalUserInfo : Returning: Address1: , City: , Country: , EmailAddress: Nick.Couchman@seakr.com, ExternalAuthId: Nick Couchman, Gecos: Nick Couchman, Name: Nick Couchman, Organization: , RealName: Nick Couchman, State: , WorkPhone: , Zip: (/opt/rt3/local/lib/RT/User_Vendor.pm:703)
[Fri Jan 21 17:14:07 2011] [info]: RT::User::CanonicalizeUserInfo returning Address1: , City: , Country: , EmailAddress: Nick.Couchman@seakr.com, ExternalAuthId: Nick Couchman, Gecos: Nick Couchman, Name: Nick Couchman, Organization: , RealName: Nick Couchman, State: , WorkPhone: , Zip: (/opt/rt3/local/lib/RT/User_Vendor.pm:444)
[Fri Jan 21 17:14:08 2011] [debug]: UPDATED user Nick Couchman from External Service (/opt/rt3/local/lib/RT/User_Vendor.pm:990)
[Fri Jan 21 17:14:08 2011] [error]: FAILED LOGIN for Nick Couchman from 192.168.10.71 (/opt/rt3/share/html/autohandler:251)

So, it looks to me like it successfully pulls all of the information
from the LDAP service successfully, but for some reason still fails the
login. I know I’m typing the correct password - tried that along with
bogus ones a few times. Any other hints?

Thanks,
Nick

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

The line:
use RT::Extension::SaltedPasswords;

is still clobbering LDAP logins, even using the RT-Authen-ExternalAuth
extension. If I comment out that line, it works fine. If the line is
present and uncommented, LDAP logins fail with:

[Fri Jan 21 17:21:20 2011] [debug]: UPDATED user Nick Couchman from
External Service (/opt/rt3/local/lib/RT/User_Vendor.pm:990)
[Fri Jan 21 17:21:20 2011] [error]: FAILED LOGIN for Nick Couchman from
192.168.10.71 (/opt/rt3/share/html/autohandler:251)

-NickOn Fri, 2011-01-21 at 10:37 -0500, Kevin Falcone wrote:

On Fri, Jan 21, 2011 at 07:48:15AM -0700, Nick Couchman wrote:

[Fri Jan 21 03:40:09 2011] [debug]: UPDATED user Nick Couchman from LDAP
(/opt/rt3/local/lib/RT/User_Local.pm:628)

Looks like you’re using an old extension that clobbers IsPassword.
You’re going to need to merge that code with the IsPassword in
SaltedPasswords to handle both cases.

-kevin

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

[Fri Jan 21 03:40:09 2011] [debug]: UPDATED user Nick Couchman from LDAP
(/opt/rt3/local/lib/RT/User_Local.pm:628)

Looks like you’re using an old extension that clobbers IsPassword.
You’re going to need to merge that code with the IsPassword in
SaltedPasswords to handle both cases.

-kevin

Well, I’m getting closer. I decided to remove the old LDAP method and
install the RT-Authen-ExternalAuth extension, version 0.05, instead.
Now the log output looks like this:

[Fri Jan 21 17:14:07 2011] [debug]: LDAP Search === Base: dc=seakr,dc=com == Filter: (&(objectClass=posixAccount)(cn=Nick Couchman)) == Attrs: l,cn,st,mail,cn,co,physicalDeliveryOfficeName,postalCode,telephoneNumber,cn,o,cn (/opt/rt3/local/lib/RT/User_Vendor.pm:850)
[Fri Jan 21 17:14:07 2011] [debug]: LDAP Search === Base: dc=seakr,dc=com == Filter: (&(objectClass=posixAccount)(isDisabled=true)(cn=Nick Couchman)) == Attrs: uid (/opt/rt3/local/lib/RT/User_Vendor.pm:890)
[Fri Jan 21 17:14:07 2011] [info]: ENABLED user Nick Couchman per External Service (0, That is already the current value) (/opt/rt3/local/lib/RT/User_Vendor.pm:957)
[Fri Jan 21 17:14:07 2011] [debug]: RT::User::CanonicalizeUserInfo called by RT::User /opt/rt3/local/lib/RT/User_Vendor.pm 966 with: Name: Nick Couchman (/opt/rt3/local/lib/RT/User_Vendor.pm:400)
[Fri Jan 21 17:14:07 2011] [debug]: Attempting to get user info using this external service: eDirectory1 (/opt/rt3/local/lib/RT/User_Vendor.pm:408)
[Fri Jan 21 17:14:07 2011] [debug]: Attempting to use this canonicalization key: Name (/opt/rt3/local/lib/RT/User_Vendor.pm:417)
[Fri Jan 21 17:14:07 2011] [debug]: LDAP Search === Base: dc=seakr,dc=com == Filter: (&(objectClass=posixAccount)(cn=Nick Couchman)) == Attrs: l,cn,st,mail,cn,co,physicalDeliveryOfficeName,postalCode,telephoneNumber,cn,o,cn (/opt/rt3/local/lib/RT/User_Vendor.pm:538)
[Fri Jan 21 17:14:07 2011] [info]: RT::User::LookupExternalUserInfo : Returning: Address1: , City: , Country: , EmailAddress: Nick.Couchman@seakr.com, ExternalAuthId: Nick Couchman, Gecos: Nick Couchman, Name: Nick Couchman, Organization: , RealName: Nick Couchman, State: , WorkPhone: , Zip: (/opt/rt3/local/lib/RT/User_Vendor.pm:703)
[Fri Jan 21 17:14:07 2011] [info]: RT::User::CanonicalizeUserInfo returning Address1: , City: , Country: , EmailAddress: Nick.Couchman@seakr.com, ExternalAuthId: Nick Couchman, Gecos: Nick Couchman, Name: Nick Couchman, Organization: , RealName: Nick Couchman, State: , WorkPhone: , Zip: (/opt/rt3/local/lib/RT/User_Vendor.pm:444)
[Fri Jan 21 17:14:08 2011] [debug]: UPDATED user Nick Couchman from External Service (/opt/rt3/local/lib/RT/User_Vendor.pm:990)
[Fri Jan 21 17:14:08 2011] [error]: FAILED LOGIN for Nick Couchman from 192.168.10.71 (/opt/rt3/share/html/autohandler:251)

So, it looks to me like it successfully pulls all of the information
from the LDAP service successfully, but for some reason still fails the
login. I know I’m typing the correct password - tried that along with
bogus ones a few times. Any other hints?

Correct ldap password or correct local password?
RT-Authen-ExternalAuth 0.05 messes with IsPassword, and you’d likely
have to merge the IsPassword from SaltedPasswords with
IsInternalPassword to make it go.

RT-Authen-ExternalAuth 0.08 (the version compatible with 3.8) uses a
different technique that doesn’t clobber IsPassword

-kevin

Correct ldap password or correct local password?
RT-Authen-ExternalAuth 0.05 messes with IsPassword, and you’d likely
have to merge the IsPassword from SaltedPasswords with
IsInternalPassword to make it go.

RT-Authen-ExternalAuth 0.08 (the version compatible with 3.8) uses a
different technique that doesn’t clobber IsPassword

-kevin

Correct LDAP password.

I was able to get it working - here’s how, in case anyone else is
interested.

  • For RT using the really old LDAP method, I changed the name of the
    IsPassword function in the Salted extension to “IsSaltedPassword” as
    well as the override for IsPassword, and then in my RT_SiteConfig.pm
    file, I used the following:

Set($AuthMethods, [‘LDAP’, ‘Salted’]);

So, authentication calls IsLDAPPassword() and then IsSaltedPassword(),
and ignores the old IsInternalPassword() function.

  • For RT using the RT-Authen-ExternalAuth extension, I made the same
    change of the function name to IsSaltedPassword in the salt extension,
    and then in the local/lib/RT/User_Vendor.pm file, I changed the call for
    IsInternalPassword($value) to IsSaltedPassword($value).

-Nick

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.