Score:0

After logging in with my AD credentials, why can I not change any settings?

mn flag

I've been setting up a new machine with Ubuntu 22.04 Desktop. And since I'm on the IT team, I've been using it as an opportunity to broaden my knowledge of configuring Ubuntu for a work environment, as well as figure out how to correctly configure Ubuntu in case some other researcher/engineer in the organization ever wants to switch to Ubuntu.

One of the aspects I'm trying to get right is authenticating users using Active Directory.
I've got it working where I can log in using my AD creds, but then I can't seem to configure my settings any further.

Setup

My procedure to set up the machine was:

  1. Install Ubuntu 22.04, and create a local admin user (admin)
  2. Sign in to admin.
  3. Install updates.
  4. Install AD-related stuff for SSSD.
    sudo apt install sssd-ad sssd-tools realmd adcli adsys
    
  5. Join the domain.
    sudo realm -v join -U [MY-AD-ADMIN] organization.org
    
  6. Make some adjustments to the auto-generated /etc/sssd/sssd.conf, with the final result being...
    [nss]
    allowed_shells = /bin/sh,/bin/csh,/bin/bash,/bin/ksh,/bin/fish
    #debug_level = 0x0200
    
    [sssd]
    services = nss, pam, autofs
    config_file_version = 2
    domains = organization.org
    default_domain_suffix = organization.org
    full_name_format = %1$s
    #debug_level = 0x0200
    
    [domain/organization.org]
    ad_domain = organization.org
    use_fully_qualified_names = True
    realmd_tags = joined-with-adcli manages-system
    krb5_realm = ORGANIZATION.ORG
    krb5_store_password_if_offline = True
    cache_credentials = True
    ldap_id_mapping = False
    id_provider = ad
    access_provider = ad
    pwd_expiration_warning = 0
    default_shell = /bin/bash
    override_homedir = /home/%u
    fallback_homedir = /home/%u@%d
    debug_level = 0x0400
    
    • I set default_domain_suffix to the value you see so that I can log in with ad-username instead of having to type out ad-username@organization.org.
    • I set full_name_format and override_homedir to the values you see so that when I log in with my AD User, the home directory and file ownership also only have ad-username instead of ad-username@organization.org.

With all of this set up using my admin user, I logged out then logged back in using my AD creds. While the login process was completing, I saw a message that my home directory was being created, user settings applied, and thought all was good until I went to actually change settings.

The Problem(s)

After logging in as ad-username, I opened "Settings" and went about doing things like changing my desktop background, window appearance/colors, dock settings, favorited applications, notifications, power settings...

The exception seems to be that I can change my display's scaling from 200% to 100%, and that stays if I log out and log back in.
I can interact with the slider for "Fractional Scaling", but the "Scale" setting doesn't change to a dropdown, and the slider reverts back to off if I navigate to a different section of Settings.
I also cannot enable the "Night Light" setting.

Basically, anything and everything in settings could either not be changed, or the GUI showed it changing but reverted the changes as soon as I navigated away.

I would appreciate any suggestions on where to look for the root cause.

  • Is my machine trying to save my user's settings back to the AD servers?
  • Did I forget some property in my sssd.conf?
  • Is there something in Ubuntu that is preventing my AD User from changing any settings?
Score:0
mn flag

This isn't really an answer, per se, but I did resolve my issue.
.... I do wish someone could explain why things weren't working.

Anyway, solution!

Solution

I built a new sssd.conf file, this one using LDAP instead of AD options. The [nss] and [sssd] sections of the configuration file stayed the same, while the [domain/XXXX] section was redone as below.

[domain/organization.org]
use_fully_qualified_names = True
realmd_tags = joined-with-adcli manages-system
krb5_realm = ORGANIZATION.ORG
krb5_store_password_if_offline = True

ldap_uri = ldap://ldap.organization.org:389/
ldap_id_use_start_tls = False
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_schema = ad
ldap_default_bind_dn = CN=ldap_sssd,OU=SpecialUsers,DC=organization,DC=org
ldap_default_authtok_type = password
ldap_default_authtok = MySecretPassword!SSHHHHHH
ldap_search_base = OU=AllUsers,DC=organization,DC=org
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
ldap_id_mapping = False

id_provider = ldap
autofs_provider = ldap
cache_credentials = True
pwd_expiration_warning = 0
default_shell = /bin/bash
override_homedir = /home/%u
fallback_homedir = /home/%u@%d

debug_level = 0x0400
Score:0
ng flag

I've resolved my issue with stop & disable systemd-resolved service and add domain controller IP as nameserver in /etc/resolv.conf.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.