Table of Contents
1. Mapping Permissions
The first step in the table mode is the mapping of permissions.
Only then can you fill in 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 from the initial state with the help of the button" Start filling ". The excel tables can read in the "Import or create a table"And"Novell migration".
Further, in each of 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 you wish to transfer, you can set this value up to 10 levels.
This function acts as a filter. The users and groups are hereby not transferred. It is possible that you wish to remove them from the grown structures, or remove them from permitted administrators to permit them once on the share. After entering the first characters, the objects are 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 those with inherited permissions. In case of continuation of the program they are / are transferred from these inherited permissions. This is not so useful, rather it saves time for taking path name without tedious typing. Otherwise must be 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 transferred from the initial structure by filling, instead of 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 therefore 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 now created by migRaven under the target path given above. Target path and the completed 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 it should not appear twice.
- Delete paths: Rows can be selected and deleted completely. If only the content is deleted 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 edited 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 the 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 created by migRaven, then chose "groups are reused". In this case it is recommended to enter only groups and no users, as migRaven so 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 who are to be assigned to the corresponding columns. Other permissions can not 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 separated by a semicolon (;), blank spaces are not valid.
- "Must be" netbios domain \ SAMAccount "for example aikux \ f.miller
- The 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" 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.
How does this interruption work? In Windows, there are many variants of the interruption of inheritance. In migRaventhere 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 located on this path.
- List permissions (List groups and permitted groups with list permissions) for permission.
- All permissions, which are based on the target share at the time of migration. This ensures that administrators do not loose 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. This 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 field of objects in a field
- Paths without permissions
Objects, which you create later in the AD, wants to 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 selected, 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 can not be used in the permission groups, for example, universal permission groups can not 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 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 therefore possible that this is not correct.|
4.1. Export to Excel (CSV)
Here you have the possibility to issue the read permission structure in the form of a CSV file. You could finish the project here, edit the permission structure in the spreadsheet and then read the table again, using the table-import.
Please find additional information in this article: Export access rights structures as .csv file
4.2. Save the work progress and continue working in Drag & Drop mode
The updated working state is stored in the database.
migRaven automatically jumps into the Drag and drop mode.