Bug 2006028 - Non-root user cannot join an Active Directory domain through Cockpit
Summary: Non-root user cannot join an Active Directory domain through Cockpit
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: cockpit
Version: 35
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Matej Marušák
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://ask.fedoraproject.org/t/we-ar...
Depends On:
Blocks: F35FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2021-09-20 17:49 UTC by Stephen Gallagher
Modified: 2021-12-03 01:05 UTC (History)
10 users (show)

Fixed In Version: cockpit-254-1.fc35
Clone Of:
Environment:
Last Closed: 2021-10-05 00:50:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Stephen Gallagher 2021-09-20 17:49:46 UTC
Description of problem:
When logging into Cockpit as a non-root user (but one that is a member of group `wheel` and thus generally treated as root), the "Overview" tab initially states "Domain: Not Joined" but when I turn on administrative access, it switches to "Domain: Join Domain". However, when I enter the correct credentials and attempt to join, I am told: "Not authorized to perform this action".


Version-Release number of selected component (if applicable):
cockpit-250-1.fc35

How reproducible:
Every time

Steps to Reproduce:
1. Sign in as a non-root user who is a member of the "wheel" group.
2. Turn on administrative mode
3. Provide credentials to join a domain (either FreeIPA or Active Directory).

Actual results:
"Not authorized to perform this action"

Expected results:
The device is joined to the domain.

Additional info:

I'm reasonably certain that I have done this successfully in the past as a non-root user. Fedora 35 will default to having the root user disabled, so I view this as an urgent problem.

Comment 1 Fedora Blocker Bugs Application 2021-09-20 17:51:52 UTC
Proposed as a Blocker for 35-beta by Fedora user sgallagh using the blocker tracking app because:

 "It must be possible to log in to the default Cockpit instance and use it to: Enrol the system to a FreeIPA or Active Directory domain" -- Beta criterion.

Arguably, we could move this to a Final Blocker, since at least one user (root) can succeed at this, but I don't think we can ship GA in this state.

Comment 2 Adam Williamson 2021-09-20 18:37:49 UTC
CCing Jan Rybar for any policykit angle here. Stephen, can you attach journal messages from the relevant time just in case any turn out to be useful?

Comment 3 Stephen Gallagher 2021-09-20 19:09:46 UTC
Sep 20 15:08:47 client1.windows.sgallagh.rht realmd[1081]:  * Resolving: _ldap._tcp.windows.sgallagh.rht
Sep 20 15:08:47 client1.windows.sgallagh.rht realmd[1081]:  * Resolving: _ldap._tcp.windows.sgallagh.rht
Sep 20 15:08:47 client1.windows.sgallagh.rht realmd[1081]:  * Performing LDAP DSE lookup on: 192.168.122.184
Sep 20 15:08:47 client1.windows.sgallagh.rht realmd[1081]:  * Performing LDAP DSE lookup on: 192.168.122.184
Sep 20 15:08:47 client1.windows.sgallagh.rht realmd[1081]: Searching  for (objectClass=*)
Sep 20 15:08:47 client1.windows.sgallagh.rht realmd[1081]: Got defaultNamingContext: DC=windows,DC=sgallagh,DC=rht
Sep 20 15:08:47 client1.windows.sgallagh.rht realmd[1081]: Sending TCP Netlogon request
Sep 20 15:08:47 client1.windows.sgallagh.rht realmd[1081]: Received TCP Netlogon response
Sep 20 15:08:47 client1.windows.sgallagh.rht realmd[1081]:  * Successfully discovered: windows.sgallagh.rht
Sep 20 15:08:47 client1.windows.sgallagh.rht realmd[1081]:  * Successfully discovered: windows.sgallagh.rht
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: Using 'cockpit-1' operation for method 'Join' invocation on 'org.freedesktop.realmd.KerberosMembership' interface
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: holding daemon: current-invocation
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Couldn't find file: /usr/sbin/oddjobd
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Couldn't find file: /usr/sbin/oddjobd
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/sbin/adcli
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/sbin/adcli
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Resolving required packages
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Resolving required packages
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: packages: CreateTransaction call
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: packages: SetHints call
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: packages: call Resolve (327680, ['oddjob', 'oddjob-mkhomedir', 'sssd', 'adcli'])
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: packages: call Resolve completed
Sep 20 15:08:51 client1.windows.sgallagh.rht PackageKit[1080]: resolve transaction /23_cabebbdc from uid 0 finished with success after 3ms
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: packages: signal: Package (1, 'adcli;0.9.1-9.fc35;x86_64;installed:anaconda', 'Active Directory enrollment')
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: packages: signal: Package (1, 'oddjob;0.34.7-4.fc35;x86_64;installed:@System', 'A D-Bus service which runs odd jobs on behalf of client applications')
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: packages: signal: Package (1, 'oddjob-mkhomedir;0.34.7-4.fc35;x86_64;installed:@System', 'An oddjob helper which creates and populates home directories')
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: packages: signal: Package (1, 'sssd;2.5.2-5.fc35;x86_64;installed:anaconda', 'System Security Services Daemon')
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: packages: signal: Finished (1, 3)
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * LANG=C /usr/sbin/adcli join --verbose --domain windows.sgallagh.rht --domain-realm WINDOWS.SGALLAGH.RHT --domain-controller 192.168.122.184 --login-ty>
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * LANG=C /usr/sbin/adcli join --verbose --domain windows.sgallagh.rht --domain-realm WINDOWS.SGALLAGH.RHT --domain-controller 192.168.122.184 --login-ty>
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: process started: 27932
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]: packages: freeing transtaction
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Using domain name: windows.sgallagh.rht
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Using domain name: windows.sgallagh.rht
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Calculated computer account name from fqdn: CLIENT1
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Calculated computer account name from fqdn: CLIENT1
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Using domain realm: windows.sgallagh.rht
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Using domain realm: windows.sgallagh.rht
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Sending NetLogon ping to domain controller: 192.168.122.184
Sep 20 15:08:51 client1.windows.sgallagh.rht realmd[1081]:  * Sending NetLogon ping to domain controller: 192.168.122.184
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]:  * Received NetLogon info from: WIN-6DM2OJDDH3I.windows.sgallagh.rht
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]:  * Received NetLogon info from: WIN-6DM2OJDDH3I.windows.sgallagh.rht
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]:  * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-Mismxs/krb5.d/adcli-krb5-conf-SK4I33
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]:  * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-Mismxs/krb5.d/adcli-krb5-conf-SK4I33
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]:  ! Couldn't authenticate as: @WINDOWS.SGALLAGH.RHT: Client '@WINDOWS.SGALLAGH.RHT' not found in Kerberos database
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]:  ! Couldn't authenticate as: @WINDOWS.SGALLAGH.RHT: Client '@WINDOWS.SGALLAGH.RHT' not found in Kerberos database
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]: adcli: couldn't connect to windows.sgallagh.rht domain: Couldn't authenticate as: @WINDOWS.SGALLAGH.RHT: Client '@WINDOWS.SGALLAGH.RHT' not found in Kerb>
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]: adcli: couldn't connect to windows.sgallagh.rht domain: Couldn't authenticate as: @WINDOWS.SGALLAGH.RHT: Client '@WINDOWS.SGALLAGH.RHT' not found in Kerb>
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]: process exited: 27932
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]:  ! Failed to join the domain
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]:  ! Failed to join the domain
Sep 20 15:08:52 client1.windows.sgallagh.rht realmd[1081]: released daemon: current-invocation

Comment 4 Matej Marušák 2021-09-21 08:22:02 UTC
Confirmed. This is indeed bug in Cockpit. If you would reload the page or re-login, it would work again. I am looking at fixing this now.

Comment 5 Matej Marušák 2021-09-21 08:40:27 UTC
Upstream fix: https://github.com/cockpit-project/cockpit/pull/16371

Comment 6 Stephen Gallagher 2021-09-23 00:14:31 UTC
I monkey-patched the upstream fix into my Fedora VM to test it. Unfortunately, it's still failing with:

```
 * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/sbin/adcli
 * LANG=C /usr/sbin/adcli join --verbose --domain windows.sgallagh.rht --domain-realm WINDOWS.SGALLAGH.RHT --domain-controller 192.168.122.184 --login-type user --login-user  --stdin-password
 * Using domain name: windows.sgallagh.rht
 * Calculated computer account name from fqdn: CLIENTF35B
 * Using domain realm: windows.sgallagh.rht
 * Sending NetLogon ping to domain controller: 192.168.122.184
 * Received NetLogon info from: WIN-6DM2OJDDH3I.windows.sgallagh.rht
 * Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-zaGDap/krb5.d/adcli-krb5-conf-TrWA5I
 ! Couldn't authenticate as: @WINDOWS.SGALLAGH.RHT: Client '@WINDOWS.SGALLAGH.RHT' not found in Kerberos database
adcli: couldn't connect to windows.sgallagh.rht domain: Couldn't authenticate as: @WINDOWS.SGALLAGH.RHT: Client '@WINDOWS.SGALLAGH.RHT' not found in Kerberos database
 ! Failed to join the domain
```

`sudo realm join windows.sgallagh.rht` works properly as before.

Comment 7 Matej Marušák 2021-09-23 05:33:34 UTC
> I monkey-patched the upstream fix into my Fedora VM to test it.

OOI how did you do it? Have you built rpms or symlinked the source?

> Unfortunately, it's still failing

Do you still see in the UI error message saying "Not authorized to perform this action"?

Comment 8 Adam Williamson 2021-09-23 06:21:37 UTC
When I discussed this with sgallagh in IRC, we were talking about editing the .js file on the system after package installation, before running Cockpit.

If this may not be effective - e.g. if Cockpit uses a minified form of the file from somewhere else - could you please provide a scratch build with the fix, or instructions for building one? Stephen mentioned that just applying the patch to the package build does not work because it causes the package's build scripts to want to regenerate something without the necessary tools being available, and I recall encountering the same problem before. This is quite a stumbling block for quickly testing fixes like this.

Comment 9 Martin Pitt 2021-09-23 06:32:00 UTC
A good way to check if the upstream PR (https://github.com/cockpit-project/cockpit/pull/16371) was really the root cause is to force-reload the Cockpit page after raising privileges. This will work around the issue which the PR fixes. If it still fails then, then the root cause is somewhere entirely different.

https://copr.fedorainfracloud.org/coprs/packit/cockpit-project-cockpit-16383/build/2838041/ has a build with this fix (it's not exactly the packit COPR from the above PR for $reasons, but close enough).

Comment 10 Adam Williamson 2021-09-23 06:38:40 UTC
Stephen did say in IRC that he tried the reload workaround and it didn't work. He didn't specify exactly when he tried to reload, but he's not dumb so he probably did it in the right place/time...

(I'm speaking for him now as I assume he's gone to bed, he's further east than I am).

Comment 11 Stephen Gallagher 2021-09-23 11:59:51 UTC
You can disregard this. I had a flaw in my testing methodology. It appears that this fix does indeed work after all. Sorry for the noise.

Comment 12 Adam Williamson 2021-09-23 14:59:41 UTC
Well, that's good news at least. Does the 'refresh the page' workaround work, for commonbugs purposes?

Comment 13 Stephen Gallagher 2021-09-23 15:03:47 UTC
(In reply to Adam Williamson from comment #12)
> Well, that's good news at least. Does the 'refresh the page' workaround
> work, for commonbugs purposes?

Yes, it seems that it does.

Comment 14 Ben Cotton 2021-09-23 18:04:29 UTC
Moving to Final Blocker. This was rejected as a Beta Blocker in today's Go/No-Go meeting, but it will still be considered for Final Blocker status.
https://meetbot.fedoraproject.org/fedora-meeting/2021-09-23/f35-beta-go_no_go-meeting.2021-09-23-17.00.log.html#l-140

Comment 15 Adam Williamson 2021-09-27 16:03:16 UTC
+5 in https://pagure.io/fedora-qa/blocker-review/issue/465 , marking accepted.

Comment 16 Fedora Update System 2021-09-30 05:08:40 UTC
FEDORA-2021-55aee7fb50 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-55aee7fb50

Comment 17 Fedora Update System 2021-10-05 00:50:59 UTC
FEDORA-2021-55aee7fb50 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.