This is a four-part series of posts explaining how to install and configure a Linux-based appliance in your vSphere lab environment to take the role as a Windows Domain Controller.
- Part 1 – Why and what
- Part 2 – Deploying the appliance
- Part 3 – Selecting the roles and configuring the appliance
- Part 4 – Creating the accounts and configuring vCenter
Creating the accounts
Completing all three previous parts take us to the dashboard which has a great layout. At this stage, if you chose to set this as a standalone domain, you’re done! The domain controller is configured and ready to use.
Before we can join any clients to it, we’ll add a regular Domain Admin account (not to be confused with the zentyal admin account created during the install).
- Under the Users and Computers menu, select Manage. I highlighted the Users OU and clicked the green Plus sign.
The admin account you create during the install and the “Administrator” account seems to be hidden reserved account names.
- I created a cunningly obfuscated account called domainadmin and added it to the Domain Admins group.
- At this stage it’s probably worth creating another user account for regular vSphere administration. Something like vi-admin.
Before I move onto the vCenter configuration, it’s worth pointing out that the dashboard shows the GPOs applied across the domain. But there’s no way in the Zentyal GUI to create or edit them. To do this:
“Even if you don’t have any Windows Servers in your domain, it’s still possible to create and enforce any GPO using a Windows client joined to the domain. Installing Microsoft RSAT tools and logging into the client using the Domain Administrator LDAP account, you will use RSAT interface to design the desired GPO. The GPOs will be automatically added to the domain SYSVOL and enforced by the Zentyal server.”
You can use your newly formed Domain Controller with either a Window-based vCenter, or the Linux-based VCSA. I’m guessing for the same reasons you’re looking not to use a Windows Domain Controller, you’re probably the clever type of chap or chapess that would favour VCSA. Suffice it to say that it should work well in either case.
There are plenty of good guides on the web explaining how to stand-up a VCSA v5.5, but just to prove that I haven’t forgotten my l33t vSphere admin skills, here’s a quick summary:
- Deploy the VCSA ova
- Power it on
- If the subnet has DHCP, then log into https://your.ip.address:5480 page (default username and password is root / vmware)
- If the subnet doesn’t have DHCP:
- Login into the VCSA console and run
and follow the menu prompts the set the IP configuration required
- Once you can log into the admin console:
- Accept the EULA
- Accept the default settings
- Set the hostname setting with an FQDN
It’s now relatively straightforward to join your vCSA to a domain:
- On the vCenter Server Appliance admin web interface > vCenter Server > Authentication, and fill in the domain, username and password.
- Stop the vCenter service
- Set the password for the [email protected] SSO user
- Start the vCenter service
Now you can log into the Web Client as the [email protected] user.
- Go to Administration > Single Sign-On > Configuration > Identity Sources tab
- Click the green plus sign
- Select Active Directory (Integrated Windows Authentication) and add in your domain name
- Highlight the domain in the list and set it as the default domain (the blue circle with an arrow pointing into it)
- Log out and log back in with your domain admin account
At this stage, if you’ve created a domain account for vSphere administrative work, you should head to the appropriate level in the vCenter hierarchy and give the account the appropriate permissions. For example, if you created a vi-admin account, you could go to the root object and give the account the Administrator role.
We’re done creating and configuring your Domain Controller and successfully joining vCenter to it. For bonus points, you could now start joining your ESXi hosts to AD. Either way, the panda is super happy.