Bug 11691 - smbd fails to accept connections from a different domain if NTLM authentication is disabled at DCs
Summary: smbd fails to accept connections from a different domain if NTLM authenticati...
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 4.3.4
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-24 20:06 UTC by Uri Simchoni
Modified: 2017-03-02 09:00 UTC (History)
4 users (show)

See Also:


Attachments
git-am fix for 4.3.next and 4.4.0 (11.65 KB, patch)
2016-02-24 05:44 UTC, Uri Simchoni
slow: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Uri Simchoni 2016-01-24 20:06:57 UTC
When winbindd at an AD member machine opens an SMB connection to a domain controller of a domain other than the primary domain (i.e. other than the one defined at smb.conf), it does so using NTLMSSP. If NTLMSSP is not allowed (restrict NTLM under W2K8R2 and newer servers), then the connection cannot be established.

This prevents smbd from servicing SMB connections from other domains, as some info is fetched from the domain using this SMB connection.

To reproduce:
1. Set a group policy for all domain controllers in all domains that restricts NTLM.
Network security : Restrict NTLM: Incoming NTML traffic' to 'Deny all accounts'
Network security : Restrict NTLM: authentication in this domain' to 'Deny all'
2. Restart winbindd
3. From a logon session on a Windows client, with a user from a different domain, try to connect to an SMB share on the server.
The connection fails and packet traces show the failed NTLMSSP towards a DC of the foreign domain.
Comment 1 Uri Simchoni 2016-02-24 05:42:58 UTC
The root cause for the bug is that winbindd is trying to authenticate to 
the foreign DC using NTLMSSP and that's not allowed in this setup.

Why? because when the domain object is created at the parent winbindd, 
before forking the child, the "active_directory" field is set to false 
by default, and later, in the child, all attempts to find out if it's an 
active directory domain either fail or are skipped.

The fix is to flag the domain as active directory based on the trust info that's been obtained while initially discovering this domain.
Comment 2 Uri Simchoni 2016-02-24 05:44:14 UTC
Created attachment 11868 [details]
git-am fix for 4.3.next and 4.4.0
Comment 3 Ralph Böhme 2016-02-24 06:10:50 UTC
Guess we need this for 4.2 as well?
Comment 4 Volker Lendecke 2016-02-24 07:24:01 UTC
(In reply to Uri Simchoni from comment #1)

Hi, Uri!

Can you get us the whole picture here? Trust setups, smb.conf and full debug level 10 logs from smbd and all winbind processes? While your fix is good, the real fix should be that winbind does not even try to connect to trusted DCs. To work on that, we need to understand why it does so in your situation.

Thanks,

Volker
Comment 5 Uri Simchoni 2016-02-24 07:26:47 UTC
With regards to 4.2 -
Just from looking at the code, I'm not sure the bug exists in 4.2. It seems like the bug is a regression by commit 0392ebcd1d48e9f472f2148b85316a77d9cc953b - the hunk that says:

+       } else if (!domain->active_directory) {
+               cli_credentials_set_kerberos_state(creds,
+                                                  CRED_DONT_USE_KERBEROS);
+       }

that commit assumes that domain->active_directory is properly set, and if NTLM is restricted, that's not the case.

I currently don't have a working 4.2.x setup, so verifying this will take some time - I'll get around to it if someone doesn't get there first...
Comment 6 Uri Simchoni 2016-02-24 18:14:52 UTC
(In reply to Volker Lendecke from comment #4)
Working on it, have some setup issues and other issues, hoping to come up with requested details shortly.

Volker - If I understand your point correctly, the winbindd patch is good, but smbd setting up sessions and serving files to users from another domain is not supposed to cause winbindd to attempt connection to a DC of that domain (it should get everything it needs from "our" DC or from the Kerberos ticket).

I therefore suggest that I supply the details separately from this bug, verify the bug does not exist on 4.2.x, and if so, hand it over to Karolin for 4.3.x and 4.4.x processing.

Sounds like a plan?

Thanks,
Uri.
Comment 7 Volker Lendecke 2016-02-25 09:43:45 UTC
(In reply to Uri Simchoni from comment #6)
> Volker - If I understand your point correctly, the winbindd patch is good,
> but smbd setting up sessions and serving files to users from another domain
> is not supposed to cause winbindd to attempt connection to a DC of that
> domain (it should get everything it needs from "our" DC or from the Kerberos
> ticket).

Correct. In many setups winbind just does not have the permission to connect to trusted DCs. Windows doesn't do it, so we might be blocked for many reasons.

Volker
Comment 8 Uri Simchoni 2016-02-28 19:40:21 UTC
(In reply to Volker Lendecke from comment #7)
created https://bugzilla.samba.org/show_bug.cgi?id=11759 to track this.
Comment 9 Uri Simchoni 2016-03-01 21:03:01 UTC
(In reply to Uri Simchoni from comment #5)
Verified that 4.2.x is OK - Winbindd can contact a foreign DC without trying NTLM.
Comment 10 Uri Simchoni 2016-03-01 21:04:09 UTC
Assigning to Karolin for inclusion in 4.3.next and 4.4.0.
Thanks,
Uri
Comment 11 Karolin Seeger 2016-03-04 10:33:37 UTC
(In reply to Uri Simchoni from comment #10)
Pushed to autobuild-v4-[3|4]-test.
Comment 12 Karolin Seeger 2016-03-14 08:30:22 UTC
(In reply to Karolin Seeger from comment #11)
Pushed to both branches.
Closing out bug report.

Thanks!