Summary: Create a home drive with Microsoft MVP and honorary Scripting Guy, Sean Kearney.

Microsoft Scripting Guy, Ed Wilson, is here. If you are a seasoned Hey, Scripting Guy! Blog reader, you know that the most frequent guest blogger is Sean Kearney. If you are new to the blog, I welcome you, and I encourage you to catch up with Sean’s previous blogs.

Sean is a Windows PowerShell MVP and an Honorary Scripting Guy. Sean has been selected to present sessions called Integrating with Microsoft System Center 2012 and Windows PowerShell at TechEd NA and TechEd Europe this year. In his free time, Sean has written several blog posts about Hyper-V and some other cool stuff. Sean will be the blogger all week, and today he is writing about home folders.

BTW, if you are in New Orleans for TechEd this week, be sure to come by the Scripting Guys booth and say hello. The Scripting Wife and I will be there in addition to Chris Duck and Brian Wilhite. We also invited www.powershell.org to share the booth with us, so come by say hello to Don Jones, Jason Helmick, and Mike Robbins. I am also sure Sean will be hanging out at the booth.

Last time in Creating a Home Drive with Windows PowerShell: Part 1, we defined a common structure with permissions to create a base structure for private or home drives for our user.

Our next challenge is to ensure that we assign the proper NTFS permissions in a consistent manner. For that we will be leveraging .NET.

To find out which .NET library to access, just run Get-ACL on any folder or file on your computer and then pipe that through Get-Member. (Get-ACL is the Windows Powershell cmdlet for “get access control list.”)

GET-ACL C:\Users | GET-MEMBER

The top line marked “TypeName” will indicate which .NET library was leveraged to access this information. To obtain information on any .NET library, you need to enter the library name as your search details on the MSDN site.

With this information in hand, we have some information about building out access control lists.

There are two key things we look at in an access control list. Really—only two. There is the owner of the object, and there is a series of access rules.

In the case of the NTFS permissions, we will be building a simple series of access rules that meet the following guidelines:

• No rights inherited from the parent folder
• Domain Admins have Full Control of the folder structure
• The user for which this folder is defined has full control on this folder

To achieve this goal, we must define a list of access rules for the folder. This involves defining a set of rules and then applying them to the user’s home drive by using the Set-ACL cmdlet.

First let’s take a look at the object exposed when we run Get-ACL. Running Get-ACL on C:\Users in Windows 7 provides the following output:

We can see the owner that is already present on this folder is the built-in SYSTEM account. To view the access rules for this folder, we can run it again and specify only the access property to be viewed.

This returns an array of access rules presently applied to the C:\Users object on the file system. We can view these rules individually by specifying their position within the array.

If I want to view the first member of this access rule, I need only specify its index position in the following manner:

(GET-ACL C:\Users).Access[0]

This will return only the first access rule. To create a new access rule, we need to know what type of object it is within .NET. We need to pipe the output of any access rule returned to Get-Member to determine the .NET object type.

The structure of an NTFS rule:

From the output returned, we can see from “TypeName” that the access rules are from [System.Security.AccessControl.FileSystemAccessRule].

We need to define five components to create an access rule. You will see them as five of the properties returned from an access rule. They are:

• IdentityReference
• FileSystemAccessRights
• InheritanceFlags
• PropagationFlags
• AccessControlType

IdentityReference will be a user name within Active Directory or the local system. The IdentityReference is strictly a string that contains a valid account name. It can be a user or a group for our purposes. We will define the IdentityReference for our first rule as ‘CONTOSO\JohnnyTest’:

$IdentityReference=’CONTOSO\JohnnyTest’

FileSystemAccessRights identifies what type of access we are defining, whether it is Full Access, Read, Write, Modify or any of several rights that are available to apply to an object in file system. This is a [System.Security.AccessControl.FileSystemRights] object. For our home folder, we are going to assign FullControl as the right we are defining:

$FileSystemAccessRights=[System.Security.AccessControl.FileSystemRights]”FullControl”

InheritanceFlags defines how the security propagates to child objects by default, such as to other files or folders. For the purposes of our home folder, we will allow the same rights on all files (objects) and folders (containers). This is a [System.Security.AccessControl.InheritanceFlags] object:

$InheritanceFlags=[System.Security.AccessControl.InheritanceFlags]”ContainerInherit, ObjectInherit”

PropagationFlags specifies which characteristics (if any) are to be inherited from the parent object. We want to have an exclusive set of rights on our Home folder. No rights will be inherited. This object is of the type [System.Security.AccessControl.PropagationFlags].

$PropagationFlags=[System.Security.AccessControl.PropagationFlags]”None”

AccessControlType actually defines if the rule we are creating is an Allow or Deny rule. That’s it. We are defining a way to allow access, and will set this rule as Allow. This object is of the type [System.Security.AccessControl.AccessControlType]:

$AccessControl=[System.Security.AccessControl.AccessControlType]”Allow”

When we have defined the five objects for our access rule, we need to create the actual access rule, which is an object in itself.  Do you remember TypeName from when we ran Get-Member against the access rule? We will be creating an object of this type, which was [System.Security.AccessControl.FileSystemAccessRule].

Note   The definition for how to create an access rule is on MSDN if you use System.Security.AccessControlFileSystemAccessRule as your search parameter. It is referenced as a constructor.

To create an access rule, we need to pass the five parameters we have defined to the [System.Security.AccessControl.FileSystemAccessRule] object:

$AccessRule=NEW-OBJECT [System.Security.AccessControl.FileSystemAccessRule]($IdentityReference,$FileSystemAccessRights,$InheritanceFlags,$PropogationFlags,$AccessControl)

~Sean

Thanks, Sean, for a great post. Join us tomorrow for Part 3 of Sean’s home drive series.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy