add notes to create an emergency user

[1letter]

i created a subdirectory for users and groups and add a file with a short description to create an emergency user in a pip and buildout based installation of Plone.

Closes #948
Closes #1702

• https://plone6--1703.org.readthedocs.build/admin-guide/index.html
• https://plone6--1703.org.readthedocs.build/admin-guide/add-emergency-user.html

---

📚 Documentation preview 📚: https://plone6--1703.org.readthedocs.build/

[1letter]

@stevepiercy can you check wording and spelling please?

[stevepiercy]

I merged content from Plone 5 documentation, and added an introduction for each scenario.

There was one sentence remaining that confuses me. Please see my review comment. Thank you!

[stevepiercy]

What would someone do in a Production environment? Are they out of luck?

[1letter]

Of course, you can do this operations in a production env, but you should not do this. ;-)

[stevepiercy]

What should someone do in production instead? We can't say "don't do this", then in the next section say "do this". It's very confusing.

Perhaps you can include what are the consequences and risks of doing this in production, aside from the obvious, specifically that the site will be down while adding the emergency user.

[stevepiercy]

@1letter can you answer the following questions? I want to move this PR forward.

1. What should someone do in production instead?
2. If someone does this in production, what are the risks?
3. In which environments is it OK to do this?

[ale-rt]

I think I addressed these issues with #1854

I decided to talk about "Zope Manager Users", which IMO it is more appropriate than "Emergency users"
I added a note about taking in to account the security implication of adding a Zope manager user.

[acsr]

@ale-rt @stevepiercy I like the change to extend the scope to "Zope Manager Users" and mention the "Emergency user", but the traditional term "Emergency user" should be highlighted in the text to reflect the purpose in production!

I added this here, because of the context of the suggestion by @stevepiercy in my discussions with him and seperately with @jensens.

But it needs to be seen also in context of the current preview:
https://plone6--1703.org.readthedocs.build/admin-guide/add-emergency-user.html

I would also enhance two things:

1. Do not tag admin:admin "as usual":

It is OK to use that for an instance fired up for testing and to be destroyed at once or soon or later before going to production. But it should be mentioned and made clear that for instances installed ending in production the password should be changed before anything goes into persistence. The consequences might be not obvious, but even behind a proxy the ZMI root may be reachable (like with Volto) and can lead to a permanent backdoor not easy to discover even not using admin:admin.

Imagine a different user:password than admin/admin and the sysadmin / integrator changes and the httpauth in the ZMI backend is not changed or restored from a backup. Then an in fact unauthorízed person can try to gain access with these hardcoded credentials.

2. Prominent warning to immediately change default credentials

There should be a prominent warning

• to immediately change these credentials and
• pack the database before going into production.

Further considerations

3. @1letter completely denied to use this in production.

I am contrary because the emergency user purpose is still valid for emergency use cases like changed admins or lost credentials. The Challenge in production is, that the user is persistent in the database and therefore also in backups. So old backups are still accessible with the old credentials when restored without proper awareness and documentation of changes in access credentials including point in time.

4. Revamp random password as default

In the past there was an approach that the installers created a random password and wrote it into the filesystem when the initial password was not specified during install.

When you removed the file, took a note in your password manager and changed the password at once no traces were left. Today these ways are deeply buried in e.g. docker containers and not easy to handle.

Maybe this is a trap in automated deployments

ongoing work on this

I am working on writing this up for cookieplone based docker deployments, but it is too early and would block the release of this PR. This can be added later.

[ale-rt]

The traditional term "Emergency user" should be highlighted in the text to reflect the purpose in production!

Do you have suggestion on how to do that?

So old backups are still accessible with the old credentials when restored without proper awareness and documentation of changes in access credentials including point in time.

Uhm maybe here I am missing something. When you have access to the DB you can anyway change the password manually there. So I do not consider this a real issues.

In the past there was an approach that the installers created a random password and wrote it into the filesystem when the initial password was not specified during install.

I think this is extending the scope of this PR.

I am working on writing this up for cookieplone based docker deployments, but it is too early and would block the release of this PR. This can be added later.

Agreed!

[acsr]

So old backups are still accessible with the old credentials when restored without proper awareness and documentation of changes in access credentials including point in time.

@ale-rt The issue in my deployments was in place because the Cookieplone project template sets up a Traefik that creates a basicauth middleware and is created by a label in the docker swarm stack service backend.

In my early attempts I tried to modify the deployment in the docker-compose.yml file, but the changes had no effect and seemed to be ignored in the redeployment.

Today @pbauer, @tlotze and me went through the training docs for the deployment and weeded out lots of pitfalls in order of execution and issues related to images missing on the arm platform for servers.

During these attempts it became clear that the initial modifications during setup were rolled out into the yml file in devops/stacks/ named after the hostname. Making the changes in this file allows to change the http basicauth of the middleware that overrides the password of the actual ZMI user "admin". Other additional Zope admins or so called "emergengy users" were not affected. The ZMI "admin" users password could be changed successfully in the ZMI but had no effect in this setup behind Traefik. Keep in mind that this user has an ID admin and a seperate name admin that can be changed and should not be mixed up.

That said, the origin of the "persistent" basicauth is discovered and therefore the Cookieplone docs needs to be updated to point to the place for changing that.

[stevepiercy]

@1letter would you please respond to @davisagli's suggestions?

Let's get this finished and published!

[ale-rt]

Here are direct links to the RTD pull request preview:

• https://plone6--1703.org.readthedocs.build/backend/users-groups/index.html
• https://plone6--1703.org.readthedocs.build/backend/users-groups/emergency-user.html

Those are now:

• https://plone6--1703.org.readthedocs.build/admin-guide/index.html
• https://plone6--1703.org.readthedocs.build/admin-guide/add-emergency-user.html

[acsr]

@stevepiercy I dump this here until final decision where to put this

[[Draft]] Emergency User Creation in dockerized setup

I can confirm that the following procedure works for me on a running docker swarm instance for the full featured docker based Plone Volto deployment created by current Cookieplone project template including postgres, traefik, varnish:

How to create a new Zope Manager User with a non existing user-ID

1. Enter the host via ssh as root
2. list the running containers: docker ps
3. enter a shell in the first backend container listed: docker exec -it [[4-digitPartOfID]] bash
4. run command in the app folder: ./docker-entrypoint.sh bin/addzopeuser -c /app/etc/relstorage.conf admin3 plone
5. Response: User admin3 created

The user is now available in the ZMI root at at /acl_users/users/manage_users

• In Volto use the url /ClassicUI/aq_parent/acl_users/users/manage_users

What I did not test now

• Execute the command in an entrypoint / overlay container with or without running backend / database
  Advice is maybe available via @jensens

Notes on permissions

• Check permissions in the ZMI root at /acl_users/manage_access and search for admin3
• In Volto use the url /ClassicUI/aq_parent/acl_users/manage_access
• The new user has Manager role, but not Owner role and no Take ownership permission
• You can add the Owner role in the ZMI root manually, but only as the original admin user

^^updated below [[20250214]] 15:40 acsr^^

Remark on httpauth challenges for the ZMI admin user in Cookieplone based Volto and ClassicUI projects using Traefik

The original cookieplone-template project mentioned in my README.md as Cookieplone (0.8.2) and cookiecutter-plone (d9b5293) includes a traefik middleware mw-backend-auth in the docker-compose.yaml service backend Labels section. This httpauth may override the ZMI httpauth for the original admin user-id.

To change the Traefik middleware basicauth password edit the yaml file in devops/stacks/[hosturl].yml named after the hostname and follow the instructions in the comments for mw-backend-auth to create a proper hash and redeploy the project.

Test the result in fresh incognito windows!

• in the ZMI root
• at the Plonelogin

How this has impact on the Plone Volto login needs testing in your particular setup.

[ale-rt]

Note that I would like to rename the file name to match its actual content: #1859

[ale-rt]

@acsr please check this #1703 (comment), I think that #1860 will better fit your comments.

Anyway I have planned a call with @stevepiercy in a few minutes

[acsr]

See #1703 (comment)

[acsr]

It seems my comment was not saved:
Please reopen this Pull Request after an initial release and we can start to add add my updated stuff for docker deployments #1703 (comment)

Updated below the mark

[davisagli]

LGTM.

We should also add instructions on how to do this in the plone-backend Docker image, based on @acsr's notes -- but this already helps fill the gap and we shouldn't delay merging what is already here.

[stevepiercy]

I'll fix the mistaken deletion.

I have another PR #1867 that I will merge into this one, once it is all green.

[stevepiercy]

I merged PR #1867.

Once this passes CI, and I double check the PR preview build, I will merge.

[stevepiercy]

@acsr would you please open a new PR with your suggestions? Sorry, I can't make sense of it, as I don't have experience with the situation you describe.

[acsr]

@acsr would you please open a new PR with your suggestions? Sorry, I can't make sense of it, as I don't have experience with the situation you describe.

Done: #1869