Can't authenticate using local Administrator UNLESS machine is joined to the domain?

[chrisheartland]

Any time I build a new vm in our environment and try to run a workflow that must first authenticate, i.e. copy a file from vco to guest, I get the error "Failed to authenticate with the guest operating system using the supplied credentials."

The moment I join the domain I can get it to authenticate. Would this be due to some type of security setting I'm not aware of? We have pretty tight firewall rules in place although I have all of the vCO ports open to and from vCenter (and I thought it was using vmtools anyway which should be going around the FW in the first place).

[Anjani_Kumar]

your vcenter must be authenticated with the AD. Thats why its not allowing to run your workflow in your local environment as it can be authenticated to the vcenter. So you must need a service account or a user ID in your domain to get it work.

All the best,

Please consider marking this answer "correct" or "helpful" if you found it useful.

Anjani Kumar

VMware vExpert 2014 .  Infrastructure Specialist.

Email ID : Anjani.kumar@vmwareminds.com

Website :   http://www.Vmwareminds.com

[chrisheartland]

"your vcenter must be authenticated with the AD. "

I'm not sure I follow. Our vCenter is on the domain and is able to talk to the domain.

"So you must need a service account or a user ID in your domain to get it work."

How can I use a service account if the vm is not joined to the domain directly after being built? There are things I want to do to the vm before it joins.

[Jeremy_VE]

Let me preface this by saying I'm still new to vCO and coding in general so I'm fumbling my way through vCO.

My problem is exactly opposite.  I can authenticate fine when the VM is in a workgroup, but as soon as I make it a domain controller it can no longer authenticate.  Also, I inserted breakpoints on all of the components involved in the timing/status checking to see what was going on.  When I ran through the debug on the workflow just to see what was going on every step of the way, the workflow completed successfully.  I then duplicated the workflows (Run script in VM Guest & Run Script in Guest), modified the Sleep/Count scriptable task (set sleep time for 5 minutes, thinking it was a timing issue), and wasn't able to get it to work.

My PowerShell script was:

Install-Windowsfeature -Name AD-Domain-Services

Import-Module ADDSDeployment

Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "Win2012" -DomainName $domain -DomainNetBIOSName $nbName -ForestMode "Win2012" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SysvolPath "C:\Windows\SYSVOL" -Force:$true -safemodeadministratorpassword (convertto-securestring "14qrafzvZVAFQR!$" -asplaintext -force)

I then changed things up and created 2 scripts:

Install-Windowsfeature -Name AD-Domain-Services

&

Import-Module ADDSDeployment

Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "Win2012" -DomainName $domain -DomainNetBIOSName $nbName -ForestMode "Win2012" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SysvolPath "C:\Windows\SYSVOL" -Force:$true -safemodeadministratorpassword (convertto-securestring "14qrafzvZVAFQR!$" -asplaintext -force)

I then used the default package workflows, as my duplicated ones weren't working as I suspect that I forgot to duplicate something or messed something up in the process, to run the Install-WindowsFeature script by itself to try to make things simpler.  However, the workflow still looped despite the fact that the AD Role did in fact installon the server.  I'm thinking I may need to set the timer to wait longer before checking the status of the install, but I can't modify the packaged WF's, and when I try to duplicate them they don't seem to work correctly.

~Jeremy

[chrisheartland]

I'm still having the issue of not able to login until I join the machine to the domain.

Anyway, I just want to make sure after you make your machine a DC that you are trying to login with a domain account and not a local account (because DC's don't have local administrators). Something you probably know but if not can be a "gotcha".

[Jeremy_VE]

Using the "Run script in VM Guest" workflow (without making any modifications), the only option I have for authentication is username and password.  All I put in is "administrator" for the username and the password.  I don't make any modifications down the line at all.  The server is in workgroup mode so there's no logging in with .\administrator, which you would have if the system was on the domain.  I'm assuming that the workflow is just using the username/password combination without specifying weather to log on to the domain or not.  How would I modify the workflow so that after running the powershell script that it makes sure to use domain\username format to authenticate just to ensure that it's logging in to the domain?

~Jeremy

[chrisheartland]

I think all you would do is "domain\username". The fact that the machine is on the domain, you would just set the username as you would if you were manually logging into the console.

[Jeremy_VE]

That's the funny thing about it.  When logging into a server in a Workgroup, there's no .\username.  Also, when logging in to a domain controller there's also no .\username.  Unless vCO is doing something on the backend that I don't know about, it should just be passing username and password and not worrying about local/domain authentication.

~Jeremy

[chrisheartland]

My thoughts are this: If it's not on the domain, whatever you put in will be local admin. If you are on a domain, whatever you put in will be domain. If you're on the domain and you put in ".\" it'll be local admin.

So, yea. But, just in case, I would go ahead and put in "domain\username" even if on the domain.

[Jeremy_VE]

So how do I modify the workflow to do that automatically after the script runs?  When I execute the workflow it takes VM I selected, the username, the password, and data for any variables that I want to replace in the powershell script (in my case I'm replacing $domain with "my.lab" and $nbName with "my").  The replacement data is inserted into an array.

I'd like to have a javascript statement in the "Get Process in Guest" workflow script that says something like:

If error is "Can't authenticate using provided credentials", thenusername changes from administrator to my\administrator (even my.lab\administrator would be acceptable as this would also work for authentication) and check runs again before throwing an error and looping for another wait period (only errors I've seen so far are authentication, guest tools not ready, and vm not accessible (the latter 2 both due to reboots for install completion).

I want it to be dynamic to support any domain that is being created, so it would have to pull the domain value out of the array

~Jeremy

[chrisheartland]

I'm not as good with error handling in vco/javascript, but I think all you have to do is dragNdrop your red error line to the next element you want. So, if it fails, the next element you want it to do is to retry the same script/workflow but with the new credential. Edit: If you want more scriptable error handling, you can do something like "if (error = "failed to authenticate") { boolean = true}; This will allow you to use the boolean flag to send your error to the next workflow (but I think the red line should work that way too if it's easier).

As for the guest tools not ready, just use action "vim3waittoolsstarted" and it won't continue until the tools are ready.