Network share with an untrusted domain

Shaamaan

8/8/24, 5:49 AM

We have a network share on a Windows Server 2022 which hosts a number of both "production" files as well as development files. We have two domains - a prod domain (ex. "prod.local") and a dev domain ("dev.local").

Some folders have been set up with "Everyone" access and, while a trust relationship was present between the prod and dev domains, dev users had read-only access to the shares, as expected.

However I've been asked to make the trust one way (dev trusts prod, prod doesn't trust dev) and now the "Everyone" permissions don't work any more.

I've tried to implement the changes suggested here but a) it seems those are solutions for Windows 10/11 and b) it still doesn't work (i.e. dev users still can't access the shares).

How should such a share be configured on a Windows Server to allow another domain access?

2 + 0

network-share

trust-relationship

windows-server-2022

Score:2

Server

Greg Askew

8/8/24, 12:45 PM

You were asked to configure a trust from two way to ONE way so that a that a share in PROD (and any other resource in PROD) is only accessible to PROD and NOT dev. Now dev users are unable to access the share in PROD.

This is the expected behavior.

Removing the two way trust is the correct thing to do. It should never have been created.

If you want a share (or any other resource) to be available to the dev domain, the resource (share) needs to be in a location independent from the PROD domain that should not be accessible from the dev domain.

Additional information:

The Everyone security principal was changed in 2003 to not be "Everyone". It is functionally identical to the Authenticated Users security principal. Previously Everyone functioned similar to a Guest account functionality, which is usually disabled. This means that the Everyone principal does not include Anonymous.

https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users

In summary, Windows requires that users must authenticate to access a resource such as a share. There is no anonymous or guest access, and Everyone means only users that have authenticated from trusted domains.

The relationship between the resource in the PROD domain and the principals that you want to grant access has been specifically configured to disallow all access to all users that are from untrusted domains, to all resources, including shares.

+ 0

Score:1

Server

Zac67

8/8/24, 7:47 AM

I think you are mistaking trust for access privileges.

Trust means that you trust that domain to authenticate users, so that you can assign access privileges to that domain's users (in addition to your own).

Access privilege means that a user may or may not read or modify a network resource. In order to assign privileges you first need to have a user object - which can be from another domain that you trust. Usually, you group users and then assign privileges to the group. On the file level you use ACLs for that.

Without trust, you have no way to know who's trying to access a resource.

So basically, trust the other domain, but don't assign its users any privileges that you don't want.

+ 2

Shaamaan

8/8/24, 8:14 AM

I'm not mistaking domain trust and access privileges. The instruction to drop the trust came "from the top", so it wasn't my decision. Otherwise I was happy to have that trust and rely on "Everyone" in terms of access privileges, but my boss is a bit paranoid. Now that this trust is gone I'm looking for alternatives.

Zac67

8/8/24, 8:41 AM

Perhaps you need to explain to your boss that *trust* doesn't mean *privilege*.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Network share with an untrusted domain

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.