Depending on how you use Active Directory in your organization, you may be setting a lot of security policies on workstations, and some of these settings can be problematic during the automated build of computers.
A few workarounds exist to avoid applying those to the workstations being imaged:
* Create a temporary OU for the computer account, and move it to the proper location once the build is done
* Change the order of the steps in your build to avoid issues caused by security settings
* Configure a GPO to override the settings that need to be set only during deployment, and filter that only to machines being used.
For multiple different reasons, I had to use the last option. It is a rather clean option, as it doesn’t involve moving computer accounts after the build or any chances on the domain during the imaging process, other than joining the machine, which is great.
One word of notice: Make sure whatever you are overriding is not a must for security and is simply an “annoyance”, because eventually (within a few minutes probably), a user WILL figure out how you’re doing the filtering and WILL apply it to his own machine, in order to bypass some security settings.
Only a few steps are involved :
1) Create a GPO that will set the values to what they need to be during the build (don’t link it yet)
2) Create a WMI filter called “BoxBeingBuilt” or something similar. Have it do a query on something you know is true only during imaging. If you can’t find anything reliable, do something like this:
Select * from Win32_Environment Where Name = “BuildinDaBox”
3) Ensure your built process sets a system variable with that name at the beginning, and removes it at the end.
Tada!
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.
