user logon - blank workgroup

In the offical documentation is indicated that:

[FONT=inherit][FONT=inherit]User Logon Management. [/FONT] Use both an identity service (usually LDAP) and a user authentication service (usually Kerberos). This option is based on SSSD and in the majority of cases is best suited for joining Active Directory domains.[/FONT]
This module is described in Section 7.3.2, “Joining Active Directory Using [FONT=inherit]User Logon Management.

And doing steps indicated in section 7.3.2 I face the “blank” workgroup error.

So for the moment I prefer to open the bug indication.

Antonio[/FONT]

Hi,
I just took another look at the documentation and there is some important information that seems to be missing… <sigh>

The documentation you’re following (7.3.2) does not apply to the YaST module you’re using.

First, congrats on finding and installing the YaST Windows Domain Membership module (yast2-aducc). It’s not installed by default, and should do a good job connecting to a SAMBA 4 server or AD Domain configured to support older ntfs protocols(primarily NetBIOS) but not typical modern versions of MSWindows AD.

So, that’s why you can’t configure, SSSD, because this client doesn’t support that.

Instead, section 7.3.2 and its screenshots apply to the YaST Kerberos and LDAP client module which is installed by default and does support sssd (is not automatic, you still need to configure correctly following the documentation).

Your main options for setting up your machine to join an AD are described on the following page… But again, section 4.1 may not be written well because it isn’t clear of the 3 options the first and third would use the Kerberos and LDAP client module while the second would use the Windows Domain Membership module.

https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-security-auth.html

Hope that clears things up…

And, another reminder…
Although the documentation advises entering the IP address of the DC you’re connecting to, I still highly recommend creating appropriate /etc/hosts entries to ensure working name resolution during initial setup and not relying on networking services all working properly…
And, of course your NTP must (or highly, highly should point to the Domain NTP server which is often a DC)

TSU

Hi.

actually on the page I’m following (in section 7.3.2) it says:

To join an Active Directory domain using SSSD and the User Logon Management module of YaST, proceed as follows:

So the user logon management module of yast use sssd (realmd) to join the linux client to active directory.

For me the real problem is that in some way I have nscd activated and this cause conflicts with sssd.

I will try some tests on a clean openSuse installation and the let you know.

Also on Red Hat documentation it is indicated that sssd and nscd must not be used at the same time:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/usingnscd-sssd

Regards

Hi.

… my first post…

This thread is quite old but the problem still exists even in SUSE tumbleweed. And we probably found the reason and a possible solution today.

We had exactly the same problem as the original poster: “invalid configuration (“workgroup” set to ‘’, should be MADDANT)”
We found out that the GUI join runs a “net ads lookup -S schulung.local” in the background (schulung.local is my Active Directory domain).
And this fails becaucse it tries a DNS lookup for the parent domain “local” first which is not resolvable because schulung.local is our root domain and there is no DNS forwarding to some parent DNS server. Which is a normal situation in an isolated Active Directory network IMO.

We could solve the problem by creating an empty forward lookup zone for the domain “local” in our (Windows-) DNS-Server.
“net ads lookup -S schulung.local” runs fine after that and so does the domain join via sssd.

I would call this a bug in the net ads tool.

Regards, Andreas

Hi.

I have just tried indicated solution and I confirm that is working fine.

Best regards