YAST2 domain join breaks Tumbleweed

Hello everyone,

I’d like to confirm the problems first described by @His.Dudeness on 01.01.2025 in https://forums.opensuse.org/t/tumbleweed-wont-boot-after-windows-domain-join/181510/6. Unfortunately, his issue has remained unresolved (at least to my knowledge). Joining a Microsoft AD domain using YAST2s “Windows domain membership” option seems to completely break the install. I have tried multiple clean installs of openSUSE Tumbleweed Snapshot 20250304 on a Lenovo ThinkaPad X13 and was able to replicate this issue each and every time. Joining the domain prevents the user from rebooting from the GUI, only sudo reboot seems to do the trick. During the reboot openSUSE gets stuck at the plymouth bootscreen with an error message saying something along the lines of “start job is running for create static device nodes in dev gracefully”. I suspected the full disk encryption to be part of the problem, but the boot process failed even without LUKS enabled. Instead multiple different error messages got displayed, that i unfortunatley cannot recall anymore. Applying changes to /etc/nsswitch.conf in a recovery environment as described in https://forums.opensuse.org/t/boot-failure-failed-to-start-create-static-device-nodes-in-dev/178966/7 returned the system to a bootable state.

After some more tinkering I followed the steps described in https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-security-ad.html#sec-security-ad-sssd, but using YAST2s “User logon management” option only results in a bug, that got first described in 2022 (https://forums.opensuse.org/t/user-logon-blank-workgroup/142279/24)… As far as I know, it should not be necessary to create an empty forward lookup zone for the .local domain. I’ve connected many different Linux clients to multiple ad domains over the years and have never needed this option.

After several attempts, I decided to do another clean install and fallback to manually installing the necessary software (realmd, sssd, adcli). Had to edit some config files, but ended up with a reasonably functional ad join within minutes (system boots and allows me to log in with my ad credentials). I feel like this should be the expected behaviour of both YAST2 modules. Maybe I missed a point, maybe the forward lookup zone for .local should be there by default, or maybe YAST2 could use some tweaking in this regard. I’m open to any feedback, maybe we can find a solution so that any enterprise customer who want to give openSUSE a try can easily join their machines in their domain.

Best regards
Sebastian

You are in the best position to debug it. Find out what YaST does differently (incorrectly) and submit bug report.

Hello @arvidjaar, thanks for the reply. Do you have any tips for debugging yast2 other than y2log? More than happy to collect some data and open up a bug report, but i was hoping for some users to share their experience on this topic.

I did not say “debug yast2 code”. I said “compare the non-functional configuration yast created with the functional configuration you created manually and submit bug report showing the difference”.

Oh, I wasn’t going to debug YAST2 code, I’m not qualified enough for that anyway. At this point we should also ignore the whole “problem” regarding YAST2s “Windows domain membership” option for now, since I actually havent tried to manually join the notebook using winbind yet… It might be a completely different issue, and if so, deserves it’s own investigation and bug report.

I can’t compare the configuration files created by YAST2 since the setup fails way before any config file is actually written or changed. I think the actual question/problem is: Is the behaviour of net ads lookup -S domain.local not returning the workgroup if there’s no forward lookup zone for .local expected or not? realmd seems to handle all of this internally without any additional lookup necesseray, it also returns the correct realm.

If you don’t see any point in having this conversation on the forums, please let me know and I’ll file a bug report instead.

At least nice to see that I am not completely stupid and someone else has the same problem.

If I was able to reproduce it on different hardware and somebody else too, and a basic function accessible via built-in GUI (next, next, done) renders the system completely broken - shouldn’t the OpenSUSE developers be interested to work on this bug and fix it?

I tried to deliver info in my post and I would be willing to help (within my means as linux noob) and further work on this, but I didn’t even get a response … :expressionless:

a) This is user to user forum where no developers are present.
b) Even as user to user - most users here are private users and so do not really have any experience with AD nor necessary infrastructure to reproduce your issue even if they would like to do it.

Which post? This is your first post in this topic and post is 2 hours old. If you expect mandatory response in this timeframe, you really need to pay for it.

Anyway, the proper channel to report bugs is bugzilla.

The very first post in this thread references @His.Dudeness separate post about this subject … that post is Closed

Correct! That is the post I meant. It was closed automatically after a month without any response.

But I guess that bugzilla is maybe a better place for a bug report…

Hello everyone,

no need to escalate this issue any further in the forum. I agree that this post might have been better off on Bugzilla from the get go. I’ll try to collect some more information over the next two weeks, maybe we could use this post to collect even more data from other users, in case anyone else experienced similar issues. After that I would like to open up a bug report.

Have a nice one
Sebastian

Great! Thanks! Let me know if you need any data. I still got my VM with a clean snapshot and I think I can reproduce the issue any time :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.