migRaven Builds all permission groups in one operation and nests them as recommended by Microsoft Best Practice. (AGDLP / AGGP)
Depending on the project scope, this can be up to thousands of groups. The selection must take into account whether it is a single domain, a domain Forrest or even choked domain environments. In certain constellations you can not select every group type.
The Group configuration of migRaven The group type and name structure of the Active Directory authorization groups to be created, the creation depth of the list groups and the storage location for the new groups are specified in AD.
The group configuration must take place before the first project call, since the authorization groups are created according to this configuration during the project run.
The Rider Type The group type for the authorization groups and the storage location for them must be entered in the AD.
The tab Type
Here you select which type of authorization groups should be migRaven automatically generated. The choices are:
- domain local groups,
- universal groups and
- global groups.
When choosing the right group type, it is crucial to know whether you work with one or more domains and which group type your user groups have. The groups available for selection differ in which groups they can accept, whether they can accommodate groups from other domains, and how many bytes a group has in the login token (TokenSize problem) busy.
Only one domain
With only one domain, global or universal groups make sense, both occupy only 8 bytes in the Kerberos token and can accommodate global groups, the common type for user groups. Global groups can only accommodate global groups. If you want to opt for this, please check if all your user groups are global. Universal groups have the advantage of being able to accommodate universal groups as well as global groups, and others from other domains as well. You can also use domains local groups, this recommendation can also be found frequently on websites or in books. The main disadvantage of domain local groups is that they occupy 40 bytes in the login token. The account can be a member of five times as many permission groups before there are any problems with the size of the security token.
Multiple domains in a forest
When working with multiple domains in a forest, global groups are not appropriate as permission groups because they can not accommodate groups from other domains. Here, domain local and universal groups can be used. Universal groups from other domains occupy 40 bytes in the Kerberos token, local groups always occupy 40 bytes. A disadvantage of the universal groups could be that they replicate themselves in the global catalog of the forest and thus increase the load.
Integration of external trusting forests or domains
When working with external relying domains, only domain local groups can be used as permission groups. Universal groups can include members from all domains of the forest, but not from external trusting domains.
Group nesting group: Here you can see which user group types can be nested in which authorization group types. It is easy to see what impact the use of subdomains and foreign trusted forests has on the selection of the appropriate group type for the permission groups.
Location: In the OU (Canonical Name)
become the of migRaven stored authorization groups.
The name to be specified consists of your domain and the OU. For the domain, the top-level domain (TLD) must be specified, in our case ".local". The OU can also specify sub-OUs. As a default OU name there migRaven the OU MigR in front. You can change this name. If the OU does not exist, put migRaven to her. You can even change this OU in every project, ie you can save your compensation groups on a project or share basis.
Below the OU specified here migRaven an OU with the server name. In this server OU will be migRaven Save all newly created permission groups for the shares of this server.
If you do not want to create these additional file server OUs, you can do so in the migRavenApp.exe.config with the parameter "ServerOU" and the value "0" prevent this. The authorization groups are then restarted after migRaven stored directly in the specified OU.
Finally, the configuration must be saved.