AD Member doesn't keep membership after reboot

Hello everybody,
I don’t know exactly when this problem started, but it was after an minor system update.

I have here a rocky linux 9.4 file server. As file system I use ZFS and the shares goes mostly over samba.

The server is part of an Windows AD, and that was running smoothly all the time. But now after a reboot, Linux and Mac clients can not connect with AD credentials any more. What helps is, when I run:

realm leave domain.org
realm join --membership-software=samba --client-software=winbind domain.org

Or:

 net ads join -S domain.org -U "DOMAIN\administrator"

Do you have ideas, why this is happen, and what I can do?

Don’t know about the realm option because you shouldn’t be using realm with Samba, are you using sssd as well ? If so, bad idea.

As for the ‘net ads join’ command, ‘-S’ is supposed to point to a server, yours appears to be pointing to a dns domain and you shouldn’t need to use it anyway.

I think you need to post the output of ‘testparm -s’

Thank for answering @hortimech!

I use manly the steps from redhat to get the system working. I don’t use sssd, instead winbind.

Dump from testparm -s is:

Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

Server role: ROLE_DOMAIN_MEMBER

# Global parameters
[global]
	additional dns hostnames = nas.lan.example.org
	deadtime = 15
	disable spoolss = Yes
	kerberos method = secrets and keytab
	load printers = No
	map to guest = Bad User
	max open files = 163840
	max xmit = 65535
	printcap name = /dev/null
	realm = DOMAIN.INTERN
	security = ADS
	server min protocol = SMB2
	template homedir = /home/%U@%D
	template shell = /bin/bash
	usershare allow guests = Yes
	winbind offline logon = Yes
	winbind refresh tickets = Yes
	wins support = Yes
	workgroup = DOMAIN
	fruit:delete_empty_adfiles = yes
	fruit:wipe_intentionally_left_blank_rfork = yes
	fruit:zero_file_id = yes
	fruit:veto_appledouble = no
	fruit:posix_rename = yes
	fruit:model = MacSamba
	fruit:aapl = yes
	fruit:nfs_aces = no
	fruit:encoding = native
	fruit:locking = netatalk
	fruit:resource = xattr
	fruit:metadata = stream
	elasticsearch:ignore unknown type = yes
	elasticsearch:ignore unknown attribute = yes
	elasticsearch:port = 9200
	elasticsearch:address = localhost
	idmap config * : range = 10000-999999
	idmap config DOMAIN : backend = rid
	idmap config DOMAIN : range = 2000000-2999999
	idmap config * : backend = tdb
	delete veto files = Yes
	hide files = /._.*/._*/.DS_Store/Network Trash Folder/TheFindByContentFolder/TheVolumeSettingsFolder/Temporary Items/.TemporaryItems/.VolumeIcon.icns/.FBCIndex/.FBCLockFolder/
	level2 oplocks = No
	printing = bsd
	spotlight backend = elasticsearch
	use sendfile = Yes
	vfs objects = catia fruit streams_xattr

[archiv]
	comment = Archive Storage Share
	create mask = 0664
	directory mask = 0775
	path = /mnt/exp1/archiv
	read only = No


[backup]
	comment = Backup Storage Share
	create mask = 0664
	directory mask = 0775
	force create mode = 0664
	force directory mode = 0775
	path = /mnt/exp1/backup
	read only = No
	valid users = DOMAIN\backup


[clonezilla]
	comment = CloneZilla Storage Share
	create mask = 0664
	directory mask = 0775
	path = /mnt/exp1/clonezilla
	read only = No
	valid users = +DOMAIN\Domänen-Admins


[gitea]
	comment = Gitea Storage Share
	create mask = 0664
	directory mask = 0775
	path = /mnt/exp1/gitea
	read only = No
	valid users = DOMAIN\user DOMAIN\backup


[playout]
	comment = Playout Storage Share
	create mask = 0664
	directory mask = 0775
	path = /mnt/exp1/playout
	read only = No


[public]
	comment = Public Storage Share
	create mask = 0664
	directory mask = 0775
	path = /mnt/exp1/public
	read only = No
	spotlight = Yes

...

That looks fairly okay, but I have a few comments:

These parameters are set, but do not need to be, they are all set to the default:

	server min protocol = SMB2
	fruit:aapl = yes
	fruit:model = MacSamba
	fruit:posix_rename = yes
	fruit:zero_file_id = yes
	elasticsearch:port = 9200
	elasticsearch:address = localhost

Do you really want guest access, none of your shares are set to be accessible by a guest user, not even the one named ‘public’ ?

	map to guest = Bad User

Why have you set this ? you shouldn’t need to touch it:

	max open files = 163840

You have a couple of old SMBv1 related parameters, but you are not using SMBv1:

	max xmit = 65535
	wins support = Yes

This only really works with a ZFS filesystem:

	fruit:resource = xattr

Finally, we come to the ‘idmap config’ lines, which will work:

	idmap config * : backend = tdb
	idmap config * : range = 10000-999999
	idmap config DOMAIN : backend = rid
	idmap config DOMAIN : range = 2000000-2999999

Those allow for 989,999 users or groups in the default ‘*’ domain. The default domain is meant for the Well Known SIDs (there are less than two hundred of them) and anything outside the ‘DOMAIN’ domain (so really 0), <200 != 989,999, why redhat doesn’t use the Samba recommended range of 3000-7999 (which is still really too large) I do not know, unless you have already saved data to your fileserver, I would change them to:

	idmap config * : backend = tdb
	idmap config * : range = 3000-7999
	idmap config DOMAIN : backend = rid
	idmap config DOMAIN : range = 10000-2999999

I suspect that your problems lie elsewhere, so can you post the contents of the following files (sanitised if must):
/etc/hostname
/etc/hosts
/etc/resolv.conf
/etc/krb5.conf
/etc/nsswitch.conf

Thanks for your suggestions! Some parts of that config a very old, maybe that is way it still contains parts that is not necessary any more.

You say:

unless you have already saved data to your fileserver, I would change them to

The file server is in use, so it is not save to change this idmap settings?

I see also that I have a command out parameter:

# password server = DOMAIN.intern

That is not needed, right?

The output from the requested files are:

/etc/hostname:

nas.lan.example.org

/etc/hosts:

10.10.0.19	nas.lan.example.org nas

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

/etc/resolv.conf:

# Generated by NetworkManager
search lan.example.org
nameserver 192.168.0.3
nameserver 192.168.0.4
nameserver 10.10.0.1

/etc/krb5.conf:

# To opt out of the system crypto-policies configuration of krb5, remove the
# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.
includedir /etc/krb5.conf.d/

[logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

[libdefaults]
    dns_lookup_realm = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    rdns = false
    pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
    spake_preauth_groups = edwards25519
    dns_canonicalize_hostname = fallback
    qualify_shortname = ""
    default_ccache_name = KEYRING:persistent:%{uid}
    udp_preference_limit = 0
    default_realm = DOMAIN.INTERN


[realms]
# EXAMPLE.COM = {
#     kdc = kerberos.example.com
#     admin_server = kerberos.example.com
# }

[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM

[plugins]
    localauth = {
        module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so
        enable_only = winbind
    }

/etc/nsswitch.conf:

passwd:     files winbind systemd
group:      files winbind systemd

shadow:     files
hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname
services:   files sss
netgroup:   sss
automount:  files sss

aliases:    files
ethers:     files
gshadow:    files
networks:   files dns
protocols:  files
publickey:  files
rpc:        files

Maybe what is important also:
I have two networks: 129.268.0.0 and 10.10.0.0. The file server is in network 10.10.0.0, but the AD is in the other network. Routing and everything is fine. The AD domain name is domain.intern, but the computers in the 10.10.0.0 network has *.lan.example.org domains.

Maybe is not to optimal to have different domain names, but in the past that was never a problem.

Samba ADS, from my experience, requires all computers to be in the same DNS domain, there are ways around this, but, again from my experience, these always have problems. Now being in the same DNS domain doesn’t mean the computers have to be on the same site or in the same subnet, AD has a thing called ‘sites’, but this will require a DC in the 10.10.0.0 subnet (could be a Samba AD DC)

Where to go from here will depend on you.

The windows computers from 10.10.0.0 network register to the domain.intern DNS, computers that I wanted to have a *.lan.example.org domain, I have to add manually. So I guess that should be fine then, without a second site, or not?

AD is basically composed of ldap, kerberos, dns and time.
ldap to store the directory.
kerberos for authentication
dns so kerberos knows who is who
time so everything keeps to the same time, plus or minus 5 minutes.

It gets very complicated on the kerberos side if there are two dns domains, what with UPNs, SPNs and tickets, there is just so much that can go wrong. Now Windows DCs may be able to deal with this, but I don’t think Samba can, it may be able to do so in the future, who knows. Windows can do ‘sub’ or ‘child’ domains, Samba cannot.

If you do not want to go down the ‘site’, the alternative would be to setup a new Samba domain and set up a trust between that and your existing AD domain. Or you could setup an ldap server and proxy that to your AD domain, but that would only give you authentication.

Ok, that sounds like, I have a bit work to do :-(. I will check your suggestions more deeply.

Just to be sure: the problem would not be much the different IP ranges, but the different DNS suffixes? Even when the reverse entry can’t be setted, for one subnet?

In general I would be fine, to have only one DNS suffix, but we have some complicate accounting software in the network, which is why I didn’t dare to change anything about the domain. The domain name comes from another decade and causes some problems. A few years ago, for this reason and with a view to greater security, I started to put at least everything that has nothing to do with accounting into a different subnet and to give it a different DNS suffix. Which has worked well so far.

The real problem is the kerberos, is works using a realm, which is always the DNS domain in uppercase, so if the DNS domain is ‘example.com’, the realm would be ‘EXAMPLE.COM’. There are also things called UPNs and SPNs (User Principal Names and Service Principal Names), these all end with the realm e.g. ‘@EXAMPLE.COM’, so unless they ‘match’ the realm, kerberos isn’t going to work.

Thanks for all your explanations! I have read and think a bit more now, and would try to create a second DC with the correct domain. I think that is cleaner and also faster.

One last update: I tried a bit with a second domain, but in the long run I think the maintenance is not worth it.

I changed the hostname and DNS from the file server to the DC domain name, and now everything works as it should. I can still use my other DNS suffix for other services not related to the DC…

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