We are migrating a site from 6.1.6 up to latest v7. The site is currently load balanced and we use machine keys in the environments (PROD, STAGE, TEST).
When I have been adding the Machine Key to upgraded version of the site (v7.2.4) - the admin user (all users) are not able to access the back-office. I have read the threads on the forum about the .net 4.5 Memebership Provider Hashing that is now done in Umbraco. We have a small enough editing base (20 editors) that a password reset for them is fine...but I seem to stuck in trying to just get the admin access to the back office when a new machine is added to the web.config.
Here is what I have tried. Login as admin user, add Machine Key to Web.config, this causes the App Pool to refresh though and so the admin user is logged out, and now the machine key is in the web.config but the hashing will not match, bc we were unable to update the admin password.
What are the steps / tips to be able to do this. I am sure this would happen on a fresh install as well, unless before you start the install you put in the desired machine key entries in the web.config. Are there any User service APIs we can use to update the password without being logged in?
Any recommedations would be greatly appreciated. We have been working at this but kind of feel like we are stuck in a Catch 22.
So after digging in further have got a better understanding of what is happening here and the order of how you may to do some stuff. I wrote a bunch of notes that I am just going to paste in here - hopefully it helps someone who may come across this in the future.
This was completed on 7.2.4 install. the word "password" was used in these tests as the password. Where you see "value of 'password'" is just the value as it stored in the dbo.umbracoUser table.
Use Legacy Encoding TRUE
This is the default style out of the box currently which keeps the old school .net Membership provider Hashing for passwords. It does not use the salt etc. So this "works" but is not entirely future proof if looking to keep upgrade paths in Umbraco (and it's not as secure). This works as well with a Machine Key defined in the Web.config as long as that Machine Key does not have the "IsolateApps" in the values. [See StackOverflow]
useLegacyEncoding="true" :: value of "password" /7IIcyNxAts3fvQYe2PI3d19cDU=
Use Legacy Encoding FALSE
No Unique Define Machine Key
This setting says to use the "new" Umbraco Membership Provider security settings for hashing and salting passwords. In this case we have no unique Machine Key defined. So this Hashed/Salted password uses a dynamically created Machine Key based on the App Path. [See Umbraco Thread]
useLegacyEncoding="false" :: value of "password" hSV3SmZPfJLCRFr0gGc5xw==R6QlpnPpJFG5sWNnxs+iuAmOdo0u7lmZmIacWQWmZto=
With Unique Machine Key
Log in first as LegacyEncoding set to True with a Machine Key defined in the web.config.
Once logged in, then change the useLegacyEncoding to "false" and save.
Go into back office (you should already be logged in) and then change the password. The resulting password save should now use your web.config Machine Key for the salt/hash password.
useLegacyEncoding="false" :: value of "password" ZRFkCKX2lACtKl/6CqsxVA==5k1JxuFfyNy2fyrFDX9V/jfAUn84gACM+odwFQu3/l0=
Note: If you use a unique Machine Key, which is probably the case in any Load Balanced Environment, then you have to use that same Machine Key setting in all Environments (DEV, TEST, STAGE, PROD). If not - you won;t be able to login to the back office.
Break in Case of Emergency
Once you go down the path of using a custom Machine Key in the web.config with your passwords, any change to that machine key's values will basically lock you out of accessing the back office (the hashing will no longer work). So, if you do need to "rollback" you could do the following to get back to a basic starting point.
Login to the back office.
In web.config, change the useLegacyEncoding to "true"
In back office now update the password. (It should save without looking at any machine keys for hashing). Your resulting Hashed password should be something like password originally set in the first section of this article.
Now you can go and follow the same steps as listed in "With Unique Machine Key"
Scenario: I have an existing project, that I now need to set a MachineKey for. Doing so means I cannot login into the backoffice.
Why has this happened?
You didn't define your MachineKeys at the beginning of your development project. / You are moving the application from one load balanced environment to another. / You didn't expect the application to be hosted in a load balanced environment.
Issue: The passwords stored in the database do not match the new Machine Key.
Solution: Setup a new Umbraco instance using the correct machineKey and then copy the values into your existing database.
Steps:
Create new VS Solution
Install UmbracoCms using NuGet
Build
Open the web.config file
Insert your new machineKey before </system.web>
Run solution (e.g. hit play!)
Setup Umbraco and set your Admin username and password
View the database using SQL Management Tools
View the dbo.umbracoUser table
Copy the values for: userName, userPassword, userEmail, securityStampToken
now... go to your existing project...
Open the web.config, and ensure you have set the machineKey
Ensure useLegacyEncoding is false
Open SQL Management Tools, select the assosicated database
Paste the values from your new Umbraco instance into the database
Viola! You now have admin access, and can update the other Users passwords :D
I've updated my previous blog post about this. It really comes down to the hashing algorithm used as the default and the hashing algorithm you add with your machine key
@Shazwazza there has to be a better way and some documentation. I have many sites and i can't upgrade or login to upgrade. What is the process? nuget usually fails and then I spend time patching and trying to get this to work. An upgrade should not be this complicated.
This seems like a completely unrelated issue. If you can't upgrade because you can't login it's usually because you changed the UsersMembershipProvider during web.config merging. This should will never work, for all of the reasons listed above. So the advise is: when you're upgrading, do not touch the UsersMembershipProvider.
The NuGet upgrade doesn't change this provider and in a manual upgrade you don't need to update it.
We purposely test this exact scenario for each(!) new version to make sure that you can upgrade without having login problems.
Anyway, this is unrelated to the topic of adding a machine key later in the process.
U7 Adding Machine Key for Load Balancing (How to?)
We are migrating a site from 6.1.6 up to latest v7. The site is currently load balanced and we use machine keys in the environments (PROD, STAGE, TEST).
When I have been adding the Machine Key to upgraded version of the site (v7.2.4) - the admin user (all users) are not able to access the back-office. I have read the threads on the forum about the .net 4.5 Memebership Provider Hashing that is now done in Umbraco. We have a small enough editing base (20 editors) that a password reset for them is fine...but I seem to stuck in trying to just get the admin access to the back office when a new machine is added to the web.config.
Here is what I have tried. Login as admin user, add Machine Key to Web.config, this causes the App Pool to refresh though and so the admin user is logged out, and now the machine key is in the web.config but the hashing will not match, bc we were unable to update the admin password.
What are the steps / tips to be able to do this. I am sure this would happen on a fresh install as well, unless before you start the install you put in the desired machine key entries in the web.config. Are there any User service APIs we can use to update the password without being logged in?
Any recommedations would be greatly appreciated. We have been working at this but kind of feel like we are stuck in a Catch 22.
So after digging in further have got a better understanding of what is happening here and the order of how you may to do some stuff. I wrote a bunch of notes that I am just going to paste in here - hopefully it helps someone who may come across this in the future.
This was completed on 7.2.4 install. the word "password" was used in these tests as the password. Where you see "value of 'password'" is just the value as it stored in the dbo.umbracoUser table.
Use Legacy Encoding TRUE
This is the default style out of the box currently which keeps the old school .net Membership provider Hashing for passwords. It does not use the salt etc. So this "works" but is not entirely future proof if looking to keep upgrade paths in Umbraco (and it's not as secure). This works as well with a Machine Key defined in the Web.config as long as that Machine Key does not have the "IsolateApps" in the values. [See StackOverflow]
useLegacyEncoding="true" :: value of "password" /7IIcyNxAts3fvQYe2PI3d19cDU=Use Legacy Encoding FALSE
No Unique Define Machine Key
This setting says to use the "new" Umbraco Membership Provider security settings for hashing and salting passwords. In this case we have no unique Machine Key defined. So this Hashed/Salted password uses a dynamically created Machine Key based on the App Path. [See Umbraco Thread]
useLegacyEncoding="false" :: value of "password" hSV3SmZPfJLCRFr0gGc5xw==R6QlpnPpJFG5sWNnxs+iuAmOdo0u7lmZmIacWQWmZto=With Unique Machine Key
useLegacyEncoding="false" :: value of "password" ZRFkCKX2lACtKl/6CqsxVA==5k1JxuFfyNy2fyrFDX9V/jfAUn84gACM+odwFQu3/l0=Note: If you use a unique Machine Key, which is probably the case in any Load Balanced Environment, then you have to use that same Machine Key setting in all Environments (DEV, TEST, STAGE, PROD). If not - you won;t be able to login to the back office.
Break in Case of Emergency
Once you go down the path of using a custom Machine Key in the web.config with your passwords, any change to that machine key's values will basically lock you out of accessing the back office (the hashing will no longer work). So, if you do need to "rollback" you could do the following to get back to a basic starting point.
Further to the excellent advice above:
Scenario: I have an existing project, that I now need to set a MachineKey for. Doing so means I cannot login into the backoffice.
Why has this happened?
You didn't define your MachineKeys at the beginning of your development project. / You are moving the application from one load balanced environment to another. / You didn't expect the application to be hosted in a load balanced environment.
Issue: The passwords stored in the database do not match the new Machine Key.
Solution: Setup a new Umbraco instance using the correct machineKey and then copy the values into your existing database.
Steps:
web.configfile</system.web>dbo.umbracoUsertableuserName, userPassword, userEmail, securityStampTokennow... go to your existing project...
machineKeyuseLegacyEncodingis falseViola! You now have admin access, and can update the other Users passwords :D
Laurie
It turns out you can add/change a machine key.
I've updated my previous blog post about this. It really comes down to the hashing algorithm used as the default and the hashing algorithm you add with your machine key
https://shazwazza.com/post/umbraco-passwords-and-aspnet-machine-keys
@Shazwazza there has to be a better way and some documentation. I have many sites and i can't upgrade or login to upgrade. What is the process? nuget usually fails and then I spend time patching and trying to get this to work. An upgrade should not be this complicated.
This seems like a completely unrelated issue. If you can't upgrade because you can't login it's usually because you changed the
UsersMembershipProviderduring web.config merging. This should will never work, for all of the reasons listed above. So the advise is: when you're upgrading, do not touch theUsersMembershipProvider.The NuGet upgrade doesn't change this provider and in a manual upgrade you don't need to update it.
We purposely test this exact scenario for each(!) new version to make sure that you can upgrade without having login problems.
Anyway, this is unrelated to the topic of adding a machine key later in the process.
is working on a reply...