Admin password not working after upgrade (7.10.3 to 7.15.7)
A client from long ago recently resurfaced. After getting the dev server propped back up with the latest content, I'm attempting to upgrade from 7.10.3 to 7.15.7. I've gotten to the point of running the DB upgrade, but none of my admin accounts are working. I've set the uselegacyencoding to true, bumped down the minRequiredPasswordLength back to 8, abnd confirmed that the accounts haven't been locked out. I've even tried changing the password on production and then copying the new values from production's user table to dev's; no luck.
Do you setup the 7.10.3 site locally on your machine 'first'? or are you attempting to upgrade only the database to a vanilla 7.15.7 solution?
If you setup the 7.10.3 site on your local machine, can you login with the admin account? and if you have SMTP setup, can you 'reset' a password on your machine using 7.10.3? Before you attempt upgrade.
Now the other thing that can affect versions of Umbraco in different environments and the hash used to encrypt the password, is I think the Machine Key - there is an article here that, explains a bit about it...
The gist is perhaps there is a difference in the algorithm type of the validation part of the Machine Key, which can be different between different environments and .net framework versions - so is the production site running under a different version of .net than on your local machine?
If you can login successfully in 7.10.3 on your machine, then make a note of the Membership Provider settings in the Web.Config for the Users membership provider. eg the value of useLegacyEncoding... basically you shouldn't need to 'change' this value, if it's set to true, leave it set to true, if it's set to false, leave it set to false!
Anyway, the slight secret 'trick' here, is that if you 'login' as an Admin to the Umbraco Backoffice on the local url you are running under in 7.10.3, you will set a cookie on your machine for the session accessing the backoffice, if you quickly Nuget upgrade to 7.15.7, and visit the site to trigger the upgrade... your freshly baked cookie will not require you to login to trigger those upgrade steps... and the upgrade will continue.
If your NuGet upgrade updates the Users Membership Provider, then you'll want to see what it's changing, and revert settings like useLegacyEncoding to match what you had before.
This setup is so old I no longer have a local copy; just the dev and prod servers. I'm doing the upgrades manually. Both machines are on the same version of .NET (4.8.3761). There's an update on that article stating that the Machine Key is NOT part of the hash -
the key used to hash the passwords is the generated salt we produce it
is not the key part of the Machine Key.
So sadly, I'm still stuck on square one.
Another interesting bit: I switched the connection string on the 7.10.3 codebase (living on production, late at night) to point to the dev DB that was rejecting my passwords, and they work fine there.
As you've determined your issue isn't to do with the upgrade!
It's to do with the different environments, eg your 7.10.3 on live can connect to the dev db, so it's how the environments are hashing the password, rather than an upgrade issue.
WIth the paragraph you quote about the machine key not being relevant, it goes on to say:
The part of the Machine Key that is used to hash the passwords is
specifically the algorithm type. As you can see on this machine key
generator, there can be a handful of different algorithm types used
for the ‘validation’ part of a machine key and the default of this
value changes based on the ASP.NET version being used. In ASP.NET 4.5
the default is HMACSHA256. Also note that in ASP.NET 4.5 the following
algorithms are no longer allowed in the Machine Key config: AES, 3DES,
and MD5
That was the bit that made me think .net version... and ask about the Machine Key - even on the same version they 'could' have different algorithm type set - although I guess pretty unlikely!
Be interesting to see if you had a vanilla version of 7.10.3 on your machine, and you setup an Admin user with the same password as the existing site, what the 'hash' in the database table would be... and you could perhaps use that to get around the problem!
Yes, you can always reset the password hash of an umbracoUser in the umbracoUsers table to match a password that you know works on that particular server via SQL.
or you can setup SMTP, and trigger a password reset email to be set.
or there is an official way to reset the password described here:
Admin password not working after upgrade (7.10.3 to 7.15.7)
A client from long ago recently resurfaced. After getting the dev server propped back up with the latest content, I'm attempting to upgrade from 7.10.3 to 7.15.7. I've gotten to the point of running the DB upgrade, but none of my admin accounts are working. I've set the uselegacyencoding to true, bumped down the minRequiredPasswordLength back to 8, abnd confirmed that the accounts haven't been locked out. I've even tried changing the password on production and then copying the new values from production's user table to dev's; no luck.
What obvious step am I missing?
Hi Andrew
How are you upgrading?
Do you setup the 7.10.3 site locally on your machine 'first'? or are you attempting to upgrade only the database to a vanilla 7.15.7 solution?
If you setup the 7.10.3 site on your local machine, can you login with the admin account? and if you have SMTP setup, can you 'reset' a password on your machine using 7.10.3? Before you attempt upgrade.
Now the other thing that can affect versions of Umbraco in different environments and the hash used to encrypt the password, is I think the Machine Key - there is an article here that, explains a bit about it...
https://shazwazza.com/post/umbraco-passwords-and-aspnet-machine-keys
The gist is perhaps there is a difference in the algorithm type of the validation part of the Machine Key, which can be different between different environments and .net framework versions - so is the production site running under a different version of .net than on your local machine?
If you can login successfully in 7.10.3 on your machine, then make a note of the Membership Provider settings in the Web.Config for the Users membership provider. eg the value of useLegacyEncoding... basically you shouldn't need to 'change' this value, if it's set to true, leave it set to true, if it's set to false, leave it set to false!
Anyway, the slight secret 'trick' here, is that if you 'login' as an Admin to the Umbraco Backoffice on the local url you are running under in 7.10.3, you will set a cookie on your machine for the session accessing the backoffice, if you quickly Nuget upgrade to 7.15.7, and visit the site to trigger the upgrade... your freshly baked cookie will not require you to login to trigger those upgrade steps... and the upgrade will continue.
If your NuGet upgrade updates the Users Membership Provider, then you'll want to see what it's changing, and revert settings like useLegacyEncoding to match what you had before.
Hope that helps!
regards
Marc
Thanks for the reply.
This setup is so old I no longer have a local copy; just the dev and prod servers. I'm doing the upgrades manually. Both machines are on the same version of .NET (4.8.3761). There's an update on that article stating that the Machine Key is NOT part of the hash -
So sadly, I'm still stuck on square one.
Another interesting bit: I switched the connection string on the 7.10.3 codebase (living on production, late at night) to point to the dev DB that was rejecting my passwords, and they work fine there.
Hi Andrew
Not quite square one!
As you've determined your issue isn't to do with the upgrade!
It's to do with the different environments, eg your 7.10.3 on live can connect to the dev db, so it's how the environments are hashing the password, rather than an upgrade issue.
WIth the paragraph you quote about the machine key not being relevant, it goes on to say:
That was the bit that made me think .net version... and ask about the Machine Key - even on the same version they 'could' have different algorithm type set - although I guess pretty unlikely!
https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.machinekeysection.validationalgorithm?view=netframework-4.8
Be interesting to see if you had a vanilla version of 7.10.3 on your machine, and you setup an Admin user with the same password as the existing site, what the 'hash' in the database table would be... and you could perhaps use that to get around the problem!
regards
Marc
Hmmm.
I'm not so sure we've really ruled out the upgrade being the cause of the problem.
I wound up copying the 7.15.7 codebase from the dev server into a new website hosted on the production machine- pointing to the dev DB.
The good news - the upgrade went through and the DB upgraded! Woo-hoo!
Except... once it did, I still couldn't log in to the back end.
So now I have an upgraded site, but no way to log in.
Any thoughts on how to work around this? Can I change the password in the DB somehow to regain access?
HI Andrew
Yes, you can always reset the password hash of an umbracoUser in the umbracoUsers table to match a password that you know works on that particular server via SQL.
or you can setup SMTP, and trigger a password reset email to be set.
or there is an official way to reset the password described here:
https://our.umbraco.com/Documentation/Reference/Security/reset-admin-password-v7 which leads to: https://our.umbraco.com/Documentation/Reference/Security/reset-admin-password (just remember to use 0 and not -1)
regards
Marc
is working on a reply...