Polkit Authentication Fails for Active Directory Domain Users on Amazon WorkSpaces (Ubuntu)

Problem

An Active Directory (AD) domain user logged into an Amazon WorkSpaces Ubuntu instance can authenticate via AD/WebAuthn, use sudo, and is recognized as an administrative user. However, any operation that requires polkit authentication fails.

Affected operations include pkexec commands (returns "Request dismissed"), Snap Store application updates, PackageKit actions (software installation via GUI), and any GNOME desktop action that triggers a polkit authentication dialog.

The polkit authentication dialog displays:

Authenticating as: Ubuntu (ubuntu)

It shows the local system account instead of the logged-in domain user. The domain user's password is rejected because polkit is attempting to authenticate the wrong account.

Investigation

Confirm AD authentication is healthy

Start by verifying that the AD integration itself works. In this scenario, all of the following confirmed healthy AD authentication.

SSSD identity resolution shows the domain user resolves correctly:

getent passwd <domain_user>
# Returns valid AD user entry with UID <ad_uid>

Session ownership via loginctl correctly identifies the active session as the domain user:

loginctl list-sessions
# Shows session owned by <domain_user>

Sudo works. The domain user has full administrative privileges via AD-delivered sudo policy:

sudo -l
# User <domain_user> may run the following commands:
#     (ALL : ALL) ALL

Confirm polkit recognizes the domain user

Review the polkit logs (sudo journalctl -b | grep -i polkit). They show that polkit correctly associates the authorization request with the AD user:

polkitd[911]: Operator of unix-session:c4 FAILED to authenticate to gain
authorization for action org.freedesktop.policykit.exec for
unix-process:8873:65718 [/usr/bin/zsh -l] (owned by unix-user:<domain_user>)

The Amazon WorkSpaces image also includes a polkit configuration that references the AD user's UID:

# /etc/polkit-1/localauthority.conf.d/zz-ws-admin-user.conf
[Configuration]
AdminIdentities=unix-user:<ad_uid>

Identify the authentication target mismatch

The key evidence appears in the PAM authentication logs within the polkit entries:

polkit-agent-helper-1[9580]: pam_unix(polkit-1:auth): authentication failure;
    logname=<domain_user> uid=<ad_uid> euid=0 tty= ruser=ubuntu rhost= user=ubuntu
polkit-agent-helper-1[9580]: pam_sss(polkit-1:auth): authentication failure;
    logname=<domain_user> uid=<ad_uid> euid=0 tty= ruser=ubuntu rhost= user=ubuntu
polkit-agent-helper-1[9580]: pam_sss(polkit-1:auth): received for user ubuntu:
    10 (User not known to the underlying authentication module)

Polkit correctly identifies the request as originating from the domain user. But the authentication dialog attempts to verify credentials for the local ubuntu account instead.

Root cause

Two different administrator identity models operate independently on the same system.

Sudo privileges flow through the AD, SSSD, and sudo policy chain. This works because SSSD resolves the domain user and applies the appropriate sudo rules.

Polkit administrator selection checks membership in the local Unix sudo group:

getent group sudo
# sudo:x:27:ubuntu

The AD user is not a member of the local sudo group. Their sudo privileges come through SSSD policy, not group membership. So polkit falls back to the only user it finds in the sudo group: the local ubuntu account.

The WorkSpaces polkit configuration (zz-ws-admin-user.conf) references the AD user by UID. But the GNOME polkit agent's administrator selection logic still relies on local group membership to determine which user identity to present in the authentication dialog.

Resolution

Add the AD domain user to the local sudo group:

sudo usermod -aG sudo <domain_user>

After reloading group membership (log out and back in, or use newgrp sudo), the polkit authentication dialog changes from:

Authenticating as: Ubuntu (ubuntu)

to:

Authenticating as: <Domain User Display Name>

The domain user's AD password is now accepted. All polkit-protected operations (pkexec, Snap Store updates, PackageKit actions) work as expected.

Automate the fix for fleet deployment

For environments with multiple AD users, consider adding this step to your golden image provisioning or post-login automation. One approach modifies the polkit rules directly to recognize AD-delivered administrative identities without requiring local group membership:

// /etc/polkit-1/rules.d/50-ws-ad-admins.rules
polkit.addAdminRule(function(action, subject) {
    if (subject.isInGroup("sudo") || subject.isInGroup("domain admins")) {
        return ["unix-user:" + subject.user];
    }
});

You can also handle this through configuration management (SCCM, Ansible, or a WorkSpaces post-launch script) that adds each provisioned AD user to the local sudo group during setup.

Summary

On Amazon WorkSpaces Ubuntu instances joined to Active Directory via SSSD, domain users may have full sudo privileges (delivered through AD policy) but still fail polkit authentication. This happens because polkit determines administrative identity from local Unix group membership, not from AD-delivered sudo policy. The fix: ensure AD users are also members of the local sudo group so polkit recognizes them as valid administrative identities.