• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 391
  • Last Modified:

How to limit shared folder access to logged in user?

School situation: all students have their login name, password, personal folder on the server, personal profile.  During a test, all students login with their proper user name.  Each of them access his/her own personal folder.  But, if you know the username/password of another student, you can also access his/her personal folder, and so it is difficult to copy his/her answers on the test.  Nice for collaboration purposes (only close friends exchanhe usernames/passwords), but the teacher can no longer rely on the results...

So, is it possible to limit the access to a shared folder to the logged in user, and to deny access to another user, who is logged in with his/her username/password, and access the shared folder using the username/password of somebody else?  On first sight, this cannot be done, because a logged in user accesses his/her own personal folder by the mean of the sharing way of security.

Maybe using Group Policies?  I am not that familiar with GPE...

Thx in advance,
  • 3
  • 2
  • 2
  • +1
1 Solution
I don't think so - with newer windows operating systems, if your students are savvy enough, they can easily use the "RunAs" feature to supply another students credentials to get to their folder.
Only sure method I could think of is maybe utilizing EFS.
See if this would help: http://www.microsoft.com/windows2000/techinfo/planning/security/efssteps.asp
Pete LongTechnical ConsultantCommented:
Hello Peter

SB is correct even with a GPO, the ACL that is attached to the username/password will explictly be given access to the resource that the rights have been granted on - this is the basis of kerberos authentication that the whole security system runs on :(
I wonder if enabling auditing would help?
Perhaps you could turn on auditing on the system and then search for entries where
Jim Brown logged in, but Joe Smith's share was accessed....

It's not a solution, but it would allow you to track the access and if found, deal with it accordingly...
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

PeterJanssensAuthor Commented:
I think "RunAs" can be disabled, cannot it?  I do not see a need a user should run something (whatever) as somebody else.

EFS is about encryption.  So you're suggesting only the logged in user has the key information,  and it is not in the user profile?
Hmm - I hadn't initially thought of disabling runas.
Good point - you can probably just locate the runas.exe and change the security permissions to only allow access to the local administrator account.
If you're using NTFS on these systems, then by default the logged in user should not have access to other user's profiles.
What file system are you using?
PeterJanssensAuthor Commented:
NTFS is used on the server (Win2003) and the 22 workstations (Win2000 Pro).
AD is used for domain controlling.
Pete LongTechnical ConsultantCommented:
>>I think "RunAs" can be disabled

correct its a service, and any service can be disabled :)

start >run >services.msc

set the runas service startup to disabled
Let me summarize, I think this is the situation:
- all students logon with their domain account to one of the 22 W2K Pro workstations
- the testing application stores each student's answers on the server, in the student's personal share on that server

Blocking runas.exe isn't enough - students can also just "net use" to the share as another student's name, or probably one of a hundred other tricks to authenticate to the remote server temporarily as their buddy, and read the answers that are stored on their buddy's personal share.

This is a tough one - when students have an incentive to cheat, they'll look for all sorts of ways to try to "sneak around" without the teacher knowing.  Anything you try to restrict on the workstations will probably only meet with limited success, since your students have an incentive (and probably a lot more time than you do) to try to find other workarounds to your security measures.

You'll have a lot more success if you focus your attention on the things you can do on the server to

Is it enough that you can detect the "possible cheating" after the fact, or do you need to prevent the attempts completely?  If detection afterwards is enough, then sirbounty's suggestion of using auditing (on the server) should be enough, so long as your students aren't smart enough to spoof the name of the workstation during their attempt to "connect to the server using their buddy's account".

Here's how I'd approach it:
- configure Object Access auditing on the server (just Success - failure auditing isn't necessary in this case)
- configure very specific audit settings on the server's personal share folders for each student using the Security Templates feature of Windows (or Group Policy directly) - e.g. if all students' personal shares are stored on D:\students\shareXXX, then go to D:\Students, right click, choose Properties, Security, Advanced, Auditing tab, click Add, type "Authenticated Users", click OK, then check each of the desired permissions you wish to verify - you'll probably want at least Successes for "List folder/read data".  Also, you'll probably want to select "Files only" in the "Apply onto" drop-down list, so you don't get any more audit records than you have to.
- You probably want to enable this policy just before tests, and disable it afterwards - there's just going to be too many freakin' audit logs accumulated as it is, and crawling through them will already be enough hassle without having to go through all the innocuous records.
- You'd want to make sure the students don't have any permissions on their personal share folders to be able to Change Permissions or Take Ownership either - so they can't mess around and grant *others* the ability to access their files.

EFS won't be practical here:
- for students to be able to encrypt the files on their personal share, you'll have to enable "Trusted for Delegation" on the server, and you'll probably want to enable Roaming User Profiles (so you don't have to worry about managing more than one set of keys for each user).  This is technically feasible, but is a significant security risk (if anyone ever gets the ability to install their own software on the server, such as applications, services, drivers, etc.) - theoretically, this capability would allow an attacker to usurp a user's credentials on the server and access *anything* on *any* other server that *any* user is allowed to access, and all the attacker has to do is wait for that user to connect to the server (once they've taken over, and inserted this kind of malicious code).  This kind of attack is very difficult, and it's not that you shouldn't be able to detect this has occurred, but there are many organizations out there that don't wish to take this kind of risk.  [BTW, the risk is extremely reduced with Windows Server 2003 Active Directory, when you can use "Constrained Delegation" of Kerberos tickets.]
- However, all this aside, the bigger trouble is this: if a student is able to remotely encrypt files, any other student who uses their account can *decrypt* those files as well.  That's because the encryption & decryption are enabled via the user's ID & password, and there's nothing natively in Windows stopping that user's account from being used in two places at once.

[Hmm, there *are* rumours of an application that Microsoft should be releasing soon called "LLogin", that will allow you to prevent a user account from being used to logon from more than one workstation at once.  The old "CCONNECT.EXE" originally did this as well, but it wasn't the most robust piece of code out there, so it wasn't perfect at preventing > 1 logon at once.  In the meantime, check these articles for some interesting ideas: http://support.microsoft.com/default.aspx?scid=kb;en-us;260364, http://support.microsoft.com/default.aspx?scid=kb;en-us;237282]

Ideally, you'll probably have to look into building a new testing application that uses more than just username/password to access/store the student's answers to the test, so that even if students share their account with buddies, the act of reading/writing the answers can only be successfully completed when something else (that can't be shared, such as a smart card or other hardware token) is present during the attempt to commit the answer.

Another approach might be to setup the application as a database-based app, and configure the application so that the student's answers can be written TO the database, but that the student's answers can't be READ back from the database (at least, can't be READ by the students themselves, but only by the teacher).  It might be possible to take this same approach with the file share-based testing application, but I suspect trying to grant Write/Execute permissions, without granting Read/Read Attributes might be very complex and difficult to maintain (without potentially hosing the students' access to the rest of the stuff stored on their personal share).

However, watch out: the students will then look for any way they can to "own" the server where the database is stored.  If you host the database on the same server where the students can access their shares, and that server allows any other kind of remote access (e.g. web server, Terminal Server, VNC, pcAnywhere, Telnet, SSH, SMTP, POP3), you'll probably find that those students will look for any way they can to exploit a vulnerability on the server to take it over, and be able to make server-side changes as well.  Ultimately, if they get admin-level access to the server, they'd be able to access any server-side code (including your testing app), potentially make changes, or just use the app to access the database.  If the database was hosted on the server they just "owned", then they might potentially try to "own" the database as well, or at least grant themselves more access to the database tables than you'd originally setup.

This isn't an impossible situation, but it *does* merit a solid security approach on the server, applications and data: keep all your patches up to date immediately, audit the crap out of the privileged access to the data, application files/objects and remote access venues (e.g. IIS, TS, Telnet), and use freakin' strong passwords on any privileged accounts in the system.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

  • 3
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now