Manage domain permissions using PowerShell and the ADSI API

Hello! Consider a way to automate the assignment of user rights to resources using ADSI and PowerShell. Initially, the task arose when using old Windows 2003 domain controllers and limited Internet access. This topic was touched on Habr earlier. In the case described by me, the transition to the Windows 2008 OS took place only partially, but in terms of complexity and length of the process is comparable, perhaps, to a mission to Mars.

Formulation of the problem:

When a new user is created in a large organization, a document is created that describes all the privileges of this account, including the AD groups in which he is a member.
')
There is a storage system used as a file storage for users with a large number of shared resources. Each shared resource (or just a ball) on the storage system contains an ACL (Access Control List) that includes at least two AD access groups — user (with read and execute permissions) and administrative (editing and deleting). The name of both groups in AD includes the name of the resource itself for easy retrieval. Thus, for full access to the resource, the user needs membership in both groups.

On the storage also exists a directory with shortcuts-links to resources in the public domain. When a new entry is logged into the domain, a group policy that contains Startup.script is processed. The script copies all the necessary shortcuts to the user's desktop. The user is not looking for anything and immediately gets access to all the documents he needs.

Our task includes:

1. Create user.
2. Define a list of directories to which the user should have access.
3. Create groups with a name containing the directory name.
4. Add groups to the ACL directory. Assign the appropriate NTFS rights for each group.
5. Include user in created groups.
6. Create shortcuts with the name of the directory in the title.
7. Update Startup.script, if the user is in one of the groups, copy the corresponding shortcut to it on the desktop.
8. Use available technical tools.

There are at least four ways to do the above in Windows systems. Needless to say, performing these actions through standard equipment, even for one new user, you will not keep within a hundred clicks of the mouse. If they have fifty users and they have a lot of access privileges, they will definitely not manage in a day. We will try to automate each item separately. We will not describe in detail the creation of the user, this easily accessible information.

Point 7 is also beyond the scope of the article, in fact it is an administrative template in a GPO policy. The contents of the script are as follows: if the user is in a group, you must copy the corresponding shortcuts from a certain directory to the desktop. Everything else is also well automated in PowerShell.

Let's write a test script without error checking and other nuances.

Manually determine the variables for the test. The user's full name and the list of available resources will be obtained from the account creation document:

$server_name = read-host -prompt "Enter fileserver" $share_name = read-host -prompt "Enter share_name" $UNC="\\$server_name"+"\$share_name"+"$" 

If everything is entered correctly, first create a directory and a shortcut that refers to it:

 if ($server_name -eq "S182froc152"){ $path = "\\$server_name" +"\vol1$\projetspec2\" #Check if the directory exists. Skip if true. if(!(Test-Path($UNC))) { #Create directories Write-Host "Creating $share_name" New-Item -path $path -name $share_name -Type directory 

Create a shortcut via a COM object:

 Write-Host "Creating shortcut" New-Item -path $path\E182_P_GroupWare\Projets_Specifiques\$share_name -Type directory $wsh = New-Object -com 'WScript.Shell' $dir = "$path\E182_P_GroupWare\Projets_Specifiques\$share_name" $sct = $wsh.CreateShortcut("$dir" +"\$share_name.lnk") $sct.TargetPath =$UNC $sct.Save() 

Create a security group.

First, a little theory:

There are security and distribution groups in AD. Distribution groups are used for mailing lists, mostly for MS Exchange.

Also groups are divided into local, global and universal.

• Local groups - manage permissions in the domain. May include objects from other domains.
• Global - give access to an object in any domain, but include only users from one domain.
• Universal - are used in forests for multiple domains and are all very confused. I did not have to use them.

Having rummaged in attributes, it is possible to find that local groups have the identifier groupType -2147483644, and global ones have -2147483646.

It seems that the purpose of the group itself is determined by some bit in the number. If you are too lazy to look, you can look at the ID on TechNet.

We specify and create a local group in our domain - we specify additional information in the comment: the path to the group resource, and what rights the group itself gives.

Add user:

 #Create security_group $ADS_GROUP_TYPE_LOCAL_GROUP = -2147483644 $objOU = [ADSI]"LDAP: //OU=Groups,OU=MPC,OU=E182,DC=emea,DC=corpdir,DC=net" $GroupName = "$share_name" $objGroup = $objOU.Create("group", "CN=" + $GroupName) $objGroup.Put("groupType", $ADS_GROUP_TYPE_LOCAL_GROUP ) $objGroup.Put("description", $UNC ) $objGroup.Put("sAMAccountName", $GroupName ) $objGroup.SetInfo() }} 

Resource rights are divided into SMB permissions and NTFS. This, respectively, access at the folder level and access at the file system level. In fact, they are independent. If you use FAT, you will only have to operate with SMB permissions. Access to the resource is ultimately the sum of the SMB + NTFS permissions.

In order to avoid confusion with rights to resources, we operate only with NTFS rights. In SMB rights, we expose the general access for all users. Recall the theory:

Each user in the system has an access token with security information for a given login session. The system itself creates an access token at the entrance. Every process that runs on behalf of a user has a copy of this access token. The token identifies the user, user group, and privileges. The token also contains the login SID (security identifier), which identifies the current login session. When a user tries to gain access to the protected object, authorization occurs in the system and, as a result, he receives permission or access denial. In this case, authorization is based on a search in an ACL (access control list).

Each entry element (or ACE - Access Control Entry) in the object's ACL defines access rights. The record contains three elements:

• SID - user or group identifier to which the record is applicable.
• Access type - read, write, etc.
• Record type - enable or disable.

If the object owner has not created any entry in the object's ACL, the system grants access immediately. Thus, all SID entries in the access token are compared. The order of entries is also important.

The system stops checking ACE records when the requested access is explicitly allowed or denied. For example, an explicit access denial takes precedence over inherited permission from the parent directory. In the second place are the inherited permissions from the parent directories, then all the permissions go up the directory tree. It also means that the owner of the object can define its own permissions on the object, which allow to give access to a group of users and deny access to the subgroup of the group. The inheritance parameters for an object can take the following values:

Value	Description
"None", "None"	Permissions apply only to this folder.
"ContainerInherit", "None"	Permissions apply to this folder and its subfolders.
"ObjectInherit", "None"	Permissions apply to this folder and its files.
"ContainerInherit, ObjectInherit", "None"	Permissions apply to this folder of its subfolders and files.
"ContainerInherit", "InheritOnly"	Rights apply only to subfolders
"ObjectInherit", "InheritOnly"	Permissions apply only to files.
"ContainerInherit, ObjectInherit", "InheritOnly"	Permissions apply only to subfolders and files.

The test revealed that the group is not always created in the domain before the next step is performed. I haven’t done a check yet, so just pause for 5 seconds. Next we get the directory ACL. Create a new entry in the ACL access list and save it:

 start-sleep 5 $dirpath=$path+$share_name $acl = get-acl $dirpath $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$share_name","ReadAndExecute", "ContainerInherit, ObjectInherit", "None", "Allow") $acl.SetAccessRuleProtection($True, $True) $acl.AddAccessRule($rule) Set-Acl $dirpath $acl 

Repeat the same for the second group, administrative, with other access rights:

 start-sleep 5 #$objOU = [ADSI]"LDAP://OU=Groups,OU=MPC,OU=E182,DC=emea,DC=corpdir,DC=net" $GroupName = "$share_name"+"_ADM" $objGroup = $objOU.Create("group", "CN=" + $GroupName) $objGroup.Put("groupType", $ADS_GROUP_TYPE_LOCAL_GROUP ) $objGroup.Put("description", $UNC ) $objGroup.Put("sAMAccountName", $GroupName ) $objGroup.SetInfo() start-sleep 20 $dirpath=$path+$share_name $acl = get-acl $dirpath $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$GroupName","Modify", "ContainerInherit, ObjectInherit", "None", "Allow") $acl.SetAccessRuleProtection($True, $True) $acl.AddAccessRule($rule) Set-Acl $dirpath $acl Write-Host " $share_name created" 

It remains to simply "share" the directory:

 $dirpath=$path+"\$sharename" $Shares=[WMICLASS]”WIN32_Share” If (!(GET-WMIOBJECT Win32_Share -filter “name='$share_name'”) { $Shares.Create(“$dirpath”,”$share_name”,0) } 

Conclusion

In PowerShell, there are additional handy modules Active Directory and File System Security PowerShell Module. A normal administrator may not think of contacting the wilds of object classes when assigning rights to PowerShell, otherwise he would not be an administrator, but a programmer. The list of local groups using the AD module can be obtained, for example, as follows:

 get-qadgroup -GroupScope DomainLocal | Get-QADGroupMember -Type group | Where{$_.GroupScope -eq "Local"} 

On the other hand, using ADSI is a more universal approach. There are a large number of conservative customers who, by the way, cannot be persuaded to give up Windows XP.

Cloning all permissions from one user to another, in this case, can be done from the command line using standard utilities:

 dsquery user -samid Person |dsget user -memberof |dsmod group -addmbr "CN=Some Other Person(222),OU=Users,OU=_GlobalResources,OU=222,OU=E777,DC=emea,DC=corpdir,DC=net" –c 

Successful automation!