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

Update: Fernando Pimenta has been kind enough to translate this series into Portuguese. You can find the translated copies here.

An existing domain

First off, I’m assuming you’re creating a new lab domain. You can join a Zentyal instance to your existing lab domain, promote it to act as a Domain Controller, handover the FSMO roles, then retire your Windows-based Domain Controller. Any existing GPOs will be available in the transferred domain. However that’s more than I want to get into for this series of posts. I like to rebuild my lab from scratch on occasion, to clear up the cruft that appears in a setup that lacks disciplined change management. But if you’ve built a complex setup, and the thought of rebuilding it all seems like too much work, then we’d love to hear your battle stories in the comments section below.  Here are a couple of pointers to the online documentation that might help you.

Joining Zentyal server to an existing domain:
http://doc.zentyal.org/en/filesharing.html#joining-zentyal-server-to-an-existing-domain

Total Migration (transferring FSMO roles):
http://doc.zentyal.org/en/filesharing.html#total-migration

An existing server

If you already have an existing Ubuntu (or Debian) server, you can install the Zentyal package. Again, this is out of the scope of these posts, but here’s a couple of pointers if that’s what you want to do.

Zentyal 3.3 is developed and tested with Ubuntu 12.04.3 (Precise) Server Edition, and hasn’t been tested with other versions – YMMV.

• Add their repository to your /etc/apt/sources.list:

  deb http://archive.zentyal.org/zentyal 3.3 main extra

• To authenticate the packages in the Zentyal repository you can import its public key with the following command:

  wget -q http://keys.zentyal.org/zentyal-3.3-archive.asc -O- | sudo apt-key add -

• The base package is called “zentyal” – suprise! So this will get you started:

  sudo apt-get update
  sudo apt-get install -y zentyal

A new server

Zentyal does provide pre-built VMDK images here, but I’d recommend just rolling your own. It’s simple and that way you can choose the modules you need from the outset. Go here to grab the latest release: http://www.zentyal.org/server/

I created a VM shell with these specs:

Guest OS: Ubuntu 64-bit
vCPU: 1
vRAM: 1GB
Disk: 10 GB (thinly provisioned)
Disk Controller: LSI Logic

I suspect you could run this off 512MB of memory for a lab if you’re in tight squeeze but I haven’t tested it.

Deploying the appliance

• Boot up the VM (with the downloaded ISO image attached)
• Keep English as the highlighted language and press enter
• Select the default option of “Install Zentyal 3.3 (delete all disk)”

• Select your location

• Detect keyboard layout – I selected the default of No and moved on to select my keyboard from the list in the subsequent 2 screens (English US)
• The installer then started to copy base packages to the disk
• Then the installer asked what the hostname should be – I was happy to keep it as zentyal for my lab.

• Next, you’re asked for an administrator’s username – I was happy to keep it simple, avoid any pesky security best practises, and used zentyal for my lab

• Stick in the password when requested
• Set the time zone
• The installer then copies the remainder of the base packages to the disk
• Once the base install is complete, disconnect the CD ISO image and reboot
• Upon reboot the Zentyal core packages get installed
• It then boots to a Ubuntu desktop (XFCE or LXDE desktop?) with Firefox open at a login screen

At this point in the proceedings I increased the size of the desktop resolution beyond the default 800 x 600. To do this click in the bottom left desktop icon > Preferences > Monitor Settings – Make sure you “Apply” the setting, not just “Save”.

All of this hard work make the Zentyal panda very happy. You should be too. We’re half way to building a Linux-based Domain Controller.

Part 3 of this series explains how to configure the Zentyal instance.

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

Update: Fernando Pimenta has been kind enough to translate this series into Portuguese. You can find the translated copies here.

Why

Microsoft has produced the de facto Directory Services tool with its Active Directory (AD) software ever since it nudged past Novell Directory Services (NDS) over ten years ago. Microsoft has dominated the market ever since with probably the stickiest piece of infrastructure in any large enterprise today. Whether you like Microsoft’s solution or not, it has become central to most business’s application soup.  It’s a key dependency for many applications, relying on it for things like Identification (user management), Authorization (Role Based Access Control [RBAC]), Authentication (password management); along with a raft of other AD integrated features. SaaS is probably the only application trend that is actively pushing in the opposite direction. Add to this the key role that AD plays in managing Windows clients and servers, and we realize that AD is very, very sticky.

In a vSphere environment, an AD domain (or even Windows itself) isn’t strictly a requirement. ESXi doesn’t need it and vCenter can run without it. VMware produces its vCenter Server Appliance (VCSA) which is a Linux-based server, and the Web Client can be run in non-Windows client browsers. As vCenter evolves, it increases the integration with its own Single Sign On (SSO) component. VMware’s SSO does “identity management” and “federates authentication services”, which sounds a lot like the basis for a Directory Services model, but in its current incarnations it doesn’t service requests like a real LDAP store and VMware has said they have no interests in creating an AD competitor.

There are VMware components that require AD, e.g. View Connection servers (and things like vSphere Update Manager that needs Windows). And if you’re building a vSphere lab the chances are that you’re also interested in testing other pieces of software that also need/want AD services. We don’t live in VMware bubble.

So why try to replace the Microsoft Domain Controller in your lab?

So if Microsoft’s AD is so prevalent and effectively necessary, why don’t we accept the fact that we need at least one Microsoft Windows server in our labs to run as a Domain Controller?

• Microsoft is big and evil and must be banished? No, I don’t believe this, but I do believe that diversity in any ecosystem is a good thing. Competition is healthy, drives innovation, and helps prevent unhealthy market practices.
• Cost. Windows server licenses aren’t cheap and can have a sizeable impact on the cost of standing up a lab environment. Microsoft’s TechNet subscription service, used by many IT professionals in their labs, is ending soon. Microsoft (and VMware) are keen for individuals to uses their online lab services as an alternative, but there is a lot to be said for getting your hands dirty and standing up your own lab.
• Windows based. Conspiracy theories aside, a lot of folks prefer non-windows based server tools. And this extends to their lab environments. Windows 2012 is less familiar to many folk, and does need a certain amount of hardware resources to do its thing.
• Resources. A lab is often hardware constrained, particularly in the memory department . A small, tuned Linux appliance can arguably run on a lighter footprint (Windows domain controllers can run in fairly minimal setups, but this requires more Windows setup and management foo than many of us want to get into in a vSphere-focused lab).
• It’s kool – even the Unicorn Kool-Aid guy thinks so.

I’m sure there are plenty of other good reasons why you want to try this in your lab. Tell us your story in the comments below.

What

There are a few software options to build a Linux-based Domain Controller, mostly based on the work being done in the Samba 4 project.  I’m going to use a tool called Zentyal, which is a slick, free to download application suite that runs on Ubuntu Linux and can impersonate a Windows Domain Controller by implementing SMB, managing the domain and setting up Kerberos for authentication services.

“Zentyal is a drop-in replacement for Microsoft Small Business Server and Microsoft Exchange Server, that you can set up in less than 30 minutes.”

One of the great things about using Zentyal as a Domain Controller is how simple it was to set up. The last time I rebuilt my lab’s Windows Domain Controller from scratch I followed this great post series. Setting up Zentyal was even easier and more intuitive.

When we’re done we’ll have an Active Directory server which is fully compatible with vCenter 5.5 SSO’s “Active Directory Integrated Windows Authentication” configuration, can used by your lab’s Windows clients/servers, and your ESXi hosts or vSphere Management Assistant (vMA) if you join them to the domain.

At this stage it’s worth pointing out the current limitations of Zentyal as of version 3.3:

• Only one domain in the forest, Samba doesn’t support multiple domains
• Functional Domain level min 2003, current max 2008R2
• Trust relationships between domains and forests are not supported
• GPOs will be synced from Windows servers to Zentyal servers, but not the other way around

None of which seems like a deal beaker for my small lab!

Part 2 of this series explains how to deploy a Zentyal instance into your lab.