Adventures with Samba AD

So a company that I am doing work for has the requirement for federated logins between services such as VPN, Email and filesharing. The users were having to manage multiple passwords and it was a nightmare for all involved, especially considering that users were expected to know the difference between an email pasword and a fileshare password (protip, they don’t).

As a bad solution, I rolled a Samba AD which handles the DNS, DHCP and user objects for the business, and attempted to AD-ify it under the guidance of an actual AD expert.

I’ll try to break down my experiences doing this, so that you can make an informed decision. Some of things we discuss here will be transferrable between Microsoft AD and Samba AD, however they will be specifically pertient to Samba AD.

Planning

Get this defined early on. I largely yolo’d our deployment because we already had an unmaintained implementation sitting on an end-of-life’d server. You want to plan out every aspect of your AD before moving on, because most experts recommendation is to “destroy, rebuild”.

Naming Conventions

Name Length

A gotcha I experienced with my naming convention is that netbios names need to be a maximum of 11 characters long. This means constoso-ny-intranet-01 is not a valid name for a machine. We used cny-intranet-01 but even that is 15 characters long.

In previous companies, we used cryptic descriptions for servers. Transferring the above into a compatible naming convention; cnyi01 would be sufficient, as would cnyint01.

Taking this further, you can have cn-int-01 (9 chars) or even cnb-int-01 (10 chars). Your naming convention will be documented as [company][site][type]-[purpose]-[interation].

Notice I said iteration: some companies will decomission an interation permanent. ie if you have cnb-sdc-01 and you build a new DC onto cnb-sdc-02, then subsequently decommission 01, then your next DC that you build would be cnb-sdc-01.

You would need to document what everthing is as well. You need to designed c = contoso, n = new york, b = bare metal, etc.

You should also account for on-prem and cloud infrastructure as your company progresses into new technologies. This gets complicated because a totally condensed yet ultra informative name for just the AWS AZ would be usenv or use1. You could have cau1e-web-01 but that’s 12 characters.

I am genuinely open to suggestions on naming convention, because I can’t come up with anything that accounts for AWS Availability Zones. At least in the on-prem scenario, cnbint01 is short, informative, and memorable.

Stop naming them after Star Wars and Star Trek ships.

Domain Name - top level

You need to stop using things like contoso.local because Generic TLDs have definitely become a raging meme and anyone can buy any TLD if they have the money.

.local may be reserved as a ‘special-use domain name’ by the https://datatracker.ietf.org/doc/html/rfc6762, but that doesn’t mean that you should still use it. Especially when people are using things like .vm, like this guy.

Microsoft recommends that you use a domain registered with an internet registrar.

Scott Lowe has a good write up about how Mac OS X uses the .local TLD for Bonjour/Rendezvous services, leading to potential conflicts in an AD environment.

Essentially, the general recommendation is to register your FQDN with a registrar and have authoriative DNS servers specific in the WHOIS database. I have seen recommendations that the internal domain should be separate from the public domain, but I have yet to verify this against any official recommendations.

If you want to go down that route, I’m saying that you could register contoso.corp (a proposed gTLD), but use contoso.com for your public serving infrastructure. I personally have an unused domain as my FQDN serving my in-home AD.

Domain Name - third level

I have been told never to use ad.constoso.com. If your business was to buy Glorzo Inc and merge their asset pool into yours, you’re going to have to manage both ad.contoso.com and ad.glorzo.com. This gets super confusing, and could potentially cause problems, when both Contoso and Glorzo users have ad\username as their login.

You should use something like corp.contoso.com. Another example would be crew.contoso.com, or team.contoso.com. You may work for a huge company that has a forest per department, because each department is the size of a small business. This would lead you to have forests like mktg.contoso.com, it.contoso.com, etc. We have actually used oso.contoso.com in the past, which makes way more sense when you know our company name.

You should forward plan on this, reasonably account for anticipated scale over the next 10 years and design accordingly. It is not fun rebuilding an AD infrastructure.

Company (OU) Structure

You need to define how you want your corporate structure to appear. You will find this changes if your company doesn’t accurate define it’s own structure, but you will need to at least have a rough idea of what you’re doing going in.

The recommendation that I followed was to have crew.contoso.com, then to define OU=Contoso,DC=CREW,DC=CONTOSO,DC=COM, ie an OU named “Contoso” (or the company name) under the forest. We then defined all additional Organizational Units under the Contoso OU.

When you log into our AD using the AD Users and Computers tool, you’ll see a logical seperation of groups which are easy to peruse through. Remember that by making your AD neat and clean, you’re making it easier for other people to pick it up and use it correctly, and you’re reducing how often you’ll need to chekc over your notes to do basic functions.