szakal
(Krzysztof Raczka)
2 February 2026 09:15
1
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?
hvacguy
(Shaun HVAC)
2 February 2026 11:04
2
check this post for possible solution.
I digged a bit deeper into my problem and found that the root cause was an update of some NTLM related emerging-info.rules located at /var/lib/suricata/emerging-info.rules on 26th January 2026:
grep -i ntlm /var/lib/suricata/emerging-info.rules
drop smb $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO Outbound SMB NTLM Auth Attempt to External Address"; flow:established,to_server; content:"|ff|SMB|73|"; content:"NTLMSSP|00 03 00 00 00|"; within:200; fast_pattern; cla
sstype:misc-activity; si…
szakal
(Krzysztof Raczka)
2 February 2026 12:42
3
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
szakal
(Krzysztof Raczka)
2 February 2026 13:47
4
Lowering restrictions on the domain controller still doesn’t help at all….
Microsoft network server: Digitally sign communications (always) → Disabled
Microsoft network client: Digitally sign communications (always) → Disabled
Domain controller: LDAP server signing requirements → None
Network security: Configure encryption types allowed for Kerberos → AES128 + AES256 + RC4
szakal
(Krzysztof Raczka)
2 February 2026 13:48
5
Samba 4.23.5-119 from the testing repository also doesn’t solve the problem.
szakal
(Krzysztof Raczka)
2 February 2026 14:26
6
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
ewald
(Ewald XYZ)
2 February 2026 14:40
7
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?
szakal
(Krzysztof Raczka)
3 February 2026 11:58
8
ewald:
Suricata
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
szakal
(Krzysztof Raczka)
3 February 2026 11:59
9
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
ewald
(Ewald XYZ)
3 February 2026 14:29
10
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?