Issue: gdm-greeter issue after installing adsys

[tlcarpenter]

Is there an existing issue for this?

• I have searched the existing issues and found none that matched mine

Describe the issue

After installing adsys on Ubuntu 26.04, once the system boots, it advances to what I'll call a guest session, i.e. to a GUI interface without being prompted to authenticate. It's possible to open a virtual terminal and log in to a local user account. auth.log contains entries that include

gdm-launch-environment]: pam_sss(gdm-launch-environment:account): Access denied for user gdm-greeter: 10 (User not known to the underlying authentication module)
gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm-greeter(uid=60578) by (uid=0)
systemd-logind[2606]: New session 'c1' of user 'gdm-greeter' with class 'greeter' and type 'wayland'.
(systemd): pam_sss(systemd-user:account): Access denied for user gdm-greeter: 10 (User not known to the underlying authentication module)
(systemd): pam_unix(systemd-user:session): session opened for user gdm-greeter(uid=60578) by gdm-greeter(uid=0)
systemd-logind[2606]: New session '1' of user 'gdm-greeter' with class 'manager-early' and type 'unspecified'.
login: pam_unix(login:auth): check pass; user unknown
login: pam_unix(login:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty2 ruser= rhost=

Prior to installing adsys, the system had been joined to our AD domain; domain users could sign in and a GPO that implemented an ACL worked as expected, i.e. users that were supposed to be able to login could and those that weren't in the ACL couldn't. If logged into a local account and then become root by running "sudo -i", it's possible to "su - <domian user>", but a domain user isn't able to login by authenticating from a "login:" prompt UNLESS "ADSys authentication" is disabled as mentioned in #550.

Steps to reproduce it

Ubuntu users: System information

Ubuntu 26.04 LTS

Non Ubuntu users: System information

Environment

• adsys version: please run adsysctl version 0.16.4ubuntu1.1
• Distribution: (NAME in /etc/os-release) Ubuntu
• Distribution version: (VERSION_ID on /etc/os-release): 26.04

Log files

Please redact/remove sensitive information:

level=info msg="github.com/ubuntu/adsys/internal/config/config.go:79 Init() Using configuration file: /etc/adsys.yaml"
level=debug msg="Connecting as [[12137:077969]]"
level=debug msg="github.com/ubuntu/adsys/internal/grpc/logconnections/logconnections.go:28 (*Service).RegisterGRPCServer.StreamServerInterceptor.func3() New request /service/Cat"
level=debug msg="github.com/ubuntu/adsys/internal/grpc/logconnections/logconnections.go:61 loggedServerStream.RecvMsg() Requesting with parameters: "
level=debug msg="github.com/ubuntu/adsys/internal/authorizer/authorizer.go:112 Authorizer.IsAllowedFromContext() Check if grpc request peer is authorized"
level=debug msg="github.com/ubuntu/adsys/internal/authorizer/authorizer.go:156 Authorizer.isAllowed() Authorized as being administrator"
level=info msg="github.com/ubuntu/adsys/internal/grpc/logstreamer/server.go:48 (*Service).RegisterGRPCServer.StreamServerInterceptor.func1() New connection from client [[12246:609836]]"
level=debug msg="github.com/ubuntu/adsys/internal/grpc/logconnections/logconnections.go:28 (*Service).RegisterGRPCServer.StreamServerInterceptor.func3() [[12246:609836]] New request /service/UpdatePolicy"
level=debug msg="github.com/ubuntu/adsys/internal/grpc/logconnections/logconnections.go:61 loggedServerStream.RecvMsg() [[12246:609836]] Requesting with parameters: IsComputer: false, All: false, Target: <USERNAME>, Krb5Cc: KEYRING:persistent:<UID>, Purge: false"
level=debug msg="github.com/ubuntu/adsys/internal/ad/ad.go:653 (*AD).NormalizeTargetName() [[12246:609836]] NormalizeTargetName for \"<USERNAME>\", type \"user\""
level=debug msg="github.com/ubuntu/adsys/internal/ad/ad.go:693 (*AD).NormalizeTargetName() [[12246:609836]] Target name normalized to \"<USERNAME>@<DOMAIN>\""
level=debug msg="github.com/ubuntu/adsys/internal/authorizer/authorizer.go:112 Authorizer.IsAllowedFromContext() [[12246:609836]] Check if grpc request peer is authorized"
level=debug msg="github.com/ubuntu/adsys/internal/authorizer/authorizer.go:156 Authorizer.isAllowed() [[12246:609836]] Authorized as being administrator"
level=debug msg="github.com/ubuntu/adsys/internal/ad/ad.go:199 (*AD).GetPolicies() [[12246:609836]] GetPolicies for \"<USERNAME>@<DOMAIN>\", type \"user\""
level=info msg="github.com/ubuntu/adsys/internal/grpc/logconnections/logconnections.go:40 (*Service).RegisterGRPCServer.StreamServerInterceptor.func3() Error sent to client: error while updating policy: can't get policies for \"<USERNAME>@<DOMAIN>\": failed to read source file: open /KEYRING:persistent:<UID>: no such file or directory"
level=debug msg="github.com/ubuntu/adsys/internal/grpc/logconnections/logconnections.go:34 (*Service).RegisterGRPCServer.StreamServerInterceptor.func3.1() Request /service/UpdatePolicy done"

Application settings

Please redact/remove sensitive information:

# Service and client configuration
verbose: 2

# Service only configuration
service_timeout: 3600
detect_cached_ticket: true

Additional information

No response

Double check your logs

• I have redacted any sensitive information from the logs

[tlcarpenter]

Is the use of "default_ccache_name = KEYRING:persistent:%{uid}" (for krb5.conf with sssd) compatible with adsysd?

[GITGUYX8]

I'd like to tackle this bug. Here’s my plan:

1. Stop the crash first: I’ll patch the PAM and client code to detect KEYRING: caches and skip the file-read attempt gracefully. This stops the login failure immediately without needing a full rewrite.
2. Fix it properly next: I’ll implement a helper to safely copy the keyring ticket to a temporary file, process it, and clean up. This will let ADSys support secure keyrings fully.