Apparently my karma is this: to implement standard tasks in all sorts of non-trivial ways. If someone has a different vision of the problem, please discuss it so that the issue can be worked out.
One fine morning an interesting task arose to distribute rights to groups of users for different shares containing subfolders of projects with document folders. Everything was fine and a script was written to assign rights to the folders. And then it turned out that the groups should contain users from different domains, from different forests (). Let's say the share itself is located on Synology media, registered in the FB domain of the PSI forest. Task: to allow users of domains in another forest to have access to the contents of this share, and very selectively.
After some time, the technical specifications took the following form:
- 2 forests: PSI forest, TG forest.
- Each forest has 3 domains: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- There is a trust relationship between forests; Synology sees all Security groups in all forests.
- Shares and folders/subfolders must have FB domain administrator accounts with FullControl rights
- The names of the folders should be systematized. Management coordinated the project IDs; I decided to link the name of the Security groups to the project IDs.
- Project folders in system shares must contain a structure prepared in advance in an .xlsx file, with appropriate access privileges (R/RW/NA, where NA β no access)
- It should be possible to restrict the rights of users/group members of one project to only certain directories of that project. The user may not have access to other directories/projects, depending on group membership.
- When creating a project folder, groups should be created as automatically as possible in the appropriate domains with names corresponding to project IDs.
Notes to the technical specifications
- Setting up trust relationships is not included in the scope of the technical specifications
- Project ID contains numbers and Latin characters
- Project user roles for all domains have standard names
- An .xlsx file with folders and access rights (access matrix) is prepared before the start of the entire project
- When implementing projects, it is possible to create user groups in the corresponding domains
- Automation is achieved by using standard MS Windows administration tools
Implementation of technical specifications
After formalizing these requirements, a tactical pause was taken to test methods for creating directories and assigning rights to them. It was intended to use only PowerShell, so as not to complicate the project. As I wrote earlier, the script algorithm seemed quite simple:
- we register groups with a name derived from the project ID (for example KC40587) and the corresponding roles specified in the access matrix: KC40587-EN- for engineer; KC40587-PM β for product manager, etc.
- we get the SIDs of the created groups
- register the project folder and the corresponding set of directories (the list of subfolders depends on the share in which it is created and defined in the access matrix)
- assign rights to groups for new subdirectories of the project according to the access matrix.
Difficulties encountered at stage 1:
- misunderstanding of the method of specifying the access matrix in the script (a multidimensional array is now implemented, but the path to filling it is being sought based on the contents of the .xlsx file/access matrix)
- impossibility of setting access rights in SMB shares on synology drives using PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas -share?forum=winserverpowershell), because of which a lot of time was lost and everything had to be adapted to scripts using the icacls access rights editing utility, which required the creation of an intermediate repository of text and cmd files.
In the current mode, the execution of cmd files is controlled manually, depending on the need to register a folder for the project.
It also turned out that the script should also be executed to register groups in other forests (the term Cross-domains was used), and the ratio can be not only 1 to one, but also 1 to many.
This means that groups from other cross-domains, including a neighboring forest, can now claim access to the resources of any domain. To achieve uniformity, it was decided to create a symmetrical structure in the OU of all serviced domains of all forests (black vertical ovals). As they say, in the army everything should be ugly, but uniform:
Thus, when registering project 80XXX in the TG domain, the script executes:
1. creation of the corresponding OU (red horizontal ovals) in this domain and cross-domains, that is, those domains whose employees must have access to this resource.
2. filling OU with groups with names like -, Where:
- SRC_ domain β cross-domain whose employees will have access to DST domain resources
- DST_domain β the domain to whose resources, in fact, access should be provided, that is, for the sake of which everything was started
- β project number
- ROLES β names of the roles listed in the access matrix.
3. reading the array of SIDs of all groups of all involved domains and saving it for subsequent data transfer to a file that defines the rights to a specific project subfolder
4. generation of source files (parameter /restore) with a set of rights for use by the icacKC utility in executable file mode βicacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. creating a CMD file that combines all launched icacls for all project folders
As was written earlier, launching the executable file is done manually and evaluation of the execution results is also done manually.
Difficulties that we had to face in the end:
- if the project folder is already filled with a large number of files, then running the icacls command on the existing volumes can take considerable time, and in some cases led to failure (for example, when there are long file paths);
- in addition to the /restore parameter, we had to add lines with the /reset parameter in case the folders were not created, but were transferred from previously existing folders, with inheritance rights from the root disabled;
- Part of the script for creating groups had to be executed on an arbitrary dc of each forest, the problem concerns administrative accounts for each tree.
General conclusion: it is very strange that there are no utilities with similar functionality on the market yet. It seems possible to implement similar functionality based on the Sharepoint portal.
It is also incomprehensible that it is not possible to use PoSH utilities for setting folder rights on sinology devices.
If desired, I am ready to share the script by creating some project on github if anyone is interested.
Source: habr.com