1. Mapping Permissions
The first step in the table mode is the mapping of permissions.
Only then can you fill your table to set permissions.
2. Filling Table
The data is inserted here depending on the type of project. In case of “Scan Your resources“, the data is taken over from the initial state with the help of the button “Start filling”. The excel tables can be read in the “Import or create a table” and “Novell-migration“.
Further in all the types of projects it is possible to manually insert rows and change values. Here you must pay attention to the syntax of the field content and the column headers.
Prior to the transfer of the data, there are several options which can influence the data transfer.
Transfer of Directories
With the default settings, directories and permissions down to three levels under the Share are imported. If there are permissions even below that, which you wish to transfer, you can set this value up to 10 levels.
This function acts as a filter. The users and groups entered here are not transferred. It is possible that you wish to remove here the groups or users from the grown structures, or remove them under permitted administrators to permit them once on the Share. After entering the first characters, the objects matched from the AD are listed out. You can select the objects with the tab or press enter and continue the search. The number of entries is not limited.
Include directories that only contain inherited permissions
In this function not only are the directories transferred, which are explicitly permitted, but also those with inherited permissions. In case of continuation of the program they are explicitly transferred from these inherited permissions. This is not so useful, rather it saves time for taking path name without tedious typing but then you have to delete a lot. This must be observed, otherwise, numerous excessive ACL entries are generated.
With this, you can transfer the scanned initial structure to the present table after considering the adjusted options.
If data is not transferred from the initial structure by filling, instead through manual entries, then you come to the next step with “To the validation”.
2.2. Editing the Table
a. Target Path
- The target path is given at the beginning of the project. This is composed of the server and the share name. It can also be supplemented by a directory name. The target path is displayed above the table.
- The path can be specified in the table beginning with “\”. They are then created by migRaven under the target path given above. Target path and the entered path result in the complete path name.
- Edit directory paths: In the column “Path”, the path data that is read is entered and can also be edited here. It should be noted, that a path should not appear twice.
- Delete paths (delete rows): Rows can be selected and deleted completely. If only the content is deleted and a blank line remains in the table, then an error message appears in the validation.
- Rows can be marked with the checkbox in the 1st column. A section can be marked by clicking on the empty space in the left row and holding down the mouse button.
- Add new path: Under the header “+ Click here to add new item” you can add new rows to the project and fill them as per the specifications.
- At least one permission must be given for every path.
c. Editing the Permissions
Once the path is entered in the first column, the permission is set as per your requirement in the subsequent columns.
migRaven offers two variants for configuration of the permissions:
- migRaven creates new groups: In this specification, you can enter the users and groups in the permission column, as this is automatically attached to a migRaven-group.
- If NO new groups are to be created by migRaven, then chose “groups are reused”. In this case it is recommended to enter only groups and no users, as migRaven also writes these directly in the ACE. Generally the permissions should take place through the groups. Therefore, this procedure is not recommended.
Editing the Permissions:
- migRaven uses the standard permissions: “Read and Execute”, “Write”, “Modify”, “Modify Plus” and “Full Control”. Those that are to be permitted are to be assigned to the corresponding columns. Other permissions cannot be allocated by migRaven.
- Multiple entries in a permission column: If in a step multiple objects are to be permitted, then the individual accounts are to be separated by a semicolon (;), blank spaces are not valid.
- The format of the groups or users that are to be stored, must be “netbios-Domain\SAMAccount” for example aikux\f.miller
- Enter permissions only at the permission end points because the permissions from the share down to the actual permission endpoint are automatically set. It is enough to delete the redundant rows from the table.
- Restrict to the standard permissions like “Read and Execute”, “Write”, “Modify” and “Modify Plus”. The permissions for “Full Control” for the system accounts should be entered by migRaven directly on the top directory on the Share. This is inherited up to the lowest level. In case you have entries in this table in the column for full access, delete them if necessary.
- Always start migRaven with an account, which has the right to edit the permissions of the corresponding directories.
d. Interruption of Inherited Permissions
In the 3rd column you can initiate an interruption of the inheritance by marking the box for this path. The condition being that for the related directory at least one explicit permission is given, as the validation for these lines will otherwise brings errors.
How does this interruption work? In Windows, there are many variants of the interruption of inheritance. In migRaven, there is only one.
The interruption works in such a way that, on this path the permissions that are inherited end here and are not passed down any. We assume that, interruption of inheritance is placed for this purpose.
The following permissions are inherited below:
- Permissions, which are placed explicitly on this path.
- List permissions (List groups and permitted groups provided with list permissions) for permission end points lying below that.
- All permissions, which are based on the target share at the time of migration. This ensures that administrators do not lose their permissions.
In the example on the screenshot in the directory “Chief Accountant” the inheritance is interrupted and the chief accountant is given a “Modify plus” permission on this directory. Thereby, the group “accounting _g” takes over the permission to see the directory of the chief accountant.
Here you verify the syntactic correctness and the existence of the groups and accounts used. These should be present. Errors are displayed in the status column. Reasons for errors can be:
- Missing or misspelled groups and accounts
- Blank spaces in the list of objects in a field
- Paths without permissions
Objects, which you create later in the AD, will be unknown in migRaven. The AD must then be scanned again with “Rescan”, so migRaven can recognize the new objects. After that you must repeat the “Design & Work” for this project.
The option “Paths are verified for their existence” must be de-selected if new paths are to be created, which usually is the case.
Run migRaven with an account, which is equipped with sufficient permissions (Domain Administrator).
|Error messages||Possible reasons|
|“No connection to the share”||The option “Paths are checked for their validity” should be un-selected.|
|“…Nesting forbidden due to the group type ”||The given groups cannot be nested in the permission groups, for example, universal permission groups cannot include any local user groups.|
|“Account unknown …”||The given object is not known. It must be created in the AD and then read with Rescan. Perhaps here in the table even a blank space is too much between object names and semicolon when counting objects.|
|“Account not found in the AD-Graph ”||The given object is not known. It must be created in the AD and then read with Rescan. It is also possible, that here it was not correctly written.|
4.1. Export to Excel (CSV)
Here you have the possibility to issue the read permission structure in form of a CSV file. You could finish the project here, edit the permission structure in the spreadsheet and after that read the table again, using the table-import.
Please find additional information in this article: Export access right structures as .csv file
4.2. Save the work progress and continue the work in Drag & Drop mode
The updated working state is stored in the database.
migRaven automatically jumps into the Drag & Drop mode.