My blog about Active Directory and everything else

You will often hear the acronyms UGLY and AGDLP when people are talking about how to apply permissions to resources (usually in the context of files/folders) in an Active Directory environment.

There are three types of security groups in Active Directory they are

• Universal
• Global
• Domain Local

More information on the scope of these groups can be found here:

http://technet.microsoft.com/en-us/library/cc755692.aspx

As you can see you can nest global groups into domain local groups and that is where these acronyms come into play

AGDLP = Accounts into globals, Globals into Domain Locals, assign Permissions

UGLY = Users into global groups, Global into domain Local groups, You assign permissions

NOTE: You will also hear AGLP refered to as AGDLP

So the question comes up should this method always be used when assigning permissions?

If you are in a single domain forest or if you are using an empty root design then you don’t need to worry about either of these acronyms. You can just use globals or domain locals and add members and apply permissions. Don’t worry about nesting groups.

In a multi-domain forest the thought process behind AGLP and UGLY is that you only ever add members to the global groups. From the link above you can see that

because groups with global scope are not replicated outside their own domain, you can change accounts in a group having global scope frequently without generating replication traffic to the global catalog.

The one issue that can come up is that you may lose some control of who has access to the resources unless you have a good auditing process setup.

Suppose you have a North America, Asia, Europe, & South America domain. Now in the North America domain you have an Accounting folder and you use AGLP/UGLY to apply permissions. If you are only an admin in North America then the admins from all the other domains could be adding members to their global groups that may not really need access.

So as you can see there are pros and cons to the various methods. The final answer here is that there is no set in stone hard and fast answer. You have to look at your organization/structure/environment and decide what is best for you