Restrict windows fileshare by IP or hostname?
July 19, 2010 11:19 AM   Subscribe

Is it possible with Windows server in a domain setting to restrict file shares by IP of the clients?

I have a requirement brought to me by a client and I have no idea how we can fulfill it. Essentially, we are to setup a Windows server as a file server, and have it configured so that:

1) Anyone with an account on the domain can access the fileshare IF AND ONLY IF they are logged on to one of 5 specific workstations

2) All members of a particular security group on the domain can access the fileshare from any workstation

Essentially, what we want is something like this (bad pseudo-type code)

[Share X]
share dir: c:\blahblah
allowed hosts: IP1, IP2, IP3, IP4, IP5

[Share Y]
share dir: c:\blahblah
allowed users: DOMAIN\SecurityGroup

This would be a setup where there are two shares to the same data path, one which allows access only from certain IPs, the other only to a certain security group. This is very simplified, as there may be more complex rights to assign, but that's the basics.

I know this is likely possible under UNIX/Linux with Samba, but I don't believe this is a workable solution for us (client is resistant to change, UNIX team has concerns about granularity of ACLs, etc.). I also know that there may be a way to get Samba to work on Windows with Cygwin, but this would not be appropriate in a corporate production setting (not officially supported by anyone).

Is there any way (complex or not) to accomplish this on Windows? Assume we can coerce cooperation from the network team so we can also get some routing rules implemented if necessary, etc.

Is there any kind of third-party product that could help us with this?

Any alternatives to this kind of setup?
posted by splice to Computers & Internet (17 answers total) 1 user marked this as a favorite
 
Response by poster: Er? If it was that simple I'd have done it long ago. What do you mean by "restrict the shares to the computer name and the security group"? Where would you do that? The security group is from the domain, so I can't restrict something to "CLIENT1\SecurityGroup" since SecurityGroup is on DOMAIN, not CLIENT1. If I restrict to "DOMAIN\SecurityGroup", then that does not help me having the share restricted by IP.

If you think it's that simple and straightforward, then please, memail me the exact steps and I'll go ahead and test it out. But I've not seen anywhere in the standard windows file share dialogs where I can restrict by computer name or IP, and all my research so far supports that.
posted by splice at 11:33 AM on July 19, 2010


Yeah you have to add Computers to the list in the "Locations" block. It's a checkbox.

Personally, I'd create a security group and add the computers to the security group at the domain level.
Then I'd create another security group for the users, and adjust security accordingly.
posted by disclaimer at 12:02 PM on July 19, 2010


Response by poster: You gave me some hope there, unfortunately it doesn't seem to work.

I have tried testing the simplest case possible. I made a folder on a local drive and set file permissions to Everyone - Full control (no other permissions). Then I shared it, found a computer object to test it with, gave it full control, and remove all other share permissions.

The person logged on to the workstation cannot access my share (access denied). Looks like the request isn't being made under the computer object credentials, but rather under his domain logon credentials.

Did you ever get a succesfull setup with this feature? I imagine computers may not be checked by default for just this reason, that there will be no file access request made under a computer object's credentials, it would always be under the logged-in user's credentials, no?
posted by splice at 12:07 PM on July 19, 2010


Response by poster: disclaimer, just saw your response. So you've used this feature before? Any gotchas, any settings you can think of that could prevent it from working?

It looks so simple, but it just doesn't seem to work like I would hope.
posted by splice at 12:07 PM on July 19, 2010


I'm not entirely sure this method works as I couldn't get it to work either.
In fact, on Server 2008/2008 R2, Computers isn't even available at all in Object Types anymore for ACLs, which says to me that it probably never worked as described above. (???)
posted by yeoz at 12:09 PM on July 19, 2010


Set a startup script on those specific machines (under the all users startup section) to map the drive using credentials that work for that share. Use the "net use" command. You can pass it domain user and password. I guess it may be something of a security risk as they can read the .bat file and see the username and password, but I find most users aren't that clever.
posted by damn dirty ape at 12:17 PM on July 19, 2010


Response by poster: Don't forget to also add the group/computers into the NTFS permssions.

Alright, I can do that, but if "Everyone" is there with full control, I would assume this actually covers the file access requirements?

Well, I did include them anyway, and had no more success than previously. I also tried to use a local account instead of domain, but all that did was prompt for username and password when trying to connect to the share. The local account didn't work.
posted by splice at 12:18 PM on July 19, 2010


Response by poster: All right Burhanistan, any way you can memail me the exact settings you have for NTFS permissions and share permissions? Obfuscate your domain, not a problem, but do indicate where you have it.

On my side, NTFS permissions are Everyone - Full Control, DOMAIN\COMPUTER - Full Control. On the share permissions, DOMAIN\COMPUTER - Full Control. Is this any different from yours? I imagine if you have more groups in there maybe you're hitting the share through them, but I may be wrong there.

damn dirty ape, you may have something. I think the network guys may be able to set a GPO to run a script and apply that GPO to specific computers? If so that may be an alternative... I'll think on that while trying to get the other solution we're talking about here to work.
posted by splice at 12:22 PM on July 19, 2010


Oops, tried it on a server on the domain instead of one of my test boxes and Computers does show up now. But, I still can't get it work.
posted by yeoz at 12:22 PM on July 19, 2010


The 'everyone' group contains authenticated users and guest. I'm not sure if it contains machines at all. I'd put them in and see if it helps.
posted by damn dirty ape at 12:24 PM on July 19, 2010


Response by poster: Damn, just thought of it, the logon script idea is a non starter. Due to security restrictions (this is government stuff, with a bunch of requirements due to sensitive tax data, etc.), it simply is not possible for us to have a share that will be access by multiple users using a common account. Since we have over 2500 users (with a lot of departures, new employees, external employees coming in, employees from other agencies coming in, etc.), it won't be possible or practical to create a special account for all of them.
posted by splice at 12:25 PM on July 19, 2010


Response by poster: I'm not sure if it contains machines at all. I'd put them in and see if it helps.

Yeah I did that and no joy.
posted by splice at 12:25 PM on July 19, 2010


it simply is not possible for us to have a share that will be access by multiple users using a common account

Then you can't do it by machine account because machine accounts are common accounts too.
posted by damn dirty ape at 12:32 PM on July 19, 2010


In a pinch you can put it on its own little file server and disallow access via the firewall from any computer that isn't on your whitelist.
posted by damn dirty ape at 12:35 PM on July 19, 2010


Response by poster: Yeah, you may be right. If it obtains access through the computer object, I guess all auditing would record the computer object and not the logon credentials?

There may be a case made for auditing on both server and client, so that we could see that when computer account X was used to access a file, user Y was logged onto it. But this may not be ideal for the client, and their interpretation of the language in various data sharing agreements would factor into it greatly.

If I got it to work I could always propose it to them, but for now it's not working right under our configuration, for some reason.
posted by splice at 12:36 PM on July 19, 2010


Response by poster: In a pinch you can put it on its own little file server and disallow access via the firewall from any computer that isn't on your whitelist.

Problem is that the system has to fulfill that requirement AND also allow access to the same location to a security group, logged on to any workstation on the network. So the firewall solution would fulfill the first requirement but kill the second.
posted by splice at 12:38 PM on July 19, 2010


There may be a case made for auditing on both server and client

Right. That may be the way to go. If machine accounts don't work then you can always make a unique user account per machine. At least you'll be able to see who was logged in at 3:33pm when the file was deleted by user "Machine666" or whatever.
posted by damn dirty ape at 1:10 PM on July 19, 2010


« Older Hey Molly - piss in your hole not on my carpet....   |   What to drink with hot/spicy foods? Newer »
This thread is closed to new comments.