Hi I have a Windows 2003 SP2 server in my domain - server1.domain.com We have an in-house application running on this server that writes some details to text file. Whilst the details aren't in the realm of credit card numbers or anything like that, we would prefer to keep the details as confidential as possible. The files are written in clear text files to D:\App1\ and in the form of <date>.txt. The problem is that all of IT are members of the local Admin group on all our servers, this means that technically, anyone logging onto the server (or mapping a drive to \\servername\d$\App1) can read these files. I understand these are the following options for 'locking down' this file location: 1. Remove the local Administrators group from the NTFS permissions and then explicitly add only those peolpe we want to have access. 2. Encrypt the file folder using EFS (but this has problems since the log files are created daily, and you can't give multiple users access to an EFS encrypted folder, only files) Can anyone think of anything else?

You will likely need to remove administrator access from the system for everyone except those who need access to the files. Even if you lock down the NTFS permissions, anyone who is a member of the local administrators group can still take ownership of the files/directories and then modify the permissions to be able to access them. I would instead focus on auditing the files/directories. If you enable success/failure for "Audit object access" and then set up auditing on the folder, through the advanced NTFS permissions, then you have a record that you can see who has been accessing the directory. This is not infallable as members of the local administrators group can still manipulate the Security event log and thus you may need a solution such as the Audit Collection Services component of System Center Operations Manager that quickly transmits the events written to the Security event log o a secure server. See About Audit Collection Services (ACS) in Operations Manager 2007 http://technet.microsoft.com/en-us/library/bb381373.aspx -- Mike Burr

Hi I have a Windows 2003 SP2 server in my domain - server1.domain.com We have an in-house application running on this server that writes some details to text file. Whilst the details aren't in the realm of credit card numbers or anything like that, we would prefer to keep the details as confidential as possible. The files are written in clear text files to D:\App1\ and in the form of <date>.txt. The problem is that all of IT are members of the local Admin group on all our servers, this means that technically, anyone logging onto the server (or mapping a drive to \\servername\d$\App1) can read these files. I understand these are the following options for 'locking down' this file location: 1. Remove the local Administrators group from the NTFS permissions and then explicitly add only those peolpe we want to have access. 2. Encrypt the file folder using EFS (but this has problems since the log files are created daily, and you can't give multiple users access to an EFS encrypted folder, only files) Can anyone think of anything else? Why don't you advise your developers to program this application to execute a runas behind the scenes and remove members from the Administrators group to prevent unauthorized access? They will need the username and password for this runas. Obviously SOMEONE has to have access to this directory and you have to trust someone otherwise you would be the developer. You can also set DENY permissions for anyone to read that directory. This even blocks admins, and the ntfs permissions would have to literally be tampered with in order to gain access once you set a deny permission to read. The read denial will not prohibit write permissions as needed by the application. Thus, you can prevent users from accessing the directory, and leave it to the application itself. Steve Kline Microsoft Certified IT Professional: Server Administrator Microsoft Certified Product Specialist Microsoft Certified Network Product Specialist This posting is "as is" without warranties and confers no rights.

Thanks both. Auditing definately sounds like a way forward, thanks. In terms of the NTFS permissions - are there any benefits to either of these: i) Removing the Administrators from the NTFS permissions list and granting rights explicitly to those that need it only ii) Instead of removing the Administrators group, setting a DENY for everything on their list of rights?

Thanks both. Auditing definately sounds like a way forward, thanks. In terms of the NTFS permissions - are there any benefits to either of these: i) Removing the Administrators from the NTFS permissions list and granting rights explicitly to those that need it only ii) Instead of removing the Administrators group, setting a DENY for everything on their list of rights? This really doesn't add any security. It's like putting a cardboard over an empty door way and painting it with colors that do not match the hole in the wall you are covering. You can still see the poorly covered hole, you can see the creases in the cardboard. If you poke at it enough, the tape will let go and your hole is uncovered. Auditing... Definately. NTFS Permissions are editable by all administrators. So in that escense, you have already given them the keys. In order to take the keys away, you must remove them from the admins group. May I ask the nature of adding them to the administrators group instead of something more common like the Power Users group which allots them access to manage printers and minute privileges? I understand that its easier for admins to accomplish work but there are security forums to aide you in configuring applications with settings and policies so that you can implement a stable structure for the end users to complete their tasks without hassles of support. Typically I've seen or implemented a secondary user account to escelate privileges with on that distant occasion that it's needed. Usually its not needed unless admin stuff is required to get done like making updates or modiifcations to active directory. Unless they need to work in active directory, write policies... etc... take them out of the admins group. Nothing but harm can come from this. Consider this; if a virus is accidentally executed by an end user that has limited privileges, the infection can't get very far to damage the domain because it can only do what the user can do. Not too bad... A hassle, but not too bad. What if an domain administrator account executes a virus by mistakenly opening a PDF document with an adobe reader not up to date. They just opened up system access and rooted itself into your server or whatever system they had opened that PDF on. Not only that, they have system access with the Domain administrators passwords. Now they can use all sorts of tips and tricks to gain further access. There goes the entire corporations private data.... People start getting fired and the company somehow looses business to joe schmoe up the street who recently purchased a business plan or idea from another random joe schmoe whom suddenly came across some incredibly sensitive data that could impact the market in which your business conveys its primary goods or services to. Here's a list of Built-in Groups and their Permissions. http://technet.microsoft.com/en-us/library/cc755925(WS.10).aspx It's not really a nice story but... check http://datalossdb.org/ ... they keep mostly current on new stories related to penetrations. Some other good resources http://www.sans.org Server 2003 Security Guide http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-4D89-B655-521EA6C7B4DB&displaylang=en NonClassified Security Technical Implementation Guides(STIGS) from Department of Information Security Agency. http://iase.disa.mil/stigs/stig/index.html Disa handles a lot of Miliary communications Steve Kline Microsoft Certified IT Professional: Server Administrator Microsoft Certified Product Specialist Microsoft Certified Network Product Specialist This posting is "as is" without warranties and confers no rights.