Issue: unclear definitions of domainname case and adsys breaking dconf #1054
Comments
|
Hi, I did go through the hassle to reproduce the dconf issue once again to provide you with the bug report and some more infos! The file is attached. Additional Info: |
|
Thanks for this very complete bug report. We will have a look and keep you posted. |
|
The dconf part is the same issue of #1002 but I don't have experience on get logs and report errors |
|
Got the same issue, it's totally bricks endpoints with ubuntu 24.04 since adsys 0.9.2 isn't available there. |
jibel
changed the title
|
Hey, everyone! Here is an update on this:
Note: This didn't break authentication as DCONF would switch to using the default user profile, but it affected the possibility of changing any DCONF-related setting (such as the background picture).
# getent is a command for querying the NSS databases for entries
user@machine:~$ getent passwd [email protected]
[email protected]:*:{uid}:{gid}:user:/home/[email protected]:/bin/bash
user@machine:~$ getent passwd [email protected]
[email protected]:*:{uid}:{gid}:user:/home/[email protected]:/bin/bash
user@machine:~$ getent passwd [email protected]
[email protected]:*:{uid}:{gid}:user:/home/[email protected]:/bin/bashThus, if you change the config to As SSSD mainly deals with authentication, this is not a big deal. But ADSys has to deal with environment variables, DCONF values, mounts, and so on. So this has way more impact on it. TLDR: We are still discussing the best way (if there's any) to handle this without risking breaking sensitive stuff (there's a lot of these). Meanwhile, I suggest you editing the |
|
Hello @denisonbarbosa Thank you so much for fixing this issue and the info on the case issue! Thanks, appreciate it! |
|
Hey, @snussbaumermpreis. In adsys 0.9.2, we supported only the SSSD backend, so the codebase was very different from what we have in 0.13+, as we added support for the winbind backend also, which involved quite some changes in the code and it is now more generic (so we can't rely on some stuff that we used to before, when there was only SSSD). |
|
We are facing the dconf issue as well and it is a huge issue for us. Big company based in Spain. The dconf issue won't let us save keyboard mapping info so we are forced to use english keyboard layout instead of spanish. And the same happens with a lot of different settings. They just won't save and won't apply. As stated by @snussbaumermpreis , previous versions (0.9.2) worked like a charm but the latest won't. @denisonbarbosa any way to know when will the fixed version rollout to customers? Happy to help providing more info for debbuging, Kind regards |
|
Hey, @aitzubi! If you configure at least one DCONF policy through the AD controller, it should work (provided you keep the domain name lowercased, as mentioned here). As soon as the pull request is merged, we'll upload the fixes to a PPA so you guys can try it out while we proceed with the SRU to release the fixes into the archive. |
|
@denisonbarbosa it does not work. I've tried to use lowercase settings and it just does not work. I've also tried to remove the latest version of adsys and to reinstall the 0.9.2 version but it does not work. It gets installed but users are unable to login. Something related to be unable to read users gpos. I will open a ticket tomorrow with canonical because this makes our ubuntu fleet unusable due to be unable to save some critical settings. |
|
@aitzubi Hi, I have made the same observations under some circumstances. I would suggest you try to PURGE adsys 0.14 then reboot, and then try to install 0.9.2, at least this always worked for me. Also maybe try to clear SSSD cache (if you are using SSSD backend) if you change the Domainname case. Another possible issue with unreadable gpos is some gpos which are unable to be parsed by adsys, in my experience blocking inheritance and enforcing the gpos you want to apply can help here. BUT this has always been a computer gpo issue for me. I hope some of this is able to get you back to a working setup. |
|
Hi @snussbaumermpreis , You were right. After purging and rebooting, i was able to install 0.9.2 and it works without clearing sssd cache. Thanks! Nevertheless, this should be fixed asap as being unable to save settings is a deal breaker for non english adsys users. Just one question as i was unable to test it myself. Is certificate autoenrollment available in 0.9.2? Or was a feature that was added later? Thanks guys! |
|
Hey, guys! The fixed version (0.14.2) is now available at ppa:ubuntu-enterprise-desktop/adsys if you'd like to use it while we are preparing things for releasing the fixes into the archive. Thanks again for reporting the issue and helping us make adsys better! |
@denisonbarbosa i just tested it and I can confirm that it works! After installing it and rebooting, i logged in with my domain user and everything was working as expected. I can write in spanish after a couple of weeks! That's huge! Thank you very much and feel free to contact if you want me to test something. Kind regards, |
Is there an existing issue for this?
Describe the issue
**adsys does not accept uppercase domainnames and lowercase ones mixed like this:
This is only with newer Versions (0.14.1) older ones (0.9.2) worked, the result is a crash of the daemon with the following output:**
Now logins fail because of adsys pam.
The fix is obviously to change the domainname to lower case or all to uppercase. But as stated before older versions supported the Config of these Domainnames.
So sssd.conf then is for example:
But then the second issue arises (I don't know if they are really related, but it is definitly only with the newer versions).
The new user somehow does not get a dconf profile, and therefor can not change any settings saved in dconf/gsettings(Favorites, Background, Proxy Settings, Gedit does not work, ....). This is because the user now gets an environment variable: DCONF_PROFILE=[email protected] and that dconf profile does not exist and ~/.config/dconf/user is not created! So the user has no dconf profile where the settings could be saved as far as I understand this. This issue exists in new as well as existing users. The following error is thrown basically everywhere, some examples from syslog:
In summary:
adsys does not support uppercase Domainnames in sssd.conf at least since Version 0.14.1.
adsys somehow messes with the dconf profile and it does not get created.
Possible solutions:
Provide clear indications on how to format Domainnames (uppercase/lowercase) in sssd.conf! I have not found any documentation which mentions how this should be handled... Also it is unclear to me what case the mentions of the domain should have in the GPOs? -> Admingroups for sudo for example.
As I can not exactly say what the underlying problem with DCONF is someone should take a deeper look and fix the problem or provide a solution.
Steps to reproduce it
Domainname Case Issues:
Remidation:
Downgrade adsys to 0.9.2
It works again...
OR
Use lowercase domainname -> this leads to the dconf issue.
DCONF Issue:
Ubuntu users: System information
Report for the case issue in domainnames:
Note: The entries connected to the error start at 14:30
adsysreport_caseissue.txt
Report for the issue with dconf:
I can not see how you would be able to spot anything related to this issue (which is not present in the bugreport above) in the system information here, if needed I can reproduce it again and upload this, but I currently do not neccesarilly want to got throught all the hassle with the user profile again, so I did not include this for now.
Non Ubuntu users: System information
Environment
adsysctl version/etc/os-release)/etc/os-release):Log files
Please redact/remove sensitive information:
Application settings
Please redact/remove sensitive information:
Additional information
If this makes any difference, please note our domainname has a two level tld:
domain.subtld.tld
I have also commented on the following issue:
(which is exactly the dconf issue), but as there was no response until now, and that case was also open since May and the original post hat had little info about the cause and link with adsys I decided to open this new one, do what you want with this. I am just hoping to get some kind of mitigation or fix for this issue...
I have opened a case with Canonical for this because it affects multiple production servers which can not be updated until a Mitigation or a Fix is provided.
Double check your logs
The text was updated successfully, but these errors were encountered: