Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
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.
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=
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=
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.
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:
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.
userName, userPassword, userEmail, securityStampToken
now... go to your existing project...
Viola! You now have admin access, and can update the other Users passwords :D
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
@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.
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted