I have a Jetson Orin that has Ubuntu 20.04.6 LTS (GNU/Linux -tegra aarch64).
On all other Ubuntu machines, there isn’t an issue using realm join to add a machine to an Active Directory domain, and then logging in with AD credentials.
For the Jetson Orin, I have gone through the steps of joining the device to the domain, and it does in fact join. I see it in AD and all. However, there seems to be an issue when trying to log in with the AD credentials. The Jetson seems to be able to resolve the username when you put in your credentials, it black screens for about a second or two like it’s going to log you in, then it spits you back out to the login screen.
I’ve made sure the “Create home directory on login” in the PAM configuration was selected.
Just wondering if maybe the kernel version isn’t totally compatible with realm join.
Hi,
This would need other users to share experience. The default rootfs is Ubuntu 20.04 and we have steps in developer guide for customizing rootfs. However, we don’t have much experience in advancing functions of Ubuntu 20.04. Would see if other users can check and provide suggestion.
I tried reaching out to enterprise support since I have an enterprise account and they told me I had to reach out to consumer support.
I reached out to consumer support and they told me to just respond to your reply.
I don’t believe it is rootfs since the user is capable of logging in using ssh, and their home directory is built to match the skel directory. Instead that there may be an issue with Pam or GDM’s configuration when interacting with the realm authentication for Active Directory.
I made another local account and there were no issues, so this is only happening with AD accounts.
This is what the gdm log looks like:
Jun 15 10:36:05 Jetson-Orin.ad.mycompany gdm-password][2138]: gkr-pam: unable to locate daemon control file
Jun 15 10:36:05 Jetson-Orin.ad.mycompany gdm-password][2138]: gkr-pam: stashed password to try later in open session
Jun 15 10:36:05 Jetson-Orin.ad.mycompany gdm-password][2138]: pam_unix(gdm-password:session): session opened for user user1234@ad.mycompany by (uid=0)
Jun 15 10:36:05 Jetson-Orin.ad.mycompany gdm-password][2138]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
Jun 15 10:36:06 Jetson-Orin.ad.mycompany gdm-password][2138]: pam_unix(gdm-password:session): session closed for user user1234@ad.mycompany
Jun 15 10:36:06 Jetson-Orin.ad.mycompany gdm3[1777]: GdmDisplay: Session never registered, failing
Jun 15 10:36:13 Jetson-Orin.ad.mycompany gdm-password][2303]: gkr-pam: unable to locate daemon control file
This is what returns in sudo journalctl -xb | grep gkr-pam:
Jun 15 12:26:12 Jetson-Orin.ad.mycompany gdm-password][2131]: gkr-pam: unable to locate daemon control file
Jun 15 12:26:12 Jetson-Orin.ad.mycompany gdm-password][2131]: gkr-pam: stashed password to try later in open session
Jun 15 12:26:12 Jetson-Orin.ad.mycompany gdm-password][2131]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
Jun 15 12:26:46 Jetson-Orin.ad.mycompany gdm-password][2293]: gkr-pam: unable to locate daemon control file
Jun 15 12:26:46 Jetson-Orin.ad.mycompany gdm-password][2293]: gkr-pam: stashed password to try later in open session
Jun 15 12:26:47 Jetson-Orin.ad.mycompany gdm-password][2293]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
Jun 15 12:29:59 Jetson-Orin.ad.mycompany gdm-password][4785]: gkr-pam: unable to locate daemon control file
Jun 15 12:29:59 Jetson-Orin.ad.mycompany gdm-password][4785]: gkr-pam: stashed password to try later in open session
Jun 15 12:29:59 Jetson-Orin.ad.mycompany gdm-password][4785]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
For some reason that we have not figured out yet, it appears that the AD accounts don’t get the same groups as the local accounts.
We can create local account after local account and it gets all the groups but not the AD accounts.
The groups are:
audio
video
render
i2c
gdm
gpio
weston-launch
Once we added the AD accounts to these groups, they were able to log in just fine and have everything available to them.
This has not been an issue on any other “regular” Ubuntu 20.04 machines. And I know this isn’t an Ubuntu forum but I feel like there is something in the way this particular set up of the kernel that is disrupting the process of this particular account creation. Hopefully a moderator or someone has an idea?