Problems provisioning Win2k8 Domain Controller

[tristianc]

I have two base boxes. One base box has a default installation of Windows 2k8, with a local 'vagrant' account. I can use vagrant-windows to up, halt, and destroy this box fine.

Another has an installation of Windows 2k8 where it has been promoted to be a domain controller. Consequently, I can not add local accounts to this installation. I created a new account on the domain called 'vagrant' and added that user to the Administrators group, so this user can log in locally. However, I can not run vagrant up successfully using this account's credentials (which are the default credentials: vagrant/vagrant).

Is using vagrant-windows with a domain controller possible?

[sneal]

It looks like using domain credentials with winrm basic auth (which is what vagrant-windows uses) doesn't work. @pmorton can probably answer more definitively, see knife-15.

[pmorton]

There was an issuse with the underlying rubyntlm gem. This prevented winrm sessions from using anything but the default domain/workstation for the machine. On a domain joined machine it is the machines domain and on a non-domain joined machine it is the workstation. To get around this, I think that we use basic across the board. This is why only the vagrant user works. I am torn here, this issue is fixed in WinRM 2.0-pre but I have not yet released at because it needs some more manual testing. My inclination would be to release WinRM-2.0 and integrate that into this gem. Note WinRM 2.0 uses ntlm across the board and sucessfuly toggels between domains and workstations regardless of where the workstation is attached. The other option it to support in a backwards compat manner, I am not sure that can be done without breaking other projects.

[NicCOConnor]

Has there been any progress on this issue. I'm having the exact same problem. The First part of my recipes need to have a Domain Controller added. I'm getting 500 Errors from WinRM that I think might be related to this NTLM issue.

[sneal]

Not yet. I plan on tackling this when I get back from vacation in September.

[sneal]

@pmorton Any thoughts on moving forward with the WinRM 2.0 gem? I'd be willing to help push this forward.

[ianrossi]

@sneal @pmorton Is there anything I can do to move this forward? It's blocking me on testing with vagrant. Thanks.

[artemyarulin]

Hi guys,

I'm also quite interesting to resolve this issue, if you don't have a time to resolve it - can you at least describe how it should be handled? Maybe I could help then as well as @ianrossi

[sneal]

We need the WinRM2.0 gem that @pmorton has sitting in a branch to move this forward.

[ianrossi]

@sneal @pmorton @NicCOConnor @artemyarulin For me, the user account was not the issue. When I ran vagrant provision with VAGRANT_LOG=info, it appeared that the vagrant run was hanging on the user login. However, I discovered that after the domain join, network sharing settings were changed. I had to browse "Network" on the Windows Server machine and turn on networking and then browse to the \\VBOXSVR\tmp_vagrant-chef-1_chef-solo-1_cookbooks share to make sure it was working. After that, I was able to complete a vagrant run successfully with the Administrator/vagrant user/password combo. There is probably a way through group policy or something to turn this networking setting on during Chef-driven domain-join operation.

[StevenArmstrong]

We normally take a VM template, invoke a sysprep as part of the vagrant set-up to do the domain join and any other commands such as setting a new SID which is important for windows boxes. The sys prep will set a default network sharing setting but this could be set to obtain automatically if desired. Once the sysprep process is completed vagrant will put the box on the correct network sharing settings specified in your vagrant file, invoke the provisioner on the box when winrm comes back up after the sysprep has completed, the puppet or chef provisioner will kick in to carry out your desired run-book commands. This flow works well for us.

[ianrossi]

@StevenArmstrong Thanks very much for sharing that! I'll work that into my workflow as well.

[StevenArmstrong]

No worries happy to help :) I would recommend using the vsphere provider if you can as it makes this workflow very easy with the vagrant-vsphere plugin providing sysprep via the customisation spec input. I also have it working with cloudstack but I had to script the sysprep bits myself so it is still possible without.

[ianrossi]

@StevenArmstrong Wow, just keeps getting better. Thanks again. I'm just using the Virtualbox provider right now for local VMs, but I'll check out getting it setup with our vSphere implementation.

[sneal]

This plugin is no longer maintained since Vagrant natively supports Windows guests. If you have a Vagrant issue you need to ask the Vagrant mailing list or file a GitHub issue on Vagrant core.