GC Universal Group Membership

jbaello

I need clarification on this, when I create a user, do I need to put him on a Universal Security Group? to make it a member of the GC Universal Group Membership? one of the windows admin at my last job mentioned this, I am little vague that this is not needed, and when a user is created it automatically becomes a member of the GC UGM, regardless of being added to a Universal Security Group.

dynamik

No. It's actually poor practice to put users in universal groups.

Remember AGULP (accounts - global - universal - [domain] local - permissions)

Universal group membership is obviously limited to members of universal groups. I guess you could automatically put users in universal groups if you wanted to for some reason. You could simply duplicate a user template that is a member of a universal group, and there's probably some scripting/command line techniques to do something similar as well.

jbaello

This sucks, so that means for me to leverage GC Universal Group Membership and UGMC (caching) every users accross the domain needs to be a member of a Universal Security Group? I don't see the reason why I need an extra configuration to make them available in UGM.

royal

Just to expand on what dynamik stated, the reason putting users into Universal Groups is bad is because Global Catalogs are the ones who store membership Universal Groups and the regular Domain Controllers are the ones that store the membership for Domain Local and Global Groups.

Now can you guess why it's bad? Well, you can nest global groups in Universal Groups. Now if you added 500 users into a Universal Group, a Global Catalog would be replicating 500 objects. Now if you stored all 500 members in a Global Group and nested that into a Universal Group, your Global Catalogs are only replicating 1 object now, the Universal Group.

Make sense?

royal

The only reason you'd use UGMC is if you have really slow private WAN links or VPN links and you don't want GC traffic replicating to your slow site. Instead, you enable UGMC and when a user logs on, it'll check a GC in another site and cache that information.

When you are in 2000 mixed, when a user logs on, that DC is not required to check a GC "IF" a user is a member of a Universal Groups because Universal Security Groups cannot be made (but distribution groups can). When you bump it up to native, Universal Security groups can be made, and because of this, a DC will now check if the user belongs to a Universal Security group to check for permissions when building the user's token.

So if you have your slow site, and no GC is there, you can use UGMC which will cause DCs in that site to cache the user's Universal Group membership information for building the token when in 2000 native. But this all still happens even if the user isn't in a Universal Group. It just still has to check to make sure due to security (permissions) reasons.

Annoying thing about UGMC is that if you make a modification to security permissions, the DC won't update its cache for 8 hours. So if you make a deny, it won't reflect that deny in the new site for another 8 hours or less depending on when the last refresh occurred. Could be a really bad thing from a security standpoint.

On a side note, who even uses UGMC anyways?

jbaello

royal wrote:

dynamik wrote:

Universal group membership is obviously limited to members of universal groups..

The only reason you'd use UGMC is if you have really slow private WAN links or VPN links and you don't want GC traffic replicating to your slow site. Instead, you enable UGMC and when a user logs on, it'll check a GC in another site and cache that information.

When you are in 2000 mixed, when a user logs on, that DC is not required to check a GC "IF" a user is a member of a Universal Groups because Universal Security Groups cannot be made (but distribution groups can). When you bump it up to native, Universal Security groups can be made, and because of this, a DC will now check if the user belongs to a Universal Security group to check for permissions when building the user's token.

So if you have your slow site, and no GC is there, you can use UGMC which will cause DCs in that site to cache the user's Universal Group membership information for building the token when in 2000 native. But this all still happens even if the user isn't in a Universal Group. It just still has to check to make sure due to security (permissions) reasons.

Annoying thing about UGMC is that if you make a modification to security permissions, the DC won't update its cache for 8 hours. So if you make a deny, it won't reflect that deny in the new site for another 8 hours or less depending on when the last refresh occurred. Could be a really bad thing from a security standpoint.

On a side note, who even uses UGMC anyways?
quote]

This is what I was looking for "But this all still happens even if the user isn't in a Universal Group." I understand the AGULP process, this is for us to save bandwidth. I just got confused when someone mentioned that membership to Global Catalog UGM requires that a user must be a member of "Universal Security Group" but even no GC is present UGMC refresh it's cache on a DC.

Thanks Royal you r leetness...

jbaello

I guess I was correct with my 1st understanding, until a windows admin cofused it all...

astorrs

Well the only thing I can ask is the domain Windows 2003 mode with only a single domain (a root/plcaeholder domain is okay too) and are all DCs GCs? If so (and only if) then you can do what you like with universal groups without a significant impact (you can throw AGULP out the window if you want).

Pash

Yeh UGMC isnt used much currently, I can only think of one client I have done work for that have to use it and that was mainly because the only line there was also being used for peersync between sites, although this was a BCP site as well, so kinda a perfect scenario if you like.

Considerations of when to use a GC at another site rather than go with UGMC:-

1. When you don't have any bandwidth concerns.

2. When membership of your universal groups might change frequently.

3. exchange servers hosted at remote sites.

4. when your main office and remote office are both part of the same AD site.

TBH if you match any of those, just tick that GC box

royal

Pash wrote:

Considerations of when to use a GC at another site rather than go with UGMC:-

1. When you don't have any bandwidth concerns.

2. When membership of your universal groups might change frequently.

3. exchange servers hosted at remote sites.

4. when your main office and remote office are both part of the same AD site.

TBH if you match any of those, just tick that GC box

http://technet2.microsoft.com/windowsserver/en/library/0e4d2466-68e8-40d8-8c72-099f8bc259ff1033.mspx?mfr=true

Pash

royal wrote:

Pash wrote:

Considerations of when to use a GC at another site rather than go with UGMC:-

1. When you don't have any bandwidth concerns.

2. When membership of your universal groups might change frequently.

3. exchange servers hosted at remote sites.

4. when your main office and remote office are both part of the same AD site.

TBH if you match any of those, just tick that GC box

http://technet2.microsoft.com/windowsserver/en/library/0e4d2466-68e8-40d8-8c72-099f8bc259ff1033.mspx?mfr=true

Nice link again royal, hats off.

jbaello

jbaello wrote:

royal wrote:

dynamik wrote:

Universal group membership is obviously limited to members of universal groups..

The only reason you'd use UGMC is if you have really slow private WAN links or VPN links and you don't want GC traffic replicating to your slow site. Instead, you enable UGMC and when a user logs on, it'll check a GC in another site and cache that information.

When you are in 2000 mixed, when a user logs on, that DC is not required to check a GC "IF" a user is a member of a Universal Groups because Universal Security Groups cannot be made (but distribution groups can). When you bump it up to native, Universal Security groups can be made, and because of this, a DC will now check if the user belongs to a Universal Security group to check for permissions when building the user's token.

So if you have your slow site, and no GC is there, you can use UGMC which will cause DCs in that site to cache the user's Universal Group membership information for building the token when in 2000 native. But this all still happens even if the user isn't in a Universal Group. It just still has to check to make sure due to security (permissions) reasons.

Annoying thing about UGMC is that if you make a modification to security permissions, the DC won't update its cache for 8 hours. So if you make a deny, it won't reflect that deny in the new site for another 8 hours or less depending on when the last refresh occurred. Could be a really bad thing from a security standpoint.

On a side note, who even uses UGMC anyways?

This is what I was looking for "But this all still happens even if the user isn't in a Universal Group." I understand the AGULP process, this is for us to save bandwidth. I just got confused when someone mentioned that membership to Global Catalog UGM requires that a user must be a member of "Universal Security Group" but even no GC is present UGMC refresh it's cache on a DC.

Thanks Royal you r leetness...