ExternalAuth, local users, and upgrade woes

yan_seiner1 · November 8, 2011, 3:27pm

Yesterday we upgraded our RT instance to 4.0.2. Before then we were
running 3.8.10 in production, and 4.0.2 in testing.

We had 4.0.2 set up in testing with ExternalAuth. That worked well; our
LDAP users could log in with their credentials. I could create non-LDAP
users manually (which is the setup I wanted).

Then we moved the database from the server hosting 3.8.10 to our new 4.0.2
server. Everything went well, except that non-LDAP users cannot log in.
Further, I cannot change their password.

When I try to change their password, I get

Please enter your current password correctly. Password has not been set.

I tried creating a user manually. Same thing; I can create the user but
cannot set the password.

This worked fine in the 4.0.2 test but started happening after we moved
the 3.8.10 database over to 4.0.2. I did use the procedures in the README
and otherwise the new installation is working great.

Where do I look?

Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

Izz_Abdullah · November 8, 2011, 3:31pm

I’ve seen this on our system. When you move the database and are using external authentication, you, at least I am able, to login with either my MySQL credentials, or my LDAP credentials. When modifying / adding users, I have to put in my MySQL password for this to work for local users. I would try using the password you used in 3.8.10 installation on the new system as the current password to see if that fixes your problem.-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Yan Seiner
Sent: Tuesday, November 08, 2011 9:28 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] ExternalAuth, local users, and upgrade woes

Yesterday we upgraded our RT instance to 4.0.2. Before then we were
running 3.8.10 in production, and 4.0.2 in testing.

We had 4.0.2 set up in testing with ExternalAuth. That worked well; our
LDAP users could log in with their credentials. I could create non-LDAP
users manually (which is the setup I wanted).

Then we moved the database from the server hosting 3.8.10 to our new 4.0.2
server. Everything went well, except that non-LDAP users cannot log in.
Further, I cannot change their password.

When I try to change their password, I get

Please enter your current password correctly. Password has not been set.

I tried creating a user manually. Same thing; I can create the user but
cannot set the password.

This worked fine in the 4.0.2 test but started happening after we moved
the 3.8.10 database over to 4.0.2. I did use the procedures in the README
and otherwise the new installation is working great.

Where do I look?

Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

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

Barcelona, Spain November 28 & 29, 2011

yan_seiner1 · November 8, 2011, 3:49pm

That worked!

Interesting…

Any way to remove the mysql password?On Tue, November 8, 2011 7:31 am, Izz Abdullah wrote:

I’ve seen this on our system. When you move the database and are using
external authentication, you, at least I am able, to login with either my
MySQL credentials, or my LDAP credentials. When modifying / adding users,
I have to put in my MySQL password for this to work for local users. I
would try using the password you used in 3.8.10 installation on the new
system as the current password to see if that fixes your problem.

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Yan Seiner
Sent: Tuesday, November 08, 2011 9:28 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] ExternalAuth, local users, and upgrade woes

Yesterday we upgraded our RT instance to 4.0.2. Before then we were
running 3.8.10 in production, and 4.0.2 in testing.

We had 4.0.2 set up in testing with ExternalAuth. That worked well; our
LDAP users could log in with their credentials. I could create non-LDAP
users manually (which is the setup I wanted).

Then we moved the database from the server hosting 3.8.10 to our new 4.0.2
server. Everything went well, except that non-LDAP users cannot log in.
Further, I cannot change their password.

When I try to change their password, I get

Please enter your current password correctly. Password has not been set.

I tried creating a user manually. Same thing; I can create the user but
cannot set the password.

This worked fine in the 4.0.2 test but started happening after we moved
the 3.8.10 database over to 4.0.2. I did use the procedures in the README
and otherwise the new installation is working great.

Where do I look?

–
Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

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

Barcelona, Spain November 28 & 29, 2011

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

Barcelona, Spain November 28 & 29, 2011

!DSPAM:4eb94b64141411804284693!

Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

Izz_Abdullah · November 8, 2011, 3:54pm

What I did, and it may be a “no-no”, is
update Users set Password=“” where username = something <excuse the syntax as the column / table names may differ slightly>

But this worked and forced External Authentication only. I had to do it directly to the mysql db though.From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Yan Seiner
Sent: Tuesday, November 08, 2011 9:49 AM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] ExternalAuth, local users, and upgrade woes

That worked!

Interesting…

Any way to remove the mysql password?

Ruslan_Zakirov1 · November 8, 2011, 7:08pm

Direct db access in this case is ok. Have you sent a bug report?

Regards, Ruslan. From phone.

написал:

Izz_Abdullah · November 8, 2011, 7:11pm

No, I haven’t. It makes sense to me that the old authentication was local (mysql) and the new authentication is external (LDAP for example) that if the username is the same, you should be able to use either. It doesn’t make sense, however, that it requires the local password for administration (enter current password: ).
I also didn’t submit a bug report, because the installation here was so messed up, I wasn’t sure it wasn’t just local until someone else just now asked about it.

But yeah, setting the password = ‘’ actually forces the external authentication (trying to login with a blank password does NOT work).From: ruslan.zakirov@gmail.com [mailto:ruslan.zakirov@gmail.com] On Behalf Of Ruslan Zakirov
Sent: Tuesday, November 08, 2011 1:08 PM
To: Izz Abdullah
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] ExternalAuth, local users, and upgrade woes

Direct db access in this case is ok. Have you sent a bug report?

Regards, Ruslan. From phone.

What I did, and it may be a “no-no”, is
update Users set Password=“” where username = something <excuse the syntax as the column / table names may differ slightly>

But this worked and forced External Authentication only. I had to do it directly to the mysql db though.

From: rt-users-bounces@lists.bestpractical.com mailto:rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Yan Seiner
Sent: Tuesday, November 08, 2011 9:49 AM
To: rt-users@lists.bestpractical.com mailto:rt-users@lists.bestpractical.com
Subject: Re: [rt-users] ExternalAuth, local users, and upgrade woes

That worked!

Interesting…

Any way to remove the mysql password?

Thomas_Sibley · November 8, 2011, 7:17pm

But yeah, setting the password = ‘’ actually forces the external
authentication (trying to login with a blank password does NOT work).

I believe properly the password column should be ‘NO-PASSWORD’ not the
empty string.

Thomas

Izz_Abdullah · November 8, 2011, 7:18pm

I thought about that, but didn’t try it. I thought it may would have interpreted the password = NO-PASSWORD rather than interpreting it as not having a password. =)-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Thomas Sibley
Sent: Tuesday, November 08, 2011 1:17 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] ExternalAuth, local users, and upgrade woes

On 11/08/2011 02:11 PM, Izz Abdullah wrote:

But yeah, setting the password = ‘’ actually forces the external
authentication (trying to login with a blank password does NOT work).

I believe properly the password column should be ‘NO-PASSWORD’ not the
empty string.

Thomas
RT Training Sessions (http://bestpractical.com/services/training.html)

Barcelona, Spain November 28 & 29, 2011

Ruslan_Zakirov1 · November 8, 2011, 8:41pm

But yeah, setting the password = ‘’ actually forces the external
authentication (trying to login with a blank password does NOT work).

I believe properly the password column should be ‘NO-PASSWORD’ not the
empty string.

RT::User has method to check if password is set or not, it supports a
few cases. I think ExternalAuth doesn’t use it and a bug was reported.

Thomas

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

Barcelona, Spain November 28 & 29, 2011

Best regards, Ruslan.

yan_seiner1 · November 9, 2011, 12:03am

But yeah, setting the password = ‘’ actually forces the external
authentication (trying to login with a blank password does NOT work).

I believe properly the password column should be ‘NO-PASSWORD’ not the
empty string.

RT::User has method to check if password is set or not, it supports a
few cases. I think ExternalAuth doesn’t use it and a bug was reported.

As near as I can figure, when we merged the two databases the user table
got smashed together.

In 3.8.10, all users were local to the RT instance (all data stored in
mysql). In 4.0.2, we went with AD authentication (ExternalAuth/LDAP).
Somehow the user table must have gotten corrupted. None of my local users
can log in. I cannot create local users. Most of my ExternalAuth users
are OK, except for a few who cannot log in with their ExternalAuth
credentials, but can with their mysql credentials.

I only have about 20 active users, so it’s not a big deal to clean it out
and start over if I need to.

We went live this week and I need to fix this quickly. At this point I
can delete all the users if need be and have them start over.

What is the best way to proceed?

Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

Thomas_Sibley · November 9, 2011, 2:07pm

As near as I can figure, when we merged the two databases the user table
got smashed together.

How did you merge the databases?

There is no existing tool to do a merge properly and doing it manually
is not trivial even with a good understanding of the schema.

Thomas

yan_seiner1 · November 9, 2011, 3:31pm

As near as I can figure, when we merged the two databases the user table
got smashed together.

How did you merge the databases?

There is no existing tool to do a merge properly and doing it manually
is not trivial even with a good understanding of the schema.

I think “merge” was not the right thing to say. We migrated the old
database to the new database using the instructions in the README. We
threw away our 4.0 test database.

I think the problem is that we had user XXX in the 3.8 database as a local
user and in the 4.0 database user XXX was LDAP external auth. Everything
else works fine; just my local mysql users cannot log in and I can create
them but not give them passwords.

Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

Izz_Abdullah · November 9, 2011, 3:34pm

This is exactly the scenario here. Except, the old MySQL accounts, I can login with either the MySQL credentials or the LDAP credentials (note the username is the same for both by convention for us). If you want to use MySQL login, did you add that as a secondary path of authentication in your SiteConfig file? I didn’t want this option, but seems like when using ExternalAuth, if you wanted to allow local login / MySQL, you have to configure that as well in the config file. I could be wrong.-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Yan Seiner
Sent: Wednesday, November 09, 2011 9:31 AM
To: Thomas Sibley
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] ExternalAuth, local users, and upgrade woes

On Wed, November 9, 2011 6:07 am, Thomas Sibley wrote:

On 11/08/2011 07:03 PM, Yan Seiner wrote:

As near as I can figure, when we merged the two databases the user table
got smashed together.

How did you merge the databases?

There is no existing tool to do a merge properly and doing it manually
is not trivial even with a good understanding of the schema.

I think “merge” was not the right thing to say. We migrated the old
database to the new database using the instructions in the README. We
threw away our 4.0 test database.

I think the problem is that we had user XXX in the 3.8 database as a local
user and in the 4.0 database user XXX was LDAP external auth. Everything
else works fine; just my local mysql users cannot log in and I can create
them but not give them passwords.

Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

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

Barcelona, Spain November 28 & 29, 2011

yan_seiner1 · November 9, 2011, 3:47pm

This is exactly the scenario here. Except, the old MySQL accounts, I can
login with either the MySQL credentials or the LDAP credentials (note the
username is the same for both by convention for us). If you want to use
MySQL login, did you add that as a secondary path of authentication in
your SiteConfig file? I didn’t want this option, but seems like when
using ExternalAuth, if you wanted to allow local login / MySQL, you have
to configure that as well in the config file. I could be wrong.\

The local user/LDAP user thing worked fine when we tested 4.0 (built from
scratch). We could create local users and autocreate LDAP users.

We use the same SiteConfig file for the migrated 3.8->4.0 database, and
the users don’t work correctly.

I’m trying to get phpmyadmin working right now so I can look at the tables
and see what’s going on. (Another story; apache is being subborn but
that’s not for this list.)

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Yan Seiner
Sent: Wednesday, November 09, 2011 9:31 AM
To: Thomas Sibley
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] ExternalAuth, local users, and upgrade woes

As near as I can figure, when we merged the two databases the user
table
got smashed together.

How did you merge the databases?

There is no existing tool to do a merge properly and doing it manually
is not trivial even with a good understanding of the schema.

I think “merge” was not the right thing to say. We migrated the old
database to the new database using the instructions in the README. We
threw away our 4.0 test database.

I think the problem is that we had user XXX in the 3.8 database as a local
user and in the 4.0 database user XXX was LDAP external auth. Everything
else works fine; just my local mysql users cannot log in and I can create
them but not give them passwords.

–
Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

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

Barcelona, Spain November 28 & 29, 2011

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

Barcelona, Spain November 28 & 29, 2011

!DSPAM:4eba9dac253411804284693!

Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

Kevin_Falcone · November 9, 2011, 4:49pm

If you want to use MySQL login, did you add that as a secondary path
of authentication in your SiteConfig file? I didn’t want this option,
but seems like when using ExternalAuth, if you wanted to allow local
login / MySQL, you have to configure that as well in the config file.

This is false - RT-Authen-ExternalAuth falls back to the internal
mysql password if it cannot log you in with the configured LDAP
sources. You should not configure RT-Authen-ExternalAuth to look
directly at the Users table, it is unnecessary.

If you’re having trouble managing RT internal users while logged in as
an LDAP user, please see Ruslan’s response about possible bugs. Try
logging in as root and seeing if that helps.

-kevin

yan_seiner1 · November 9, 2011, 5:01pm

If you’re having trouble managing RT internal users while logged in as
an LDAP user, please see Ruslan’s response about possible bugs. Try
logging in as root and seeing if that helps.

Is the bug report public? If so, where?

Thanks!

Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

Kevin_Falcone · November 9, 2011, 5:10pm

If you’re having trouble managing RT internal users while logged in as
an LDAP user, please see Ruslan’s response about possible bugs. Try
logging in as root and seeing if that helps.

Is the bug report public? If so, where?

If there is an existing bug report it would be in the rt.cpan.org
queue for RT-Authen-ExternalAuth. If there is no report, please make
one.

-kevin

yan_seiner1 · November 9, 2011, 5:45pm

If you’re having trouble managing RT internal users while logged in as
an LDAP user, please see Ruslan’s response about possible bugs. Try
logging in as root and seeing if that helps.

Is the bug report public? If so, where?

If there is an existing bug report it would be in the rt.cpan.org
queue for RT-Authen-ExternalAuth. If there is no report, please make
one.

I’ve been poking around in the databases…

In the virgin RT4 database (the one we created from scratch) the password
field is varchar(256).

In the converted RT3->RT4 database the password field is varbinary(40).

In the original RT3 database, the password field is varbinary(40).

I don’t know enough about mysql but that doesn’t seem right. Can some
mysql gurus clue me in?

Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

Izz_Abdullah · November 9, 2011, 5:48pm

That is odd. The migrate database should have set it to varchar(256), at least that is how our mysql database, imported 3.8.6 and upgraded to 4.0.2, is on the password field as well. Did you have any errors on the migration sequence?-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Yan Seiner
Sent: Wednesday, November 09, 2011 11:45 AM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] ExternalAuth, local users, and upgrade woes

On Wed, November 9, 2011 9:10 am, Kevin Falcone wrote:

On Wed, Nov 09, 2011 at 09:01:01AM -0800, Yan Seiner wrote:

On Wed, November 9, 2011 8:49 am, Kevin Falcone wrote:

If you’re having trouble managing RT internal users while logged in as
an LDAP user, please see Ruslan’s response about possible bugs. Try
logging in as root and seeing if that helps.

Is the bug report public? If so, where?

If there is an existing bug report it would be in the rt.cpan.org
queue for RT-Authen-ExternalAuth. If there is no report, please make
one.

I’ve been poking around in the databases…

In the virgin RT4 database (the one we created from scratch) the password
field is varchar(256).

In the converted RT3->RT4 database the password field is varbinary(40).

In the original RT3 database, the password field is varbinary(40).

I don’t know enough about mysql but that doesn’t seem right. Can some
mysql gurus clue me in?

Pain is temporary. It may last a minute, or an hour, or a day, or a year,
but eventually it will subside and something else will take its place. If
I quit, however, it lasts forever.

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

Barcelona, Spain November 28 & 29, 2011

Kevin_Falcone · November 9, 2011, 5:55pm

If you’re having trouble managing RT internal users while logged in as
an LDAP user, please see Ruslan’s response about possible bugs. Try
logging in as root and seeing if that helps.

Is the bug report public? If so, where?

If there is an existing bug report it would be in the rt.cpan.org
queue for RT-Authen-ExternalAuth. If there is no report, please make
one.

I’ve been poking around in the databases…

In the virgin RT4 database (the one we created from scratch) the password
field is varchar(256).

In the converted RT3->RT4 database the password field is varbinary(40).

In the original RT3 database, the password field is varbinary(40).

I don’t know enough about mysql but that doesn’t seem right. Can some
mysql gurus clue me in?

It looks like you didn’t run the database upgrade scripts.
On 4.0.3 after running make upgrade it should tell you about
make upgrade-database. There is a step that the automated process
runs which converts you to a varchar(256).

There are a lot of important changes between 3.8 and 4.0 that happen
at the database level, including lots of new columns and tables.

-kevin