2

I have to install an Active Directory environment for our company and it would be the first from scratch installation one for me, so I have questions, basically about the structure.

First some description:

  • we have less than 100 users (external and internal), so not much
  • we have offices in different places, in different countries
  • I have to have domain controllers practically in every office (all in all not more than 10)

My plan and questions:

  • I want to use one domain for all of the users without subdomains. Am I right? Actually I don't see the advantage of using more domains, not even subdomains.
  • I want to use Organization Units to separete the different users. See the planned strusctures bellow
  • Can I replicate only subtrees between DCs? Like "OU=country1, OU=Internal, CN=Users"?
  • I saw somewhere an AD where they didn't use the CN=Users for the "normal" users, but a new CN="Company Users" in the root. Is it a common convention? I don't see any good reason to don't use the original CN=Users subtree.


CN=Users OU=Internal, CN=Users OU=country1, OU=Internal, CN=Users OU=country2, OU=Internal, CN=Users OU=ADMINS, OU=Internal, CN=Users (The only non geographic group on this level for the company IT administrators) OU=External, CN=Users: all the external users OU=EXTERNALCOMPANY, OU=External, CN=Users OU=OTHERCOMPANY, OU=External, CN=Users

I use Windows 2012R2 if it matters.

Thanks for any response.

  • 4
    Have you been given any education at all on how to do this ? – Iain Oct 15 '14 at 10:08
  • What do you want to say with that? :) – redseven Oct 15 '14 at 13:12
6

Your plan looks fine. Ish.

  1. 10 Domain Controllers for less than 100 users is a very high ratio of DCs to users. Strictly speaking, you don't need a Domain Controller at every office.

    • Not having a Domain Controller at a site will result in increased traffic across the site link, as a result of authentication and other domain service traffic traversing the link
    • Domain services will be unavailable if the site link goes down (which may or may not be a problem for you)

  2. A single domain without subdomains sounds right. Microsoft doesn't recommend the use of subdomains anymore, except in a few rare use cases anyway.

  3. You cannot selectively replicate OUs between domain controllers. You don't want to either.

  4. It's a common convention not to use the built-in Users or Computers containers. (And note that they're containers, not OUs.) These are the locations where new users and computers go by default, and so it makes life easier if they're not used for anything else. Using them as a root container for your hierarchy is generally not a good idea.

  • 1. Right now we have 3 offices and 1 data center, so 10 was a bit over estimated, but I guess I need 5. I don't like the idea any site internal communication would depend on their internet/VPN connection. Every office should work offline for days. – redseven Oct 15 '14 at 15:00
  • 3. That's an issue for me. Probably I'm too paranoid, but I don't want to synchronize to a remote contry the entire user database (with all the passwords), when 99% of the users won't go there... – redseven Oct 15 '14 at 15:05
  • 4. I still don't understand why I can't use CN=Users if I use OUs under this... but OK, it's a convention, I will maka 'Company Users' into the root. – redseven Oct 15 '14 at 15:05
  • @redseven If that (#3) is an issue, you need to use different domains or forests. But make sure it's actually an issue before you go down that route, because that adds a lot of complexity and administrative overhead. The amount of data that will be replicated is probably small enough that it doesn't matter, in reality. For example, my employer has >1,000 users, dozens of different sites, and we replicate all that AD data to one of our sites, which is connected with a 256Kb ISDN line... without causing link congestion. So you're probably worrying over nothing. – HopelessN00b Oct 15 '14 at 15:12
  • 1
    If you're worried about all passwords being in DCs at remote sites, look into RODC - Read-only domain controllers. – mfinni Oct 15 '14 at 15:16
4

I'm sorry, in advance, for the rambling nature of my commentary.

I want to use one domain for all of the users without subdomains. Am I right? Actually I don't see the advantage of using more domains, not even subdomains.

Single-domain is nearly always the way to go for organizations of almost any size, large or small (especially since Microsoft added fine-grained password policy). Single-domain is the easiest configuration to administer, by far.

Domain Controller Computers

If there are local resources that users in each physical office can access to keep working in the event of WAN failure then putting a Domain Controller (DC) in every physical office is certainly nice. If all the resources they access are remote anyway then it might not make sense to deploy so many DCs.

If your plan is to use the DC in each office as a file server, too, I'd strongly recommend using Hyper-V to host the DC as a separate VM guest. You should try to isolate DCs to providing domain-related services and nothing else, if at all possible. It decreases your attack surface.

Think about what happens if somebody steals a DC from one of the offices and plan for that. You should read-up on Read Only Domain Controllers (RoDC) to see if it fits the bill for your needs. If an RoDC gets stolen the passwords on that RoDC are compromised. If a traditional read/write DC gets stolen all passwords (and the krbtgt hash) are compromised and you will need to reset all passwords (and reset the krbtgt hash and reboot all the domain member computers).

Sites, Subnets, Replication

You'll want to configure Sites and Subnets to allow AD to properly manage the replication topology.

Can I replicate only subtrees between DCs? Like "OU=country1, OU=Internal, CN=Users"?

Don't worry about any selective replication of AD. You have so little data that any attempts to selectively replicate (which is what child domains are about, primarily) will just cause a lot more grief than benefit.

Be aware that intersite replication latency (15 minutes between sites, by default) will make you want to get in the habit of connecting your remote administration tools directly to the DC in an office when you want to make changes that are immediately "visible" to users in that site. (There is an option to enable a change notification protocol for intersite replication that will speed replication dramatically, but that's not the default behavior of the product.)

OU Structure

Delegation of administrative control is the first design constraint you should use in determining an OU structure. For example, if there will be users in each remote office who can act as "helpdesk" and reset passwords for local users then you'll want a geographically-oriented OU structure (as you've proposed). In some companies the OU structure breaks down first by departmental / business-unit lines because delegated administration is handled at the departmental / business-unit level. Even if you're not planning for any delegation of control now think about how the company might grow in the future and try to plan for that. (Geographic is generally the way people go.) Delegation of control amounts of access control lists (ACLs) applied to objects in the directory. Since an object can only have a single ACL applied, and since it inherits its ACL from the container (OU, in most cases) it's placed into, by default, the getting the location of the object is pretty important.

The second design constraint should be application of Group Policy. Since you're new to AD you should take some time to read-up on Group Policy. Unlike delegation of control, Group Policy is more flexible about applying to objects that are "spread out" in subordinate containers (through a feature called "Security Filtering"), so it's less critical that your OU structure reflect your planned Group Policy application strategy (though, when you can just link GPOs to OUs without any security filtering things are much simpler).

I saw somewhere an AD where they didn't use the CN=Users for the "normal" users, but a new CN="Company Users" in the root. Is it a common convention? I don't see any good reason to don't use the original CN=Users subtree.

The practical reason is that the "CN=Users" object is a "Container" object (not an OU-- compare the difference in the icons in "Active Directory Users and Computers" to "Users" versus "Domain Controllers") and cannot have Group Policy applied to it, nor can it have OUs created beneath it. The same holds true for the "CN=Computers" container. Practically speaking, nobody who uses Group Policy uses these containers for anything other than the default user accounts and groups placed in "CN=Users" (which, in general, you shouldn't move!).

You can't create the OU structure you're looking for below "CN=Users" because you're not allowed to create OUs there. The typical convention is to create a domain-level OU and place all your OUs, users, computers, groups, etc, under that OU.

It looks like you're off to a solid start, but I'd spend some time playing with this in a lab and thinking about common administration scenarios. Spend a little money and time on reading about AD in general and Group Policy, in particular, and I think you'll have a reasonable time of it.

  • Thanks for the detailed answer. About the "partial replication", I don't worry about the traffic, I worry about the security. I my opinion every single full replication is a risk. If someone hack a server or just steel it somehow he will have all the passwords, many of them is really not necessary there... RODC sound a good option. Probably I will install "real" DCs only in our country and deploy some RODCs (as a cache) to the other locations. – redseven Oct 16 '14 at 12:45
  • You are right, I lack of knowledge, but I try to close up. I also have a virtualized environment to play/test. – redseven Oct 16 '14 at 12:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.