I got an e-mail from a forum buddy yesterday asking about a quick and easy way to change the OU that a deployed virtual machine (or any machine for that matter) belongs to.<\/p>\n
When machines are added to an Active Directory domain, they are automatically joined to the Computers OU. Well, actually, Computers is a Container, but that’s semantics.<\/p>\n
Group Policy Objects can’t be applied to the Computers container, and as a result, they cannot be leveraged on computers in that container. That is, with the exception of a domain wide GPO.<\/p>\n
So what is a Windows\/VM admin supposed to do when deploying 100+ VDI Desktops, 10 new guests, or the like, and they want to ensure that they have the deployed systems in the right OU?<\/p>\n
I worked on part of the puzzle last night, and felt pretty good about the work I had done. Then when I awoke this morning, a couple more concerns came to mind.<\/p>\n
Well, there’s 2 ways to tackle this problem (one secure and inflexible, another insecure and flexible).<\/p>\n
Let’s start with the insecure one: Cons: Create an admin script\/exe that a privileged user runs outside of the VM Cons: So is there a way to have your cake and eat it too?<\/span> An imperfect method, a local script with elevated privileges:<\/span> Here’s the AutoITScript:<\/p>\n #cs —————————————————————————-<\/p>\n AutoIt Version: 3.2.12.1 Script Name: moveou.au3 Syntax: moveou.exe “OU=Target,DC=domain,DC=com”<\/p>\n #ce —————————————————————————- ; Setup constants for writing to the ; Setup our variables so we can have ; Create a Windows Shell object, ; Create an AutoIT Error handler, ; Grab the local computer name ; Grab the destination Org Unit’s ; Grab the DefaultNamingContext so we have ; Set the Short and Long Distinguished Name values ; Load the Target Org Unit as an object ; Move the Computer into the Target Org Unit ; If we were successful, write to the event log as such ;COM Error function Again, this doesn’t handle the elevated credentials piece. After the script is compiled into an exe, it would be run from the command line like this:<\/p>\n moveou.exe “OU=Destination Org Unit,”<\/p><\/blockquote>\n And yes, the following comma is necessary.<\/p>\n Now on to the elevated credentials piece. To do this with “runas”, there is one caveat. The password cannot be passed as part of a script.<\/p>\n To do this with CPAU, a batch file with the following contents would have to be used:<\/p>\n CPAU -u user [-p password] -ex “moveou.exe ‘”OU=Destination Org Unit,'”<\/p><\/blockquote>\n And the destination org unit has double quotes on the outside, and single quotes on the inside.<\/p>\n To do this with AutoITScript, another au3\/exe would have to be created that can elevate the credentials. Here’s one that would do that for you:<\/p>\n ;moveelevated.au3<\/p>\n Runas($CmdLines[1],$CmdLines[2],$CmdLines[3],0,”Drive:PathTomoveou.exe ” & $CmdLines[4])<\/p><\/blockquote>\n This would be run as<\/p>\n moveelevated.exe username domain password ‘”OU=Destination Org Unit,'” Two of these three options (not runas, due to the password limitation) could be put in a RunOnce registry key, and would accomodate the move once the guest has been joined to the domain, and rebooted.<\/p>\n If used with a VMware VirtualCenter’s Customization Specification, this line could be put in a runonce instruction. The data (including the password) would be stored in the VC database, and not be sent across the network, except through the customization package dropoff during a guest deployment.<\/p>\n A better method, being run by an admin (on the back end):<\/span> This can easily be done using the dsadd command.<\/p>\n <\/tt>dsadd computer “cn=ComputerName,ou=Test Servers, dc=domain,dc=com”<\/p><\/blockquote>\n Or it can be put in a batch file that will accept a parameter<\/p>\n <\/tt>dsadd computer “cn=%1,ou=Test Servers, dc=domain,dc=com”<\/p><\/blockquote>\n Which would be run like this:<\/p>\n addcomputer.bat ComputerName<\/p><\/blockquote>\n This method is very easy if you know the name of the computer you wish to add. And keep in mind, this would have to be run before the guest is joined to the domain.<\/p>\n 2. Using the previously mentioned moveou.exe (after the guest is on the domain) moveou.exe “OU=Destination Org Unit,” ComputerName<\/p><\/blockquote>\n As before, the admin would have to do this manually.<\/p>\n 3. Use the existing Active Directory Users & Computers interface. How VMware could help us out:<\/span> Mass deployment of guests and assignment to an appropriate OU is somewhat problematic right now. Until we get a little extra functionality from VirtualCenter, we’ll have to continue the hacking.<\/p>\n
\nCreate a local script or executable that will move the Computer to a new OU<\/span>
\nPros:
\n1. Easy to use, can be very flexible, depending on how coded
\n2. Add the ability to accept command line parameters to change the target OU
\nDifferent OU paths could be implemented by different .bat files in the RunOnce registry key.
\nOne .bat for one path, another for a different one, etc.
\n3. Is run from the deployed system, and can be pretty much automated.
\n4. Is run dynamically, and automatically is run as new templates are deployed<\/p>\n
\n1. The script cannot make changes to Active Directory, unless the logged in account has AD privileges.
\n2. To run the script as a non-authorized user, the script would have to be run with an alternate user’s credentials
\n3. Is there any secure way to store this process where it cannot be exploited?<\/p>\n
\n<\/span>Pros:
\n<\/span>1. The script is only run by an authorized user, outside of the VM
\n2. Leveraging existing tools, and an administrative user’s security can be better protected<\/p>\n
\n1. Manual
\n2. Someone has to know to run it<\/p>\n
\nIn a perfect world, yes. In the real world, not without some finagling.<\/p>\n
\nI did write a vbscript that will handle the move (minus the elevated credentials piece), but decided to turn it into an executable using AutoITScript<\/a>. After downloading the AutoITScript package, and installing it, save the script below as an .au3 file, and use the AutoITScript package to compile it.<\/p>\n
\nAuthor: Jase McCarty<\/p>\n
\nScript Function:
\nTake a computer out of the Computer Org Unit,
\nand place it in a specific target Org Unit<\/p>\n
\n#Include<\/p>\n
\n; event log
\nGlobal Const $SUCCESS = 0
\nGlobal Const $ERROR =1<\/p>\n
\n; space to work
\nDim $WshShell,$oMyError,$sComputer
\nDim $sTargetDN,$sRootDSE,$sDomain
\nDim $sCompLongDN,$sCompShortDN
\nDim $objCont,$sErrorSet<\/p>\n
\n; so we can write to the event log
\n$WshShell = ObjCreate(“WScript.Shell”)<\/p>\n
\n; for error trapping
\n$oMyError = ObjEvent(“AutoIt.Error”, “ComError”)<\/p>\n
\n$sComputer = @ComputerName<\/p>\n
\n; Distinguished Name
\n$sTargetDN = “LDAP:\/\/” & $Cmdline[1]<\/p>\n
\n; DC=company,DC=com or whatever
\n$sRootDSE = ObjGet(“LDAP:\/\/RootDSE”)
\n$sDomain = $sRootDSE.Get(“DefaultNamingContext”)<\/p>\n
\n$sCompShortDN = “CN=” & $sComputer
\n$sCompLongDN = “LDAP:\/\/CN=” & $sComputer & “,CN=Computers,” & $sDomain<\/p>\n
\n$objCont = ObjGet($sTargetDN)<\/p>\n
\n$objCont.MoveHere($sCompLongDN, $sCompShortDN)<\/p>\n
\nIf $sErrorSet <> 1 Then
\n$WshShell.LogEvent ($SUCCESS, $sComputer & ” moved to the ” & $sTargetDN & ” organizational unit”)
\nEndIf<\/p>\n
\nFunc ComError()
\n; If we weren’t successful, write to the event log as such
\n$WshShell.LogEvent ($ERROR, “Error running MoveOU script” )
\n$sErrorSet = 1
\nReturn 0
\nEndFunc<\/p><\/blockquote>\n
\nTo elevate credentials, one must use a package like “runas”, a custom AutoITScript, or possibly CPAU<\/a> from joeware.net<\/a>.<\/p>\n
\n*Disclaimer… I haven’t tested this, but it should work.<\/span><\/p><\/blockquote>\n
\n1. Using DSADD (before the guest is added to the domain)
\nA preferred method, would be to add the computer accounts into Active Directory, in the appropriate OU beforehand, and as a result when the new machine is added to AD, it will already be in the correct OU.<\/p>\n
\nBy modifying the moveou.exe script to accept the computername as a command line parameter, an administrator could run the command with the destination OU, as well as the computername, and have the script move the computer to the desired OU.<\/p>\n
\nI shouldn’t have to say anything about this.<\/p>\n
\nNow, if VMware could add a piece to the deployment process, where after a machine is run, a command could be run (outside of the guest) with the rights of the VirtualCenter user that deployed the machine.<\/p>\n