Tuesday, November 27, 2012

Why you shouldn't use .local in your Active Directory domain name.

This post was updated on 14 November 2013

There are an awful lot of .local, .corp, and .lan Active Directory domains out there for many reasons. Sometimes, there is no easy way to change this due to things like Exchange, custom apps that integrate tightly with AD, or just the massive amount of testing that a domain rename requires. I can understand if you walk into a situation like this that you did not create, but please don't ever do this on a new domain.

The correct way to name an Active Directory domain is to create a subdomain that is the delegation of a parent domain that you have registered and have control over. As an example, if I ever started a consulting business and used the Internet-facing website mdmarra.com as my company's site, I should name my Active Directory domain ad.mdmarra.com or internal.mdmarra.com, or something similar. You want to avoid making up a TLD like .local and you also want to avoid the headache of using mdmarra.com for the Internet-facing zone and the internal zone.


I hear a lot of different reasons why people might want to use .local, some a bit crazier than others. A select few are:

"Since .local isn't a valid TLD, it's more secure since my AD can't be attacked from the Internet."
I actually heard this on an Active Directory certification training video today and I was shocked. It's just plain silly. You shouldn't be exposing your Domain Controllers to the Internet, period. They should be behind a firewall on the trusted side of your LAN. If you do expose them to the Internet, having a made-up TLD isn't going to help you much. This is a false sense of security that has no root in reality.
"Small Business Server defaults to using a .local TLD during the setup wizard."
Trust me when I say that SBS is not a product that you want to model your organization around. It is meant to be an out-of-the-box solution that can be managed by users with minimal knowledge of Active Directory or Windows Server. Microsoft is betting that people that install SBS either won't already own a valid Internet domain or won't understand what it means to use a third level domain name. SBS also has Active Directory, SQL Server, Exchange, and SharePoint all on the same server. Like I said, not something you want to model your environment after.
"I want my users to see Company\User as the login name. I don't want something ugly like AD\User or Corp\User!"
These two things aren't really related. You can set the NetBIOS name of the domain (the part before the backslash) to whatever you want during domain creation. You can also set the UPN (@whatever.domain.com) to anything that you want as well. This will allow you to have your AD's FQDN be something like internal.company.com, while your users will log in with Company\User or user@company.com. The FQDN of the domain has little to do with the format of a user's login name other than it picks a reasonable default during domain creation. You are free to change this default if you want to make it prettier.

If I haven't made up your mind about this yet, you should read Best Practice Active Directory Design for Managing Windows Networks on TechNet. It's a Windows 2000 era document, but this best practice hasn't changed. The relevant passage is as follows (The bolding is mine for emphasis):
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
Another reason, albeit a much smaller one, is that mDNS, otherwise known as Bonjour, uses .local to identify nodes on the local subnet without using a DNS lookup. According to Apple, this should only happen when there is a single label in front of .local, like server1.local. If your AD is called company.local – guess what – that's a single name in front of a .local. Not a good situation to be in. There are certainly workarounds for this, but I've worked in mixed environments with both .local and proper AD FQDNs and it's a lot less painful when you aren't using .local.

Really, there are zero good reasons to use .local in a new installation of Active Directory and there are plenty of reasons not to, so make it easier on yourself and your successors and put a little bit of planning into the naming of your forest root domain.

Update: Since this post was written, there has been a major new development with fabricated TLDs. The CA/Browser forum, which is a consortium of web browser vendors and public CAs has released a document titled:  Internal Server Names and IP Address Requirements for SSL: Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses provided by the CA/Browser Forum. It can be found here (warning: direct link to PDF).

This document states that no major certificate vendor will issue an SSL certificate for an address with a made up TLD in it, such as .local, .lan, .corp, etc. This echos the best practices that have been published for years, but now has real tangible consequences attached to it.

118 comments:

  1. I made just this error when I helped set up the first AD environment at my then-job. The AD deployment project ran from 2001 to 2003, and one of the decisions was what to name the freaking domains. Pushed for, and got, a "it'll never be used TLD". Being one of the junior members on that team, I saw it as a personal victory. Ahem.

    In my defense there wasn't nearly as much literature on domain-picking back then, and the TLD-explosion ICANN is doing wasn't even on the horizon. That particular gTLD has now been applied for by three different entities, so... bad ideas can come around and smack you a decade later.

    ReplyDelete
    Replies
    1. gTLDs are such a mess for so many reasons.

      At my previous job, we had two separate forests and both were .local. I had to do a domain rename on one so that it ended in .edu and then I had to migrate 20k objects from the other forest into the newly consolidated domain. Talk about a nightmare.

      Delete
    2. Why, specifically, did you "have to" rename the Active Directory? Having your AD forest name match your public-facing domain name is not remotely "required," and it seems like a minimal/non-existent problem that "some other organization" might end up buying "yourdomain.local" and cause DNS issues. You should just purchase whatever domain name you're using, if your chosen TLD suddenly becomes publicly available... We're talking about < $20 per year here, people.

      Vs. Weeks of planning and work to rename AD forests. That seems pointlessly wasteful with zero real benefit.

      Delete
    3. mDNS on versions of AD-joined OS X at the time did not play nice with .local AD domains. The decision was made to "fix" the AD forest to avoid future similar or unforseen issues rather than change the config on every Mac in the organization.

      Delete
  2. Hi Mark, regarding your statement: "you also want to avoid the headache of using mdmarra.com for the Internet-facing zone and the internal zone." You can do this, as long as you add the zone entries to address internet facing traffic - correct? Are you just saying that using the subdomain like ad.mdmarra.com is just plain simpler and avoids having to add these zones?

    ReplyDelete
    Replies
    1. Well, first of all, internal clients wouldn't be able to get to the external mdmarra.com website. They'd have to use something like www.mdmarra.com. This is because the Domain Controllers for a domain register A records for themselves in the root of the zone they they're in. This means that internally, there will be one A record for mdmarra.com for each DC that points to the DC. Obviously you won't be hosting your site on the DCs, so you'll need to do something messy like installing IIS on your domain controllers to do redirection or teaching your employees that mdmarra.com doesn't work from the inside.

      For other records like mail.mdmarra.com or anything else like that, yes, you just need to add them twice.

      Imagine a situation where you have a split DNS infrastructure like what we're talking about. Now imagine that you have a partner that has the same setup. You have a private fiber link between you two. Can you imagine what would need to be done to make sure that only internal traffic traverses that link while traffic meant to hit your partner's external sites goes out over the Internet? It takes a ton of unnecessary work to make that happen.

      Basically, there's no compelling reason to use an overlapping namespace. Sure, for some people it's fine, but for others it's not. You don't know how your company is going to grow or who it will partner with in the future. There's no downside to using a subdomain and there are plenty of gotchas when doing it any other way.

      Delete
    2. There is a way to make the domain.com available for the internal users. Just install IIS on all domain controllers and configure a redirect to www.domain.com.

      Works like a charm :)

      Delete
    3. Sounds like a bad workaround...

      Delete
  3. Mark,

    I work for a CA SSL provider and are running into trouble helping our clients get past the .local/internal name issue. We are required to limit their certs to a two-year term even though they want longer. I cannot find any relevant articles let alone walk-through's to reconfigure the exchange environment to not use .local's. For example when they go thru the CSR generation process and pick the services to enable, it automatically wants to generate a SAN for domain.local or just the server name.

    Can you provide insight to this problem? Thanks from all of us.

    ReplyDelete
    Replies
    1. There's no easy way for them to get off of .local. They'll need to migrate to a whole new AD domain. This is why it's critical to get the name of your AD correct during implementation, since it's months or even years worth of intense preparation to migrate to a new domain.

      Unfortunately, Exchange 2007 and 2010 don't support a domain rename like Exchange 2003 did. Once you have exchange in a domain, it can no longer be renamed and requires an entire migration to a whole new domain.

      Delete
    2. They can just use a internal CA.

      Delete
    3. There is a walktrough for exchange 2007 and above to change the behaviour of exchange: https://www.digicert.com/ssl-support/redirect-internal-exchange-san-names.htm

      Delete
    4. Hi Mark,

      Is it supported by exchange 2003 SP1 only or can also be done regardless the SP installed in the organization (sp1 sp2)

      Delete
  4. Mark -

    We are running into what you've mentioned. A consultant named our (very small) domain the same as our external facing website. Now when people are on-site and try to go to domain.edu, they get sent to the DC and and not to the website. I had originally planned on going to domain.local, but then I found your site. I'm definitely not an AD expert...so, can we just rename our domain to ad.domain.edu with the domain rename tool? Or is it much more heavily involved? Users don't authenticate or really interact with this domain. It was simply setup in order to utilize DFS for some web servers.

    ReplyDelete
    Replies
    1. You can rename it from domain.edu to ad.domain.edu with the domain rename tool, just make sure that you read, test, and fully understand the documentation and limitations (like you can't rename a domain with Exchange 2007+ in it.)

      Delete
  5. we have a domain currently with no TLD whatsoever, so if you name your company xyz, the name of our AD domain is simply xyz.
    I am thinking about renaming it according to what you have suggested here but I do have a exchange 2003 server running as well. According to Microsoft I can't do rename of the netbios domain name with any version of Exchange. Am I understanding this wrong or does it really mean I can't do a rename at all? Or does it mean that I won't be able to change the netbios name of the domain but I will be able to rename it to xyz.xyzpublic.com?

    ReplyDelete
    Replies
    1. Ouch, a single-label domain name. I actually don't know the caveats of changing that since it's so rare. You *should* be able to just do a rename and change only the FQDN, but a domain migration using ADMT might be just as easy depending on your size. It really depends.

      Make sure you read the documentation for either path carefully and check for caveats regarding single-label domains.

      Delete
  6. I strongly second you, Mark!

    AD domain names ending with ".local" are a nuisance.

    I like to add that ISO Standard 3166 reserves the country codes codes AA, QM-QZ, XA-XZ, and ZZ as user-defined codes. These will never be used in the public Internet!

    So it is feasible to use e.g. 'company.xa' as AD name space.


    ReplyDelete
    Replies
    1. That's interesting. Are organizations able to register them to guarantee that they are unique? If not, they should still be avoided. If I'm example.xa and you're example.xa, we can never have a trust between us or resolve each others internal namespace for collaborative purposes.

      Delete
  7. Hi Mark and and everyone who is participating in this very excellent discussion--Hat's off to you Mark for this exemplary post. I currently inherited an AD environment (company.com with an externally hosted website company.com--and yes dns was and is a pain) with one sever running under windows 2003 r2, and is running AD/DNS services at a windows 2000 functional level. It is also running exchange server 2003 sp2. I am charged with migrating this whole thing to several new servers that will have 2008 r2. My plan is to have one server running ADDS and one server running exchange 2010. If I rebuild my AD from the ground up on these new servers, can I name my new domain, company.com like the old system was without worrying about users having access to their mailboxes--i.e. will the new system create new SIDs that will prevent me from importing/migrating our mail store into the new exchange? I want to hear what peoples' opinions are on this, or any recommended strategies. Has anyone had an experience like this before?

    ReplyDelete
    Replies
    1. First of all, why are you starting a new AD? Why not just add new DCs to what you have?

      Secondly, you should always have more than one DC. Always.

      Finally, if you do actually need to stand up a new infrastructure for some reason, you'll need to create a trust (which you can't do if the domains have the same name) in order to move the mailboxes. Users won't have the same SID in each domain anyway, since the domain SID is derived from the SID of the first DC in the domain, which will be unique.

      Hope that helps.

      Delete
  8. Interesting discussion. I have a question regarding isolated networks. If you know for certain that your domain will never be connected to internet, is it still feasible to use .com vs. .local?

    ReplyDelete
    Replies
    1. I don't see what you would gain from .local in that situation. Can you explain why you think it would be better?

      Delete
    2. If you're not ever going to connect to the Internet all of these rules are totally moot, because you're probably on a classified or sensitive network so it totally doesn't matter. Government networks that run this way usually have access to issue "official" certificates via a delegation from a well-known CA.

      This is a program available to any enterprise that can afford it through most of the "Big boys" of the CA universe, and well worth the money if you want everything to run encrypted and certified via "well-known CA" certificates.

      Delete
  9. Hi Mark !
    After reading your article I am making my mind to create move for domain.com
    Previously we had several domain.com web and application services and locally we have domain.local. Now as a pilot project we are working on domain2.local with the same domain.com externally .But I am facing lots of certificate and SSO issues on implementing 2012 RDS deployment.
    I am thinking to replace this domain2.local with domain.com , Please help on these

    1: should I go for domain.com or abc.domain.com
    2: If we go for abc.domain.com , what advantages we can get on domain.local
    3: If move with abc.domain.com , my domain.com certificates will still work ?

    Please guide me , I will be thankful .

    ReplyDelete
    Replies
    1. 1. abc.domain.com

      2. This whole article is about why you shouldn't use .local. Is there a specific point you'd like clarified?

      3. Sure. Why wouldn't they?

      Delete
  10. Mark,
    Thanks for a great article. Our very small company leases a dedicated remote web server from Hostgator. Initially it was intended for hosting .NET web applications via the internet. We also sell or rather "rent" a massive desktop applications written in VB6 (no flame please ... we are talking about a large vertical industry application that has grown and evolved over 12 years... our newer apps are written in .NET).

    The "web" server was originally provisioned with Plesk control panel and no AD Domain. Some of our customers asked about a "cloud" version of our
    VB6 app. So I installed RDS 2008 on the Windows 2008 R2 server and it worked like a dream. Until I wanted to add another "cloud" customer that needed to see a distinct version of our application in RDweb. I found that I could not accomplish that scenario without full blown AD.

    The server also serves as a registered name server. I was not sure how I could promote the server to DC, as it is and will always be the only domain member (we have our own local AD domain at our office location with members).

    Now I will use a subdomain naming scheme when I elevate the server. You corporate guys will say "buy another server". We employees had to take a 20% pay cut as it is with the bad economy...so don't even mention that.

    Thanks again for the article.

    ReplyDelete
  11. Hello Mr. Marra,
    I have a few questions regarding the installation of server 2008R2 Enterprise as it will ultimately relate to an exchange 2013 installation. I am in a 2013 Exchange class which is why part of these questions are relevant. 1. I have a domain which I will be using for the exchange services. I am limited at this time to only 1 server, if you will and will need to run all the required components on the same box; AD DC IIS Exchange, etc. I realize that the namespace; i.e. domain name is critical for correct operation or at least I think that it is. #2. I have played with the idea of giving the computer name, mail so when resolution will eventuaqlly occur it will look like mail.mydomain.com. Interestingly enough when all is said and done it will look more like mail.mail.domain.com. My box is behind a router/firewall and it is certainly not the best level of security but this is just an exercise for my class. There will be no data on this box. I will be using the outlook anywere process (web - owa only) so I do not think security will be an issue. So.....if I have my host point the mx records to my box without opening up the DNS or creating Name Server alias' will it really matter about the netbois and computer name being the same? Sorry for the long post but I am in a crunch with this class and really need any asistance possible. No one else has got this working so I want to get a heads up...
    Thank you in advance.

    Respectfully,
    Daniel W

    ReplyDelete
    Replies
    1. Your internal presence (the AD name and the server's hostname) have nothing to do with your external web presence, which could be something like mail.example.com. This is why you use UCC certificates with multiple SANs with Exchange. It allows you to secure both the internal naming and public naming of the server.

      Even in this scenario, there's no reason to have your internal AD name overlap with your external name. It's a hard concept to grasp if you're new to DNS.

      Delete
  12. young_teknivor5/09/2013 9:58 PM

    Hi Mark,
    Hi Everybody,
    First, thanks for this great article and discussion.
    I am handling a project migrating an Exchange 2010 Server1 from the Active Directory domain mycompany.local to another Exchange Server 2010 on the new Active Directory domain mycompany.com
    I know that to be able to migrate a exchange database to another server, the exchange organization name should be exactly same but what about the Active Directory domain name ?
    Thanks for sharing your practices.

    ReplyDelete
  13. I just want to point out that you are wrong according to SANS, and they are cooler than you!
    http://www.sans.org/reading-room/whitepapers/win2k/basic-security-issues-active-directory-191
    (page 6)
    "If your organization has a presence on the Internet, the name of your forest root domain
    should be registered. An example would be the SANS Institute, which would use sans.com as a DNS namespace for the Internet, and sans.com would be the namespace for their Active Directory forest root domain"

    ReplyDelete
    Replies
    1. SANS can be (and in this case, is) wrong!

      Delete
  14. Hi Mark,

    First of all, thanks for such a great article. I was looking for alternate UPN suffixes when I found this article.

    I inherited an 8 year old AD with internal name as "company.co" and external domain as "company.org". This month we migrated to Office 365 and got rid of on-premise Exchange 2003. This migration required me to add an alternate UPN suffix so that DirSync could map the users to the cloud AD. So far, so good. Users can log on as "user@company.org" internally as well as on O365.

    Now, the problem was that our internal application servers (in fact all servers) are still named as "server.company.co". So, internally the users on LAN have to access "http://server.company.co" to use the app. But, when coming from outside, they need to access "http://server.company.org" to use the same app (I did an 'A' record on "server" subdomain on my external "company.org" domain DNS records to point to the static public IP on that server).

    I was wondering how could I get rid of this situation as well? That is how I landed on this article while searching.

    May I seek your expert insight/guidance, which could point me in the right direction.

    Should I rename the internal domain? (No on-premise Exchange servers). But, then will the user and computer SIDs change? Will the current user-profile on client computers stop working? What are the pitfalls?

    If I rename the internal domain to say "internal.company.org", then how would I map internal access to apps to "http://server.company.org" instead of "http://server.internal.company.org"?

    Apologies for my limited understanding of AD/DNS internals.

    Thanks / @bhi

    ReplyDelete
    Replies
    1. You can approach this one of two ways - neither rely on you changing your internal namespace despite it being "incorrect"

      1. Configure your network so that internal users can access servers by the external name. If you have something like an ASA and are using the internal and external zone interfaces, you'll have to configure NAT hairpinning.

      2. Create a copy of your company.com zone on your internal DNS servers and replace their public IP addresses with their internal ones.

      Delete
    2. Thanks a lot Mark for taking time out to help me out. Much appreciated.

      I did try the second option suggested by you earlier, but perhaps due to my inadequate knowledge, I couldn't make it work.

      However, option #1 did it for me! We used to have ASA in HA mode earlier, but was de-commissioned long back. Cost-cutting measures by organization :( Got replaced by much cheaper local UTM devices. Surprisingly, these boxes supported mapping of internal name to external one in the NAT config area.

      Works great now. Thank you so much again for pointing me in the right direction.

      Thanks / @bhi

      Delete
  15. Great Article!
    From a .local domain created back in 2000 I would go now for dc.company.com or similar.

    Can I suggest an article for domain users profiles: local profiles vs roaming vs redirected.?

    I prefer redirected profiles, including AppData folder ( I know that so many apps do not understand that but...still good) so what would you recommend with W2012R2?

    ReplyDelete
  16. I have some counter points. Lookup DNS devolution, I have had this bite my users in the past, especially with the wpad bug, that tricky person who registered wpad.com.au had a field day.

    I would also suggest you have a look at your firewall when you have some users out and about, and see the occasional 88, 389 and 135 hit from that users public IP, so possible plain text credentials of users going over the public internet or a hash you can use, perfect for a bad guy to MITM.

    My counter to your trust issue, would be to think about your domain name and ensure it is likely unique; how likely is it that usa.contoso is going to be used by a competitor contoso just bought out, and how likely is it that the contoso TLD gets registered.

    ReplyDelete
    Replies
    1. Strongly disagree here. Neither NTLM not Kerberos send anything in plaintext and they also do not transmit the password hashes. They send a *verifier* that's been salted and hashed one way.

      Also, if you've got DNS devolution problems like you've said, you've mis configured something somewhere. I also don't understand the point you're trying to make in your last paragraph.

      Delete
    2. Just to be clear - verifier or not - if you've got logon/auth traversing the public internet, you've configured something wrong. I was just pointing out that your specific point is flawed, but flawed or not, it should not factor into a properly configured infrastructure at all.

      Delete
  17. I know how NTLM and Kerberos work, however if the NTLM hash is captured over the wire it can then be passed using "pass the hash" to authenticate as that user or the Kerberos packet brute forced to discover the NTLM hash then passed. The NTLM hash can also be thrown at an NTLM rainbow table handy to discover the users plaintext password. You don't even need to be in the middle to do this, just on the same broadcast network say a coffee shop wifi. There are torrents of the NTLM rainbow tables too.

    DNS devolution problems are also pretty widespread, the WPAD bug I am talking about has reared its ugly head at least twice in my career (1999 and 2007); http://technet.microsoft.com/en-us/security/advisory/971888
    But DNS devolution does happen on machines, and a big enough network 10,000+ nodes you will see a few a day, adding to the noise, surely it is better to keep them from being able to devolve to wpad.domain.tld or wpad.tld as has been the case before. Who is to say there isn't another vulnerability of this ilk coming. I know microsoft have given us the ability to turn off devolution, but it hasn't always been there.

    My point on auth traversing a public internet is still a valid one, lets say you set your internal domain to ad.contoso.com, and www.contoso.com and contoso.com are your public facing website, someone takes a laptop home and during the usual login process it attempts to resolved ad.contoso.com, obviously if you have proper split DNS it won't, unless for some reason you have created the subdomain ad.contoso.com or it does devolve to just contoso.com, then your auth will route to your public ip for your website. It can happen.

    My last paragraph is addressing seemingly your only point of contention for why you shouldn't use a non-registerable domain. You say in case you need to setup a trust. I can see this, I had a client many years ago who's previous admin had set the domain as corp.local, they bought another business that just happened to have the domain corp.local... fortunately the other business only had a hundred or so users, but it still meant nuking their domain, no nice easy trust to migrate things. My point is, if you think about your domain a little more and pick one that is unlikely to be used by anyone else this problem is mitigated. If you pick USA.contoso it is not likely that contoso will be put into the new TLD's that are coming out, and unlikely that you buy a company that has the same AD domain in use in their organisation.

    ReplyDelete
    Replies
    1. I think that we are going to have to agree to disagree here. All of the things that you mentioned can be mitigated with proper configuration. Not doing something because there was once a bug that impacted it isn't something that I take into consideration. There have been vulnerabilities and bugs in almost every part of every OS at one time or another. To pick and choose which ones you care about when making these decisions doesn't make sense to me. But, of course, I value feedback and you're certainly entitled to your own opinion. I've cited sources published directly from Microsoft that are clear on this issue. Deviate at your own risk.

      Delete
  18. Hi Mark!

    I have a situation here and i would like our advise. I inherited an infrastructure in which the domain is named abc.local. There are others sites and all are on abc.local domain. We have 3 writable DCs and 3 RODCs. We dont use exchange but Google Apps. We also have another domain in the same company seperated as a Headquarter and on HQ.local. My compnay operates a Hub and Spoke network topology for the abc.local domain. Now based on business needs i am saddled with the task changing the HQ.local domain to abc.local or establish a trust between the 2 separate domains.

    ReplyDelete
    Replies
    1. I think you forgot to ask your question :)

      Delete
  19. I'm sorry Mark. I actually want to know the best way to go about this. Or would it be safer to do decommission existing domain name and do a clean install of an additional DC then deploy to the site?

    ReplyDelete
    Replies
    1. The easiest thing to do is just create a trust. That will take about 5 minutes of your time, whereas doing a domain migration will take significantly longer and has a much more visible impact to operations.

      Delete
  20. I think i forgot to tell you that i have tried doing a trust but it was not successful. Do i have to get all DCs in abc.local to talk to the HQ.local server before the trust is successful?

    We have 3 DCs and 3 RODCs in abc.local domain.

    ReplyDelete
    Replies
    1. Yes. You need DNS resolution between the two environments. The documentation for this is very thorough on TechNet. I'd recommend you look it up and read it if you haven't yet. It is very explicit.

      Delete
  21. Do i need the 3 RODCs too. The last time i tried doing the trust thing i could not get a forest trust in my options.I only had Realm trust and windows domain options.However, two of the Writable domain controllers in abc.local are already talking to HQ.local. Will the trust still be successful if we are able to get the 3rd DC in abc.local to talk to the HQ.local server?

    ReplyDelete
  22. Hi Mark,

    First off, thank you for also stating that it's a bad idea to use a TLD for your internal domain as well as your internet facing TLD. Also, this is something i've seen and even from my Microsoft Certification i recall adding a .local is preferred as opposed to a .com, .org, .net, anything that could be registered publicly. However, i'm curious because a .local does seem to add that additional security by not allowing the internal domain to be published publicly AND authentication to any resource outside (by VPN or application) would require that .local or .whatever (if you're using SPN)... but most would probably force the user to use the NetBios XXX/username for authentication.

    Now, like you said all this can be avoided and secured with proper implementation, i get that.. it also seems to me the argument here pertains to only scenarios when multiple domains (internal) have the same name because you can't trust contosso.local with contosso.local... and i can see that being a nightmare with administrating a migration. I'm curious on your thoughts of security that it might add or take away...

    For instance, if i register contosso.org, and i name my internal domain ad.contosso.org, even though the TLD is unique, contosso.org is registered publicly. Does that pose any threat because i have that part in my internal domain name as well?

    Also what about a scenario where public domains don't match with internal domain names? And i'm not talking about contosso.com to contosso.local... what if i have my internal domain called by a totally different domain name? For example, my internal domain is JDOE.COM, but my external site is registered as JOHNDOE.COM. Is this still the same issue here as the .local even if JDOE.COM could be registered publicly?

    ReplyDelete
    Replies
    1. > However, i'm curious because a .local does seem to add that additional security by not allowing the internal domain to be published publicly

      It doesn't add any security. You have to actively try and expose your AD's DNS zones to the internet.

      > AND authentication to any resource outside (by VPN or application) would require that .local or .whatever (if you're using SPN)... but most would probably force the user to use the NetBios XXX/username for authentication.

      Not sure what you mean by SPN here, SPNs are related to Kerberos auth and have little to do with AD domain naming. Also, relying on NetBIOS for name resolution is bad news.

      > it also seems to me the argument here pertains to only scenarios when multiple domains (internal) have the same name because you can't trust contosso.local with contosso.local.

      Not just internal, it's quite common for companies that are partners to have private connectivity with a trust between them. This applies to that situation as well.

      > and i can see that being a nightmare with administrating a migration. I'm curious on your thoughts of security that it might add or take away...

      Again, using .local or any other made up TLD has nothing to do with security. At all. Ever.

      > For instance, if i register contosso.org, and i name my internal domain ad.contosso.org, even though the TLD is unique, contosso.org is registered publicly. Does that pose any threat because i have that part in my internal domain name as well?

      No. Only if you go out of your way to misconfigure your DNS.

      >
      Also what about a scenario where public domains don't match with internal domain names? And i'm not talking about contosso.com to contosso.local... what if i have my internal domain called by a totally different domain name? For example, my internal domain is JDOE.COM, but my external site is registered as JOHNDOE.COM. Is this still the same issue here as the .local even if JDOE.COM could be registered publicly?

      If you do this, you should register jdoe.com. It's common for a company to be example.com publicly and example.net for their internal AD network. This is fine as well, same idea roughly. Just make sure you register the domain name you use internally.

      Delete
    2. I also think you're misunderstanding that TLD means. A TLD is strictly the top-level domain (org, com, net).

      Delete
    3. Err... i didn't mean SPNs, i meant UPNs: User Principal Names. Instead of authenticating by domain\username you're authenticating with username@domain.com (or username@domain.local according to my question). But you pretty much answered my question regarding security to a resource thats accessible from the outside that authenticates through AD. I see that it wouldn't matter if it's a .com or a .local. Even though most applications will automatically apply the UPN for authentication or NETBios name to the user account when authenticating. Thanks.

      Delete
  23. so let’s say we call our domain ad.company.com. our internal servers would then be server1.ad.company.com, server2.ad.company.com etc? and we would create similar entries on our external DNS, so users can always enter the same URL to get to the same site regardless of whether they were internal or external… but what about wildcard SSLs? They only work for one level of subdomain… so right now we are able to use a wildcard SSL to cover server1.company.com and server2.company.com etc. Wouldn’t naming our domain ad.company.com prevent us from being able to use wildcard certs for our internal URLs? (unless we keep internal DNS records for company.com but then we are back to split domain, which was what we were trying to avoid in the first place?)

    ReplyDelete
    Replies
    1. You don't want to create an "ad" zone on your public DNS. You can configure your network to not have hairpinning issues so that internal clients can access public-facing resources on their public IP. Then you don't need split DNS. If you can't do this, split-DNS is the lesser of two evils here.

      Delete
  24. Hi Mark,
    very, very interesting articles.
    May I ask you a question about my situation at a customer?
    I'll try to explain:
    The official external domain is company.at, mail-gw in DMZ is mail.company.at.
    The internal domain is also company.at, the Netbios-name is company (same as real name of the company).
    I have two locations, on each a domain-controller (W2K8 R2), FQDN of the Servers are location1.company.at and location2.company.at. Both sides are connected through VPN (site-to-site). All users authenticate the same way on both sites.
    The internal Exchange-Server is a W2K3-server with Exchange 2003.
    All users in AD identify through netbios-name "company\user1" (on both sites)
    Now I have the situation, that the company changed the name to newcompanyname.
    What users there ask me:
    Is it possible to change the names (AD, Netbios) from company.at (AD) and company (Netbios) to newcompanyname.at (AD) and newcompany (Netbios)?
    The external newcompanyname.at is already set up and works with additional address-space in Exchange (additional default-mailaddresses user1@newcompanyname.at).
    Actually I didn't set up anything in AD or DNS with "newcompanyname.at or newcompanyname".
    At location1 (Headquarter, Financing, Sales) I have app. 30 client-pc's (and 6 Servers, one of them the W2K3-Exchange 2003, another SQL2005 on W2K8 R2), at location2 (production, stock, ...) I have app. 50 client-pc's (and 7 servers, one of them W2K3-Terminalserver, another also SQL2005 on W2K8 R2). I don't want to think about lot of work on setting up newcompanyname.at parallel to existing and moving users/pc's/servers to the new AD-/Netbios-Domainname. Is there a way to Change ?
    Thanks in advance for your appreciated advice.

    Greetings from Austria,
    Andy

    ReplyDelete
  25. I see your point.. but...

    Biggest problem I see when naming your internal domain the same as your public domain, is that your public domain name can change much easier and more often. This can leave you in a pinch down the road when your internal domain name is not relevant (or worse, hated).

    For example: I register a public domain fruitcakes.com. I decide to name my new AD ad.fruitcakes.com. Sometime later my company restructures and we don't sell fruitcakes any more. Now we sell hammers, and we hate fruitcakes. So we register hammers.com. But my internal domain space is fruitcakes.com .. and will be forever unless I migrate to a new AD. No easy fix there.

    However, if my internal domain name was corp.local, my CEO wouldn't harass me every day in the hallway about having that old name pop up from time to time. He really hates fruitcakes now.

    Another unpleasantry would be if the public domain name was very long. Like: fortheloveofgiganticfruitcakeswithnuts.com.
    fc.local sure is easier to those managing AD.

    Or what if my company name doesn't have anything do with my public domain name. If I register the domain freefruitcakes.com as the face of my company, but my company name is Microsoft, that doesn't make much sense.

    Or what if I'm a cloud services provider in multi-tenant situation. I have multiple companies managed under the same domain or multiple domains. Using a public name would not be possible.

    Or what if I own multiple public domain names. Which should I choose? Whatever I choose, I would have to keep renewing forever even if I hate the name now to make sure some other company doesn't snatch it up and name their AD the same as mine.

    As for the internal server SSL problem, you can usually use an internal CA.

    Finally, the odds are probably very low that your company merges with another company that uses the same internal AD name. Especially if both companies use their public domain name but just replace .com, .net, or whatever with .local. In fact, it would literally have to be two companies that own the same public name, but one owns .com and the other owns .net. Very rare.

    Oh. And nothing prevents me from naming my AD the same as yours, despite your best efforts to be unique.

    ReplyDelete
    Replies
    1. Mark, care to respond to this post? This is a very valid reason. We are now in a situation where our domain name does not represent our business.
      We are being harassed about it.
      Therefor with our new domain name we want to choose something universal. So if the organization name would change in the future we have no issues there.

      We host all our services within our own domain (have our own CA as well), so what exactly would be my benefit of choosing a public domain name?

      Besides not going to get a SSL certificate and maybe some bonjour issues I'm not reading that many strong arguments.

      Delete
    2. I think this falls under another best practice that states you don't name your domain after a product line. Your domain name should be well thought out and something that will age well. If you name your domain fruitcake.com, then well... you pretty much deserve to be harassed daily by the CEO. Better yet, you deserved to be fired. Your domain name doesn't need to be the same as your public web names. The only thing recommendation I see being made is that you also register your domain name so that it's guaranteed to be unique.

      Delete
  26. First Many thanks for clarifying lot of concepts with DNS.
    One question if I may ask. which you probably answered but will like to clarify as currently doing it in prod environment...
    Existing - Scenario : SMB Location with Windows 2003 Server AD/DC - DNS is messed up.
    Current DNS setting on the windows 2003 server is DNS Server IP address of ISP. User workstation have ISP DNS too ..
    Planned work going on : Building Windows 2012 r2 . AD / DNS.. Point user to IP address of the Win 2012 r2 server. Have root hints enabled by adding ISP IP addresses.

    Question : when building AD DNS win2012 r2 you get prompted to create NEW FOREST then fill in Root domain name : can this root domain be named as i.e AD.company.com,
    Internal.company.com - where company.com is real registered domain name with website running as company.com and then do the AD NETBIOS name as i.e " ABCD " so when user logon it will be ABCD\username .. Am I on the right track here..

    Your help to answer this and if I am doing this right is greatly appreciated. Regards ..

    ReplyDelete
  27. So if I have an internet domain called (for example) happyservice.com and an internal domain called happy.local, am I better off renaming my intranet domain to internal.happyservice.com or is it just as well to use happy.com? I like the subdomain idea, seems it would be better when you set up your UCC certificate, but internal.happyservice.com is a lot more to type into a username (internal.happyservice\username) than happy\username. Does it make any difference? Thx!

    ReplyDelete
  28. Hello Mark,

    thans for this article.

    I'm going to install a new AD. abc.de is registered and has a website hosted. I'd go for ad.abc.de now. Will there be any trouble if the domain provider resolves all subdomains (even them which do not exist) to the IP of the webserver? There is no Exchange, nor any services which need to be accessed from outside.

    Thanks in advance and sorry for my maybe crappy english ;)

    Greetings from Germany.

    Alfred

    ReplyDelete
    Replies
    1. Nope. No problem with that! Good luck!

      Delete
    2. Thank you so much for this super-fast response!

      -Alfred

      Delete
    3. Hello again,

      I'm currently testing what I wrote at 7/08/14.
      I got myself "alfred.de" (as example ;)) registered and my AD's name is "ad.alfred.de". I'm using 2012 R2.

      In DNS I got a forwarding to my local ADSL router.
      When I now do a nslookup on "Google.de" I always get the response:

      Name: Google.de.ad.alfred.de
      Adresse:

      Why is that and how can I turn it off?
      Thanks in advance! Still learning, so sorry for stupid questions.

      Delete
  29. Interesting that nobody said anything about that on February 20, 2013, .local is officially has been approved... http://en.wikipedia.org/wiki/.local

    You are all talking about 6-8 year old standards here....

    I think .local could be used now with no problem!

    ReplyDelete
    Replies
    1. Did you bother to read the article that you linked to? .local is reserved for use in multicast DNS. That's even more of a reason NOT to use it.

      Delete
  30. Hello,

    You wouldn't happen to have a guide (or know of a guide) to setup a new domain using server 2012r2 with a subdomain of a registered TLD do you? All that I've been able to find are guides explaining either adding server 2012r2 to existing domains, or setting up a new domain using domain.local (etc).

    Thanks,
    Dustin

    ReplyDelete
    Replies
    1. I posted a video on this very blog about how to do just that.

      Delete
  31. Thank you. Nice article.
    Just 1 question.
    If I install new domain aaa.contoso.com I should select option "root domain in new forest".

    So aaa.contoso.com has nothing to do with my contoso.com registered with Godaddy.
    Contoso.com is not a parent for aaa.contoso.com.

    Correct?

    Thank you.

    ReplyDelete
  32. I just recently inherited an environment with this exact .local ad domain issue. I am working on changing it but as you know it is quite a project.

    In the mean time I am attempting to set up an additional mail server on a different domain on the same lan. The problem I am encountering is that when a message is sent from my new mail server to user@company.net it is unable to see it because the domain is company.local. This is causing the message to come in over our public address. How can I set up the local DNS server on company.local to recognize company.net look-ups and forward them to its mail server keeping everything internal...

    I apologize if what I am saying is unclear. It is a little difficult for me to explain. I appreciate any insight you can provide.

    ReplyDelete
  33. There's one problem. Microsoft also says you shouldn't have a domain name of more than 15 characters, for whatever reason. That's an stupid constraint, since there are LOTS of domain names with more than 15 characters including the ".com" (that's just 11 characters worth of domain name, ridiculous!) so if I should use a real domain name and mine is longer than 11 characters (plus the dot com), what do I do then? Don't tell me I have to register a short domain name just for this!

    ReplyDelete
    Replies
    1. You're getting confused with two different things. The domain's NETBIOS name cannot exceed 15 characters. The DNS FQDN of the domain is constrained only by the character limit of DNS itself.

      Delete
  34. I just found an updated Technet Article that is more current than the 2000 article you referenced above.
    See http://social.technet.microsoft.com/wiki/contents/articles/17974.active-directory-domain-naming-considerations.aspx
    It says that you need to have a registered domain name in order to interact with Azure.
    It also EXPLICITLY says not to use .local, .example, .test, among others since these are all actually "IANA Special-Use Domain name" reserved names.

    ReplyDelete
  35. Dear Mark,

    I'm working with a customer to implement a complete new domain. The website is hosted externally and the domain is abc.com.ar. My idea is to name the domain as ad.abc.com.ar . Could you please confirm me if that is a good choice ?

    Many Thanks !!
    Best Regards
    Franco A Nicosia

    ReplyDelete
  36. Mark,
    I just found this blog, while fighting with a .local network, regarding a future problem with obtaining a UCC certificate. I have one domain controller Server 2008R2 Std (AD, FSMO roles, DHCP, ...) that is called abc.domain.local. The client has a domain name registered as domain.com. I just installed Exchange 2013sp1 on a member server (2012R2 Std) called xyz.domain.local. The network has about 40 computers/users. What should I do? I was thinking:
    1. uninstall Exchange 2013SP1, since it is not in production yet
    2. rename domain to ad.domain.com
    3. install Exchange again

    Is this a correct approach?
    Thank you for your input.

    ReplyDelete
  37. Hi Mark,
    First of all I am glad to see the discussion still active. I am a consultant charged with restructuring AD DS for a conglomerate which has acquired several companies, and to bring them in to a single forest each with their own disjointed name space, and a single Exchange 2013 Org. to serve all domains in the forest. My plan is to have a root domain "ad.xyz" per your advice, for administration of the forest; and all subsequent domains having disjointed namespaces. However, the 2012r2 DC's in the root domain will be authoritative DNS servers for all domains configured with FLZ's. I have it set up that way in an OOB lab and it all works great. The main reason they want this setup is to save on the cost of Exchange Server Licensing. My question is: Is there any reason I couldn't use a .net for all the domains in the forest with a .com as my TLD?

    Thanks

    ReplyDelete
  38. Thanks for the great article.

    I am reading this because our AD domain name is not registered by our company. The AD domain name is based on the name of our company, but is not the same. It's been setup that way since about 2000.

    The domain name has been for sale for years, and they want > $15k to buy it (strange to me, because it doesn't seem like a name anyone would want.) So buying the name is out of the question.

    This has never created any problems, but I am seriously considering doing an AD rename to something that we can register.

    I am not looking forward to this process. We have two sites, 3 DCs, about 150 workstations, and about 40 Macs bound to AD as well (what in the world happens to them during a domain rename?)

    Is it worth renaming the domain to something that we can register (or to a sub-domain of our web domain)? What are the reasons to do so? What are the risks of continuing to use an internal AD domain name registered elsewhere on the Internet?

    Thanks.

    ReplyDelete
  39. Dear Mark, I have a domain name say xyz.com but netbios suggested during domain creation was xyz0. I used that. and now my users have xyz0\firstname as usernames. I would like to have an external internet facing domain, how can I register my domain?

    ReplyDelete
  40. Dear Mark,

    I am testing a roll-out. I followed best practices by naming active directory sub.mydomain.com where mydomain.com is registered.

    Next I installed exchange 2013 and this is where my confusion starts. Email addresses are user@sub.mydomain.com. What would I do to get email addresses like user@mydomain.com.

    It would be preferable to make this the default setting, as I would rather avoid having to run a rename script every time I add a new user.

    I didn’t mention, buy mine is a simple on-premise install with single exchange server with mailbox & client access roles – no edge server.

    ReplyDelete
    Replies
    1. Tortoise, when it comes to exchange and the email addresses, you shouldn't have to worry about doing anything with the UPN suffixes. Addresses in Exchange are determined by the email address policy. For instance our organization's domain and forest are denoted by (ex: contosso.org), while our email addresses to the outside world are ex: (supermelon.com). Now Exchange can take the UPN, but through the address policy you can tell it which domain names you want.. as long as you own that name and it is registered. which by your post it is. User UPN names will be still user@ad.mydomain.com while Exchange can give them an email address of user@mydomain.com.

      Delete
  41. First you have to add all dns suffixes in ADSI, then add the domains to allowed domains in exchange. Then you will be able to have domain specific email addresses.

    ReplyDelete
    Replies
    1. The correct way to add UPN suffixes is through the AD Domain and Trusts console (or through PowerShell) not directly through ADSI Edit.

      Delete
  42. Mark,
    Great article. I'm new to AD and building DC's, and wish I'd have seen this a week ago! I just finished building Win Server 2012 R3 Ess for a friend with a small business. The install defaulted to .local so I went with it not knowing. So far I only have one of his 4 workstations joined to the domain, and a company specific file share on the server they are using in a production mode. Since this is new and small... realistically how much work would it be to rename the domain (No Exchange) for an AD greenhorn?

    Thanks
    Steve

    ReplyDelete
  43. We just ran into yet another reason to never use fake TLDs. We just enabled DNSSEC validation on our recursive servers. Even with forwarder records, our ".local" domains simply stopped resolving. After some head scratching, we realized it had to be the DNSSEC validation process causing it. That is because the recursive server will insist on going to the root to validate the DNSSEC chain from the root to .local, and then to xyz.local even though we had an explicit forwarder statement for the domain. As there is no such TLD, the first level validation fails... and subsequently all resolution for any .local domain fails (or anything that doesn't adhere to an officially designated TLD).

    I bodged this by creating the local hierarchy on my recursive servers so that any xyz.local domains get properly delegated (and now do not need to reference the root servers), but that is just a stop-gap measure. It's not a truly valid solution to the issue.

    ReplyDelete
  44. I have a sbs2008 server on the blink and it has the .local on it. So I have 2 new servers with Windows 2012 r2 essentials and win 2012 r2 standard exchange 2013 planned to replace the sbs 2008 but need to migrate exchange and folders and mailboxes to new servers.
    So .local needs to change to server.abc.net and mail.abc.net but I don't know how to migrate the sbs if I change the domain? What do you suggest?
    Thanks

    ReplyDelete
  45. I have a sbs2008 server on the blink and purchased 2 servers installing win 2102 r2 essentials and win 2012 r2 standard with exchange 2013. I just found out about the .local as you have been discussing in this blog. How would you approach setting the the new servers up as I don't know how to migrate sbs 2008 with the .local domain to the new servers to server1.abc.net.
    How would you do this? Nothing on the microsoft tech net could i find to support this change.
    Thanks

    ReplyDelete
  46. I have a AD DC server with a DNS and DHCP server set up, and i would like to connect it to 2 client pcs. The error i get is "an active directory domain controller for the domain 'domainhere' could not be contacted.

    ReplyDelete
    Replies
    1. When trying to join the PCs, add the AD server's IP address to the preferred list of DNS servers in each PCs network config and you should not see this error.

      Delete
  47. Hi Mark,

    This article has nailed exactly where we shouldn’t be. We just outsourced our migration (no-one in our company is very cluey when it comes to the MS world) from an old SBS machine to Exchange 2013 and Windows Server 2012 R2 for the DC’s. Unfortunately the outsourced company have migrated us to a .local domain (which I now see as being a clear mistake, particularly in light of the changes by registered CA's).

    This is already causing us grief since we use a web service for email filtering. This service needs to to talk with our AD in order to authenticate users. Unfortunately, the filtering service will not accept self-signed SSL certificates (and CA’s apparently no longer sell certs for domains that are not publicly resolvable). This leaves the clear text option for LDAP, or nothing.

    As I understand it, we can't do a domain rename due to the Exchange server, hence, we should build an entirely new AD domain (as a sub-domain of our existing public domain) and then migrate all the machines and mailboxes in a cross-forest migration.

    Can we build the new domain on the DC's in parallel with the currently operational production domain (company.local) and then migrate everything over to the new sub domain (internal.company.com.au)?

    Can you see any alternative to this domain migration, given that we need to have the machines talking securely to at least one web service that only accepts certs issued by registered CA’s?

    Could we proxy LDAP and similar requests through a machine we setup on our public domain (but living behind the firewall) and set the public domain as being trusted by the machines in the .local domain?
    Is that a really bad idea from a security point of view? (all the machines involved are secured behind a firewall but even so, it seems risky to me to tell the DC's to trust the public domain....)

    Any thoughts would be appreciated, and thanks for the great article!

    ReplyDelete
  48. Hello Mark,

    very informative and well written.

    Could you please clarify the following sentence "The correct way to name an Active Directory domain is to create a subdomain that is the delegation of a parent domain that you have registered and have control over." From what I understood we should never create a delegation from the external to internal DNS Server to keep the local DNS data private. I'm not an native speaker, just looking for confirmation.

    thank you

    Adam

    ReplyDelete
  49. Wow! Just sheer GREAT advice!!! Thanks out to Microsoft for screwing so many over with .local as the default when using the configuration wizard of windows server essentials 2012. :(

    ReplyDelete
  50. Since .local is now a reserved gTLD by ICANN, is it now OK to use .local in your Active Directory name?

    http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf

    ReplyDelete
    Replies
    1. No, it's reserved for an entirely different purpose. If anything, it's worse to use it now.

      Delete
  51. Hi Mark,
    Excellent article and insight to the situation I just inherited. I'm a one man show and our small network is comprised of VM 5.5 running 3 servers (2 are Serv. 2012 R2 & 1 is Serv. 2012) and one physical server running Serv. 2003 SBS. The company is growing and before we get to that "too big" thresh hold I would like to change the domain setup and remove the .Local. We are now using O365 so we have no Exchange and one of the 2012 R2 Vm's is slated to become the new DC. What can I expect if I change the domain and remove the .Local? What are the steps that would need to take for this as well?

    Thanks. Russ

    ReplyDelete
  52. When someone tells you in a sarcastic tone, "there are no stupid questions.", they should be pointed to this web site. Mark you hit several nails on the head and punished more than one troll. You deserve an award for having more patience than the entire industry of IT put together. It's no wonder to me that pay has dropped when this is the calibre of support companies must put up with. Kudos to you Mark for cutting through the bologna.

    ReplyDelete
    Replies
    1. Actually, Microsoft used to recommend .local, back in the Windows NT 5.0 days. Yes, some of us have been on the bleeding edge, and sometimes you do.

      Delete
  53. Hello Mark,
    Single Windows Server 2012 Domain Controller with 10 Windows 7/10 functioning workstations that have joined the domain and functioning.
    One of the workstations suddenly started to given an error message when logging in --- "The trust relationship between this domain and the workstation has failed.....". Since we don't have the local administrator password we may be dead in the water and this may require reinstalling the O/S on this workstation. This I can handle...
    BUT...
    So, I decided to take a new workstation and tried joining it to the Domain but a couple of screens into the wizard, I get the following error message -- "The specified domain does not exist or could not be contacted".
    I did ipconfig /all and saw the workstation received an IP address from DHCP and that the workstation does point to the DNS server on the DC.
    Is there something specific I can check to look for the problem...

    ReplyDelete
  54. Mark,

    I just recently started working for a company that uses their external domain name for their internal AD domain as well. My first job is to do a major revamp of their network to help them become HIPAA compliant, and this domain name is one of the big compliance issues they're encountering, as it is a security risk.

    We're getting all new servers, and will be migrating to a new domain name to move away from this. However, I'm curious if it's possible for me to use best practice here given the situation. We have Exchange 2010, and will be moving to Exchange 2016, so we're doing a cross-forest migration of that anyway.

    My issue is whether or not I can create a sub-domain (for example, we are company.org and I want to use internal.company.org) and set up the necessary forest trust for this transfer, or if a forest trust will fail because the new domain would technically be seen as part of the existing domain.

    I'd like to resolve that question before setting up the new domain, so that I can avoid this issue if possible. Any suggestions?

    ReplyDelete
  55. Mark,

    I have an existing domain I've inherited using its public domain name for the internal domain as well. (For this example, say company.org)

    We will be migrating to a new domain name to ensure HIPAA compliance, as this practice can cause security issues. However, because we need to migrate e-mail across the domain, I need to ensure I can set up a forest trust.

    Will making the new domain internal.company.org cause forest trusts to fail, or will they work as intended even though that's technically a sub-domain of the current domain name? (I've not run into this particular situation before, thankfully.)

    ReplyDelete
  56. I've used domain.local on several domains across a few companies over the past 15 years now and never have I run into the issues described in this article.

    1. SSL not a problem, I run my own CA so why would I need to ever or want to ever spend money on a certificate that is for internal resources.

    2. Exchange, not a problem if you understand split DNS and how to create additional forward lookup zones if needed.

    3. I never have to worry about a domain name existing as mine since I use companyname.local.

    4. look at all the posts where people followed other guidance and now have to cleanup since they used the wrong domain name.

    5. I never have issues with domain name resolution, just setup the forwarders on the dc, .local resolves internally, everything else is external... simple.

    I will continue to use .local and it will continue to work for me. Have fun folks.

    ReplyDelete
  57. DONT
    FUCKING
    USE
    IT

    Linux also reserves .local for mDNS. The way some distributions are configured by the operating system does not even try to call the DNS resolver for .local domains. I'm ripping my hairs off trying to disable and/or uninstall the mDNS resolver from 900+ POS machines. Please don't.

    ReplyDelete
  58. ಠ╭╮ಠ

    I've been doing this all my life. Thanks for making me feel stupid. I mean, JEEZERS!!! I just realized that I've also made dozens of other people who listen to my advice stupid as well. I should have realized it sooner. Think about anybody who works in a Microsoft environment. Sure, you see "contoso" all over help documents and whatnot, but have you ever, I mean EVER seen a Microsoft document or internal memo or anything at all with "microsoft.local" on it? That should have tipped me off, but I'm stupid. So stupid.

    Gosh.

    ReplyDelete
  59. Hi Mark

    Good article, I have set up a complete AD and exchange environment using your advice.
    e.g. abc.companyname.com

    This is a Server 2012/Exchange 2013 environment

    its still pre-production and all seems to wok OK.

    My only concern is external users of Outlook that use Outlook anywhere or Outlook HTTPS over RPC

    I cannot get my head around how the certificate will work and if indeed it will
    The accepted domain for exchange is companyname.com, without the subdomain prefix
    I know this will accept email

    I am a fan of self-signed certificates and these have worked well for me in the past. If I change my Certificate in Exchange to the published remote.domain.com internal users stop working.

    Can you offer any guidance please?

    Thanks PaulS

    ReplyDelete
  60. Hi Mark, i think you're missing a few things. I don't see any reasons why I can't simply use .local .corp as a internal root ad top level domain name. What If I have a single forest single domain architecture and dividing AD based on location via OUs. It does make sense to have something like comapny.corp for the root ad domain and internal dns records like cz.company.corp, at.company.corp, com.company.corp instead of com.company.com. ??? And internal users are usually visiting company websites through internal dns records, that's what split dns is about. I think this post is completely useless, if somebody use .local tld it's for a reason !!!

    ReplyDelete
    Replies
    1. It seems you've missed almost the entire point of everything I've said.

      1. I'm talking about single domain forests, which is the preferred architecture in almost all cases. Empty forest roots were. A bad idea of the past.

      2. If you don't use split DNS, you don't need to maintain internal DNS records for internal sites. If your public DNS is company.com, but your AD is ad.company.com, you don't need to keep records for company.com internally and externally. It's fewer DNS records to curate, which is a win for everyone.

      3. If someone uses .local, it's because they think there is a reason, but they don't actually know what it is. I have yet to hear a single good reason to do it other than "I always have" which is never a good reason to do anything.

      If you disagree, I'd love to here specific technical points. As it is, your current post adds very little to the conversation.

      Delete
  61. Great post. I inherited an SBS 2003 server many years ago and even back then the sys admin had the sense not to use .local

    ReplyDelete
  62. Hi Mark, I have named my AD ad.company.com and now I try to configure Exchange 2016 and my host is named mta.ad.company.com Now I will have two addresses that will point to autodiscover servicess mail.company.com for external and mta.ad.company.com for internal users. I would like to users only have to know a single namespace (e.g., mail.company.com) to access their data, regardless of where they are connecting. Naming my domain this way will enable me to avoid split brain DNS, but the exchange team states : "Since the release of Exchange 2007, the recommendation is to deploy a split-brain DNS infrastructure for the Internet-based client namespaces." http://blogs.technet.com/b/exchange/archive/2014/02/28/namespace-planning-in-exchange-2013.aspx. My issue is how to keep configuration simple for my users.

    Thanks !

    ReplyDelete
    Replies
    1. If you want, you can split-brain by creating a company.com zone in your AD DNS. You don't have to name your AD "company.com" to do this. Or you can just have the users use the public "company.com" zone to connect to the mail infrastructure.

      Delete
  63. This comment has been removed by the author.

    ReplyDelete
  64. Hi Mark ,

    we are going to install new domain .
    we have site internally and public site and email that hosted locally .
    we also need to have SSO ,
    and our email is linux base server .
    do you suggest use best practice ?
    if yes please suggest the plan .

    thanks .

    ReplyDelete
  65. Hello Mark,
    First thanks for the article and you should be commended on your points and its clarity. I have to admit I implemented several SBS environments and have used the .local as suggested by the wizards. Each of them are SBS 2003, 2008, or 2011 with using Exchange and SharePoint's companyweb which made the SBS model very cost effective (even it is not recommended) but Microsoft provide the suggestion of the .local so I thought it made sense (at the time) and also Microsoft throttled down the SBS implementation so it could all reside on the same box/server.

    So, now SBS is no longer available or at least not worth purchasing due to its duration for support.

    Only recently has it caused a complication when getting certificates. Which caused me to do some reach and I found your article and I think that I have painted myself and the server in to a corner. In the past, I booted the new server with a migration answer file but that was SBS old to SBS new and then complete the rest of the migration process.

    This is nothing that I have to do soon as I merely making plans due to your .local article and I ask the following per your experience in the .local to .edu rename and migrate in comments. Also, the existing environments are less than 20 computers so I was not completely worried about the disjoining computers and joining to the new domain. But, wished to avoid the renaming of the domain due to Exchange 2007 and 2010 limitations and exporting mailbox items to .pst and importing to the newly created mailbox.

    When upgrading these clients from SBS 20xx to Server 2012 or 2016 and using HyperV for a virtual machine for the AD and another virtual machine for Exchange, do you think I will able to use an answer file technique per (https://technet.microsoft.com/en-us/library/gg563801.aspx) or ADMT to go from domainname.local to corp.domainname.com and migrate users and mailboxes as described in the following article http://blogs.technet.com/b/sbs/archive/2009/05/01/sbs-2003-to-sbs-2008-migration-to-a-different-domain-name.aspx? Or do you have another suggestion?

    Your recommendation and opinion valued and THANK YOU in advance!! Anonymously as to not call attention to my poor decision of using .local.

    ReplyDelete
  66. I named my AD to x.y.com.sb and my exchange server pointing to y.com.sb - how can I set my AD to show my fQDN when creating new email users? currently when I want to create new users it will give users - john.smith@x.y.com.sb but I want users to be like - john.smith@y.com.sb

    ReplyDelete
    Replies
    1. You're talking about a user principal name and it is configurable on a per-user basis.

      Delete
  67. I totally get your point, Mark, but creating a dependency between a public web domain and your AD domain is not a great idea when considering mergers or company name changes. Like the example of the fruitcakes in one of the comments. On the other hand, when using a more generic name like insurance.local or finance.local, does not need to be renamed when company changes it's name, but could get messy when the company merges with another financial corporation, which thought insurance.local was a good idea.

    Great discussion though!

    I think registering a more generic public domain name which relates to your company's activities can be a good way to go.

    ReplyDelete
    Replies
    1. Great examples, but by the same token, companies change lines of business as well. I have a customer who is in the health device field, but started as a jet rental company (not joking) so they log in with something like JETSETTER\user and they're not in the medical space.

      Just goes to show that you can't predict the future, you can only plan for best practices of today :)

      Delete