Joining a windows domain using YaST - fundamental changes since Leap 15.2 / .3 / .4 ?

[robert_spitzenpfeil]

At work I can join the following OS using YaST without any issues whatsoever:

Leap 15.0
Leap 15.1

I can configure pam to allow console / xdm logins. pam_mount works as well.

With Leap 15.2 I have to make adjustments to smb.conf to get it working. krb5.conf are identical between 15.2 and 15.1

15.2 smb.conf offending section (bad):

idmap config * : backend = tdb
idmap config * : range = 10000-20000
idmap config ads : backend = rid
idmap config ads : range = 20001-99999

15.1 smb.conf equivalent section (good):

idmap gid = 10000-20000
idmap uid = 10000-20000

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

[deano_ferrari]

[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

Manually configure the 'realm = ' entry as required?
https://wiki.samba.org/index.php/Set..._smb.conf_File
https://wiki.archlinux.org/title/Act...iguration_file

[deano_ferrari]

Have you tried joining the AD manually? (Sorry I can only offer general advice here as I do not have a domain environment.)

[robert_spitzenpfeil]

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.

[Miuku]

[global]
        security = ADS
        realm = DOMAINHERE
        workgroup = WORKGROUPHERE
        log file = /var/log/samba/%m.log
        kerberos method = secrets and keytab
        client signing = yes
        min protocol = SMB3
        disable spoolss = yes
        max protocol = SMB3
        winbind use default domain = yes
        winbind enum users = Yes
        winbind enum groups = Yes
        winbind offline logon = yes
        winbind expand groups = 2
        template homedir = /home/%D/%U
        template shell = /bin/bash
        usershare allow guests = No
        winbind refresh tickets = yes
        max open files = 940790
        ea support = yes
        lm announce = yes       
        local master = no
        domain master = no
        case sensitive = true
        use sendfile = yes
        large readwrite = yes
        getwd cache = true
        block size = 262144
        idmap gid = 10000-20000
        idmap uid = 10000-20000

No problems with 2016/2019 domain here.

AD DNS is used.

[robert_spitzenpfeil]

Did you joing with YaST?

I've progressed a bit further. After completely disabling apparmor, I can join our domain with YaST. Still winbind auth fails...

[Miuku]

Did you joing with YaST?

Yes, no issues.

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
[x] Use SMB Information for Linux Authentication
[x] Create Home Directory on Login
[x] Offline Authentication
[x] 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.

[robert_spitzenpfeil]

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.

[robert_spitzenpfeil]

Hmmm...

For me 15.3 has some issues with "SambaAD.pm(SamaAD::GetRealm)", which returns "(null)" in my case.

#y2log

2022-05-19 18:29:05 <1> XXX.client-fqdn(1858) [Perl] modules/SambaAD.pm(SambaAD::GetADS):112 get ads: workgroup: "FQDN"
2022-05-19 18:29:05 <1> XXX.client-fqdn(1858) [Python] modules/SambaAPI.py(GetLDAPDS):30 Found LDAP/DS server "XXX.DC.FQDN" via cldap ping
2022-05-19 18:29:06 <1> XXX.client-fqdn(1858) [Perl] modules/SambaAD.pm(SambaAD::GetADS):232 returning server: "XXX.DC.FQDN"
2022-05-19 18:29:06 <1> XXX.client-fqdn(1858) [Python] modules/SambaAPI.py(ADDomain2Workgroup):42 workgroup: ADS
2022-05-19 18:29:06 <1> XXX.client-fqdn(1858) [Perl] modules/SambaAD.pm(SambaAD::GetRealm):300 realm: (null) <-- this should be "FQDN" (as with 15.0 / 15.1 / 15.2)

[robert_spitzenpfeil]

Said perl module also tries to create a "dummy-conf" for getting info on the "realm". That file is empty :-(

Fresh install of 15.3 - apparmor off - firewall off - I can ping our domain - I can do DNS lookups of the domain, DCs and so forth.