|
 |
|
 |
|
Re: Script (s) to help with file security audit
|
|
On Mon, 4 May 2009 12:57:01 -0700, Wolfie <...@discussions.microsoft.com
Hi Al,
Thanks for your response!
What we initially wanted to do was verify that all shares and folders are
using AD groups for permissions rather than user accounts. After we talked
about it, we decided that we should check all permissions and verify they are
correct.
There are a few folks managing files here and it starts to get messy after a
while. 8-D
By specific location I meant I want to scan all files and folders on
specific hard drives. We can do this either locally on the server or
remotely (I'll connect to the admin share if needed).
You make an excellent point about the row limit in Excel, I didn't think
about that. We have several folders on this drive that we want to audit the
permissions on, instead of doing the entire drive I could easily do the check
on each folder and it's contents. I am confident we won't hit the limit if
we do it this way.
In retrospect, I don't think we need to check the individual files for their
exact permissions. Could we check to see if they have the inherit option
selected? This would flag any for me where they have specific perms setup.
I know there won't be more than a few so I can check these manually.
I would like the output as follows (I am using commas to separate the column
headers):
For Users/Groups:
Name,Type (User or Group),AD Location,Members (if groups)
For Files/Folders:
Object Type (File/Folder),Full Path,Name,Are perms inherited?,Who has
access?,What access do they have?
I looked at the info on ADsSecurity.DLL and to be honest, I'm even more
confused.
I took a look at CACLS (never used it before) and I think it will work. I
can figure out how to parse it, despite how I'm feeling at the moment I'm
really not that dense! One thing I can't figure out from what I found is how
do you tell CACLS to return the perms on all files and folders within a given
spot? I know that *.* will do the contents of where you are but how do you
tell it to run recursively?
Now for the AD User/Group information, do you have any tips on that?
I really appreciate your feedback on this one.
Nancy
>
|
| |
 |
|
 |
|
|
|
|
|
On Mon, 4 May 2009 21:26:16 -0600, "Al Dunbar" <...@hotmail.com
"Wolfie" <...@microsoft.com...
you're welcome.
I wondered about that. If your script know what is correct, would you then
just have it report discrepancies, or correct them?
Understatement!
Great. You could have a script create the output files based on the folder
being processed.
Probably, but that is one aspect of the details that I have not come to
grips with. Having looked at output from my (very rudimentary) script, I
have come to the conclusion that there are a number of ACE combinations that
imply inheritance.
The trouble arises from the fact that groups typically have multiple
members, and any cell containing enough content to require line-wrapping
will be very hard to read. If you do this, I'd suggest using the
sAMAccountName instead of the DN.
Alternately, a separate row for each member... but then you risk bumping
into the rown length limitation again...
who has access and what access do they have: I don't see how you could
possibly put this all on one line while at the same time making it possible
to read. So then you'd have separate row for each ACE. Keep in mind that if
one trustee has multiple permissions, he will need multiple rows. For
example, someone could inherit read-only, be granted read/write, and be
denied delete.
The other question is: will the "who" column contain the direct trustees
having an explicit ACE? Or will you expand groups to include their members?
And, if so, will you expand groups recursively?
And if you do all that, and produce a complete list of all individual
accounts having different types of access, good luck determining if there
are any improper permissions. That would only be possible if the person
reviewing the info actually knew all of the users.
That stuff is extremely detailed, but, imho, that is how security actually
works.
/T switch.
I thought that was what you asked above.
If you have an extremely convoluted and badly organized set of shared folder
permissions, no amount of analysis will make sense of it, as it becomes way
too complex. If you have a well-defined approach, you won't need to audit
it, as it would be easier to simply re-apply the required permissions.
By well-defined, I mean the following:
- logical user/group structure based on department, job title, and etc.
- use only basic permissions: read-only and read/write. reserve full for
admins only, and avoid deny altogether.
- for each type of permission required on a given folder, permit it to a
separate and single-purpose group.
- create the "resource permission groups" when the folder is created, permit
them at that time, and never change the permissions afterwards.
- No group should be permitted to more than one resource.
Once things are configured this way, you "permit" groups or individuals by
adding them to the groups having the permissions they require, and de-permit
by removing them.
/Al
|
|
|
|
|
|
|
|
|
On Wed, 6 May 2009 10:46:06 -0700, Wolfie <...@discussions.microsoft.com
Hi Al,
Thanks again for your feedback.
I was looking around and found a utility called DumpSec
(http://www.systemtools.com/somarsoft/index.html) that gives me the listing I
am looking for.
It has the ability to export the data to CSV file and I can run it from the
command line so it can be automated.
I'll need to parse out the path from the end folder/file name but I think I
can do this in Excel without too much trouble.
I am going to use this to dump the permission info on our data folders and
compare it to our AD users and groups. We have a small enough group of
computer users here that I know each user so I will be able to do a visual
check and manually lookup anything that seems odd.
Our setup is pretty streamlined in so far as we have standard groups that
are used for perms and we add/remove users as needed so there shouldn't be
very many spots where we've used individual accounts but that is one of the
things we are checking for.
Thanks for all of your help with this and sorry for the long route I took to
get to this point. It's the first time I've ever done anything like this so
I think I made the mistake of going to complex initially.
Nancy
>
|
|
|
|
|
|
|