A couple questions about AD Domains

[crielly]

Hi AT

So growing up, my father was an IT Pro (not networking, software developer/exec) and we always had our home network setup on an NT server with an ActiveDirectory domain. Years later as an adult, I find myself interested in the added security/control benefits of an AD Domain as I am in the planning stages of launching a little business project that will involve a network of probably 10-25 computers, a mix of Windows/Linux/maybe even a couple of Macs.

I've downloaded the trial for Windows Server 2012 and want to use my 180 days to figure out how to set up an AD domain and appropriate accompanying services, get other machines joined to the domain so that I can manage them centrally through group policy, and secure the whole thing to make it as employee/customer proof as possible (some of the machines on the network will be usable by the public as this will be a retail operation - and will therefore no doubt require a higher level of configuration to keep them secure)

I have spent a fair amount of time googling and trying to find answers to some basic questions. I have a couple to start with and will no doubt come up with others as I learn. For now:

1. When I go to set up a domain with the AD control panel, the domain name has to be a "fully qualified" domain - meaning something.something.com, for example. Why does it have to be structured like that, as opposed to just naming it "mynetworkname"?

2. If I use a virtualized copy of Win Server 2012 as my PDC, and the machine hosting it is domain joined...and I turn it off, thereby also taking the PDC offline - am I then stuck in an impossible catch 22 can't authenticate situation? And if so, is that then as bad an idea as it sounds or is there a way to make this work? For learning purposes, it is easier for me to use it as a virtualized copy rather than buy new hardware or dual boot.

 

[Genx87]

1. Because AD uses DNS. DNS doesnt like names that dont adhere to DNS structure. You can still have a netbios name that doesnt use .com. I suggest if you are going to utilize this domain on the internet to use a .local instead of .com. Makes DNS easier to deal with.

2. You can run a DC on the hardware that is running the VMs and have the VM machine part of the domain. It will take a few minutes extra to be able to logon due to waiting on the DC to boot. I would suggest leaving the machine running the VM out of the domain myself.

 

[theevilsharpie]

I suggest if you are going to utilize this domain on the internet to use a .local instead of .com. Makes DNS easier to deal with.

Using a .local domain will cause a number of autoconfiguration technologies to break. Don't do that. Use a subdomain of a public domain (e.g., int.example.com).

 

[crielly]

Using a .local domain will cause a number of autoconfiguration technologies to break. Don't do that. Use a subdomain of a public domain (e.g., int.example.com).

If that is the case, does it have to be a real domain that I have some sort of access to? I do have a domain (myname.com) - so would I have to then use something like example.myname.com, or can I use any old address I please?
Edit: That is my way of asking "if I put in a domain name that is a real domain, accessible to my server through the WAN, what relationship will my server try to develop to that domain?" IE if I use whatever.microsoft.com, is my PDC going to try and contact that domain somehow and next month I get a letter in the mail from Microsoft threatening to sue me and eat my kittens?

 

[crielly]

1. Because AD uses DNS. DNS doesnt like names that dont adhere to DNS structure. You can still have a netbios name that doesnt use .com. I suggest if you are going to utilize this domain on the internet to use a .local instead of .com. Makes DNS easier to deal with.

2. You can run a DC on the hardware that is running the VMs and have the VM machine part of the domain. It will take a few minutes extra to be able to logon due to waiting on the DC to boot. I would suggest leaving the machine running the VM out of the domain myself.

In the use case I am asking about, the PDC itself would be a VM...so I am wondering if I will even be able to log in since to turn on the PDC, I will have to be logged in to the guest machine...which to my understanding might be impossible without the PDC...hence the catch 22 question >< Or maybe I just didn't understand your answer correctly.

 

[theevilsharpie]

If that is the case, does it have to be a real domain that I have some sort of access to? I do have a domain (myname.com) - so would I have to then use something like example.myname.com, or can I use any old address I please?

It's best if you use a domain that you have access to, so you don't inadvertently conflict with a publicly-reachable domain.

 

[Genx87]

Using a .local domain will cause a number of autoconfiguration technologies to break. Don't do that. Use a subdomain of a public domain (e.g., int.example.com).

Which auto-config technolgies?

 

[Genx87]

In the use case I am asking about, the PDC itself would be a VM...so I am wondering if I will even be able to log in since to turn on the PDC, I will have to be logged in to the guest machine...which to my understanding might be impossible without the PDC...hence the catch 22 question >< Or maybe I just didn't understand your answer correctly.

Set the VM to auto-start. Once HyperV is running on the host it will start the VM.

 

[CubanlB]

Agreed with the auto start suggestion.

You can also log in to a SAM account (local user) on the member server (your hyper-v machine), so you will not be completely locked out of the machine if the domain is unavailable for any reason. All of my home lab machines run like this, though I have 2 hyper-v boxes setup so I can avoid the headache and keep my vms up if a machine needs maintenance, etc...

 

[drebo]

Using a .local domain will cause a number of autoconfiguration technologies to break. Don't do that. Use a subdomain of a public domain (e.g., int.example.com).

Microsoft's current general practices recommend using .local as the TLD. In fact, Windows Server 2012 Foundation and Essentials don't even give you a choice.

I've been using that for ever and never had a problem.

Can you elaborate on what you think it breaks?

 

[theevilsharpie]

Which auto-config technolgies?

.local is reserved for mDNS name resolution, and has long been used by Avahi and Bonjour. Using .local for unicast DNS can result in excessive amount of multicast traffic, and can cause name resolution failures if a hostname is present in mDNS and unicast DNS.

See RFC 6762 for more details.

Microsoft's current general practices recommend using .local as the TLD. In fact, Windows Server 2012 Foundation and Essentials don't even give you a choice.

Microsoft has never recommended the use of a .local domain as a best practice. Even as far back as Windows 2000, Microsoft has recommended using a reserved subdomain of a registered domain name for Active Directory:

Identify your organization's DNS owner and determine what registered DNS names you have available on the network that will host Active Directory.

Keep in mind that the names available on this network may be distinct from the names that your company exposes on the Internet. For example, the name your organization uses on the Internet might be contosopharma.com and the name used on your internal corporate network might be contoso.com. In this case the name that you select is contoso.com

If you do not have a registered domain name, you should register a name with an Internet DNS registration authority.

Note: As a best practice use DNS names registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name, or if your organization merges with, acquires, or is acquired by other company that uses the same DNS names then the two infrastructures can never interact with one another.

Add a prefix that is not currently in use to the registered DNS name to create a new subordinate name. For example, if your DNS root name were contoso.com then you should create an Active Directory forest root domain name such as concorp.contoso.com, where the namespace concorp.contoso.com is not already in use on the network. This new branch of the namespace will be dedicated to Active Directory and Windows 2000 and can easily be integrated with the existing DNS implementation.​

Microsoft defaulted to the use of .local for their small business products because of their belief that small businesses may not have or want a registered DNS name, so they defaulted to using an unregistered TLD. This is still OK (although not a best practice), it just can't use a .local TLD anymore.

It was my understanding that Microsoft had discontinued that practice starting with Server 2008, but I haven't used their newer small business products, so I'll take your word on their continued use.

 

[Genx87]

.local is reserved for mDNS name resolution, and has long been used by Avahi and Bonjour. Using .local for unicast DNS can result in excessive amount of multicast traffic, and can cause name resolution failures if a hostname is present in mDNS and unicast DNS.

See RFC 6762 for more details.



Microsoft has never recommended the use of a .local domain as a best practice. Even as far back as Windows 2000, Microsoft has recommended using a reserved subdomain of a registered domain name for Active Directory:

Identify your organization's DNS owner and determine what registered DNS names you have available on the network that will host Active Directory.

Keep in mind that the names available on this network may be distinct from the names that your company exposes on the Internet. For example, the name your organization uses on the Internet might be contosopharma.com and the name used on your internal corporate network might be contoso.com. In this case the name that you select is contoso.com

If you do not have a registered domain name, you should register a name with an Internet DNS registration authority.

Note: As a best practice use DNS names registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name, or if your organization merges with, acquires, or is acquired by other company that uses the same DNS names then the two infrastructures can never interact with one another.

Add a prefix that is not currently in use to the registered DNS name to create a new subordinate name. For example, if your DNS root name were contoso.com then you should create an Active Directory forest root domain name such as concorp.contoso.com, where the namespace concorp.contoso.com is not already in use on the network. This new branch of the namespace will be dedicated to Active Directory and Windows 2000 and can easily be integrated with the existing DNS implementation.​

Microsoft defaulted to the use of .local for their small business products because of their belief that small businesses may not have or want a registered DNS name, so they defaulted to using an unregistered TLD. This is still OK (although not a best practice), it just can't use a .local TLD anymore.

It was my understanding that Microsoft had discontinued that practice starting with Server 2008, but I haven't used their newer small business products, so I'll take your word on their continued use.

We are talking about setting up an active directory. Why would anybody rely on multi-cast DNS or zero-config in this scenario? I would be interested in seeing how AD would behave implenting it on the back of these technologies. I'd guess not real well. I'd also guess the vast majorities of business networks are not implementing these side by side either.

I tell small business or people starting out to use .local because it is easier to deal with when it comes to public facing domains. A lot of small business's have a website and no IT person on site. Or nominate some poor sap for the position regardless of qualification. They dont understand having a DNS of xyz.com and then naming their AD domain the same can cause headaches.

 

[theevilsharpie]

We are talking about setting up an active directory. Why would anybody rely on multi-cast DNS or zero-config in this scenario? I would be interested in seeing how AD would behave implenting it on the back of these technologies. I'd guess not real well. I'd also guess the vast majorities of business networks are not implementing these side by side either.

No one is going to implement AD on mDNS, but AD exists in a world where devices expect to use .local for mDNS name resolution. Anyone that has ever had to integrate Macs into an AD with a .local TLD for the domain name will understand what a pain in the ass it can be. Now that the use of .local for mDNS is an Internet standard, the problem will only expand in scope, particularly as more companies shift from providing in-house computing equipment to a BYOD model.

Use a .local unicast domain name at your own peril.

 

[Genx87]

No one is going to implement AD on mDNS, but AD exists in a world where devices expect to use .local for mDNS name resolution. Anyone that has ever had to integrate Macs into an AD with a .local TLD for the domain name will understand what a pain in the ass it can be. Now that the use of .local for mDNS is an Internet standard, the problem will only expand in scope, particularly as more companies shift from providing in-house computing equipment to a BYOD model.

Use a .local unicast domain name at your own peril.

Implementing Macs on an AD is a hassle regardless of using .local or not. I can go on and on about the issues we run into compared to PCS. Simple shit that shouldnt be a problem. And we dont have a .local domain for our AD. But I digress. I think we are focusing on two technologies are are easily bypassed or imo not applicable to many business enviroments.

I do thank you for the information. When was this standard finalized? I hadnt heard about it using .local. Was there a reason why they chose that?

Are you seeing an increase in BYOD model in business? I contract on the side with small business's and have yet to see anybody do that except for phones. But phones easily tie into a network where services have already been setup(DHCP, DNS, ect).

 

[theevilsharpie]

Implementing Macs on an AD is a hassle regardless of using .local or not. I can go on and on about the issues we run into compared to PCS. Simple shit that shouldnt be a problem. And we dont have a .local domain for our AD. But I digress. I think we are focusing on two technologies are are easily bypassed or imo not applicable to many business enviroments.

mDNS isn't meant for use in managed environments, but nonetheless, it exists. Attempting to ignore it and re-purpose .local for something else will only result in compatibility problems down the road.

I do thank you for the information. When was this standard finalized? I hadnt heard about it using .local. Was there a reason why they chose that?

The actual mDNS standard was approved as an Internet standard on Feb. 2013, although Apple and others have been using it for close to a decade. I don't know the reasons why they specifically chose .local, but since mDNS is meant to be used for link-local name resolution, .local is as good a name as any.

Are you seeing an increase in BYOD model in business? I contract on the side with small business's and have yet to see anybody do that except for phones. But phones easily tie into a network where services have already been setup(DHCP, DNS, ect).

I'm not really in a position to judge what the market as a whole is doing, but among my friends in the industry, I've seen an increasing number using their own equipment in lieu of company-provided equipment, but I'm not sure if that's due to personal preference or company mandate.

Other trades (construction, electrical, automotive, etc.) expect workers to bring their own tools, so it seems only a matter of time before IT follows suit.

 

[crielly]

So I managed to get a domain up and running (AD-DS, DHCP, DNS and WINS) and have successfully connected from my laptop at work through a PPTP VPN connection (using my cisco rv220w as the VPN server).

I can ping/tracert to my PDC and other machines on the network, and can log in to my domain user account, but I can't seem to locate any machines through the network browser - in fact, all the machines on my wireless network at work still show up. I thought the only thing missing to make that possible over a VPN connection was WINS, so I am confused. Any idea what I am doing wrong?

 

[theevilsharpie]

WINS has never worked reliably for me. I'd suggest publishing your shared resources in Active Directory instead.

 

[crielly]

Is that something I need to do for every resource (ie every shared folder), or can I group all the computers that are registered on the domain and publish them en masse?

 

[theevilsharpie]

Every resource.

 

[crielly]

Every resource.

There has to be an easier way. How does a corporate IT type dude make network resources browse able over PPTP?

After reading that sentence out loud, I can almost feel the answer coming..."Use L2TP!"

EDIT: And even if I am doing something wrong and can't browse the machines on the remote network - why are the ones on my local work network still visible?

 

[kevnich2]

There has to be an easier way. How does a corporate IT type dude make network resources browse able over PPTP?

After reading that sentence out loud, I can almost feel the answer coming..."Use L2TP!"

EDIT: And even if I am doing something wrong and can't browse the machines on the remote network - why are the ones on my local work network still visible?

Your local ones are likely communicating through WINS. The VPN won't transmit broadcasts so you have to rely on DNS to work correctly. Find other computers and servers on the domain by using it's FQDN, then it'll work just fine, assuming you configured your vpn to use the dns server of your domain dns.

 

[kevnich2]

And as far as the .local for corp dns servers - I use .local in all of my internal DNS, always have. Leave it to apple to try and take something most companies are using and try and make it used for something entirely different just so they can break things. I definitely will not be changing all my dns structures around just for mac's using .local for mdns to work. They should have chosen a different tld structure than the very common .local