Solved

New AD DS Forest Questions.. Need help badly

Posted on 2014-09-08
3
137 Views
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
0
Comment
Question by:QuazzieM
[X]
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
3 Comments
 
LVL 12

Accepted Solution

by:
Jeff_Schertz earned 500 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.
0
 

Author Comment

by:QuazzieM
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?
0
 

Author Comment

by:QuazzieM
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
0

Featured Post

Is Your AD Toolbox Looking More Like a Toybox?

Managing Active Directory can get complicated.  Often, the native tools for managing AD are just not up to the task.  The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.

Question has a verified solution.

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

Suggested Solutions

While rebooting windows server 2003 server , it's showing "active directory rebuilding indices please wait" at startup. It took a little while for this process to complete and once we logged on not all the services were started so another reboot is …
Always backup Domain, SYSVOL etc.using processes according to Microsoft Best Practices. This is meant as a disaster recovery process for small environments that did not implement backup processes and did not run a secondary domain controller that ne…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …

733 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