9

Unfortunately I inherited an Active Directory domain whose name is a DNS name the company does not own - we'll call it ABC.com. I would like it to be something under company.com instead (per MDMarra's answer on AD naming I'd probably use ad.company.com since you never want to use a DNS name you use for anything else), but the hard requirement for now is to be able to move email to Office 365 this year and using Directory Synchronization. For that, it looks like at a minimum I need a matching UPN to our email domain (company.com). Ok, the process for adding a second UPN seems simple enough. Testing it and moving accounts over until they are all on the desired UPN seems reasonable enough.

Is there any downside to just doing this? Will the technical debt grim reaper eventually arrive if we stay on this 'non-owned' domain name of ABC.com indefinitely?

For reference, we have a single forest, single domain with everything (forest, functional level, all DCs) at 2012R2 level and Exchange 2010 on this domain. There are around 150 users and 450 computers in AD (lots of dev/test automation). While I've safely navigated us from 2003 forward to 2012R2, I would by no means call myself an expert at AD.

It doesn't look like domain renames are generally advised, and since we have Exchange 2010 on our domain I don't believe it would even be an option.

As I see it, I could either:

  • add a second UPN and be done. I can deal with having to manually set the UPN on things as we create/add them...
  • add a second domain to the forest, move everything over, and always have this legacy root domain forever that I can't remove
  • create a second forest, forest <-> forest trust, do everything the way I really want it on this new forest from the ground up...move everything, and eventually remove the original forest. Really slow, really carefully, tested forwards and back, and probably at great expense (at a minimum in time spent). In a dream world this seems best, but I am not sure I can justify a business case for this (unless someone states a grim reaper arrival will occur).
  • ??? something else I haven't thought of
Community
  • 1
Joshua McKinnon
  • 1,421
  • 1
  • 13
  • 26
  • 1
    normally these kind of questions get downvoted as this is more of a "best practice" question but I am in the same boat and would also like to know – colbyt Apr 12 '17 at 22:32
  • 1
    Fingers crossed - we can't be the only ones with either a non-routable domain or one outside our control...also there have to be some facts (not just opinion) on the negatives of this situation... – Joshua McKinnon Apr 12 '17 at 23:20
  • 1
    `Will the technical debt grim reaper eventually arrive if we stay on this 'non-owned' domain name of ABC.com indefinitely?` - Eventually, yes. Note that creating an additional UPN doesn't address the fact that the AD FQDN is incorrect. The UPN is merely an "alternate" username that users can use to login with. It has no bearing on your actual AD FQDN. I've got to imagine that a move to Office 365 is going to be problematic for you, especially seeing that you don't "own" the name that's in use internally and that the name "belongs" to another organization. – joeqwerty Apr 13 '17 at 00:15
  • I've long drawn a line in the sand on O365, Federation or external SSO with prerequisite sorting out what we do about our incorrect AD FQDN. It has other headaches of course...I guess I'll need to pick a plan forward then. I don't expect it will be fun. Thanks for the note, @joeqwerty. If only I could travel back in time and prevent the person from choosing a name the company never controlled ... – Joshua McKinnon Apr 13 '17 at 00:53
  • Yeah. It's a challenging one. Great for the experience, but not so great for the stress it'll undoubtedly produce. Good luck. – joeqwerty Apr 13 '17 at 01:00

1 Answers1

8

So, existential crisis about not owning the domain you're using internally aside - from an Office 365 perspective this is fine. Office 365 cares about verifying the email domains that you have in use, not your AD domain. So the approach that you've taken by changing the UPNs to match the users' email addresses is appropriate and correct.

Now, from a purely AD perspective, you will never be able to get a third party certificate for that internal DNS domain since you don't own it. This may or may not be an issue for you. You'll also never be able to make a trust with another domain that shares the same name, so in the unlikely event that you merge with the company that owns that domain and they are also using that name, you'll have migration nightmares. I'd imagine the probability of this is somewhere close to 0.

It's a lot of work and potentially very disruptive to end users to rename or migrate out of a domain. At this point, I'm typically of the opinion that you should just leave the poorly named domain unless one of those edge cases is causing you heartache and just make sure you get it right on the next go-around :)

MDMarra
  • 100,183
  • 32
  • 195
  • 326
  • If third party certificates and acquisition from someone w/ the same domain are the main problems, I'm already quite used to #1, and #2 likelihood is close to 0. Sure, it irks me that it's not correct, but that doesn't come close to justifying the amount of work involved. Things like a domain-joined WSUS in Azure are a bit annoying to configure but most things that need outside access just leverage certs w/ our real DNS name(s) that we want to use anyway. I'm already familiar with those headaches. Any domain I name won't go down this road... such an avoidable class of problem. – Joshua McKinnon Apr 13 '17 at 13:57
  • @JoshuaMcKinnon Yeah - (as you know) I'm a crusader for properly naming an AD, but realistically doing a cross-forest migration to fix it is just an unreasonable burden for all but the smallest of environments. It's just one of those things that we have to live with in most cases. – MDMarra Apr 13 '17 at 14:40
  • Yep - it is reassuring hearing this from you. In this case the sensible thing to do is to live with it. :) I'll give this a day or two and mark accepted. – Joshua McKinnon Apr 13 '17 at 15:08