AGDLP: Microsoft’s best practice for Active Directory and why we deliberately do without it<\/h1><\/h1><\/div>What is behind Microsoft’s group structure recommendation, what is the catch and how does the BAYOOSOFT Access Manager solve the problem in a smarter way?<\/p>\n
When IT administrators talk about authorization management in Active Directory, sooner or later the abbreviation AGDLP comes up. It is Microsoft’s official recommendation for structuring groups and access rights in Windows domains, well documented, widely used and, in theory, a decent concept. However, the BAYOOSOFT Access Manager deliberately does not follow this recommendation completely. Not an oversight, not a compromise, but a well-founded technical decision. This article explains what AGDLP is, why the principle reaches its limits in practice and how the BAYOOSOFT Access Manager solves the problem more intelligently. <\/p>\n<\/div><\/div><\/div><\/div><\/div>
What AGDLP means and why Microsoft recommends it<\/h2><\/h2><\/div>The acronym stands for Accounts (user and computer accounts), Global Groups (global groups), Domain Local Groups (domain-local groups) and Permissions (authorizations) and describes the order in which user accounts and groups should be nested in a Windows domain. The basic principle is role-based: A user account (A) becomes a member of a global group (G) that maps a business role, for example “Accounting” or “Project Management”. This global role group is then embedded in a domain-local group (DL), which in turn holds specific access rights to a resource, such as read or write access to a network folder. The domain-local group is therefore the only place in the ACL (Access Control List) where authorizations are actually assigned (P). <\/p>\n
The logic behind this is understandable. If an employee changes department, it is sufficient to remove her from the old global group and add her to the new one. All resource accesses follow automatically. Nobody has to touch individual folder ACLs. The model also prevents so-called orphaned SID entries in the ACLs, i.e. remnants of deleted user accounts that otherwise accumulate over the years. When implemented consistently, AGDLP has a positive effect on transparency and Active Directory security. <\/p>\n
Sounds good, and in theory it is. For environments with several domains or overall structures, the G-level is even technically necessary because global groups can be used across domain boundaries and the domain-local resource groups can therefore be filled from any domains. In short: AGDLP solves a multi-domain problem. <\/p>\n<\/div><\/div><\/div>
<\/div><\/div><\/div>The disadvantages of AGDLP: where the principle reaches its limits in practice<\/h2><\/h2><\/div>The downside of AGDLP is well documented, but still underestimated in many IT teams.<\/p>\n<\/div><\/div><\/div><\/div><\/div>
![\"AGDLP](\"https:\/\/www.bayoosoft.com\/wp-content\/uploads\/sites\/5\/2026\/04\/SOFT_AGDLP-Microsofts-Best-Practice-fuer-Active-Directory_-Absatz1.jpg\" "\\"SOFT_AGDLP-Microsofts-Best-Practice-f\u00fcr-Active-Directory_")
<\/span><\/div><\/div><\/div><\/div>1. the initial effort is considerable:<\/b>Each role and each resource requires at least two groups instead of one, the global role group and the domain-local authorization group. This at least doubles the number of groups in Active Directory. The required structures must be set up completely manually in the Active Directory console; there are no standard tools for this. This makes the model labor- and cost-intensive and potentially error-prone at every point where human intervention is required. Anyone who has ever structured an AD with a few hundred folders, printers and applications knows what this means in practice. <\/p>\n<\/div>2. shortcuts undermine the entire model:<\/strong>The model stands and falls with consistent discipline: as soon as someone assigns authorizations directly to a global group “just this once”, the structure begins to erode. Before you realize it, the entire AGDLP logic is undermined. The model stands and falls with consistent discipline in every single authorization assignment, over years, by changing teams. <\/p>\n<\/div><\/div><\/div><\/div><\/div>3. in single-domain operation, the G-level is technically superfluous:<\/span><\/b>Global groups only develop their added value where users from different domains need to be authorized to resources together. If you only operate one domain, AGDLP solves a problem that simply does not exist and still pays the full administrative price. <\/p>\n<\/div>4. subsequent migrations are extremely time-consuming:<\/b>
Converting existing, historically grown authorization structures to AGDLP means renaming groups, changing types, maintaining old and new groups in parallel, all manually, with a considerable risk of access interruptions.<\/p>\n<\/div>The token size problem: when users can no longer log in<\/h2><\/h2><\/div>There is another technical problem that hardly anyone has on their radar in everyday life until it becomes a serious incident: The Kerberos token size.<\/p>\n
Each time a user authenticates to the system, Windows issues a Kerberos ticket. This ticket contains not only the user identity, but also the SIDs of all security groups in which the user is a member, directly and indirectly. The formula for this comes directly from the Microsoft documentation: <\/p>\n
TokenSize = 1200 + 40d + 8s<\/strong><\/p>\nWhere d stands for memberships in domain-local groups and universal groups outside your own domain (each: 40 bytes), and s for memberships in global groups and other groups within the domain (each: 8 bytes).<\/span><\/p>\nWith the old standard limit of 12,000 bytes (up to Windows Server 2008 R2), membership in more than around 120 universal groups could already lead to authentication errors. On modern systems (from Server 2012), the standard is 48,000 bytes, but the principle remains: The more groups are accumulated through nested AGDLP structures, the closer you get to this limit. If these limits are exceeded, authentication fails and the user can no longer log on. Group policies may no longer be applied. In larger, historically grown environments with deep AGDLP nesting, this is not a theoretical scenario, but a real risk. The maximum value of 65,535 bytes can technically be set, but is expressly not recommended by Microsoft, partly because of known problems with IIS. <\/p>\n
With AGDLP, this problem is structurally reinforced: each global group that is embedded in many domain-local groups accumulates a corresponding number of domain-local group SIDs in the token for each user it contains. The deeper the nesting, the faster the token grows. <\/p>\n<\/div>
How the BAYOOSOFT Access Manager intelligently adapts group structures to the environment<\/h2><\/h2><\/div>The BAYOOSOFT Access Manager does not follow a single fixed group model, but selects the technically superior structure depending on the environment. The goal is always the same: minimum Kerberos token load with maximum security and compliance. <\/p>\n<\/div><\/div><\/div><\/div><\/div>
AGP in single-domain operation<\/b>In single-domain environments, the Access Manager works according to the AGP principle: Accounts are assigned directly to global groups (G), which then hold the authorizations (P). Domain-local groups are completely omitted. As global groups only contribute 8 bytes per membership to the Kerberos token according to the Microsoft formula instead of 40 bytes like domain-local groups, this is the most token-efficient variant of all. There is also a small security advantage: global groups can only include objects from their own domain, which automatically limits the scope to their own environment. <\/p>\n<\/div>ADLP in multi-domain operation<\/b><\/div>\nAs soon as users or groups from several domains need to access shared resources, domain-local groups come into play because only they allow cross-domain memberships. In this case, the Access Manager works according to ADLP: accounts are assigned directly to domain-local groups (DL), which hold the authorizations (P). The G level from AGDLP is omitted. Each domain-local membership costs 40 bytes in the Kerberos token, so the cost is higher than in single-domain mode. However, this is technically justified and is not further increased by an additional nesting level. <\/p>\n<\/div><\/div><\/div>
What is behind Microsoft’s group structure recommendation, what is the catch and how does the BAYOOSOFT Access Manager solve the problem in a smarter way?<\/p>\n
When IT administrators talk about authorization management in Active Directory, sooner or later the abbreviation AGDLP comes up. It is Microsoft’s official recommendation for structuring groups and access rights in Windows domains, well documented, widely used and, in theory, a decent concept. However, the BAYOOSOFT Access Manager deliberately does not follow this recommendation completely. Not an oversight, not a compromise, but a well-founded technical decision. This article explains what AGDLP is, why the principle reaches its limits in practice and how the BAYOOSOFT Access Manager solves the problem more intelligently. <\/p>\n<\/div><\/div><\/div><\/div><\/div>
What AGDLP means and why Microsoft recommends it<\/h2><\/h2><\/div>The acronym stands for Accounts (user and computer accounts), Global Groups (global groups), Domain Local Groups (domain-local groups) and Permissions (authorizations) and describes the order in which user accounts and groups should be nested in a Windows domain. The basic principle is role-based: A user account (A) becomes a member of a global group (G) that maps a business role, for example “Accounting” or “Project Management”. This global role group is then embedded in a domain-local group (DL), which in turn holds specific access rights to a resource, such as read or write access to a network folder. The domain-local group is therefore the only place in the ACL (Access Control List) where authorizations are actually assigned (P). <\/p>\n
The logic behind this is understandable. If an employee changes department, it is sufficient to remove her from the old global group and add her to the new one. All resource accesses follow automatically. Nobody has to touch individual folder ACLs. The model also prevents so-called orphaned SID entries in the ACLs, i.e. remnants of deleted user accounts that otherwise accumulate over the years. When implemented consistently, AGDLP has a positive effect on transparency and Active Directory security. <\/p>\n
Sounds good, and in theory it is. For environments with several domains or overall structures, the G-level is even technically necessary because global groups can be used across domain boundaries and the domain-local resource groups can therefore be filled from any domains. In short: AGDLP solves a multi-domain problem. <\/p>\n<\/div><\/div><\/div>
<\/div><\/div><\/div>The disadvantages of AGDLP: where the principle reaches its limits in practice<\/h2><\/h2><\/div>The downside of AGDLP is well documented, but still underestimated in many IT teams.<\/p>\n<\/div><\/div><\/div><\/div><\/div>
<\/span><\/div><\/div><\/div><\/div>1. the initial effort is considerable:<\/b>Each role and each resource requires at least two groups instead of one, the global role group and the domain-local authorization group. This at least doubles the number of groups in Active Directory. The required structures must be set up completely manually in the Active Directory console; there are no standard tools for this. This makes the model labor- and cost-intensive and potentially error-prone at every point where human intervention is required. Anyone who has ever structured an AD with a few hundred folders, printers and applications knows what this means in practice. <\/p>\n<\/div>2. shortcuts undermine the entire model:<\/strong>The model stands and falls with consistent discipline: as soon as someone assigns authorizations directly to a global group “just this once”, the structure begins to erode. Before you realize it, the entire AGDLP logic is undermined. The model stands and falls with consistent discipline in every single authorization assignment, over years, by changing teams. <\/p>\n<\/div><\/div><\/div><\/div><\/div>3. in single-domain operation, the G-level is technically superfluous:<\/span><\/b>Global groups only develop their added value where users from different domains need to be authorized to resources together. If you only operate one domain, AGDLP solves a problem that simply does not exist and still pays the full administrative price. <\/p>\n<\/div>4. subsequent migrations are extremely time-consuming:<\/b>
Converting existing, historically grown authorization structures to AGDLP means renaming groups, changing types, maintaining old and new groups in parallel, all manually, with a considerable risk of access interruptions.<\/p>\n<\/div>The token size problem: when users can no longer log in<\/h2><\/h2><\/div>There is another technical problem that hardly anyone has on their radar in everyday life until it becomes a serious incident: The Kerberos token size.<\/p>\n
Each time a user authenticates to the system, Windows issues a Kerberos ticket. This ticket contains not only the user identity, but also the SIDs of all security groups in which the user is a member, directly and indirectly. The formula for this comes directly from the Microsoft documentation: <\/p>\n
TokenSize = 1200 + 40d + 8s<\/strong><\/p>\nWhere d stands for memberships in domain-local groups and universal groups outside your own domain (each: 40 bytes), and s for memberships in global groups and other groups within the domain (each: 8 bytes).<\/span><\/p>\nWith the old standard limit of 12,000 bytes (up to Windows Server 2008 R2), membership in more than around 120 universal groups could already lead to authentication errors. On modern systems (from Server 2012), the standard is 48,000 bytes, but the principle remains: The more groups are accumulated through nested AGDLP structures, the closer you get to this limit. If these limits are exceeded, authentication fails and the user can no longer log on. Group policies may no longer be applied. In larger, historically grown environments with deep AGDLP nesting, this is not a theoretical scenario, but a real risk. The maximum value of 65,535 bytes can technically be set, but is expressly not recommended by Microsoft, partly because of known problems with IIS. <\/p>\n
With AGDLP, this problem is structurally reinforced: each global group that is embedded in many domain-local groups accumulates a corresponding number of domain-local group SIDs in the token for each user it contains. The deeper the nesting, the faster the token grows. <\/p>\n<\/div>
How the BAYOOSOFT Access Manager intelligently adapts group structures to the environment<\/h2><\/h2><\/div>The BAYOOSOFT Access Manager does not follow a single fixed group model, but selects the technically superior structure depending on the environment. The goal is always the same: minimum Kerberos token load with maximum security and compliance. <\/p>\n<\/div><\/div><\/div><\/div><\/div>
AGP in single-domain operation<\/b>In single-domain environments, the Access Manager works according to the AGP principle: Accounts are assigned directly to global groups (G), which then hold the authorizations (P). Domain-local groups are completely omitted. As global groups only contribute 8 bytes per membership to the Kerberos token according to the Microsoft formula instead of 40 bytes like domain-local groups, this is the most token-efficient variant of all. There is also a small security advantage: global groups can only include objects from their own domain, which automatically limits the scope to their own environment. <\/p>\n<\/div>ADLP in multi-domain operation<\/b><\/div>\nAs soon as users or groups from several domains need to access shared resources, domain-local groups come into play because only they allow cross-domain memberships. In this case, the Access Manager works according to ADLP: accounts are assigned directly to domain-local groups (DL), which hold the authorizations (P). The G level from AGDLP is omitted. Each domain-local membership costs 40 bytes in the Kerberos token, so the cost is higher than in single-domain mode. However, this is technically justified and is not further increased by an additional nesting level. <\/p>\n<\/div><\/div><\/div>
The acronym stands for Accounts (user and computer accounts), Global Groups (global groups), Domain Local Groups (domain-local groups) and Permissions (authorizations) and describes the order in which user accounts and groups should be nested in a Windows domain. The basic principle is role-based: A user account (A) becomes a member of a global group (G) that maps a business role, for example “Accounting” or “Project Management”. This global role group is then embedded in a domain-local group (DL), which in turn holds specific access rights to a resource, such as read or write access to a network folder. The domain-local group is therefore the only place in the ACL (Access Control List) where authorizations are actually assigned (P). <\/p>\n
The logic behind this is understandable. If an employee changes department, it is sufficient to remove her from the old global group and add her to the new one. All resource accesses follow automatically. Nobody has to touch individual folder ACLs. The model also prevents so-called orphaned SID entries in the ACLs, i.e. remnants of deleted user accounts that otherwise accumulate over the years. When implemented consistently, AGDLP has a positive effect on transparency and Active Directory security. <\/p>\n
Sounds good, and in theory it is. For environments with several domains or overall structures, the G-level is even technically necessary because global groups can be used across domain boundaries and the domain-local resource groups can therefore be filled from any domains. In short: AGDLP solves a multi-domain problem. <\/p>\n<\/div><\/div><\/div>
The disadvantages of AGDLP: where the principle reaches its limits in practice<\/h2><\/h2><\/div>The downside of AGDLP is well documented, but still underestimated in many IT teams.<\/p>\n<\/div><\/div><\/div><\/div><\/div>
<\/span><\/div><\/div><\/div><\/div>1. the initial effort is considerable:<\/b>Each role and each resource requires at least two groups instead of one, the global role group and the domain-local authorization group. This at least doubles the number of groups in Active Directory. The required structures must be set up completely manually in the Active Directory console; there are no standard tools for this. This makes the model labor- and cost-intensive and potentially error-prone at every point where human intervention is required. Anyone who has ever structured an AD with a few hundred folders, printers and applications knows what this means in practice. <\/p>\n<\/div>2. shortcuts undermine the entire model:<\/strong>The model stands and falls with consistent discipline: as soon as someone assigns authorizations directly to a global group “just this once”, the structure begins to erode. Before you realize it, the entire AGDLP logic is undermined. The model stands and falls with consistent discipline in every single authorization assignment, over years, by changing teams. <\/p>\n<\/div><\/div><\/div><\/div><\/div>3. in single-domain operation, the G-level is technically superfluous:<\/span><\/b>Global groups only develop their added value where users from different domains need to be authorized to resources together. If you only operate one domain, AGDLP solves a problem that simply does not exist and still pays the full administrative price. <\/p>\n<\/div>4. subsequent migrations are extremely time-consuming:<\/b>
Converting existing, historically grown authorization structures to AGDLP means renaming groups, changing types, maintaining old and new groups in parallel, all manually, with a considerable risk of access interruptions.<\/p>\n<\/div>The token size problem: when users can no longer log in<\/h2><\/h2><\/div>There is another technical problem that hardly anyone has on their radar in everyday life until it becomes a serious incident: The Kerberos token size.<\/p>\n
Each time a user authenticates to the system, Windows issues a Kerberos ticket. This ticket contains not only the user identity, but also the SIDs of all security groups in which the user is a member, directly and indirectly. The formula for this comes directly from the Microsoft documentation: <\/p>\n
TokenSize = 1200 + 40d + 8s<\/strong><\/p>\nWhere d stands for memberships in domain-local groups and universal groups outside your own domain (each: 40 bytes), and s for memberships in global groups and other groups within the domain (each: 8 bytes).<\/span><\/p>\nWith the old standard limit of 12,000 bytes (up to Windows Server 2008 R2), membership in more than around 120 universal groups could already lead to authentication errors. On modern systems (from Server 2012), the standard is 48,000 bytes, but the principle remains: The more groups are accumulated through nested AGDLP structures, the closer you get to this limit. If these limits are exceeded, authentication fails and the user can no longer log on. Group policies may no longer be applied. In larger, historically grown environments with deep AGDLP nesting, this is not a theoretical scenario, but a real risk. The maximum value of 65,535 bytes can technically be set, but is expressly not recommended by Microsoft, partly because of known problems with IIS. <\/p>\n
With AGDLP, this problem is structurally reinforced: each global group that is embedded in many domain-local groups accumulates a corresponding number of domain-local group SIDs in the token for each user it contains. The deeper the nesting, the faster the token grows. <\/p>\n<\/div>
How the BAYOOSOFT Access Manager intelligently adapts group structures to the environment<\/h2><\/h2><\/div>The BAYOOSOFT Access Manager does not follow a single fixed group model, but selects the technically superior structure depending on the environment. The goal is always the same: minimum Kerberos token load with maximum security and compliance. <\/p>\n<\/div><\/div><\/div><\/div><\/div>
AGP in single-domain operation<\/b>In single-domain environments, the Access Manager works according to the AGP principle: Accounts are assigned directly to global groups (G), which then hold the authorizations (P). Domain-local groups are completely omitted. As global groups only contribute 8 bytes per membership to the Kerberos token according to the Microsoft formula instead of 40 bytes like domain-local groups, this is the most token-efficient variant of all. There is also a small security advantage: global groups can only include objects from their own domain, which automatically limits the scope to their own environment. <\/p>\n<\/div>ADLP in multi-domain operation<\/b><\/div>\nAs soon as users or groups from several domains need to access shared resources, domain-local groups come into play because only they allow cross-domain memberships. In this case, the Access Manager works according to ADLP: accounts are assigned directly to domain-local groups (DL), which hold the authorizations (P). The G level from AGDLP is omitted. Each domain-local membership costs 40 bytes in the Kerberos token, so the cost is higher than in single-domain mode. However, this is technically justified and is not further increased by an additional nesting level. <\/p>\n<\/div><\/div><\/div>
The downside of AGDLP is well documented, but still underestimated in many IT teams.<\/p>\n<\/div><\/div><\/div><\/div><\/div>
<\/span><\/div><\/div><\/div>1. the initial effort is considerable:<\/b>Each role and each resource requires at least two groups instead of one, the global role group and the domain-local authorization group. This at least doubles the number of groups in Active Directory. The required structures must be set up completely manually in the Active Directory console; there are no standard tools for this. This makes the model labor- and cost-intensive and potentially error-prone at every point where human intervention is required. Anyone who has ever structured an AD with a few hundred folders, printers and applications knows what this means in practice. <\/p>\n<\/div> 2. shortcuts undermine the entire model:<\/strong>The model stands and falls with consistent discipline: as soon as someone assigns authorizations directly to a global group “just this once”, the structure begins to erode. Before you realize it, the entire AGDLP logic is undermined. The model stands and falls with consistent discipline in every single authorization assignment, over years, by changing teams. <\/p>\n<\/div><\/div><\/div><\/div><\/div> 3. in single-domain operation, the G-level is technically superfluous:<\/span><\/b>Global groups only develop their added value where users from different domains need to be authorized to resources together. If you only operate one domain, AGDLP solves a problem that simply does not exist and still pays the full administrative price. <\/p>\n<\/div> 4. subsequent migrations are extremely time-consuming:<\/b> There is another technical problem that hardly anyone has on their radar in everyday life until it becomes a serious incident: The Kerberos token size.<\/p>\n Each time a user authenticates to the system, Windows issues a Kerberos ticket. This ticket contains not only the user identity, but also the SIDs of all security groups in which the user is a member, directly and indirectly. The formula for this comes directly from the Microsoft documentation: <\/p>\n TokenSize = 1200 + 40d + 8s<\/strong><\/p>\n Where d stands for memberships in domain-local groups and universal groups outside your own domain (each: 40 bytes), and s for memberships in global groups and other groups within the domain (each: 8 bytes).<\/span><\/p>\n With the old standard limit of 12,000 bytes (up to Windows Server 2008 R2), membership in more than around 120 universal groups could already lead to authentication errors. On modern systems (from Server 2012), the standard is 48,000 bytes, but the principle remains: The more groups are accumulated through nested AGDLP structures, the closer you get to this limit. If these limits are exceeded, authentication fails and the user can no longer log on. Group policies may no longer be applied. In larger, historically grown environments with deep AGDLP nesting, this is not a theoretical scenario, but a real risk. The maximum value of 65,535 bytes can technically be set, but is expressly not recommended by Microsoft, partly because of known problems with IIS. <\/p>\n With AGDLP, this problem is structurally reinforced: each global group that is embedded in many domain-local groups accumulates a corresponding number of domain-local group SIDs in the token for each user it contains. The deeper the nesting, the faster the token grows. <\/p>\n<\/div> The BAYOOSOFT Access Manager does not follow a single fixed group model, but selects the technically superior structure depending on the environment. The goal is always the same: minimum Kerberos token load with maximum security and compliance. <\/p>\n<\/div><\/div><\/div><\/div><\/div> AGP in single-domain operation<\/b>In single-domain environments, the Access Manager works according to the AGP principle: Accounts are assigned directly to global groups (G), which then hold the authorizations (P). Domain-local groups are completely omitted. As global groups only contribute 8 bytes per membership to the Kerberos token according to the Microsoft formula instead of 40 bytes like domain-local groups, this is the most token-efficient variant of all. There is also a small security advantage: global groups can only include objects from their own domain, which automatically limits the scope to their own environment. <\/p>\n<\/div> As soon as users or groups from several domains need to access shared resources, domain-local groups come into play because only they allow cross-domain memberships. In this case, the Access Manager works according to ADLP: accounts are assigned directly to domain-local groups (DL), which hold the authorizations (P). The G level from AGDLP is omitted. Each domain-local membership costs 40 bytes in the Kerberos token, so the cost is higher than in single-domain mode. However, this is technically justified and is not further increased by an additional nesting level. <\/p>\n<\/div><\/div><\/div>
Converting existing, historically grown authorization structures to AGDLP means renaming groups, changing types, maintaining old and new groups in parallel, all manually, with a considerable risk of access interruptions.<\/p>\n<\/div>The token size problem: when users can no longer log in<\/h2><\/h2><\/div>
How the BAYOOSOFT Access Manager intelligently adapts group structures to the environment<\/h2><\/h2><\/div>
![\"AGDLP:](\"https:\/\/www.bayoosoft.com\/wp-content\/uploads\/sites\/5\/2026\/04\/SOFT_AGDLP-Microsofts-Best-Practice-fuer-Active-Directory_-Absatz2.jpg\" "\\"SOFT_AGDLP-Microsofts-Best-Practice-f\u00fcr-Active-Directory_")
<\/span><\/div><\/div><\/div><\/div><\/div>![](\"https:\/\/www.bayoosoft.com\/wp-content\/uploads\/sites\/5\/2024\/02\/AccessManager.png\" "\\"BAYOOSOFT")
<\/span><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>