I cannot join 15.3 / 15.4 at all. 15.4 claims it cannot find the DC for our domain (I did check the SRV records, they are there, and it works for 15.0 … 15.2 so …).
Also the YaST logfiles for krb5.conf and smb.conf show sections with “(null)” for the REALM config line. Something is not right. resolv.conf are identical for all versions.
# krb5.conf
[realms] (null) = {
kdc = xxx.xxx.xxx (it's the right one)
}
# smb.conf
[global]
create krb5 conf = no
include = /etc/samba/dhcp.conf
kerberos method = secrets and keytab
realm = (null) <-- this is not right
security = ads
workgroup = ADS
cups options = raw
Yast error message
Failed to join domain: failed to find DC for domain XXX - The object was not found
15.3 immediately complains
Cannot use the workgroup XXX for Linux authentication. Enter a domain or disable using SMB for Linux authentication.
I would be glad if someone could try AD joining Leap clients. With tumbleweed I have identical issues as with 15.4
Not really successfully. I’ve managed to “semi-join” using “realm” (part of realmd package). Now it claims to be a member server, but the LDAP server IP is unset. Very unhappy. “sssd” appears to be in some sort of startup / crash loop.
Using net ads join + winbind also did something, but essentially it ain’t working for me.
Tested with fresh 15.3 VM in VMware, bog standard 2019 DC’s, DNS hosted on the DCs themselves and SUSE box has both set via resolv.conf.
You’re not using .local as the domain name by the way? That might cause issues.
Fresh box;
YAST > Network Services > Windows Domain Membership
Type domain.fi
Use SMB Information for Linux Authentication
Create Home Directory on Login
Offline Authentication
Single Sign-on for SSH
YAST wants to install krb5-client… wait a moment.
"This host is not a member of the domain <SOMETHING>.
Join the domain <SOMETHING>
Yes > Username Domain Admin + Pass > Domain <SOMETHING> joined successfully > Machine account successfully created and net getdomainsid gives proper SID for machine, net ads info gives proper info.
No. I use our official domain name. DNS resolvable and all. It works up until Leap 15.2 (with smb.conf fix). I will check if 15.3 works with apparmor off. The last test was with tumbleweed.
#Leap 15.0 (AD joined - everything OK):
LDAP server: "valid IP"
LDAP server name: "valid FQDN of a DC" resolving to LDAP server IP
Realm: "valid FQDN" of our domain (unique)
Bind Path: dc=XXX,dc=YYY,dc=ZZZ (same as realm)
LDAP port: 389
Server time: Thu, 19 May 2022 19:58:08 CEST
KDC server: "valid IP" (same as LDAP server)
Server time offset: 0
Last machine account password change: Thu, 19 May 2022 00:11:59 CEST
#Leap 15.1 (AD joined - everything OK):
LDAP server: "valid IP" (different one, we have multiple DC)
LDAP server name: "valid FQDN of a DC" resolving to LDAP server IP
Realm: valid FQDN" of our domain (unique)
Bind Path: dc=XXX,dc=YYY,dc=ZZZ (same as realm)
LDAP port: 389
Server time: Thu, 19 May 2022 20:02:37 CEST
KDC server: "valid IP" (same as LDAP server)
Server time offset: 0
Last machine account password change: Thu, 19 May 2022 10:18:28 CEST
#Leap 15.2 (AD joined - mostly OK - some smb.conf tweaking after joining):
LDAP server: "valid IP" (different one, we have multiple DC)
LDAP server name: "valid FQDN of a DC" resolving to LDAP server IP
Realm: "valid FQDN" of our domain (unique)
Bind Path: dc=XXX,dc=YYY,dc=ZZZ (same as realm)
LDAP port: 389
Server time: Thu, 19 May 2022 20:03:17 CEST
KDC server: "valid IP" (same as LDAP server)
Server time offset: 0
Last machine account password change: Thu, 19 May 2022 10:32:14 CEST
#Leap 15.3 (AD join fails):
LDAP server: 0.0.0.0
LDAP server name: (null)
Realm: (null)
Bind Path: (null)
LDAP port: 0
Server time: Thu, 19 May 2022 20:03:30 CEST
KDC server: "valid IP" (same as LDAP server should be) - IP resolves to proper name with nslookup
Server time offset: 0
Last machine account password change: Thu, 01 Jan 1970 01:00:00 CET
On Leap 15.1 I can run “net ads info -S DC.xxx.xxx.xxx” against all of our DCs and it gives proper results for all of them.
Doing the same on Leap 15.3 I get one usable result and all the other ones fail with the (null) pest. So the chances of getting the right one (round robin DNS) are rather slim.
