VMX launched instances do not join domain on startup

[anon33810049]

Deadline 7.0.0.36
Win 2008 R2
3DSMax 2014

an AMI, upon lauch; does not connect to the domain the AMI is set to upon shutdown with Sysprep.

this issue is also being looked at by AWS Support, as an instance that is part of a domain will not change hostname via the EC2 config exe when explicitly set to.

[Coulter]

Thanks Marko. We’ll run some tests on our side to see if we can find anything.

[Coulter]

Marko, after some internal discussion, we suspect this is a limitation of AWS sysprep with regard to AD domains. But I want to make sure we fully understand the source of the issue. Could you loop us in on the AWS ticket?

[anon33810049]

from aws:

As discussed, I have been working through testing the various items in this case.

Hostname Change

• I have now tested setting the Set Computer Name item in the ec2 config service properties.
• Created an instance and domain joined this instance and then checked Set the Computer Name item and restarted - result: computer name did not change
• Created non domain joined instance and then checked Set the Computer Name item and restarted - result: computer name changed
• To verify it was not just a problem with the domain joined instance I changed the domain joined instance to workgroup joined and then ran the test again - result: computer name changed.
  This would appear to confirm our thoughts that the issue is the fact that the computer was domain joined when the ami was created and therefore there is a permission block with changing the computer name. My advice here is to ensure the ami is created from a non domain joined instance.

Join a domain at instance creation

• I created an ami of one of my instances and then entered the following in the userdata field during instance creation (Step 3: Configure Instance Details; Advanced Details):

$domain = "myDomain" $password = "myPassword!" | ConvertTo-SecureString -asPlainText -Force $username = "$domain\myUserAccount" $credential = New-Object System.Management.Automation.PSCredential($username,$password) Add-Computer -DomainName $domain -Credential $credential

I obviously had to edit myDomain, myPassword and myUserAccount however this script seemed to run and add my instance to my domain at instance creation. The problem I have at this stage is that the script is viewable via accessing the instance metadata (from the instance after it is created open internet explorer and navigate to 169.254.169.254/latest/user-data/). This is less than ideal so I will need to continue work to see if there is a way to hide the credentials used to add the instance to the domain. I am thinking something along the lines of using a service account or some other form of authentication that does not require plain text credentials. I will continue to work on this, however it is likely I won’t have a definitive answer on this item today.

[Coulter]

Thanks for the update. I’m glad to hear this was not a Deadline or VMX bug, although I think this would be helpful information for our documentation. If you do not come up with a satisfactory way to secure your credentials, let me know and I’ll check with the team for ideas.

[anon33810049]

their current standing:

I have been testing various methods of trying to hide the password used to join my instances to my domain with limited success.

I firstly created a file that stored the password I want to use in an encrypted format by running this command:
read-host -assecurestring | convertfrom-securestring | out-file C:\secure.txt

I was then able to add my server to my domain by reading in the contents of this file in the domain join script:

$domain = “myDomainName”
$password = cat c:\script\secure.txt | ConvertTo-SecureString
$username = “$domain\myUserName”
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Add-Computer -DomainName $domain -Credential $credential -Restart

When I ran this locally on a non domain joined server it seemed to work.

I then attempted to add this line to remove the password file:
Remove-Item C:\script\secure2.txt -Force

This did not seem to work.

I then created an ami that contained the C:\script\secure.txt file and created an instance from this ami and ran the script via the userdata field. The result was that the script did not seem to work. I am guessing it was not able to read the secure.txt file.

At this point I am thinking that there may not be an easy way to secure the password beyond all doubt. I considered saving the secure.txt file to an S3 bucket and then reading it in to the script from there, but I am not convinced that saving it to S3 is the best way forward even if the file contents are encrypted.

I am thinking the best way forward may simply be to create a user account on your domain that only has permissions to add computer accounts to AD and then use these account details with userdata at instance creation as outlined in my previous email. In this case the only way for the password to be compromised would be by someone that already had access to your server and from there could access the instance metadata and then even if this account did become compromised it would not have permissions to do anything but add computer accounts to the domain.

as well as:

-seems like the ec2 config exe needs an update to account for domain joining in and with sysprep. using the powershell scripting works well enough for now but is an extra step when creating nodes.

Agreed, I will probably investigate raising a feature request on this point, but this will not be of much assistance in the short term for you and there may be a solid technical reason why they don’t have this functionality.

[Coulter]

This is good information. I’m rather surprised that AWS has not encountered this issue before, and I hope they address it in the near future. Thanks for the update!