A Linux-based Domain Controller for a vSphere lab – part 1

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.