Subscribe to Windows IT Pro
August 28, 2001 12:00 AM

Create Home Directories and Set NTFS Permissions with a Web Script

Windows IT Pro
InstantDoc ID #22048
Rating: (2)
Downloads
22048.zip

Setting Up the Scripting Environment
You now need to grant the HelpDesk group the permissions it needs to successfully run the script. After you customize HomeFolderPerms.asp, place the script and StyleSheet.css in a folder on a DC. Restrict folder access by granting the HelpDesk group only Read permission to the folder.

On the DC containing your user accounts, create a virtual directory in IIS. Point the virtual directory to the physical directory that contains the script and configure the virtual directory for the access permissions of Read and Run scripts. Then, go to Virtual Directories Properties and select the Directory Security tab. Select Integrated Windows authentication only and clear the Anonymous check box. If the DC contains home directories, grant the HelpDesk group all NTFS permissions except Full Control to the parent directory of your home directories.

Create a hidden share named xdrive$, where x is the drive containing your home directories. For example, if your home directories are on the E drive, you can create a hidden share named edrive$. Another option is to assign a more generic name to the hidden share, such as Users$. That way, if you need to move your home directories to another drive, all you need to do is reassign the share to the new drive. If you take this approach, you must modify the script. Instead of pointing the sParentPath variable to the sDriveLetter variable and the drive$ string, point it to the Users$ string.

Next, give the HelpDesk and Domain Admins groups Change and Read share access, and remove the Everyone group from the share's DACL. Although a hidden administrative share exists on each drive on a fixed disk of a computer running Win2K, you can't directly add groups or users to the administrative share's DACL. Repeat the steps of setting the NTFS permissions, creating the hidden share, and setting share access on all servers containing home directories.

On member servers that contain home directories, you must grant the HelpDesk group the Take ownership of files or other objects user right. If you don't grant this right, the HelpDesk group members won't be able to apply permissions to home directories that they don't already have permission to access.

Because the HelpDesk group will access the WMI namespace remotely, you must configure WMI security. Open Microsoft Management Console (MMC) on the DC on which the script will run. In the tree, expand Services and Applications, then select the WMI Control node. Right-click the node and select Properties. From the WMI Control Properties dialog box, click the Security tab and expand the Root folder. Select the CIMV2 folder, then click the Security button. Add the HelpDesk group, grant it Remote Enable permission, and click OK.

Next, expand the directory folder, select the LDAP folder, and assign Remote Enable permission to the HelpDesk group. This permission applies to the CIMv2 and LDAP namespaces only. Granting this permission lets the HelpDesk group members connect to and use these two namespaces from the script. Don't remove the Everyone group from the default permission settings inherited from the Root folder of the WMI namespace.

The Finishing Touches
With the script customized and the scripting environment set, double-checking a few items is a good idea. Here's a quick checklist:

  • Make sure that the home directory servers and the DCs are running Win2K SP1 or later.
  • To protect other directories that are peers of the parent directory, adjust NTFS permissions so that the HelpDesk group members don't gain access to restricted directories.
  • Make sure you use local groups for all permissions settings. You can add a global group containing your staff members to the local group.

In addition to running through this checklist, you might want to implement a few improvements to HomeFolderPerms.asp. Possible improvements include:

  • Use Dynamic HTML (DHTML) to change the value in the Path to parent directory text box when the value in the Server name drop-down list changes. For example, if Server1 contains home directories on E:\home and Server2 contains home directories on F:\homedirs, you can make the Path to parent directory text box show E:\home when Server1 is selected and F:\homedirs when Server2 is selected. You might also modify the script to find the proper file server based on the value in the User account name text box.


  • Modify the script so that it creates a list of all user accounts, then uses that information to populate a drop-down list that replaces the User account name text box. If you decide to implement this suggestion, you might want to limit the list of user accounts displayed to one organizational unit (OU) at a time. Otherwise, the script might be slow to generate the complete list of user accounts.

I'm sure some of you will come up with even more ways to improve the script. With or without improvements, the information I presented here should get you well on your way to facilitating network administration with HomeFolderPerms.asp.

Related Content:

ARTICLE TOOLS

Comments
  • KHALED
    6 years ago
    May 24, 2006

    I am not able to find the entire scripts to download. Any idea. Thanks

  • Anonymous User
    7 years ago
    Apr 21, 2005

    I am a novice when it comes to ASP, so please bear with me. I have modified your UserCreate.asp and have it working fine, but when it comes to HomeFolderPerms.asp, the home directory on the file server is not created (although the script thinks it is) - until it tries to apply rights I have domain admin rights. I can run a test vbs script from the same directory on the domain server and create directories without a problem.

  • RICHARD
    8 years ago
    Nov 04, 2004

    The script is creating the users home directory but it si not giving it the necessary rights to the folder. The error I get is Unable to retrieve the Win32_LogicalFileSecurity Setting of d:\\ririvera

  • Remy
    8 years ago
    Mar 29, 2004

    Indeed this is the best script I've seen so far. But, one little tiny thing is missing....varType function is missing.

  • Braden Callahan
    10 years ago
    Aug 28, 2002

    How can I do this with multiple users? I took your script and hacked it into a VBScript file to run against a large volume of data. The problem is that I can only use one user and it overwrites the existing ACE entries for the ACL. This is the best script I have found to do this so far. I commend you on your knowledge. Thanks for any help.



    Braden - Thanks for your kind words about the article. I have to tell you, I really sweated that one out because, as you've found, the documentation on configuring DACLs using WMI is somewhat incomplete.


    In answer to your first question, you should wrap the modifications to the DACL inside a script that uses either ADO and the ADSI OLE DB provider or a script that enumerates containers using the ADSI IADsContainer interface.


    Here's a script that uses ADO to return all user accounts that are security principals in a domain named na.fabrikam.com. Once that result set is returned, the script modifies the company attribute of each user account to Fabrikam. What you need to do is replace the bolded lines of the script below with the script I wrote to modify the DACL of user account folders. Of course, you should also change the distinguishedName specified in the query string. I know this isn't a complete solution but hopefully it puts you on the right track. This script is part of the System Administration Scripting Guide (SASG) that I'm contributing to for the Windows .NET Server Resource Kit. To see this and many other scripts, visit: http://www.microsoft.com/technet/scriptcenter. This is the area that our team is responsible for and the scripts there are derived primarily from the scripts that will eventually appear in the SASG.




    Set objConnection = CreateObject("ADODB.Connection")

    objConnection.Open "Provider=ADsDSOObject;"



    Set objCommand = CreateObject("ADODB.Command")

    objCommand.ActiveConnection = objConnection



    objCommand.CommandText = "LDAP://dc=NA,dc=fabrikam,dc=com;" & _

    "(&(objectCategory=person)(objectClass=user));" & "ADsPath;subtree"


    Set objRecordSet = objCommand.Execute



    While Not objRecordset.EOF

    strADsPath = objRecordset.Fields("ADsPath")

    Set objUser = GetObject(strADsPath)

    objUser.Put "company", "Fabrikam"

    objUser.SetInfo

    objRecordset.MoveNext

    Wend



    WScript.Echo objRecordSet.RecordCount & " user accounts modified."

    objConnect.Close



    About not overwriting the DACL, I would have to research this before feeling comfortable with answering your question. Unfortunately, I'm swamped right now with trying to get chapters delivered for the SASG. I hope, though, that I've helped put you on the right track for now. I suggest visiting the TechNet Script Center to see what you can dig up. You might also want to download the latest WMI SDK and read about the Security Provider. --Ethan



You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.