Document which user roles are needed for which actions

[leegarrett]

Please document the roles you can assign to a freshly created user more extensively:

• Vollzugriff
• Abrechnung
• Domainverwaltung
• Hosting
• DNS-Verwaltung
• Auth-Code

Also document which permissions are needed for the respective certbot challenges.

I noticed that the certbot DNS-01 challenge fails (#28) when only having the permission "DNS-Verwaltung", which from the description should be enough for creating the _acme-challenge.example.com TXT record, and reading any records (which should not need any permission at all, IMHO, since those are public). However, these permissions don't seem to be enough. Setting "Vollzugriff" worked around the problem, but of course ideally I want the minimum possible permissions to do the job.

[sebkur]

I just experienced #28 too and solved it by granting full access to my API user. It does not sound optimal to have the API user granted full permissions. The user name and password is stored in the configuration file. If an attacker gets access to that, it's bad enough, however if the credentials are for a user with limited permissions, damage that can be done is restricted. I'm wondering however if this is a problem of this program or rather a problem on INWX's side of things. Can we figure out which call to the API this plugin is doing and check manually (using curl?) whether we can successfully perform that action on the API depending on the permissions granted? I think that would be a first step to figure out where the problem is.

[sebkur]

I'm guessing it's probably https://www.inwx.de/en/help/apidoc/f/ch02s15.html#nameserver.createRecord that we need

[sebkur]

OK, I checked out the specific API call using the Python client. Turns out in order to perform the createRecord call successfully, one needs the user to have the role "Domainverwaltung", not just "DNS-Verwaltung".

Here are the descriptions mentioned in the INWX user management:

DNS-Verwaltung

Diese Rolle erlaubt es, DNS-Einträge zu verwalten sowie DNSSEC und DynDNS zu konfigurieren.

Deepl translation: This role allows to manage DNS records and to configure DNSSEC and DynDNS.

Domainverwaltung

Diese Rolle erlaubt es, Domaineinstellungen wie Nameserver, Domainkontakte und DNSSEC zu verwalten, außerdem können DNS-Einträge verwaltet werden. Nutzer mit dieser Rolle sind jedoch nicht berechtigt, Domains zu löschen, ausgehende Transfers durchzuführen oder neue Domains zu registrieren oder zu transferieren.

Deepl translation: This role allows to manage domain settings such as name servers, domain contacts and DNSSEC, also DNS records can be managed. However, users with this role are not allowed to delete domains, perform outbound transfers, or register or transfer new domains.

---

When I initially saw the names of the roles in the config screen, my first impulse was to assign the "DNS-Verwaltung" role, which didn't work. I now switched to the "Domainverwaltung" role only and that makes certbot succeed in obtaining wildcard certificates! 🎉

[leegarrett]

Two days ago I removed all roles for the API user, and DNS-01 challenge still works (use --force-renewal -vvvv). So it seems like the whole user management is broken.

[sebkur]

OK, strange. On my end, when I remove all roles, I can also no longer use the INWX API. I try with the python API directly and have created a small example script that just adds a TXT record with content 'foo' for one of my domains. Here's the example: https://github.com/sebkur/inwx-python-client/blob/master/test.py

From that minimal example it seems like the INWX role management does work OK.

While having all roles removed from the API user, I did the same as you and fore-renewed the certificate of one of my domains that already have a valid wildcard certificate. It still works indeed, however it does not seem to do anything with the INWX API! One thing I notice directly is that the certificate is renewed within a second or two while it took more than a minute when actually setting a DNS record using the API. There is a step where certbot waits for 60 seconds for the new DNS entry to propagate. It seems like this step is skipped. I'm guessing that on letsencrypt's end, they do cache something and a force renewal just hits their cache.

Looking at the output it seems like indeed no challenge is done in that case:

I'm running this:

(certbot renew --cert-name some-domain-that-already-has-a-wildcard-cert.com --force-renewal -vvvv 2>&1) | less

In the verbose log, there's actually no mentioning of an actual challenge performed, while when I run this on a domain that does not yet have a wildcard certificate:

(certbot certonly -a dns-inwx -d *.whatever-your-domain.com -vvvv 2>&1) | less

I do get this:

Performing the following challenges:
dns-01 challenge for whatever-your-domain.com