Confirming this on Arch Linux, Plasma 6.7.0 (krdp 6.7.0-1), with SystemUserEnabled=true.

Ended up here after a troubleshooting session with claude.

Workaround — create the drop-in file:
    ~/.config/systemd/user/app-org.kde.krdpserver.service.d/override.conf

with contents:
    [Service]
    NoNewPrivileges=false

then reload & restart:
    systemctl --user daemon-reload && systemctl --user restart app-org.kde.krdpserver.service

I'm having the same issue.
NoNewPrivileges=true likely conflicts with the setuid bit on unix_chkpwd, causing the bug.

Confirmed on Fedora Linux 44 KDE with Plasma/KRDP 6.7.0.

Environment:

* Fedora Linux 44 KDE Plasma Desktop Edition
* Kernel: 7.0.12-201.fc44.x86_64
* KRDP: 6.7.0-1.fc44.x86_64
* FreeRDP: 3.27.1-1.fc44.x86_64
* Plasma Workspace: 6.7.0-1.fc44.x86_64
* systemd: 259.6-1.fc44.x86_64
* PAM: 1.7.2-1.fc44.x86_64
* SELinux policy: 44.3-1.fc44
* KDE Plasma Wayland session
* SELinux enforcing

Hardware:

* Lenovo Yoga 14sARH 2021, machine type 82LB
* AMD Ryzen 7 4800H
* AMD Renoir Radeon Vega graphics using the amdgpu driver

The same local username and password authenticate successfully with:

```
pamtester login USERNAME authenticate
```

Result:

```
pamtester: successfully authenticated
```

However, KRDP fails with:

```
pam_unix(login:auth): authentication failure
pam_authenticate failure
PostConnect failed
```

The packaged user service contains:

```
NoNewPrivileges=true
```

Before the workaround:

```
NoNewPrivileges=yes
NoNewPrivs: 1
```

SELinux also records the following during each failed login:

```
avc: denied { nnp_transition }
comm=krdp_session
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:chkpwd_t:s0-s0:c0.c1023
tclass=process2
```

Temporarily running `setenforce 0` did not fix the authentication failure, which is consistent with the kernel `no_new_privs` flag remaining active independently of SELinux enforcement.

The following user-service override fixes the issue:

```
[Service]
NoNewPrivileges=false
```

After restarting the service:

```
NoNewPrivileges=no
NoNewPrivs: 0
```

The same username and password then authenticate successfully, while SELinux remains enforcing.

The issue was reproduced with Microsoft Remote Desktop Connection and Remote Desktop Manager on Windows, as well as Windows App on macOS.

*** Bug 522139 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/krdp/-/merge_requests/197

*** Bug 522093 has been marked as a duplicate of this bug. ***

*** Bug 521891 has been marked as a duplicate of this bug. ***

Git commit 981319d36b88200dd413a9a5052717189e524581 by David Edmundson.
Committed on 25/06/2026 at 14:20.
Pushed by davidedmundson into branch 'master'.

Revert "Set NoNewPrivileges on the krdpserver systemd service"

This reverts commit 8e1de600a6ea4fcb1662508626da2cf0499f9734.

The PAM backend needs privs to check.

M  +0    -1    server/app-org.kde.krdpserver.service.in

https://invent.kde.org/plasma/krdp/-/commit/981319d36b88200dd413a9a5052717189e524581

*** Bug 522219 has been marked as a duplicate of this bug. ***

Confirming this bug on CachyOS with krdp 6.7.1-1.1. The NoNewPrivileges=true directive in the systemd user service file app-org.kde.krdpserver.service prevents PAM authentication from functioning for system users.
    
    Environment:
    
    - Distro: CachyOS (latest, as of June 26, 2026)
    - Kernel: Linux 7.1.1-2-cachyos
    - KDE Plasma: 6.7.1
    - KRdp: 6.7.1-1.1 (cachyos-extra-v4)
    - Display: Wayland
    - PAM authentication: system-auth (pam_unix + pam_faillock)
    - Client tested: aRDP on Android, xfreerdp on Linux
    
    Steps to Reproduce:
    
    1. Enable "Remote Desktop" in KDE System Settings with "System User" authentication enabled
    2. Connect via any RDP client using the system username and password
    3. Observe connection fail immediately after authentication attempt
    
    Server-side logs (syslog/journalctl):
    
    
    krdpserver[PID]: New client connected: Unspecified platform Unspecified version
    krdpserver[PID]: pam_unix(login:auth): authentication failure; logname=<user> uid=1000 euid=1000 tty= ruser= rhost=  user=<user>
    krdpserver[PID]: pam_authenticate failure: Authentication service cannot retrieve authentication info
    krdpserver[PID]: [ERROR] [rdp_peer_handle_state_active]: PostConnect for peer 0x... failed
    krdpserver[PID]: [ERROR] [transport_check_fds]: transport_check_fds: transport->ReceiveCallback() - STATE_RUN_FAILED [-1]
    
    
    After repeated failures, pam_faillock locks the account:
    
    
    krdpserver[PID]: pam_faillock(login:auth): Consecutive login failures for user <user> account temporarily locked
    krdpserver[PID]: pam_authenticate failure: Authentication failure
    
    
    Root Cause:
    
    The file /usr/lib/systemd/user/app-org.kde.krdpserver.service contains:
    
    
    [Service]
    NoNewPrivileges=true
    
    
    This prevents pam_unix from spawning unix_chkpwd (a setuid binary) to verify the user's password against /etc/shadow. As a result, every PAM authentication attempt fails regardless of whether the password is correct.
    
    Workaround:
    
    Create a systemd user service override:
    
    
    mkdir -p ~/.config/systemd/user/app-org.kde.krdpserver.service.d
    cat > ~/.config/systemd/user/app-org.kde.krdpserver.service.d/override.conf << 'EOF'
    [Service]
    NoNewPrivileges=false
    EOF
    systemctl --user daemon-reload
    systemctl --user restart app-org.kde.krdpserver.service
    
    
    This restores correct PAM login behavior. The override persists across service file updates since it resides in the user's local config directory.
    
    Verification:
    
    After applying the workaround, connecting via RDP succeeds immediately with the correct system password. Logs show successful authentication and a stable session.
    
    Notes:
    
    - The password itself is correct — it works for sudo and console login. Only krdp authentication fails.
    - After clearing the pam_faillock counter and applying the override, connections succeed on the first attempt.
    - This was reported on Gentoo (Bug 521776) and I am confirming it also affects Arch-based distributions (CachyOS) with the same krdp 6.7.x version. The fix is identical.
     - Note: I'm a real person submitting this bug report but I did have hermes-agent (an AI tool) discover the problem, fix it and write this bug report for me on my PC.

*** Bug 521916 has been marked as a duplicate of this bug. ***

*** Bug 521916 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/krdp/-/merge_requests/218

Git commit 66a98cd6eb4cf92a5a09de66aa951cbd943e74f1 by Wensheng Tang, on behalf of David Edmundson.
Committed on 16/07/2026 at 03:44.
Pushed by ahiemstra into branch 'Plasma/6.7'.

Revert "Set NoNewPrivileges on the krdpserver systemd service"

This reverts commit 8e1de600a6ea4fcb1662508626da2cf0499f9734.

The PAM backend needs privs to check.
(cherry picked from commit 981319d36b88200dd413a9a5052717189e524581)

M  +0    -1    server/app-org.kde.krdpserver.service.in

https://invent.kde.org/plasma/krdp/-/commit/66a98cd6eb4cf92a5a09de66aa951cbd943e74f1