Samba - join domain windows server 2022

I replaced the domain controller from Windows Server 2012 with 2022.
Unfortunately Samba is not connecting properly, which causes the proxy to malfunction.

My current configuration:

Setup: domain name – MPWIK
DNS forward configuration → ZONE MPWIK.local → 192.168.0.5

In resolv.conf:
search MPWIK
nameserver 192.168.0.5
options edns0 trust-ad

As a result, I have all green statuses, but it still doesn’t recognize domain usernames and domain user names are not being passed to the proxy.

Has anyone here managed to get past this issue?

check this post for possible solution.

I created the file: /var/ipfire/suricata/rules/local.rules

I added the following entries:

1. Suspiciously high number of Kerberos AS-REQ → enumeration / brute-force / password-spray

alert udp any any → 192.168.0.5 88 (msg:“AD - Kerberos AS-REQ – possible brute/enumeration”; flow:to_server; content:“|a1 03 02 01 05 a2 03 02 01 0a|”; depth:10; threshold:type both, track by_src, count 12, seconds 30; classtype:attempted-admin; sid:1000001; rev:2;)

2. LDAP brute-force / enumeration (high number of binds / searches)

alert tcp any any → 192.168.0.5 389 (msg:“AD - LDAP high rate – possible brute/enum”; flow:to_server,established; threshold:type both, track by_src, count 60, seconds 60; classtype:attempted-recon; sid:1000002; rev:1;)
alert tcp any any → 192.168.0.5 636 (msg:“AD - LDAPS high rate – possible brute/enum”; flow:to_server,established; threshold:type both, track by_src, count 60, seconds 60; classtype:attempted-recon; sid:1000003; rev:1;)

3. SMB / NTLM – brute-force or relay attempts (high number of SMB sessions)

alert tcp any any → 192.168.0.5 445 (msg:“AD - SMB/NTLM high connection rate – brute/relay?”; flow:to_server,established; threshold:type both, track by_src, count 25, seconds 60; classtype:attempted-admin; sid:1000004; rev:2;)

4. Suspicious Kerberos – AS-REP Roasting (replies without pre-authentication)

alert udp any any → 192.168.0.5 88 (msg:“AD - Kerberos AS-REP no preauth – roasting?”; flow:to_server; content:“|a0 03 02 01 0a|”; sid:1000005; rev:1; classtype:attempted-admin;)

5. Zerologon / other critical Netlogon exploits (port 135 + 445 + specific bytes)

drop tcp any any → 192.168.0.5 135 (msg:“AD - Netlogon suspicious – possible Zerologon style”; flow:to_server; content:“|05 00 0b 03 10 00 00 00”; depth:8; sid:1000006; rev:1; classtype:attempted-admin;)

6. Block all traffic from untrusted subnets (very restrictive – use with caution!)

drop ip !$HOME_NET any → 192.168.0.5 any (msg:“AD - traffic to DC from outside HOME_NET – block”; sid:1000010; rev:1;)

IT DIDN’T HELP. GROK says it’s a problem in this version of Samba

Lowering restrictions on the domain controller still doesn’t help at all….

  1. Microsoft network server: Digitally sign communications (always) → Disabled
  2. Microsoft network client: Digitally sign communications (always) → Disabled
  3. Domain controller: LDAP server signing requirements → None
  4. Network security: Configure encryption types allowed for Kerberos → AES128 + AES256 + RC4

Samba 4.23.5-119 from the testing repository also doesn’t solve the problem.

I tried various Samba settings from the list below (which I found online for other distributions), but unfortunately this still does not resolve the problem.

winbind use default domain = yes
winbind refresh tickets = yes
winbind enum users = no
winbind enum groups = no

idmap config * : backend = tdb
idmap config * : range = 3000-7999

client schannel = no
server schannel = no
server schannel require seal = no
ntlm auth = ntlmv2-only

Do you use IPFire’s IPS with suricata?

If yes,
a) which rulesets do you use?
b) did you try to switch temporarily off IPFire’s IPS?
c) do you see any smb, ntlm, or your server related messages in IPFire’s IPS Log?

a) I’m using the latest version of IPFire + I also tested version 201 – meaning all versions that come with Suricata
b) yes, that didn’t help
c) no

a) I’m using the latest version of IPFire + I also tested version 201 – meaning all versions that come with Suricata
b) yes, that didn’t help
c) no

Thanks, because of

b) yes, that didn’t help

IPS Suricata is not the root cause of your problems. Changing or adding /var/ipfire/suricata/rules/local.rules won’t help.

Can you see any samba related messages in /var/log/messages?