Results 1 to 4 of 4

Thread: creating a FOREST ROOT DOMAIN

  1. #1
    JR Guest

    creating a FOREST ROOT DOMAIN

    I have a windows 2003 domain (20 DC’s). Our goal is to rename the Domain.
    However, we have decided its too risky to run the domain rename tool. We have
    decide to do a migration. We also acquisition multiple companies and migrate
    them to our domain. The goal is to create a win2k3 FOREST ROOT DOMAIN,
    (separates Enterprise and Schema admin groups from the production domain ).
    This Domain would have no users at all other than Administrator and one
    backup account. What I’m trying to figure out is what to name it? Does
    Microsoft have some best practice scenarios for this?
    Then we build the production domain under the forest root. Call it something
    like Production.Lan? This domain is subordinate to the forest root. we would
    create various OU’s in here for structure/management. Then migrate the old
    domain to this one.
    Does this sound like I’m on the right path? Can you provide any
    documentation, case studies, suggestions for this scenario?
    Many Thanks
    JR


  2. #2
    Ace Fekay [Microsoft Certified Trainer] Guest

    Re: creating a FOREST ROOT DOMAIN

    "JR" <JR@discussions.microsoft.com> wrote in message
    news:50C83448-56CE-4022-B7BA-0D23EDF1789F@microsoft.com...
    >I have a windows 2003 domain (20 DC’s). Our goal is to rename the
    >Domain.
    > However, we have decided its too risky to run the domain rename tool. We
    > have
    > decide to do a migration. We also acquisition multiple companies and
    > migrate
    > them to our domain. The goal is to create a win2k3 FOREST ROOT DOMAIN,
    > (separates Enterprise and Schema admin groups from the production
    > domain ).
    > This Domain would have no users at all other than Administrator and one
    > backup account. What I’m trying to figure out is what to name it? Does
    > Microsoft have some best practice scenarios for this?
    > Then we build the production domain under the forest root. Call it
    > something
    > like Production.Lan? This domain is subordinate to the forest root. we
    > would
    > create various OU’s in here for structure/management. Then migrate the
    > old
    > domain to this one.
    > Does this sound like I’m on the right path? Can you provide any
    > documentation, case studies, suggestions for this scenario?
    > Many Thanks
    > JR
    >



    JR,

    Did you know this is a loaded question? This has been discussed numerous
    time since the early start days of AD. And some thoughts have changed over
    the years. In a nutshell, it depends. Read my following blog on this that I
    and another MVP (prior when I was an MVP in the past), put together. It's a
    pretty complete synopsis that I even added Exchange 2007 considerations
    because of the UCC/SAN cert that is required for it to work with Outlook
    Anywhere and Mobile handhelds.

    ==================================================================================================== ==
    What's in an Active Directory DNS Name?
    Choosing a domain name.

    AD Design considerations

    Same name AD DNS domain name and external name (split-zone)
    I must say this is a classic question that stems back to the beginning days
    of AD. Naming your internal domain name can be based on a number of things,
    whether technical or political, or previous administrative experience. This
    has been highly discussed (not debated) in the past. Whatever decision you
    make for an AD DNS FQDN domain name, just understand the ramifications.
    Actually I'm not going to try to get into any sort of debate, for there is
    really nothing to debate, nor help someone decide on what is 'right' or
    'wrong' but rather just state the implications and how to get around them,
    no matter what the decision was based on.

    The following passage below is a compilation of a discussion between myself
    and Todd J. Heron, MVP, from a few years ago.

    ===

    Classic question:
    "Which are the advantages of naming my domain with domain.com rather than
    domain.local? I have a domain.com registered for my Company that i use for
    my e-mail and Site Internet."

    There are different answers to this classic question and while these answers
    ultimately depend upon company preference, much of the direction will be
    based upon administrator experience. The three basic scenarios outlined
    below are the most commonly given answers to the question, sometimes
    altogether and sometimes not. Some company networks use a combination of
    these scenarios. When explaining it to a relative beginner asking the
    question, many responses omit explanatory detail about all the scenarios,
    for fear of causing more confusion.

    All three approaches will have to take both security and the end-user
    experience into perspective. This perspective is colored by company size,
    budget, and experience of personnel running Active Directory and the network
    infrastructure (mostly with respect to DNS and VPN). No one approach should
    be considered the best solution under all circumstances. For any host name
    that you wish to have access from both your internal network and from the
    external Internet you need scenario 1, although it is the most DNS-intensive
    over time. If you do not select this option and go with scenario 2 or 3
    only, consideration will have to be given to the fact that company end-users
    will need to be trained on using different names under different
    circumstances (based on where they are (at work, on the road or at home).

    ===


    Scenario 1.
    Choosing the same name internal/external (spilt-zone, or split-brain,
    whatever you want to call it) has the most administrative overhead. Why
    chosen? Either because a misunderstanding of the pros/cons, political, or
    for ease of use.

    Pros:
    1. Their email address is their logon name. Easier to remember.

    2. Security. Each DNS zone is authoritative for the zone of that name so
    therefore the external DNS zone and internal AD/DNS zone will NOT replicate
    with each other thereby prevent internal company records to be visible to
    the outside Internet.

    3. Short namespace. Users don't have to type in (or see) a long domain
    name when accessing company resources either internally or externally.
    Names are "pretty".

    Cons:
    1. Administrative overhead. If trying to get to your externally hosted
    website, it won't resolve because a DNS server will not forward or resolve
    outside for what a zone that it hosts. You can overcome resolving the
    www.domain.com dilemma by using a delegation. Rt-click your zone, new
    delegation, type in 'www' and provide the public SOAs for the nameserver(s).
    This way it will send the resolution request to the SOA and resolve that
    way. As for http://domain.com, that is difficult and would instruct all
    users to only use www.domain.com. This is because of the LdapIpAddress, the
    record that shows up as (same as parent), which EACH domain controller
    registers. So if you type http://domain.com, you will round robin between
    the DCs. To overcome that, on EACH DC, install IIS, then under the default
    website properties, redirect it to www.domain.com and let the delegation
    handle it. Now if you were to be using Sharepoint services, or something
    else that connects to the default website (no sub folders or virtual
    directories), then it becomes a problem. I know numerous installations setup
    with this and have operated fine for years.

    2. Security. Each DNS zone is authoritative for the zone of that name so
    therefore the external DNS zone and internal AD/DNS zone will NOT replicate
    with each other thereby prevent internal company records to be visible to
    the outside Internet.

    3. Any changes made to the public DNS zone (such as the addition or removal
    of an important IP host such as a web server, mail server, or VPN server)
    must added manually to the internal AD/DNS zone if internal users will be
    accessing these hosts from inside the network perimeter (a common
    circumstance).

    4. VPN resolution is problematic at best. Company users accessing the
    network from the Internet will easily be able to reach IP hosts in the
    public DNS zone but will not easily reach internal company resources inside
    the network perimeter without special (and manual) workarounds such as
    maintaining hosts files on their machines (which must be manually updated as
    well everytime there is a change to an important IP host in the public
    zone), entering internal host data on the public zone (such as for printers,
    SRV records for DCs, member server hosts, etc), which exposes what internal
    hosts exist, or they must use special VPN software (usually expensive), such
    as Cisco, Netscreen, etc, which is more secure and reliable anyway.

    For further reading on this scenario:
    http://www.isaserver.org/tutorials/Y...Split_DNS.html
    http://homepages.tesco.net./~J.deBoy...ver-names.html

    ===

    Scenario 2.
    Choosing a child name or delegated sub domain name of the public zone. This
    is one recommendation. Name such as 'ad.domain.com', or
    'corp.microsoft.com'. The AD DNS domain name namespace starts at
    corp.domain.com and has nothing to do with the domain.com zone.

    Pros:
    1. Mimimal administrative overhead.

    2. Forwarding will work.

    3. The NetBIOS name will be 'AD' or 'CORP', depending on what you chose and
    what the users will see in the three-line legacy security logon box.

    4. Like Scenario 1, this method also isolates the internal company network
    but note this at the same time is also a disadvantage (see below).

    5. Better than Scenario 1, internal company (Active Directory) clients can
    resolve external resources in the public DNS zone easily, once proper DNS
    name resolution mechanism such as forwarding, secondary zones, or delegation
    zones are set up.

    6. Better than Scenario 1, DNS records for the public DNS zone do not need
    to be manually duplicated into the internal AD/DNS zone.

    7. Better than Scenario 1, VPN clients accessing the internal company
    network from the Internet can easily navigate into the internal subdomain.
    It is very reliable as long as the VPN stays connected.


    Cons:
    1. Confusion on users if they decide on using their UPN.

    2. While there is security in an isolated subdomain, there is potential for
    exposure to outside attack. The potential for exposure of internal company
    resources to the outside world, lies mainly in the fact that because when
    the public zone DNS servers receives a query for
    subdomain.externaldnsname.com, they will return the addresses of the
    internal DNS servers which will then provide answers to that query.

    3. Longer DNS namespace. This may not look appealing (or "pretty") to the
    end-users.

    4. Security. We are assuming that we can only access the internal servers
    thru a VPN and assuming they are in a private subnet, they won;'t be
    accessible. Also assuming to secure the VPN with an L2TP/IPSec solution and
    not just a quick PPTP connection. If this is all so, we can assume it is
    secure and not accessible from the outside world.

    The scenario is the recommendation from the Windows Server 2003 Deployment
    Guide. It states to the external registered name and take a sub zone from
    that as the DNS name for the Forest Root Domain:
    http://www.microsoft.com/resources/d...us/default.asp

    ===

    Scenario 3. Choosing a different TLD: Choosing a different TLD, such as
    domain.local, domain.corp, domain.net, etc. This option is usually best for
    either beginners or the expert, because it's the easiest to implement
    primarily because it prevents name space conflicts from the very beginning
    with the public domain and requires no further action on your part with
    respect to that.

    But this option does makes VPN resolution difficult (like option 1) and
    Exchange headers when examined closely will show the company internal AD
    name which looks unprofessional. You can use any extension you want here
    such as .ad, .int, .lan, etc...

    Pros:
    1. Easy to implement with minimal administrative overhead. Requires minimal
    action on administrators.

    2. Prevents name space conflicts with external domain name.

    3. Forwarding works.


    Cons:
    1. Domain name may look unprofessional.

    2. VPN resolution difficult (like option 1). That can be a sticky issue and
    depending on the VPN client will dictate whether it will work or not. I know
    one of the other MVPs (Dean Wells) created a little script to populate a
    user's laptop or home PC's hosts file with the necessary resources and would
    remove them once the VPN is dissolved.

    3. Exchange HELO name must be altered (to accomodate anti-spam, SPF, and RBL
    software), via MetaEdit, Metabase Explorer and thru the SMTP VS properties.


    ===

    For a broad overview of this entire topic, see below.

    DNS Namespace Planning
    http://support.microsoft.com/default...b;en-us;254680

    Assigning the Forest Root Domain Name:
    http://www.microsoft.com/resources/d..._logi_kqxm.asp


    ===
    Exchange 2007 UCC/SAN certificate:

    More things to consider concerning the internal AD DNS domain name and if
    using Exchange 2007 (added 5/18/09 by Ace Fekay):

    If you choose a TLD, be sure to not choose one that is already in use by
    another entity. Reason is it will cause due confusion, and will create
    problems if you were to get an Exchange 2007 UCC/SAN certificate and adding
    a name for the internal namespace on the certificate. Here are some existing
    TLDs that you do not want to choose if the name does not belong to your
    entity:

    So it would be a bad choice for the complications that will arise, if you
    name the internal domain is registered by others.

    In one word, please make sure never to use a internal domain with a suffix
    same as existing Top-level domain names. You can use such as ABC.earth,
    ABC.mars and ABC.<whatever> but prevent from using those exiting top-level
    domains suffix.

    Technically speaking, you can also use the same name for the internal
    domain and the external domain. However, this method is not recommended.
    You may encounter following possible issues that you may have to perform a
    domain rename in the further

    1. If you name the internal domain the same as your Internet public domain
    name, in some time domain internal client will get the domain external IP
    (resolved from external domain name). In the scenarios that you also have
    published Exchange Server to receive external mails, the issue will be much
    more complicated. A sample issue:

    Same Internal and External Domain Name
    http://techrepublic.com.com/5208-111...hreadID=181117

    2. Worse, if you name the internal domain is registered by others.

    Generic top-level domains:

    biz .com .info .name .net .org .pro .aero .asia .cat .coop .edu
    gov .int .jobs .mil .mobi .museum .tel .travel


    Country-Code Top-Level Domains that you want to be careful choosing,
    especially if someone else owns it on the internet. You'll never get the
    cert approved if it is owned by someone else, despite the argument that
    "it's my internal domain name..."

    ac .ad .ae .af .ag .ai .al .am .an .ao .aq .ar .as .at .au
    aw .ax .az .ba .bb .bd .be .bf .bg .bh .bi .bj .bm .bn .bo
    br .bs .bt .bw .by .bz .ca .cc .cd .cf .cg .ch .ci .ck .cl
    cm .cn .co .cr .cu .cv .cx .cy .cz .de .dj .dk .dm .do .dz
    ec .ee .eg .er .es .et .eu .fi .fj .fk .fm .fo .fr .ga .gd
    ge .gf .gg .gh .gi .gl .gm .gn .gp .gq .gr .gs .gt .gu .gw
    gy .hk .hm .hn .hr .ht .hu .id .ie .il .im .in .io .iq .ir
    is .it .je .jm .jo .jp .ke .kg .kh .ki .km .kn .kp .kr .kw
    ky .kz .la .lb .lc .li .lk .lr .ls .lt .lu .lv .ly .ma .mc
    me .md .mg .mh .mk .ml .mm .mn .mo .mp .mq .mr .ms .mt .mu
    mv .mw .mx .my .mz .na .nc .ne .nf .ng .ni .nl .no .np .nr
    nu .nz .om .pa .pe .pf .pg .ph .pk .pl .pn .pr .ps .pt .pw
    py .qa .re .ro .rs .ru .rw .sa .sb .sc .sd .se .sg .sh .si
    sk .sl .sm .sn .sr .st .sv .sy .sz .tc .td .tf .tg .th .tj
    tk .tl .tm .tn .to .tr .tt .tv .tw .tz .ua .ug .uk .us .uy
    uz .va .vc .ve .vg .vi .vn .vu .wf .ws .ye .za .zm .zw
    ==================================================================================================== ==



    More on Exchange and naming...
    ==================================================================================================== ==
    Exchange 2007 UC/SAN Certificate

    If you need to test OWA, Outlook Anywhere, ActiveSync, etc, please visit the
    following Microsofttest site. It will tell you where the problem lies:

    Microsoft Exchange Server Remote Connectivity AnalyzerSelect the test you
    want to run.
    https://www.testexchangeconnectivity.com

    Getting a certificate for Exchange 2007 is a little different than Exchange
    2003 or a simple website. Exchange 2007 requires a UC/SAN (Unified
    Communications - Subject Alternative Name). This type of cert supports
    multiple names, which Exchange 2007 requires, especially to include support
    for Outlook 2007 Autodiscover record.

    The four main names I usually add when I make the request are:

    mail.company.com (the name used to access OWA)
    autodiscover.company.com
    internalname.internaldomain.com (what Outlook Anywhere and DSProxy uses over
    RPC/HTTPS uses to connect to Exchange)
    internalname (the NetBIOS name of the Exchange 2007 server)

    The internalname.internaldomain.com is what Outlook Anywhere and DSProxy
    uses over RPC/HTTPS uses to connect to Exchange 2007.

    The autodiscover.company.com is used by Outlook for autoconfiguration.

    If you go to this site, they offer a web based tool to configure a
    certificate request for your Exchange 2007 server.

    DigiCert's Exchange 2007 CSR Tool
    https://www.digicert.com/easy-csr/exchange2007.htm

    Then you can use the request to submit it to the certificate authority. I've
    been using this company (DigiCert) to purchase this type of certificate for
    my customers. There are others out there, but I found this one is cheaper
    than a couple of others, and works with Windows Mobile 5 and 6 without
    problems. But that is up to you. Please check the other companies, such as
    Verisign, Thwate, InstanSSL, etc, to compare.

    Please keep in mind, your name, company name, etc, whatever name you put on
    the cert (based on the domain name), a WHOIS on your domain name must have
    this exact information, or they will not issue the certificate. This is a
    strict requirement by the certificate authorities. You can call them if more
    specific info about this.

    More things to consider concerning the internal AD DNS domain name and if
    using Exchange 2007 (added 5/18/09 by Ace Fekay):

    If you choose an internal AD DNS name, be careful of the TLD you choose. You
    do not want to choose one that is already in use by another entity. Reason
    is it will cause due confusion, and will create problems if you were to get
    an Exchange 2007 UCC/SAN certificate and adding a name for the internal
    namespace on the certificate. Here are some existing TLDs that you do not
    want to choose if the name does not belong to your entity:

    So it would be a bad choice for the complications that will arise, if you
    name the internal domain is registered by others.

    In one word, please make sure never to use a internal domain with a suffix
    same as existing Top-level domain names. You can use such as ABC.earth,
    ABC.mars and ABC.<whatever> but prevent from using those exiting top-level
    domains suffix that exist. So If I were to chose domain.net for my internal
    name, but it is owned by someone else, the certificate authorities will not
    approve the certificate request.

    Technically speaking, you can also use the same name for the internal domain
    and the external domain. However, this method is not recommended. You may
    encounter following possible issues that you may have to perform a domain
    rename in the future. Not something that one desires to do.

    Some guidelines for internal AD DNS domain naming:

    1. If you name the internal domain the same as your Internet public domain
    name, in some time domain internal client will get the domain external IP
    (resolved from external domain name). In the scenarios that you also have
    published Exchange Server to receive external mails, the issue will be much
    more complicated. A sample issue:

    Same Internal and External Domain Name
    http://techrepublic.com.com/5208-111...hreadID=181117

    2. Worse, if you name the internal domain is registered by others. Then it
    will never get approved.
    ==================================================================================================== ==

    --
    Ace

    This posting is provided "AS-IS" with no warranties or guarantees and
    confers no rights.

    Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
    Microsoft Certified Trainer
    aceman@mvps.RemoveThisPart.org

    For urgent issues, you may want to contact Microsoft PSS directly. Please
    check http://support.microsoft.com for regional support phone numbers.

    "Efficiency is doing things right; effectiveness is doing the right
    things." - Peter F. Drucker
    http://twitter.com/acefekay



  3. #3
    Paul Bergson [MVP-DS] Guest

    Re: creating a FOREST ROOT DOMAIN

    Why do you need to have a root domain? If you are having issues with domain
    admins yank their rights. There should only be a few domain admins anyways.
    I worked for a company of 55,000 and there were 4 domain admins in a single
    domain and single forest. You can always delegate permissions to OU's as
    needed. It isn't clear to me that this route is your best path and now with
    RODC's available you can have remote sites with admins on these RODC's that
    don't have domain admin rights.

    If you had time and could explain your diliemna maybe there is another way
    to do what you want by migrating everything to a single domain/forest.

    --
    Paul Bergson
    MVP - Directory Services
    MCTS, MCT, MCSE, MCSA, Security+, BS CSci
    2008, 2003, 2000 (Early Achiever), NT4

    http://www.pbbergs.com

    Please no e-mails, any questions should be posted in the NewsGroup This
    posting is provided "AS IS" with no warranties, and confers no rights.

    "JR" <JR@discussions.microsoft.com> wrote in message
    news:50C83448-56CE-4022-B7BA-0D23EDF1789F@microsoft.com...
    >I have a windows 2003 domain (20 DC's). Our goal is to rename the Domain.
    > However, we have decided its too risky to run the domain rename tool. We
    > have
    > decide to do a migration. We also acquisition multiple companies and
    > migrate
    > them to our domain. The goal is to create a win2k3 FOREST ROOT DOMAIN,
    > (separates Enterprise and Schema admin groups from the production
    > domain ).
    > This Domain would have no users at all other than Administrator and one
    > backup account. What I'm trying to figure out is what to name it? Does
    > Microsoft have some best practice scenarios for this?
    > Then we build the production domain under the forest root. Call it
    > something
    > like Production.Lan? This domain is subordinate to the forest root. we
    > would
    > create various OU's in here for structure/management. Then migrate the old
    > domain to this one.
    > Does this sound like I'm on the right path? Can you provide any
    > documentation, case studies, suggestions for this scenario?
    > Many Thanks
    > JR
    >




  4. #4
    Meinolf Weber [MVP-DS] Guest

    Re: creating a FOREST ROOT DOMAIN

    Hello JR,

    Why will you make yourself that much work and also an additional failure
    point. I would choose wherever possible a single forest domain. Within the
    OU structure you can control your admins with delegated controls and so have
    as less admins as possible. Only for having control over admins i would not
    built a structure whcih creates additional (not really needed) work.

    If you need a real security boundary you have to create differnet forests,
    domains are not security boundaries.

    So Keep it simple for your own work.

    Best regards

    Meinolf Weber
    Disclaimer: This posting is provided "AS IS" with no warranties, and confers
    no rights.
    ** Please do NOT email, only reply to Newsgroups
    ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


    > I have a windows 2003 domain (20 DC's). Our goal is to rename the
    > Domain.
    > However, we have decided its too risky to run the domain rename tool.
    > We have
    > decide to do a migration. We also acquisition multiple companies and
    > migrate
    > them to our domain. The goal is to create a win2k3 FOREST ROOT DOMAIN,
    > (separates Enterprise and Schema admin groups from the production
    > domain ).
    > This Domain would have no users at all other than Administrator and
    > one
    > backup account. What I'm trying to figure out is what to name it? Does
    > Microsoft have some best practice scenarios for this?
    > Then we build the production domain under the forest root. Call it
    > something
    > like Production.Lan? This domain is subordinate to the forest root.
    > we would
    > create various OU's in here for structure/management. Then migrate the
    > old
    > domain to this one.
    > Does this sound like I'm on the right path? Can you provide any
    > documentation, case studies, suggestions for this scenario?
    > Many Thanks
    > JR




Similar Threads

  1. LDIFDE for backup of entire forest/domain
    By NGV BalaKrishna in forum Active Directory
    Replies: 5
    Last Post: 15-09-2010, 03:52 PM
  2. Replies: 5
    Last Post: 24-08-2010, 03:12 AM
  3. Child domain or Forest with two-way trust
    By Gracious in forum Networking & Security
    Replies: 4
    Last Post: 21-08-2010, 01:16 PM
  4. Adding a 2008R2 Child Domain to a 2003R2 forest
    By Kaysel in forum Active Directory
    Replies: 2
    Last Post: 01-05-2010, 09:33 PM
  5. Replies: 1
    Last Post: 19-03-2008, 10:35 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Page generated in 1,711,621,842.89613 seconds with 17 queries