Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm relatively new to Sys Admin and there is this requirement.. or at least, the talk of a requirement whereby we restrict access to certain folders for a particular set of computers (an OU on our domain that contains a room of PCs). I just don't know if this is possible on active directory. I get the feeling that file system permissions are only designed for user/group mapping and can't figure out how i might go about trying to stop users from modifying these files except in this room (AD container) on these PCs.

Is this possible? Any suggestions are welcome (no matter how left-field).

EDIT: more info is needed it seems...

I'm at a school. The server share that i'm applying permissions to contains files that are used for school reporting functions. I have a series of security groups applied to the share such that the appropriate administrative staff can access the files how they need to and faculty staff can do the same.

In addition to the requirements satisfied in the implementation above, management wants the faculty staff to make changes to these files only in a particular room (such that they can be 'supervised' i believe). I have the AD containers set up for the PCs in this room - i was hoping that there was a group policy solution to this permission predicament.

share|improve this question
    
Where are these folders, on the computers in the room or on servers on your network somewhere? It's not entirely clear from the question. –  nray Nov 8 '09 at 15:51
    
Do the users of the computers in the room log into the domain or do they use local accounts on each computer? If the machines are just left logged in all the time then you would be using local accounts (I hope). –  nray Nov 8 '09 at 15:53
    
The folders are on the 2k3 dc. And the users in the room log onto the domain too using their own accounts. –  cottsak Nov 8 '09 at 17:35
    
Do the users ever log on other PCs outside the room? If not, you could restrict which PCs they can log on to to just those in the room (workstation AD attribute of each user), but it sounds like your users will log on to other machines as well... –  nray Nov 9 '09 at 11:43
1  
The design assumption almost requires secondary accounts here - access needs to be granted based on who you are, and the school is saying the user is someone I trust when they're in the room and someone I don't trust when they're outside the room - which is as good a basis as any for another logon identity. –  nray Nov 9 '09 at 11:55

7 Answers 7

up vote 4 down vote accepted

This is one of those interesting areas that don't fit a use-case that Microsoft thought of with the Windows operating system.

NTFS permissions don't have any functionality related to assigning permission based on the computer that's accessing, other than a very gross approximation using the "INTERACTIVE" or "NETWORK" well-known security identifiers (SIDs). The user accessing the particular resource is used in the access-control decision, irrespective of the computer from which the access attempt was sourced.

If you want a "fix" based on Group Policy, I'll suggest an ugly workaround. It's sub-optimal, but it will accomplish what you're looking for. (This is very quick and dirty. In particular, it's really not good form to stick GPOs at the top of the domain indiscriminately, because in general you want the smallest number of GPOs to apply to a given computer or user to speed the application of Group Policy.)

  • Create a global security group named, say, "Sensitive Computer Accounts" in the Active Directory. Make all the computer accounts where "Sensitive" access will be performed members of this group.

  • Create a global security group named, say, "Sensitive User Accounts" in the Active Directory.

  • Create secondary user accounts in Active Directory for all the people who will be performing the "sensitive" activities. Make all these user accounts members of the "Sensitive User Accounts" group.

  • Create and link a GPO at the top of the Active Directory called "Restrict Sensitive User Account Logons". In this GPO, head into "Computer Configuration", "Windows Settings", "Local Policies", and "User Rights Assignment". Locate the "Deny logon locally" (and, if you are so inclined and paranoid, the "Deny logon as a service", and "Deny logon as a batch job") setting and add the "DOMAIN\Sensitive User Accounts" group to the setting. (This assumes that you're not using any of these policies presently at lower levels of the AD. In a stock Active Directory in W2K-W2K8 this would be true.)

  • Modify the permissions of the "Restrict Sensitive User Account Logons" GPO by adding the "Sensitive Computer Accounts" group with "Deny / Apply Group Policy" permission.

  • Apply NTFS permissions to the folders where the "Sensitive" files are stored to allow only members of the "Sensitive User Accounts" group access. (This is an exercise left up to the poster...)

This will cause the "Sensitive User Accounts" to be able to logon locally only to the computers that are named in the "Sensitive Computer Accounts" group. In this way you can prevent access to the folders holding the "Sensitive" files, because you'll set the permissions to limit access to these folders only to the "Sensitive User Accounts" (which can only logon to the "Sensitive Computer Accounts" computers.)

Having secondary accounts for users is really, really ugly. Since you want to do something that Microsoft hasn't designed the operating system for, however, you've got to do something ugly to get around the inbuilt limitations.


Another, still potentially ugly but workable solution, would be to host these shared folders with a Samba server. Samba, using the "hosts allow" configuration parameter, does have a mechanism to limit access to shared folders based on both the user's permission and the source computer from which the access is coming. If you're not into having a *nix-based server sitting around (virtually, possibly) though, this alternative does you little good.

share|improve this answer
    
+1; messy as hell but it will achieve the result. Another option might be a dedicated file server for these people with ACLs on the switch port. Either way it's setting an awful precedent. –  Darth Satan Nov 8 '09 at 23:36
    
@mh: I aim to please, even if the result is an unmanageable nightmare. A realistic answer would be "Customer-- what you want is going to create an expensive mess. Perhaps we can work out something less outside of the realm of the design-constraints of the systems you're using." If it had to be this way I'd go the route of the Samba server. (This is one of those cases where a Win32 port of Samba would be interesting... heh heh. The idea of Samba on Win32 makes me giggle and giggle and giggle...) –  Evan Anderson Nov 9 '09 at 1:03
    
Wow. Somebody has ported Samba to CYGWIN: smithii.com/node/23 –  Evan Anderson Nov 9 '09 at 1:17
    
@Evan: believe me, i am on board with you trying to talk these guys out of it. I just wanted a backup plan if they decide to shove this down my throat. –  cottsak Nov 9 '09 at 5:14
    
@Evan: Agreed, this is smelly. I found in the GPO Editor this- Computer Config > Windows > Security > File System – it seems here you can apply a computer-GPO that adds file permissions to a folder from the GP - is this going to help me? –  cottsak Nov 9 '09 at 5:15

It is. You should have a look at ACLs. These are Access Control Lists for files and directories. They are an additional permission layer on top of the standard Unix file permissions.

share|improve this answer
    
could you point me to some great ACL doco for windows domains? –  cottsak Nov 8 '09 at 17:39

Are you using Group Policies? You can set NTFS permissions for groups using group policies (GPOs) and then just apply that GPO to a specific AD OU.

share|improve this answer
    
i am. can you give more info about how this works? –  cottsak Nov 8 '09 at 17:43
    
Using the security extension of group policy to set filesystem permissions on file servers seems like a misapplication of the technology. Sure, it'll work. So will using a screwdriver to pound nails, if you're persistent enough. Having said that, using only NTFS ACLs won't accomplish what the poster is looking for. –  Evan Anderson Nov 9 '09 at 1:06
    
@Evan: when you say "..using -only- NTFS ACLs.." - does this mean that it might work provided i set the appropriate NTFS permissions on the folder -before- i apply the additional permissions with the GPO? –  cottsak Nov 9 '09 at 5:17
    
@Evan - true but when I answered there was no mention of servers in the question. It sounded like there were a group of PCs which each had a particular folder on them that needed securing. Using GPOs to enforce file system security on clients is a pretty standard thing to do, lots of people do it to ensure things like Program Files folders are locked down properly, whilst certain sub-folders for badly written apps are opened up to certain groups, etc. –  GAThrawn Nov 9 '09 at 10:42
    
@GAThrawn: I came to the party a bit late and got the question after the edit was put on. –  Evan Anderson Nov 9 '09 at 13:32

Where are these folders, on the computers in the room or on servers on your network somewhere?

Assumption No.1 | Restrict access to network shares


"certain folders" - I am assuming that these folders are network shares, and that you don't want users of the machines in the OU to have access to these (shared) folders. That is to say, the "group" here is being defined by those with physical access to the computers in the room, like users at a public library or something.

In that case, ...

You're doing it wrong
The usual method is to restrict access to groups of users rather than machines, as it's seldom that machines (which have their own accounts in AD) access file shares acoss the network. Cases where they do include the SYSVOL share where GPOs reside, or install shares for assigned applications.

  1. Set the NTFS permissions on the folders on the servers to deny (or not include) those users you wish to keep out.
  2. You can also set the Sharing permissions to deny (or not include) those users you wish to keep out. But as well as, not instead of, (1).
  3. Access to these folders can't be (as in "shouldn't be") determined by which machine you're using, but rather who you are, which you have established by logging in to the domain.


Assumption No.2 | Restrict access to local folders


"certain folders" - here I'm assuming that these folders are on the local filesystem of each computer. Maybe there's some files in C:\Install\ that you don't want users copying to their USB sticks, for example.

Group Policy allows for file system policies,

Edit GPO > Computer Configuration > Windows Settings > Security Settings > File System

First add the folder C:\Install, then choose Properties and modify the NTFS permissions to deny (or not include) the users you want to block. Test first. Alot. I'm not sure but I think you'll be overwriting (not adding to) the NTFS permissons, Deny comes in handy here.

You can also hide whole drives through Group Policy, which would be useful if you kept your restricted files on D:\, users wouldn't see the drive - I'm not sure how robust this is, but it's popular in terminal server and SoftGrid environments.

The locally logged-on user is called INTERACTIVE, by the way. And this username is localised, if your OS is not English.

share|improve this answer
    
Based on my comments above it seems that your "Assumption No.1" applies. Maybe i wasn't clear in the question - i do have groups configured to manage which users access the server share and how they access it. -In addition-, i want to manage on which computers the said users can access this share. –  cottsak Nov 8 '09 at 17:57

Restricting to computers just doesn't seem like a great idea. I kinda get what you want to achieve, and - if I'm guessing right - I'm thinking that you have some sensitive data (like HR records or similar) that you want to definitively lock down to the relevant staff, even if it's to the extent of locking your admins out of it.

I think we really need more info on what your objective is here, and I think that stepping back and focussing on what you want to achieve rather than how you want to achieve it might be a useful exercise.

If I'm right in my guess you also need to think about the further implications of doing this, in terms of how it's going to interfere with your backup and restore, and in terms of who's now going to manage access to these folders.

share|improve this answer

It sounds like you'd segment the network and block that kind of traffic from everywhere except from the allowed rooms...

share|improve this answer
    
This sounds nice in theory, but think about what an ACL would look like. Ethernet frames don't have a "room I came from" field. You'll have to a VLAN or dedicated IP subnet for what the OP wants. He says he's hosting these files on a DC, so anything that limits SMB traffic to the DC is actually right-out anyway (since other clients might use it for GPO refersh, logon scripts, etc). Putting that aside and saying that he'll host the files on a dedicated file server, entries in the Windows Firewall on that box to exclude traffic from all but a given subnet seems easier than ACLs on a switch. –  Evan Anderson Nov 9 '09 at 1:10
    
Even if i knew how to do this, i would tell management that i didn't. –  cottsak Nov 9 '09 at 5:18
    
I missed the part about the files being hosted on a DC... except for that I think it would be an easy and a sound concept to simply segment the networks off ^^ Where the actual ACL then would be situated, on the host or in the router, is of less importance and perhaps more up to be decided by the known skills of the implementer... –  Oskar Duveborn Nov 9 '09 at 9:35

If people logging on outside of the OU do not need read access to the folders, you can set up a mapped drive that only maps when someone logs into a computer w/in the OU. This will not prevent others from getting to it if they know the UNC path, but if your users are like ours, it will do the trick. This also depends on the folders in question not being nested inside other parts of your file shares that normal people need to get to.

ETA:

Is access to the room restricted in such a way that you could use that list to restrict the network share?

share|improve this answer
    
thought of that. even tho the risk of the users knowing the UNC path is low to zip, the admin will want it secured, so i need to genuinely restrict file system access. thanx tho –  cottsak Nov 8 '09 at 17:42
1  
Security through obscurity isn't security. –  Evan Anderson Nov 9 '09 at 1:07
    
Thank you for your insight. –  JamesCW Nov 9 '09 at 2:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.