New AD DS Forest Questions.. Need help badly

Posted on 2014-09-08
Medium Priority
Last Modified: 2014-12-07
Hey everyone,

I'm having a bit of a conundrum about the new forest domain name and what possible implications it can have if I chose the wrong name convention...

Current Setup

The current issue is that the company I work for was bought out by another company and atm, where using a 2-way forest trust.

The company also has another site in Africa which is using a different forest domain but doesn't have any forest trust to either of the other 2 domains.

The current forest domains are:-

1. Company1.local (my old company)

2. Company2.com.au (main company)

3. internal.company2direct.com.ke (Africa site)

To make it worse, all three sites have their own Exchange environment and there's all types of file share/application authentication issues between sites.

Therefore, the company has decided that they want to get rid of all the exchange environments/file shares and so forth and move everything to Office365, including SharePoint and Lync

New Solution

They have also decided that they want a new forest with a single domain and that the locations and security will be delegated by using different OU structures/GPO's as it's all going to administered by 2 people at the main company site. This is non-negotiable as they don't want sub/child domains or different forests, just a single entity.

They're using a third party to do the Office365 design and implementation. However I have been assigned to setup the new initial ADDS server for the new forest.

After some reading I've found that we really shouldn't be using '.local' or '.internal' for the forest root domain. I suggested that we use 'internal.thecompanynamethatisreallylong.com.au' and a NetBIOS of 'CNF' (but because its such a long name, Ifeel that if we have to use a FQDN for anything then it will cause an issue)

They want me use the following for the forest root domain 'au.cnf' with a NetBIOS of 'CNF'

Is that really such a good idea or is there any situation whereby using 'au.cnf' as the prefix.suffix could cause any issues?

I would of like to use 'internal.cnf.com.au' however the domain name 'cnf.com.au' is already registered by another company..

Once the new forest is created, I'll be setting it up with the ADFS to Office365 and create 2way forest trusts from the new forest the 3 old ones and start migrating users to the new forest domain.

Thanks in advance for you help
Question by:QuazzieM
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
LVL 12

Accepted Solution

Jeff_Schertz earned 2000 total points
ID: 40312046
At this point in time you should stop using an invalid TLD (Top Level Domain) names like .local, .int, .etc.  For one it is no longer possible to get SSL certificates from public CAs using domain names which cannot be verified as valid and owned by your company, so whether or not you think that is an issue now think about the future when the need for public certs for 'something' comes into play.

Also depending on if you have a need for Enterprise Voice in Lync then you may be looking at leveraging a Hybrid (Split-Domain) topology for some time.  Considering that you have a couple options for your AD namespace.  The nice thing is that the hybrid scenario leverages SMTP, SIP, etc domain names which do not have to match your actual AD namespace.

The simplest solution is to basically use the same name as your external, owned namespace.  So internal AD, external, SIP, SMTP are all the same (e.g. yourcompanieslongname.co.au).  The other option is to use separate namespace, but make sure whatever you use for the internal namespace is something you own on the Internet.  Even if you won't ever publish (and should not) this namespace on the Internet you'll need to prove ownership of the domain to get any public certs issued with CN or SAN entries containing that namespace.

Author Comment

ID: 40313376
Hi Jeff, thanks for you reply..

I'm more leaning towards using the 'longcompanydomaindname.com.au' and setting the new forest root domain as either 'ad.longcompanydomain.com.au' or 'internal.longscompanydomainname.com.au'.

As were moving to more Azure cloud services like Office365/Sharepoint/Lync and I can only see us starting to utilise more IaaS sooner rather then later.

My only concern is that by using such a long winded forest root domain of 'internal.longscompanydomainname.com.au' is that if there's a scenerio whereby we need to use FQDN for some form on internal application or internal website, it can be annoying for staff to have to type that such a long winded address or login credential..

For example, if they needed to type.. 'https://intranet.longcompanydomainname.com.au' for a sharepoint site in Office365 or if the app requires them to use username@longcompanydomainname.com.au as the log in credentials..

Is there something that can be configured in AD/DNS that could create some sort of shortened verisons for these types of situations?

Author Comment

ID: 40313397
Would using a shorter UPN sort this issue out?? Sorry I'm dont know enough about UPN's and what they bring to the AD DS side of things

Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Had a business requirement to store the mobile number in an environmental variable. This is just a quick article on how this was done.
This article provides a convenient collection of links to Microsoft provided Security Patches for operating systems that have reached their End of Life support cycle. Included operating systems covered by this article are Windows XP,  Windows Server…
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
Suggested Courses

765 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question