rodc

RODC password replication

Read Only Domain controllers in windows server 2008 are designed primarily for use in branch offices (satellite locations with no onsite IT staff and slower links back to HQ).

I have blogged previously about installing an RODC which is a nice straightforward dcpromo with an added tickbox at the end, and the purpose obviously of an RODC is to provide local authentication and if required a local DNS and global catalogue. One thing that is not stored within an RODC is passwords for user accounts which obviously results in WAN traffic when an authentication attempt is made.

However there are two ways in which local users passwords can be stored within the RODC’s db.

One way is to add the users at the branch office to the “allowed RODC password replication group” in a writable domain controller.

The other is to assign objects to the “password replication policy” tab in the RODC’s computer account in AD.
When I say object this can be a group or individual user accounts (although creating and assigning a group for this purpose if clearly easier).

It is quicker and easier to add the user accounts to the allowed RODC password replication policy group in AD however this presents a possible minor issue. By putting users into this group it will replicate the password data to all RODC’s in the domain. This is not a problem if you only have one branch office, but what about if you have more than one say you have 20 or more all over the world, and branch offices can have a decent number of staff in them. This could quickly balloon the Wan traffic in each branch office as they receive all the completely unnecessary password data for the other 19 branch offices in the organisation.

Of course even with a modest residential ADSL line it probably wont bring the connection crashing down around your ears but every meg counts.

So if you have more than one branch office or it seems expansion of the business is on the cards then taking a few extra minutes to set up new groups and assign them specifically to the RODC computer accounts.

Within the RODC’s computer account “PRP” tab you can also add other groups and accounts to the policy and also specify whether the group/user is allowed or denied the password replication policy, as always if a user is a member of several groups then a deny permission always over rides an allow.

Also dont forget that computer accounts also logon to the domain so adding computers to the policy is also a good idea as a prolonged wan outage may well cause issues for the computers if their passwords are not cached as well.

Deploying ESX4 VSphere guide

Those lovely people over at Xtravirt have had this guide kicking around for a while now and its a brilliant read to get you up to speed with deploying VSphere whether you are a old hand at previous versions or a total newbie!

Check it out, its always worth saving this doc in your tech docs as you never know when it may come in handy!

LINKY

SRP

Windows 7 Applocker and Software Restriction Policies PT1

Thought I’d knock out a quick blog post on my studies of Windows 7′s implimentation of Applocker and SRP’s. Now traditionally SRP’s have been good in theory but if you attempt to use them they will lead to a world of hurt. The same is still true so unless you REALLY REALLY need to lock down your systems that much then leave well alone. Still its covered in the exam objectives so I gotta study it in some form.

Software restriction policies are a way of limiting the applications that can be executed on windows 7. These policies are set in group policy so they can be set on the local workstation or as part of an AD GPO distribution. Applocker does the same thing but in a slightly different way (and it also overides a clashing SRP).

To begin to configure a SRP you will need to get into either the local workstations gpedit.msc tool or AD’s GPO editor and drill down into COMPUTER CONFIGURATION/WINDOWS SETTINGS/SECURITY SETTINGS/SOFTWARE RESTRICTION POLICY. The container starts life empty so you will need to right click on the node and choose “Create software restriction policy”.

You will then be greated with these new options

From within the Security Levels you have 3 available options which are Disallowed, Basic User and Unrestricted. These 3 settings will specify the default options for applications that have no specific rule defined. Disallowed obviously means that software with no specific policy defined will not be allowed to run. Basic User allows software to run that does not have a specific policy defined providing that it requires no administrative access to the file system etc. Unrestricted simply means that any software will be allowed to run that does not have a specific SRP defined. To enable any of these settings you need to open the setting type you want and click the set as default button.

I shall miss out on the Additional Rules section for the moment as this is where you set specific rules for applications. The next option down is Enforcement, this defines how strict the default policies are, configurable options include applying the policies to all software files excluding or including DLL files etc. You can also specify if the SRP’s apply to users or all users including administrators (dangerous) and ignoring or enforcing certificate rules.

The Designated File Types option specifys what is considered to be executable file types (in addition to exe and vbs), from this menu you can remove any of the default types or add your own.

The Trusted Publishers option allows you to specify who is allowed to manage the list of trusted pulishers and you can set either to allow both users and administrators to manage the list, or just administrators or just enterprise administrators. There are also 2 other settings you can change which relate to checking whether the publishers certificate is still valid or not.

Looking at this post I think I will split this into two or three posts, I will go into actually creating a SRP in the next blog but for now heres a video of a basic one in action.