"click the lock to make changes" not working

Frustrating for you 😐.

It's sounding increasingly like a keychain authentication issue. I know I've asked you this before, but what happens when you run Keychain First aid (cmd+alt+A from Keychain Access app)?

Also try:

1. Open Keychain Access and choose “Change Password for Keychain ‘login.'"
2. You’ll be asked to give your former password.
3. You should then be able to update it with a new password.

Hopefully the new password will do the trick.

Tried both, but neither of those two did make a difference.

Interestingly, when I try to verify a different user name than the one I am currently logged in with in Keychain First Aid, then I am also getting asked for my password and after inputting the correct password Keychain First aid logs "Could not obtain administrator privileges (-60008)"

Maybe this error message is telling you anything.

System Integrity Protection (which is controlled by csrutil) is a new security feature of El Capitan - something Yosemite and earlier didn't have - but while the kinks are still being worked out in beta it is causing some troubles. Try turning it off as follows:

1. Boot into Recovery Mode (cmd+R).
2. Utilities menu > Terminal > Type:

   csrutil disable

3. Reboot normally.

If that doesn't help, or when you want to enable it again, do the same as above but with csrutil enable instead.

Assuming it doesn't work, you might try making a TM backup using the tmutil command from Terminal. If you're not too familiar with Terminal manual pages, then you can consult a more user-friendly guide such as: http://computers.tutsplus.com/tutorials/controlling-time-machine-from-terminal--cms-22272

In fact, nearly everything (and more) that you would normally do via System Preferences after unlocking the padlock can be done with su or sudo from the Terminal.

csrutil disable did not help either, but I made an interesting observation:
When afterwards calling "csrutil status" in recovery mode, then it states "System Integrity Protection status: disabled", but when later on calling the same command in normal mode after restarting, then I get the following output:

"System Integrity Protection status: enabled (Custom Configuration).

Configuration:

Apple Internal: disabled

Kext Signing: disabled

Filesystem Protections: disabled

Debugging Restrictions: disabled

DTrace Restrictions: disabled

NVRAM Protections: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state."
Is that supposed to happen?

Yes, that's expected. Others have noticed it too and, indeed, I saw the same myself when testing it after Beta 8 came out. You may as well re-enable SIP.

I'm hoping you'll have more luck using Terminal commands to directly work around System Preferences until you do a complete erase and re-install.

Yeah, I know about the power and of terminal commands especially with su and sudo in unix-based OS and use the terminal in OS X a lot myself.
However it is most often very difficult to find the exact terminal equivalent for a certain System Preferencs setting and vice versa, as this seems to be considered an implementation detail by Apple - at least I could not find any detailed documentation yet, about how to find out the matching terminal commands and options for every System Preferences setting.

I wasn't suggesting you live with the Terminal as an alternative to using SysPref, just that it would allow you to make a TM backup etc. before erasing your drive and reinstalling.

Sorry, I somehow managed to overlook that sentence about tmutil. Indeed, as sudo-commands still work, tmutil might turn out to be a real life-saver. I will definitely give it a try. Thanks.

I could successfully start a backup to an external harddisk with tmutil. It will take a while to complete, of course. I will give you an update tomorrow. Thank you for all your help so far.

No problem 🙂

Fingers crossed.

Doing a time machine backup, completely erasing the disk, then reinstalling OS and doing a partial restore of the backup from time machine and afterwards manually moving files from the backup that time machine refused to include in the partial restore (it somehow insisted that it would not need to restore the data inside the Users/Shared folder and inside the user-folder of my main-account, so I had to manually restore that data and fix permissions for them to get my main account back to work) fixed the issue.

Thank you for all your help.

Glad it's sorted for you 🙂