binaryfactory.ca

Having issues similar to:

Trying to enable EFS on a specific OU, while it’s disable at the top of the structure or domain?
Recovery certificates from two different GPOs mixing up instead of being replaced?

Overall EFS GPOs looking like they aren’t merging properly?

Well, it’s not because EFS GPOs are supposed to behave like black magic. Turns out there’s a bug, Microsoft’s aware of it, but doesn’t think it would be a good idea to FIX IT on Windows XP and 2003.

Thankfully, all it means is you need to edit your GPOs from a Vista, 2008 or Windows 7 machine.

KB : EFS may not be enabled expectedly after you disable a policy and this policy turn off the EFS feature

Opening my EFS GPOs in Windows 7, switching the Allow/Don’t allow and applying the ‘change’ fixed my GPOs. A few minutes later, and stuff was behaving like it should’ve been… Can I have those wasted hours of my life back, Mr. Ballmer?

Sometimes, it might be impossible to clean up all old domain accounts at the same time. Maybe you’re using Windows 2000 mixed mode and don’t have the LastLogonTimestamp field handy, maybe your users use some applications that don’t update it properly…there can be many reasons.

However, if it is a huge environment where there are a lot of administrators, and you know that the deprovisioning process is not always followed, you should at least disable the old accounts that are members of Domain Admin.

I use oldcmp by Joeware, maker of the greatest AD tools on Earth.

Oldcmp was originally designed to disable old computer accounts, but it’s also made to work with user accounts. It can use pwdLastSet and LastLogonTimestamp as attributes.

Check out the oldcmp usage first.

Then, it is a matter of running oldcmp with the proper switches, and filters. Always run it in reporting mode first.

oldcmp -users -report -af “memberof=CN=Domain Admins,CN=Users,DC=domain,DC=com” -llts -age 120 -format csv

oldcmp -users -report -af “memberof=CN=Administrators,CN=Builtin,DC=domain,DC=com” -llts -age 120 -format csv

This will output a CSV file with a list of Domain Admins that have not logged in for 120days+ according to the LastLogonTimestamp attribute. Of course, this attribute is not precise as it is replicated roughly every 2 weeks. However, this will give you a pretty good list of “old” admins.

Then, if you only want to remove them from the Domain Admins group, either do it manually or use admod to do it. If your domain is not totally insane, there should be few accounts to remove.

If you want to completely disable the accounts, you can use the same oldcmp string as above, with the safety and reporting removed. I’ll let you read the usage so you don’t blame me if you disable all your domain admins! If you are using pwdLastSet, watch out not to disable accounts that are set so that the password doesn’t expire..

You should do that on Enterprise Admins and other high privilege groups as well obviously, and also, on the whole domain.

Today I read a post on Windows Networking by Brien M. Posey about “The Confusion of AD Design”.

He argues that some people use way too many OUs and that “less is more”.

As I said before, there are situations that do warrant using multiple OUs. This is particularly true in situations in which there are multiple administrators, and each administrator needs to be delegated control over a different portion of the network.

Well, I’m not aware of many domains that do not have “multiple administrators that need to be delegated control over a different portion of the network”. Those that don’t have that usually don’t have any OUs created other than the default ones, with every user under Users, and every computer under Computers. Of course there might be some exception, for example a domain used only to host your Exchange servers, however, most companies that pay high priced consultants to come in and set up their Active Directories have structures a little more complex than a 25 employee small business.

Having a lot of OUs can be very useful in almost any big domain structure. Let’s say you have 50 different types of servers. Each of these server sets has their own Hardening rules. You apply a “master” hardening GPO at the top of your OU structure, that locks everything down, and then you unlock things for each application, at the OU level. This way, your OUs apply in the proper order by default, and delegation is pretty easy as each application has their own container.

At least, at the end of the article, he acknowledges this:

Right about now, you might be wondering what I really have against creating multiple OUs. There are a couple of reasons why I do not like using multiple OUs unless I have to. Maybe it’s just laziness on my part, but the first reason why I like to try to stick to using a single OU in an Active Directory design is because having multiple OUs tends to complicate LDAP queries.

Well, just do a subtree search then! Laziness, on my end, makes me want to have a structured design where Group Filtering is the exception rather than the rule.

When working a lot with Group Policy, one thing that I would love being able to do is merging user right assignments. If you’re aware of how to do it, be sure to post a comment (Workaround, 3rd party tool, etc).

Let’s say you have 500 servers. All servers run some agent service that must always be set to automatic, and for which you have customized ACLs. (You grant helpdesk the right to restart the service for example).

Well, this is pretty easy to handle as every service can be handled in different GPOs, so you just create a GPO with your settings, and you link it appropriately.

Now, what if you want to grant the service account that this service uses on every computer the right to “Log On as a Service” ? You could put that in the same GPO, but it would override any other policy that has “Log On as a service” defined and is applied before this one. Wouldn’t it be nice to be able to specify in a GPO that the service account must have “Log on as a service” while keeping the currently specified rights?

A great new feature in 2008 is the ability to replicate SYSVOL using DFS Replication. DFS replication is much more powerful and (IMO) easier to troubleshoot than FRS. It was a great improvement in 2003 r2, and it is great that we can now use it on SYSVOL!

Ned Pyle at Technet has a great article about verifying on his blog