Skip to main content

quick look at get-NTFSExplicitPermissions

get-NTFSExplicitPermissions
As one of favourite time saving functions of late, I thought I'd continue my recent trend of blogging again by giving a bit of insight to it's background.

One of the parts to my day job is looking after file servers.  I don't do day to day admin work on them, more look at managing space and migrating data to new servers / volumes if required.

Now the problem with doing the data migrations and not being involved in the day to day admin work (ie assigning permissions creating shares etc) is that I have no control over how and where the permissions are assigned.  I learnt how to assign permissions to file systems years ago in Novell environments, which was soon followed with the MCSE taught A-G-D-L-P model. (AGDLP? now that sound like a reasonable blog post for an AD Admin blog site!)

Anyway, I have since found that these early teaching on permission models are not implemented as thoroughly as I would like, where ever I seem to work - hence, get-NTFSExplicitPermissions.

This function allows you to return any permissions that have been assigned below the root of the folder structure, giving you exactly who would be affected if you move the data to somewhere else.  It defaults to 3 levels deep so it doesn't take hours to run on deep tree structures.  

To run it all you need is the path parameter (which is also works as positional parameter 0) and you are away....

get-NTFSExplicitPermissions -path e:\data

or

get-NTFSExplicitPermissions e:\data

and you get something like this : 

PS C:\Users\Administrator> get-NTFSExplicitPermissions e:\data

path                          IdentityReference                          FileSystemRights             AccessControlType
----                          -----------------                          ----------------             -----------------
e:\data                       BUILTIN\Administrators                          FullControl                         Allow
E:\data\2                     CREATOR OWNER                                     268435456                         Allow
E:\data\2                     NT AUTHORITY\SYSTEM                             FullControl                         Allow
E:\data\2                     BUILTIN\Administrators                          FullControl                         Allow
E:\data\2                     BUILTIN\Users                   ReadAndExecute, Synchronize                         Allow
E:\data\2                     BUILTIN\Users                       CreateFiles, AppendData                         Allow
E:\data\users                 CREATOR OWNER                                   FullControl                         Allow
E:\data\users                 NT AUTHORITY\SYSTEM                             FullControl                         Allow
E:\data\users                 BUILTIN\Administrators                          FullControl                         Allow
E:\data\users                 BUILTIN\Users                   ReadAndExecute, Synchronize                         Allow
E:\data\users                 BUILTIN\Users                 ...s, AppendData, Synchronize                         Allow
E:\data\users                 CORE\Adam Stone                                 FullControl                         Allow

note the last line is where I have assigned myself the full control permission to the users folder.  The rest of the permissions suggests that inheritance has been switched off on both e:\data\2 and e:\data\users as the default permissions are showing up as not inherited.

To increase the depth of the search, just use the recurse parameter...this will dig 10 folders deep from the root :

get-NTFSExplicitPermissions -path e:\data -recurse 10

Of course, you can filter the results in the same way as you would with the where clause... to remove NT AUTHORITY and BUILTIN results you can do this : 

get-NTFSExplicitPermissions -path e:\data | Where {$_.IdentityReference -notlike "NT AUTHORITY*" -and $_.IdentityReference -notlike "BUILTIN*"}

this command run on the same folder as above returns : 

path                          IdentityReference                          FileSystemRights             AccessControlType
----                          -----------------                          ----------------             -----------------
E:\data\2                     CREATOR OWNER                                     268435456                         Allow
E:\data\users                 CREATOR OWNER                                   FullControl                         Allow
E:\data\users                 CORE\Adam Stone                                 FullControl                         Allow

This function has already saved me more time than it took to write!  

The latest release can be downloaded here, and for more info on the module see here.

Oh, and thanks goes to Ivan for his input!

cheers

Adam

Comments

Popular posts from this blog

Enable Powershell Remoting (WinRM) via Group Policy

I have been doing some testing on enabling WinRM via group policy, being that WinRM is the service that Powershell v2 sets up it remoting capabilities. Here are the GPO settings that you need to configure WinRM .... set the winrm service to auto start Computer Configuration \ Policies \ Windows Settings \ Security Settings \ System Services Windows Remote Management (WS-Management)  set Startup Mode to Automatic start the service incorporated in to the above - you may need a restart. create a winrm listener Computer Configuration / Policies / Administrative Templates / Windows Components / Windows Remote Management (WinRM) / WinRM Service / Allow automatic configuration of listeners IPv4 filter: * * is listen on all addresses, or if you only want a particular IP address to respond use an iprange eg 10.1.1.1-10.1.1.254 - don't forget that this IP range has to be valid for all hosts that fall in the scope of the GPO you are creating.  You can use 1...

Assigning Permissions - AGDLP

AGDLP It seems I have been mildly distracted away from the title of this blog site.   It does say AD Admin, but I seem to have been taken away by file system stuff.   I have to say, it has all been worthwhile, but it’s probably time I got back to the real heart of what I do. There are probably a million permission assigning advice pages, but I thought I would put another one out there after referring to AGDLP in my last post. So, what is this all about – AGDLP.   Well, it is something I learned in my MCSE 2003 studies and has become ingrained into my ideals since.   As a contractor, I get to move job often.   This enables me to forge opinions on how to configure things in a domain, and more importantly how NOT to configure things. AGDLP is definitely on the to do list…for anyone in any size domain or forest, as it follows some very basic principals.   I will explain these whilst I go through what AGDPL stands for. A A is for...

Finding out what 'SearchFlags' are set on you AD attributes

Whilst doing some research into indexed attributes, I posted this  a while back on how to find your index attributes.  Since then, I have looked a little deeper into what indexing really means and found this excellent explanation on the numbers that can be found in the searchflags attribute of a schema object. Using Florian’s reference, I built the following script (which is both powershell v1 and v2 compatible) to get the schema attributes from the forest schema and return (among other things) the breakdown of your attributes search flags. $forest = [System.DirectoryServices.ActiveDirectory.forest]::getcurrentforest() $schema = [ADSI]('LDAP://CN=Schema,CN=Configuration,dc=' + ($($forest).name -replace "[.]",",dc=")) $attributes = $schema.psbase.children | where {$_.objectClass -eq "attributeSchema"} $collection = @() foreach ($attr in $attributes){ $store = "" | select "Name","lDAPDisplayName","singlev...