What is ADDS?

 Every Microsoft oriented infrastructure in today's enterprises will depend largely on the active directory version built by Microsoft. It is the foundation stone on which all other products (Exchange, update services, office communicator, the system center family, etc) rely on to get their information.

And that is just looking at it from an infrastructure perspective.

A well designed and implemented Active Directory implementation makes life for IT personnel and user alike a lot easier. Centralised management and the abilities opened up  by having it in place are ample.

 But what is Active Directory Domain Services?

We can look at ADDS as a centralised directory containing all objects your infrastructure runs on in one way or another. Since it is a Microsoft product you'll obviously not be seeing linux or mac clients listed in here (exceptions exist) but in general we can say it contains everything your company has in place in one form or another.

 The domain name services.

The domain naming service (or DNS for short) is a service which translates IP address (the identifiers for each computer in your domain) into readable and easy to understand names. This service is a prequisite for ADDA to work and having wrong record in a DNS server will make any ADDS service fail.

Generally speaking a DNS service will be run on the same server as the ADDS service but it is worth wile to remember that this is not necessary. You could, for example, run your DNS services on a linux box (which would need special preparing to host an ADDS integrated DNS zone) and run the ADDS service of another box…

Where to start?

If the aim is to put in place a first time implementation of ADDS in your enterprise there are plenty of things to consider depending on what you are going to do in the long run. Great care has to be taken when first designing and implementing as having it set up wrong will cause a headache down the line. It is for that reason that I like to start building from the bottom up and start with a generic installation of ADDS (which will still differ for every client) and make it adaptable for future services which can hook in to the existing environment.

Adapting existing environments is out of scope for this document (and series) although it is possible to take the pointers and change your existing environment to run in a smoother manor. Take great care when changing things as one small slip of the hand can give you a forest wide failure…

Whenever starting with an ADDS deployment I ask the client the following questions:

•  What are your long term plans and goals?
•  How flexible do you want it?
• Are you currently linux heavy and want to keep this or can we go for an all Microsoft design?

Those three questions should give some sort of indicator what direction can be taken and if the client has thought about some things themselves :). 

The technical side of things

 What is next to consider is what kind of infrastructure is already in place. For these series I'll keep it simple and introduce some general concepts without going in to depth on integrating ADDS with other DNS services.

 Building from the ground up means we need to consider our layers on which our infrastructure will rely. In my view that goes as follows:

•  Network (WAN/LAN links and physical sites
• DNS Namespacing
• All in one domain or split up in different domains/forests?
• Security (both for ADDS and physical sites)
• The network side of things

 Looking at how the network is currently set up can potentially teach us a large deal about the client. Do they have multiple physical site? What network speeds exist between these sites, etc…

Depending on this information we will design our site links (which controls replication) in future stages.

DNS Namespacing

Maybe the single most intresting thing to know is what the domain will be named (ADDS will need a DNS domain with the same name) and where this will be hosted.

Note that active directory can be set up with a singe name (aka contoso instead of contoso.com) but it is highly recommended to never do this. If you do end up with a domain like that for some reason there will be a lot of services that are going to give you good grief in the future (exchange being one of them). So one of the best practises would be always to use a double name (contoso.com or contoso.lan for example).

Internal namespace

A single namespace is just what it sounds like. You have a DNS domain which is different internally from what the client has as an external namespace.

f.e. contoso.com as an external name (out on the internet) and contoso.lan on the internal network.

his setup is has its advantages in that you have more obscurity from the internet in the DNS side of this but it will require additional work to publish services to the web.

External namespace

Quite like the internal namespace only here you do not differ the internal namespace of the company from what is known on the internet. In this implementation you would host your own DNS servers for the external domain inside the network. Or in other words, any external computer doing a DNS lookup would contact your internal DNS server for the resolution.

Generally speaking this set up is a bad idea from the security side of things.

Split DNS

Whilst using an external namespace design is fairly easy it involves a lot of security risks. Opening up you ADDS DSN servers for lookups exposes your entire network to the internet and should be avoided at any cost.

And that is where the "split DNS" design comes in. In this setup up would still have the same namespace internally and externally but you would be using different DNS servers for lookups on the external network who have no records of your internal resources unless you explicitly publish them.

All in one or not?

In determining your active directory design you can look at the following possibilities: 

• Single forest, Single domain
• Single forest, multiple domains
• Multiple forests, multiple domains
  

I've listed the possibilities for design in increasing order of administrative magnitude. Microsoft recommends trying to use a single forest, single domain in as much situations as possible. It is, however, always possible that you require your services to be seperated from your users in a resource forest with trusts set up between the different forests.

To start out I would go with the single forest design to avoid complexity unless there are strict requirements to have multiple forests.

Security

What kind of security is required on the domain and does this reflect the physical security on the sites? Not every client can afford to have a domain controller in a secluded server room on every site and it is exactly for that reason that Microsoft introduced the RODC (read only domain controller).

A RODC is a domain controller that has been limited in functionality, in essence it will only cache the data you explicitly tell it to cache and in the case of a DC compromise (it being stolen) only a limited number of accounts will need to be affected.

Th- Th- Th- That’s all folks!

Well at least for now! In future editions of this series we’ll be walking through the different task that need to be done and the thought which needs to be put in to it. But for all editions we’ll be going from the concept of running a single forest, single domain with a split DNS setup…

See you next time!