This is a simple one that goes back to a conversation I had with a consultant. We were talking about adding a computer to a domain and then moving the computer to the designated OU that was dedicated to that site. I made the comment that it might be even better to precreate the computer account in the appropriate OU and then you don't need to bug a domain administrator to do the moving around. His reply was something like "Yea I haven't had good luck with that." That's one of my favorite reasons for technical problems. It's kind of like saying, I tried it once, it didn't work, so it must be broken.

Why Do This?

Anyways, the real reason that you would want to do this is if you have a team of IT staff where a few have domain administrators rights but most of them are just local admins on the workstations to provide support and install software. Adding a computer to the domain would be a normal task for these kind of support staff.

Problem

So you have a brand new computer that you want to add to your network. You assign on of the non domain admins to install necessary software and join it to the domain. When he adds it to the domain, the computer is dumped into the "computers" folder in AD where the appropriate group policies and delegated access is NOT applied. You want the new computer to go into a separate OU but you don't want to grant the user access to move or manipulate Active Directory AND you want to delegate the entire process to the admins so that you don't need to be involved in the specifics. So what do you do?

Solution

If you precreate the computer in the appropriate OU in Active Directory, when that computer is joined to the domain, it will have the group policies and permissions that it needs. As a domain admin, you can precreate the computer account yourself but you'd rather delegate access the IT support team. Here's how you do it:

Delegate Control To Non-Domain Admins

1. Open Active Directory Users and Computers
2. Right click on the OU and then click All Tasks>Delegate Control
3. Click Add and put in the appropriate user or group (IT Admins)
4. Click "create a custom task to delegate"
5. Click "only the following objects in this folder"
6. Check Computer Objects
7. Check "Create selected objects in this folder"
8. Under "Show these permissions" uncheck everything and click "Next"

You've now granted non-admins access to create computers inside of that OU.

Pre-Create New Computer

These are the tasks for the non-admin to perform using the Server 2003 Admin Pack

1. In Active Directory Users and Computers, right click the target OU the computer should go to and choose New>Computer
2. Name the computer
3. Under "The following users or group can join this computer to the domain" choose a group that has appropriate access like "IT Admins" or "Domain Users" to allow anyone do it.
   This is the step that is usually missed. If you don't do this, then by default Domain Admins are the only one that can add the computer to the domain.
4. Click Next

Now on the client you go through the normal process of adding the computer to the domain.

I've been getting a lot of experience with the Active Directory Migration Tools [ADMT] but it seems like I always have a problem with using SID history between domains. This is more of a reminder for myself how to get SID History to work.

What is SID History

SID History is an attribute of an Active Directory object that stores an old Security IDentifier(SID) mostly commonly used during a migration. So you have an old domain, and you move to a new domain, and the user on the new account maintains access to all of their old files and folders. This saves the hassles of having to re-permission network shares, folder access, applications, etc. In order to use SID history, you must disable SID Filtering and enable SID History on the trust between the domains.

To enable SID History on a trust issue this command:

Netdom trust TrustingDomainName /domain: TrustedDomainName /quarantine:No /userD:domainadministratorAcct/passwordD:domainadminpwd

What is SID Filtering

The nemesis of SID History is SID Filtering. This is a security measure put into place by default that protects your new environment from attackers that may have broken into the old domain. Although you may think, no one's going to get into the old domain, I think that just about every migration I've done, they leave the original domain up and running and then starts to put a low priority on everything in that domain; patches, access control management, event log review all becomes secondary because no one is on it any more and now becomes a fairly large new attack vector. While it makes sense to leave the old environment up and running, it still needs that same care it has always needed.

So that's why SID Filtering is good, but unfortunately, it completely blocks the use of SID History which would be very important during a migration. This command below disables SID Filtering:

Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /userD:domainadministratorAcct /passwordD:domainadminpwd

External Links

http://technet2.microsoft.com/windowsserver/en/library/52b395b4-0313-47d8-87d4-fb1dd4d5c4701033.mspx?mfr=true - Technet article about disabling SID filtering
http://technet2.microsoft.com/windowsserver/en/library/31915de7-ff58-4f26-a8ec-450ffca759121033.mspx?mfr=true - Technet article about external trusts

One of my clients had the problem of users being excessively prompted to update Firefox

A new version of Firefox is available:
It is strongly recommended that you upgrade Firefox as soon as possible

It then shows the "Download and Install Now" button but eventually fails when a normal users runs it because they are not local admins. This prompt repeats over and over until IT gets a phone call about how they hate Firefox and are going to go back to using IE.

It's actually as simple as you may think. If you change "C:\Program Files\Mozilla Firefox" to allow "YOURDOMAIN\Domain Users" write access, a normal user can update Firefox.

You can go around to each workstation but where is the fun in that? The builtin program "cacls" with the help of PSExec will let you update all of the computers on a site. This idea was put together by my friend with a little tweaking on my part. Basically you just create a list of computers, and then run the command remotely on each one.

Create a List of Computers

You can do this however you'd like but for me I like to export a list of computers them from ADUC. This will only help if your computers are in the same folder or OU. You could always just write down the names of the computers but that's boring.

1. Open Active Directory Users and Computers
2. From the menu bar choose View > Add / Remove Columns
3. Remove all columns that are not Name [Type, Description] and click OK
4. Open the folder or OU that contains the computers you would like to update
5. Right-click on the folder or OU and choose "Export List..."
6. Save the file as "computer_list.txt" somewhere logical to you

Create the Script

Here is the entire command all together. Hopefully it's obvious to change the YOURDOMAIN\ADMIN_ACCOUNT to an account that is a member of the Domain Admins group and change YOURDOMAIN\Domain Users to whatever your domain is.

psexec @computer_list.txt -u YOURDOMAIN\ADMIN_ACCOUNT cacls “%SYSTEMDRIVE%\Program Files\Mozilla Firefox” /E /G “YOURDOMAIN\Domain Users”:W

You will want to put this into a batch file because you'll have to run it again or on a regular basis if some of your computers are turned off or not on the network when you're running the script.

External Links

http://woodruffrc.com/allow-non-admin-users-to-update-firefox.html/trackback - link to my friend's website who actually did the testing and put everything together

I found this script from the site www.rlmueller.net which has a ton of other handy scripts that are free anyone to hack as long as you don't blame him for screwing something up.

This script searches through each domain controller of whichever domain your computer is a member of and outputs the "lastlogon" attribute of the account. Very useful in finding old accounts that are unused. Just be careful because some service accounts that you may have created on the domain will not show a lastlogon event at all

' LastLogonTimeStamp.vbs ' VBScript program to determine when each user in the domain last logged ' on. Domain must be at Windows Server 2003 Functional Level. ' ' ---------------------------------------------------------------------- ' Copyright (c) 2007 Richard L. Mueller ' Hilltop Lab web site - http://www.rlmueller.net ' Version 1.0 - March 24, 2007 ' Version 1.1 - July 6, 2007 - Modify how IADsLargeInteger interface ' is invoked. ' ' The lastLogonTimeStamp attribute is Integer8, a 64-bit number ' representing the date as the number of 100 nanosecond intervals since ' 12:00 am January 1, 1601. This value is converted to a date. The last ' logon date is in UTC (Coordinated Univeral Time). It must be adjusted ' by the Time Zone bias in the machine registry to convert to local ' time. ' ' You have a royalty-free right to use, modify, reproduce, and ' distribute this script file in any way you find useful, provided that ' you agree that the copyright owner above has no warranty, obligations, ' or liability for such use. Option Explicit Dim objRootDSE, adoConnection, adoCommand, strQuery Dim adoRecordset, strDNSDomain, objShell, lngBiasKey Dim lngBias, k, strDN, dtmDate, objDate Dim strBase, strFilter, strAttributes, lngHigh, lngLow ' Obtain local Time Zone bias from machine registry. Set objShell = CreateObject("Wscript.Shell") lngBiasKey = objShell.RegRead("HKLM\System\CurrentControlSet\Control\" _ & "TimeZoneInformation\ActiveTimeBias") If (UCase(TypeName(lngBiasKey)) = "LONG") Then lngBias = lngBiasKey ElseIf (UCase(TypeName(lngBiasKey)) = "VARIANT()") Then lngBias = 0 For k = 0 To UBound(lngBiasKey) lngBias = lngBias + (lngBiasKey(k) * 256^k) Next End If Set objShell = Nothing ' Determine DNS domain from RootDSE object. Set objRootDSE = GetObject("LDAP://RootDSE") strDNSDomain = objRootDSE.Get("defaultNamingContext") Set objRootDSE = Nothing ' Use ADO to search Active Directory. Set adoCommand = CreateObject("ADODB.Command") Set adoConnection = CreateObject("ADODB.Connection") adoConnection.Provider = "ADsDSOObject" adoConnection.Open "Active Directory Provider" adoCommand.ActiveConnection = adoConnection ' Search entire domain. strBase = "<LDAP://" & strDNSDomain & ">" ' Filter on all user objects. strFilter = "(&(objectCategory=person)(objectClass=user))" ' Comma delimited list of attribute values to retrieve. strAttributes = "distinguishedName,lastLogonTimeStamp" ' Construct the LDAP syntax query. strQuery = strBase & ";" & strFilter & ";" & strAttributes & ";subtree" ' Run the query. adoCommand.CommandText = strQuery adoCommand.Properties("Page Size") = 100 adoCommand.Properties("Timeout") = 60 adoCommand.Properties("Cache Results") = False Set adoRecordset = adoCommand.Execute ' Enumerate resulting recordset. Do Until adoRecordset.EOF ' Retrieve attribute values for the user. strDN = adoRecordset.Fields("distinguishedName").Value ' Convert Integer8 value to date/time in current time zone. On Error Resume Next Set objDate = adoRecordset.Fields("lastLogonTimeStamp").Value If (Err.Number <> 0) Then On Error GoTo 0 dtmDate = #1/1/1601# Else On Error GoTo 0 lngHigh = objDate.HighPart lngLow = objDate.LowPart If (lngLow < 0) Then lngHigh = lngHigh + 1 End If If (lngHigh = 0) And (lngLow = 0 ) Then dtmDate = #1/1/1601# Else dtmDate = #1/1/1601# + (((lngHigh * (2 ^ 32)) _ + lngLow)/600000000 - lngBias)/1440 End If End If ' Display values for the user. If (dtmDate = #1/1/1601#) Then Wscript.Echo strDN & ";Never" Else Wscript.Echo strDN & ";" & dtmDate End If adoRecordset.MoveNext Loop ' Clean up. adoRecordset.Close adoConnection.Close Set adoConnection = Nothing Set adoCommand = Nothing Set adoRecordset = Nothing Set objDate = Nothing

Save this text as a .vbs file and run it something like this:
cscript LastLogon.vbs > LogonTimes.txt

External Link:
http://www.rlmueller.net/Last Logon.htm - the site which I found this script and where you should go if you like it.