a fresh install of Fedora 42 workstation with lates updates and patches installed
an enterprise Microsoft Active Directory
needed user rights to enroll a device with the AD
What I want to achieve:
I want to enroll a Fedora 42 Workstation with the AD and let Domain Users login to the graphical environment, Gnome in this case.
What works:
Enrolling the device with the directory is successful, I’m using:
realm --user --computer-ou= <my.domain.net>
Afterwards I can login on a bash with domain user login credentials.
Login to Gnome session with local user
What does not Work:
Login to the Gnome Desktop environment with domain user
What I did so far:
enabled GDM debug:
vi /etc/gdm/custom.conf
uncomment “Enabled=true” in [debug]-section
installed oddjob, oddjob-mkhomedir and make ist active: systemctl enable --now oddjobd.service
The output of the AD enrollment, as well as the debug log of GDM can be found in the log attached.
[Edit:] I just saw that I cannot attach files here… It can be found here
My gutfeeling makes me believe that something in the process of creating the home folder not working as it should.
When I log into the ad user in bash, the home folder does exist, but it contains only some “.bash*” files, as well as
a mozilla .cache-folder. No “.local”, “.config”, or “.gnome”.
When I log into Gnome with a local user and try to add an enterprise user via Setting → System → Users, I can enter the domain
and user credentials of the user I want to add and press “add”, but the process runs forever.
The log shows org.gnome.Settings.desktop constantly triggering “Perform LDAP DSE lookup” on the different DCs which realmd always
answers back with “Successfully discovered”.
When this process is canceled, a coredump is created for gnome-control-center → “Process 8024 (gnome-control-center) crashed in cc_realm_manager_discover()”
At the moment, I’m completely stuck and any kind of help is much appreciated.
Have you tested with your user and the sudo pw. You are logging in with root … it tries to create a home dir:
“/usr/libexec/oddjob/mkhomedir,”
I guess this is somehow failing. The root users home is in /root while the users home is in /home/username
And also by default you should not be able to log in to gnome with root!
I’m a bit confused - I switched to root by “sudo -i” just to do the domain-enrollment.
I never tried to login as root directly.
The login attempts are done via GDM greeter by selecting “Not listed?”.
For me it looks like the authentication of the active directory user is successful, but something between gdm, dbus and wayland seems to be broken.
I found this:
gdm-wayland-session[5960]: Gdm: could not fetch environment: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
followed by this:
/usr/libexec/gdm-wayland-session[5960]: Unable to register display with display manager
gdm-wayland-session[5960]: Gdm: Running wayland session
gdm[4348]: Gdm: GdmManager: trying to register new display
gdm[4348]: Gdm: Finding a graphical session for user 1613568507
gdm[4348]: Gdm: GdmManager: Unable to find display session for uid 1613568507: Could not find a graphical session for user 1613568507
gdm-wayland-session[5960]: Gdm: Could not register display: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No display available
As mentioned earlier by default gnome/fedora not lets you enter with root into the graphical interface.
gdm[4348]: Gdm: GdmManager: Unable to find display session for uid 1613568507: Could not find a graphical session for user 1613568507
gdm-wayland-session[5960]: Gdm: Could not register display: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No display available
To make it correct, create a user like (in my case) ilikelinux_admin in your active directory. Otherwise you will not know who messed on your system if you just use a general admin account. If you not managing something on your system you would use a normal user like ilikelinux
Good morning,
I think, there is a misunderstanding. ”admin” is the user I created wehen Fedora was installed. It is the only local user and it is from type “Administrator”.
To join the machine to the active directory, which is a process that requires higher privileges, I did sudo -i and as user root I did the AD join.
gdm[4348]: Gdm: GdmManager: Unable to find display session for uid 1613568507
shows the uid 1613568507 which is a mapped uid from an AD user. In the log I posted, I had to obfuscate AD-usernames and AD-domain names, so 1613568507 is represented by <ad-user> in the log.
I indeed saw that I included in the log a login to the graphical environment by admin, but just to prove that a login to the graphical environment is possible.
I see, did you not write that you run a bash script after enrolling the machine to the AD ?
You said the enrollment you made with sudo - i wich opens a bash shell making you root. If you now try to create a home directory without specifie the user, it tries to create a root home drive on a AD server which you not are allowed to do.
Normally home drives are created while logging in with a registred AD user. It creates a local profile and syncs it with the server. It saves it back when logging out.
I know that you not logged in as root directly. However the log you posted, shows clearly that you not had the rights to create a homedrive because in the bash shell you where still root ?!
You might have to start the script informing the user as a parameter, for which you like to create the homedrive?
did you not write that you run a bash script after enrolling the machine to the AD ?
No, I didn’t use a bash-script at any point.
And I didn’t create a home-folder manually. I simply became root by sudo -i, and enrolled the device with realm -v join --user=<ad-admin-user> --computer-ou=<an OU where I'm allowed to put computer in> <my-ad.domain.net>
The home-folder for a AD-user is created when he first tries to login, that’s not the issue. The problem is the graphical session which cannot be established.
The issue is not related to the ad-user, or the authentication against the ad by sssd. When the same user for whom the graphical login does not work, do login to a shell (for example a second terminal via shift+strg+F2) he can perfectly log in. The home folder is already populated with:
drwx------. 1 <ad-user>@<my-ad.domain.net> domain users@<my-ad.domain.net> 92 Oct 16 13:56 .
drwxr-xr-x. 1 root root 68 Oct 16 13:56 ..
-rw-------. 1 <ad-user>@<my-ad.domain.net> domain users@<my-ad.domain.net> 18 Oct 16 13:56 .bash_logout
-rw-------. 1 <ad-user>@<my-ad.domain.net> domain users@<my-ad.domain.net> 144 Oct 16 13:56 .bash_profile
-rw-------. 1 <ad-user>@<my-ad.domain.net> domain users@<my-ad.domain.net> 522 Oct 16 13:56 .bashrc
drwx------. 1 <ad-user>@<my-ad.domain.net> domain users@<my-ad.domain.net> 0 Oct 16 13:58 .cache
drwx------. 1 <ad-user>@<my-ad.domain.net> domain users@<my-ad.domain.net> 34 Oct 16 13:56 .mozilla
What I stumbled over are the missing folder like .local or .config where Gnome stores it’s stuff.
From the following lines in the log, GDM tries to start a graphical session for the user, but has some trouble with display or dbus:
fedora gdm-wayland-session[5960]: Gdm: Running wayland session
fedora gdm[4348]: Gdm: GdmManager: trying to register new display
fedora gdm[4348]: Gdm: Finding a graphical session for user 1613568507
fedora gdm[4348]: Gdm: GdmManager: Unable to find display session for uid 1613568507: Could not find a graphical session for user 1613568507
fedora gdm-wayland-session[5960]: Gdm: Could not register display: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No display available
Anything relevant in sudo ausearch -m avc and have you tried putting SELinux into permissive mode to rule it out of preventing stuff from being created? (sudo setenforce 0)
Do you have a sub-directory being created in /run/user/ for the freshly authenticated user account?
OK - well I assume not having a /run/user entry for the user will give Wayland nowhere to store it’s sockets, locks and whatever else is required to fire up a graphical interface on Wayland.
It’s not SELinux preventing the creation then, as running in permissive mode should have allowed whatever was attempted to happen and popped out an AVC about it in the log.
The “collective hivemind” reckons the following but I’m no “AD on Linux” expert so I assume this means more to you than it does to me - it makes sense what it’s doing, but I can’t verify it’s correct: