Re: 2003 AD upgrade and consolidation

"Ken Manohar" <KenManohar@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A4823477-36AC-43FA-8160-4E37ED5FC59A@xxxxxxxxxxxxxxxx
Hi Herb,

Right now they don't share resources across companies. The idea is for a
user in one company to be able to move to another company and be
authenticated using his/her same credentials.

You mean logon from a machine in another domain?
(That's a form of sharing resources, the computer
used for logon.) Trusts are required for this; computer
domain must trust the users account domain.

Currently users logon locally
when they are in another company.

Logon locally to WHAT?

The user will primarily be using resources
in his/her own company and occasionally resources in another company.

The centralized model will be used for setting group policies. GPOs that
need to be applied across the organization will be set at the tree root
domain to be inherited by all child domains.

No they won't.

GPOs are NOT inherited by child domains, only WITHIN
a domain by (child) OUs.


Patch management and antivirus
management will follow this centralized model.

Not without separate Group Policy linking.

A single windows update server
and a single antivirus update server is to be used for enusring all
workstations throughout the organization are updated.

That can actually work (with the GPOs controlling
this link to each domain etc. separately) -- but this is
also a form of resource sharing (the updates must be
on a file share point) so the "update server domain"
must trust the users' computer domain(s).

Also consider if SUS (or newer name MSUS) can help.

Some applications use
windows account. These applications are to be run from anywhere in the
organization without the user having multiple credentials.

That's resource sharing too. (Just not the built-in file
and print.)

I see your point about having the unessaccary domain. I have to ask the
person who created this design what his intentions were for abc.local.

Probably superstition, someone likely found out about
recommendation to use a private name INSTEAD of a
public name for AD domains, then applied that to the
case where the public name was ALSO needed -- in
such cases the private (e.g., domain.local) is redundant,
unnecessary, and unhelpful unless there is a specific
positive reason for it.

The type of user and resource sharing between a new company domain and the
new domain will vary, based on the new company. Users should at least be
authenticated in either domain.

That's resource sharing and trusts too.

The task of adding a new company domain to the new domain will be similar
to
what I'm trying to achieve now.

You cannot add a "domain to a domain", only to a forest
(ok, to a tree but trees are mostly incidental due to the
domain names not ending in the same suffix.)

... A child domain of the tree root will be
created for each company. The existing company domain (company.com) will
be
migrated to the corresponding child domain (sub1.abc.com).

Planning such migrations is the worst part of this design.
Domains CAN be migrated but it is generally something
best avoided so when planning you want to avoid plans
that use this method inheritantly.

As of now, the migration plan looks like:
1) Create the new forest domain. This will also be the new tree root
domain.

You probably should quit worrying about "tree root" -- as
I said, tree are of no practical importance other than the
domain names (i.e., the domain name suffix differences.)

Being in or outside of a forest is the primary distinction
when creating domains.

2) Create the child domain for Subisdary 1.
3) Use ADMT to migrate the Subsidary 1 domain (subsidary1.com) to the
child
domain (sub1.abc.com)
4) Repeat 2 & 3 for each subsidary

Bad design. Why plan for migration? Get things right to start,
OR stay outside the forest and consider external (or forest level
trusts.)

The problem with external trusts is the number grows very
rapidly if you have many domains and all must trust or be
trusted.

The problem with Forest Level trusts are that they require
BOTH forests to be in "Win2003 Forest Level Trusts".


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Regards,
Ken


.

Relevant Pages

  • Re: Is security provided by AD trusts worthless ?
    ... But trusts simply afford us the ... possibility of accessing objects (resources) in other domains. ... > separate domain-forest won't me help there. ... > that the hassle of setting up a logical forest boundary doesn't make a lot ...
    (microsoft.public.win2000.active_directory)
  • Re: Need info about trustedDomain records in forest of domains
    ... consistently referring to a "Windows Domain" or its more generic form? ... The forest has at least two child domains. ... >> presence and configuration of the trusts specific to this domain. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Transitive Forest trust
    ... that does not defeat the purpose of the forest trust.... ... forest trusts support a lot more than external trusts ... When on a machine in the domain in forest B, and I want to add a user from a child domain in forest A into a local group, it only shows the root domains and not the child domains. ... Any way to have the cild domain show up for this purpose as well? ...
    (microsoft.public.windows.server.active_directory)
  • Re: WIn2003 Trust betwee domains, same forest is possible ?
    ... >> resources and provide different set of security policies. ... > By deafult windows 200/2003 is creating two way transitive trusts ... > between the domains in the same forest and IMO it is not recommended to ...
    (microsoft.public.win2000.active_directory)
  • Re: Active Directory Design Question
    ... Argues for same forest, or explicit trusts so that IT admins ... Even with trusts from you to them, ... (removing your Everyone-Read or FC etc from resources.) ...
    (microsoft.public.windows.server.active_directory)