As an IT administrator, one of the most common tasks you are involved in is administering security groups in Active Directory. As with all things, keeping your security groups simple is always best but sometimes (especially in larger environments) it is important to use groups of differing scopes or ‘visibility’ to allow or disallow certain groups or objects to become members, etc.
A security group’s scope determines to what extent a group can be applied in the domain or forest. Sometimes remembering all the details of each scope can be difficult so here’s a great table which summarizes each scope in terms of which security objects can be listed as members, where the group can be assigned permissions and what other scopes the group can be converted to.
||Group can include as members…
||Group can be assigned permissions in…
||Group scope can be converted to…
- Accounts from any domain within the forest in which this Universal Group resides
- Global groups from any domain within the forest in which this Universal Group resides
- Universal groups from any domain within the forest in which this Universal Group resides
|Any domain or forest
- Domain local
- Global (as long as no other universal groups exist as members)
- Accounts from the same domain as the parent global group
- Global groups from the same domain as the parent global group
|Member permissions can be assigned in any domain
||Universal (as long as it is not a member of any other global groups)
- Accounts from any domain
- Global groups from any domain
- Universal groups from any domain
- Domain local groups but only from the same domain as the parent domain local group
|Member permissions can be assigned only within the same domain as the parent domain local group
||Universal (as long as no other domain local groups exist as members)
Over the last 6 months I have been taking on a greater role with our networks at work and as such have fairly good exposure to administering CheckPoint based security devices, more specifically CheckPoint Firewall-1 NGX R65 and CheckPoint SmartCenter on SecurePlatform.
We have recently installed new Polycom HDX video conferencing units and needed to allow the internal IP’s of those video conferences to NAT through our firewall out to public IPs for external calls. The way this is achieved is through Network Address Translation (NAT) through host objects in your checkpoint database which are then applied to a Firewall-1 appliance.
How do you do this? Easy. There are two translation methods supported from a host point of view, static or hide.
Once I had determined which public IP addresses I wanted to use for each video conference, I was able to sort out the NAT for each video conference unit by:
- Create a host object for the VC (eg. BoardroomVC) and add the correct internal IP
- (optional) – add each new host to a group called ‘video conference units’, useful to group all VC’s for use in firewall rulebase
- Right-Click a host and click properties
- Click ‘NAT’ on the left hand side
- Check the box ‘Add Automatic Address Translation rules’
- Select Translation Method = Static
- Enter the public IP address you wish to NAT the internal IP of the host to an external IP
- (optional) – select which gateway this NAT will work with, otherwise leave ‘All’ selected to install to all gateways managed by the SmartCenter.
That’s all there is to it. The NAT will take effect once you install the policies to your firewall gateway. Once you know how NAT works in CheckPoint it is pretty straight forward. This example was pretty basic by using static NAT’ing however NAT can get a bit more complicated but as they say in IT the simpler approach is usually the best!