2

Best practice all over the internet would have you believe that the sky will fall on your head if you register company.com as your public domain name and then use that same domain name in Active Directory here, and here for example. Yet in all those dire warnings, the only concrete reason I have ever seen is that users on internal DNS must type www.company.com in order to access the external website instead of just company.com. MS has hinted at some "future compatibility" that will be broken but this wisdom has been around since at least server 2008 judging from forum posts I've read on the subject.

For some reason, it seems that many of these warnings are also assuming that if you are using the same DNS name for AD, that you are exposing your AD zone to the internet and allowing all internal names to be resolved externally. That is most definitely not what I'm asking about.

Let's say I ignore this advice and use company.com as my AD name. Potential issues are:

  • Typing company.com in a web browser will try to go to a domain controller instead of www.company.com. Not even remotely an issue.

  • Internal names are all still internal. There is no dc01.company.com A record in our internet accessible zone file. External names like www, vpn, mail are all unrelated to our internal DNS.

  • This TechNet article warns of things like "less flexible, less automated DNS operations" and "instable[sic] operations and sub-optimal performance" but offers no details or reasons.

Let's say I follow this advice that so many people have taken to heart and use ad.company.com. I now have to deal with the following issues:

  • have a different NETBIOS name that does not match the domain name. That doesn't really bother me but it's something you have to think of.

  • The default UPN suffix when creating users in ADUC is @ad.company.com. The user's UPN suffix should match their email address so anyone who creates users has to know which UPN suffix to use and that it is not the default. One more thing to forget.

  • AD still requires ad.company.com DNS zone to run. If I want computers to be resolvable as computer.company.com I have to manage another DNS zone, as well as the DNS registration suffix and search suffix.

All this so people don't have to type "www" (which is so far from an actual problem for me it's not even on my radar)?

What is the actual danger of using the publicly registered domain name as the AD domain name?

Bonus question: What is the purpose of having company.com point to a domain controller in the first place when AD has a whole _msdcs namespace for AD related information?

succulent_headcrab
  • 387
  • 2
  • 5
  • 12

2 Answers2

4

have a different NETBIOS name that does not match the domain name. That doesn't really bother me but it's something you have to think of.

Not at all, when creating a domain, you are definitely able to specify the NetBIOS name of the domain.

The default UPN suffix when creating users in ADUC is @ad.company.com. The user's UPN suffix should match their email address so anyone who creates users has to know which UPN suffix to use and that it is not the default. One more thing to forget.

If not there already, one should be rapidly approaching the time of automated, or scripted on-boarding of new accounts. This will alleviate your concerns about what might happen if a user was created with the wrong UPN suffix.

Alternatively, it is a trivial matter to simply have a nightly clean up task that looks for user accounts with the incorrect UPN suffix and updates accordingly.

All this so people don't have to type "www" (which is so far from an actual problem for me it's not even on my radar)?

No; I believe the purpose is to avoid Split-brain DNS where two different DNS infrastructures are responsible for the same namespace. Though, the fact that it is not a problem for you now does not mean that it will not become a problem in the future for you or your successors - especialy since this is a best practice, so solution vendors may start to design solutions with that in mind.

What is the actual danger of using the publicly registered domain name as the AD domain name?

I don't know that there is a huge "danger" (certainly not one that you would view as a danger - since you have not referenced any of the other potential concerns in the article); however, it has been my experience that when one is presented with a generally accepted (and actual - as defined by the vendor) "Best Practice" one does not deviate from the best practice without a valid business or technical reason.

Edit: For what its worth - in the most respectful way possible - I do not see any valid business or technical reason presented that would justify why Best Practices should be ignored. So, I would suggest to be kind to your employer and your successors - and start with an environment that is aligned with best practices.

Semicolon
  • 1,646
  • 7
  • 7
  • 1
    Especially best practice related to AD is changing with the release so "successors" would be confused anyway in case of upgrade and "new best practice" (like internal /.local/, public, subdomain,...). In general I would say the best practices linked to the specific release are based on some set of "cooperating" options. In case you really know the impact of changes feel free to set it up your own way. In case you don't have so deep technical knowledge the following best practices could help you with "future challenges" you have not idea about so far... – Kamil J Sep 27 '19 at 21:29
  • I'm not sure what you're getting at in regards to best practices changing with the release. At least not in this case - using a subdomain of the publicly registered domain as the root of an AD forest has been either recommended or a best practice for well over 10 years. – Semicolon Sep 27 '19 at 21:40
  • AD si relatively "young" so public domain was already involved as it is build up on DNS but evolution came from domains where I remember some time ago the .local domain was preferred - and that is really not public domain (or better say for sure it was not at that time)... Not all the stuff is new with AD and some approach is taken from domain env. / edit: but domains uses netbios so .local was probably from AD beginning. – Kamil J Sep 27 '19 at 22:40
  • @Semicolon "*Not at all, when creating a domain, you are definitely able to specify the NetBIOS name of the domain*" That's not what I meant. I meant that by default, the NETBIOS name is the same as the AD name, so it's just another change that may cause issues in the future. – succulent_headcrab Sep 29 '19 at 19:55
  • @Semicolon I don't really see how this answers the question though. It's more of the same "you should do it like this or things might break some day". What things? How? Tell me a story about someone who did not follow this practice and gotten bitten. Your answer repeats exactly what I've read online and lead me to ask this question in the first place. My question is not "what should I do?" it's "what can go wrong if I do things this way?". How do I know the things I listed in my cons list are not *more* likely to break something or cause problems in the future? – succulent_headcrab Sep 29 '19 at 20:07
  • @Semicolon And as for your edit, I never said anything about an employer. I never said I was rolling out a new domain. I'm just asking a question. I usually always agree with best practices and follow them diligently because I can see the reasoning behind them, even when they require more work. This is the first time I've ever seen something that is recommended and felt that something was off about it. – succulent_headcrab Sep 29 '19 at 20:14
1

The user's UPN suffix should match their email address so anyone who creates users has to know which UPN suffix to use and that it is not the default.

There's no technical reason that the UPN Suffix needs to match the email address.

Microsoft's idea was that users remember their email addresses more readily then they remember their usernames, so using a UPN Suffix/User Principal Name that matches the email address would make the logon process easier and more intuitive for users. The problem is that it never really caught on.

One reason that you might want the UPN Suffix to match the email address is if you're synchronizing your on premises users to Office 365. Again, this isn't a technical requirement, but it makes things easier and more intuitive for the users when accessing Office 365 services, like Exchange Online and Sharepoint Online.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • I don't know much about O365 but while researching I came across a few people who mentioned that the users' UPNs *should* match their email addresses but I don't know what the technical reasons were. – succulent_headcrab Sep 29 '19 at 19:57
  • I don't think this answers the question, it's more of a comment. I wasn't asking specifically about changing UPN suffixes, my question is about the naming of the domain itself. – succulent_headcrab Sep 29 '19 at 19:59
  • I was addressing that specific point in your question. – joeqwerty Sep 29 '19 at 20:35