Domain – Windows Server 2008 – Non-Domain users can see the server shares

active-directorydomainwindows-server-2008

Windows Server 2008 – Server Machine
Windows 7 Professional – Client Machine

I have a domain. It was setup by the client. The shares on the server are restricted correctly when a user logs on to the domain and uses their workstation, I have a few groups setup to restrict some access but the groups are at their core "Domain Users".
The problem I am having is that when a user brings in a laptop with Windows 7 Pro on it, they can type up the name of the server in the "Run Dialog" on the start menu like "\SERVERNAME\" and access all of the shares freely… because they are not logged in to the domain there are no restrictions it seems.

I have reviewed the permissions on the folders and they all have to be "Domain Users" and I have removed "Everyone" from the list of people able to see it. Guest access is also disabled…

What am I doing wrong? Only group in the list is "Domain Users" isn't a domain user a user that is logged in to the domain? How do I stop non-domain users from seeing the shared folder?

I noticed this on Windows Server 2003 too at another time. I assume they both had similar security issues and neither were set up by myself so I am not sure what could have been enabled or specifically deactivated that makes this issue appear.

I am looking at the Security >> Permissions and not "Share Permissions" but wouldn't the security permissions stop read/write on non-authenticated domain users?

Best Answer

There are two types of permissions on shared folders, and you haven't explained which set you're looking at - and you haven't explained if the non-domain users can actually read files, or if they can just see the share names.

I'm guessing that you've examined the NTFS permissions on the files and folders, and those don't allow "everyone". But I bet that your share permissions (which are set in a different place) are set to allow "Full Control" to "Everyone". That's not a big issue - the more-restrictive set of permissions will mean that these anonymous users can't do anything else besides read the names of the share.

That's my guess, based on what you've said.

However, if they can access and read the actual files, then either you're missing something in the NTFS permissions, or they are successfully authenticating to the server. If their local username on the non-domain machine is the same as their domain username, and the password is the same, the client may be attempting (and succeeding) at passing NTLM authentication.

From the server, why don't you bring up Sessions under Shared Folders in Server Management and see what's going on from that perspective?

Related Solutions

How to assign permissions to ApplicationPoolIdentity account

Update: The original question was for Windows Server 2008, but the solution is easier for Windows Server 2008 R2 and Windows Server 2012 (and Windows 7 and 8). You can add the user through the NTFS UI by typing it in directly. The name is in the format of IIS APPPOOL\{app pool name}. For example: IIS APPPOOL\DefaultAppPool.

IIS APPPOOL\{app pool name}

Note: Per comments below, there are two things to be aware of:

Enter the string directly into the "Select User or Group" and not in the search field.
In a domain environment you need to set the Location to your local computer first.

Reference to Microsoft Docs article: Application Pool Identities > Securing Resources

Original response: (for Windows Server 2008) This is a great feature, but as you mentioned it's not fully implemented yet. You can add the app pool identity from the command prompt with something like icacls, then you can manage it from the GUI. For example, run something like this from the command prompt:

icacls c:\inetpub\wwwroot /grant "IIS APPPOOL\DefaultAppPool":(OI)(CI)(RX)

Then, in Windows Explorer, go to the wwwroot folder and edit the security permissions. You will see what looks like a group (the group icon) called DefaultAppPool. You can now edit the permissions.

However, you don't need to use this at all. It's a bonus that you can use if you want. You can use the old way of creating a custom user per app pool and assigning the custom user to disk. That has full UI support.

This SID injection method is nice because it allows you to use a single user but fully isolate each site from each other without having to create unique users for each app pool. Pretty impressive, and it will be even better with UI support.

Note: If you are unable to find the application pool user, check to see if the Windows service called Application Host Helper Service is running. It's the service that maps application pool users to Windows accounts.

Mounting windows shares with Active Directory permissions

One option would be to setu pam_mount. It allows you to mount shares when a user logs into the system. With pam_mount the folder will be mounted with the users credentials. They credentials do not need to be saved anywhere, they will automatically be passed through by pam from what they used to login.

Best Answer

Related Solutions

How to assign permissions to ApplicationPoolIdentity account

Mounting windows shares with Active Directory permissions

Related Topic