Troubleshooting¶
This page includes tips for troubleshooting authd and the identity brokers for different cloud providers.
Logging¶
authd¶
authd logs to the system journal.
For authd entries, run:
journalctl -u authd.service
If you want logs for authd and all brokers on the system, run:
journalctl -u authd.service -u "snap.authd-*.service"
For specific broker entries run the command for your chosen broker:
journalctl -u snap.authd-google.authd-google.service
journalctl -u snap.authd-msentraid.authd-msentraid.service
For the GDM integration:
journalctl /usr/bin/gnome-shell
For anything else or more broader investigation, use journalctl.
Logging verbosity¶
You can increase the verbosity of the logs in different ways.
PAM module¶
Append debug=true to all the lines with pam_authd_exec.so or pam_authd.so in the PAM configuration files (common-auth, gdm-authd…) in /etc/pam.d/ to increase the verbosity of the PAM messages.
NSS module¶
Export AUTHD_NSS_INFO=stderr environment variable on any program using the authd NSS module to get more info on NSS requests to authd.
authd service¶
To increase the verbosity of the service itself, edit the service file:
sudo systemctl edit authd.service
Add the following lines to the override file and make sure to add -vv at the end of the authd command:
[Service]
ExecStart=
ExecStart=/usr/libexec/authd -vv
Then you need to restart the service with sudo systemctl restart authd.
GDM¶
Ensure the lines in /etc/gdm3/custom.conf are not commented:
[debug]
# Uncomment the line below to turn on debugging
# More verbose logs
# Additionally lets the X server dump core if it crashes
Enable=true
Then you need to restart the service with sudo systemctl restart gdm.
authd broker service¶
To increase the verbosity of the broker service, edit the service file:
sudo systemctl edit snap.authd-google.authd-google.service
sudo systemctl edit snap.authd-msentraid.authd-msentraid.service
Add the following lines to the override file and make sure to add -vv to the exec command:
[Service]
ExecStart=
ExecStart=/usr/bin/snap run authd-google -vv
[Service]
ExecStart=
ExecStart=/usr/bin/snap run authd-msentraid -vv
You will then need to restart the service with:
snap restart authd-google.
snap restart authd-msentraid.
Switch authd to the edge PPA¶
Maybe your issue is already fixed! You can try switching to the edge PPA, which contains the latest fixes and features for authd, in addition to its GNOME Shell (GDM) counterpart.
Warning
Do not use the edge PPA in a production system, because it may apply changes to the authd database in a non-reversible way, which can make it difficult to roll back to the stable version of authd.
sudo add-apt-repository ppa:ubuntu-enterprise-desktop/authd-edge
sudo apt update
sudo apt install authd gnome-shell
Keep in mind that this version is not tested and may be incompatible with the current released version of the brokers.
To switch back to the stable version of authd:
sudo apt install ppa-purge
sudo ppa-purge ppa:ubuntu-enterprise-desktop/authd-edge
Note
If using an edge release, you can read the latest development version of the documentation
Switch broker snap to the edge channel¶
Maybe your issue is already fixed! You should try switching to the edge channel of the broker snap. You can easily do that with:
snap switch authd-google --edge
snap refresh authd-google
snap switch authd-msentraid --edge
snap refresh authd-msentraid
Keep in mind that this version is not tested and may be incompatible with the current released version of authd. You should switch back to stable after trying the edge channel:
snap switch authd-google --stable
snap refresh authd-google
snap switch authd-msentraid --stable
snap refresh authd-msentraid
Note
If using an edge release, you can read the latest development version of the documentation
Common issues¶
Only the first logged-in user can get access to a machine¶
This is the expected behavior.
By default, the first logged-in user is defined as the “owner” and only the owner can log in.
For other users to gain access after authentication, they must be added to
allowed_users in the broker.conf file.
This is outlined in the guide for configuring authd.
See below the relevant line in the configuration, showing both the owner and an additional user:
[users]
allowed_users = OWNER,[email protected]
If an administrator is the first to log in to a machine and becomes the owner,
they can ensure that the next user to log in becomes the owner by removing the
20-owner-autoregistration.conf file:
sudo rm /var/snap/authd-google/current/broker.conf.d/20-owner-autoregistration.conf
sudo rm /var/snap/authd-msentraid/current/broker.conf.d/20-owner-autoregistration.conf
This file is generated when a user logs in and becomes the owner. If it is removed, it will be regenerated on the next successful login.
Recovery mode for failed login¶
If authd and/or the broker are missing, corrupted, or broken in any way, a user may be prevented from logging in.
To get access to the system for modifying configurations and installations in such cases, there are two main options:
Log in as root user or another local user with administrator privileges
Boot into recovery mode to get root access
The steps required for entering recovery mode are included below.
Boot into recovery mode¶
If it is not possible to log in with the root user account or another local user account with administrator privileges, the user can boot into recovery mode:
Reboot the device
During the reboot, press and hold the right SHIFT key
When the Grub menu appears, select
advanced options for UbuntuChoose
recovery modefor the correct kernel versionSelect
drop to root shell prompt
The user then has access to the root filesystem and can proceed with debugging.