|
> Generally, the more
domains, the more administrators you require. Not need, just require.
> I know Joe would argue
that one admin could do all of this, but I've typically seen that multiple
> domains cause a lot more
administrivia than you really want to put on one person if you can help
it.
> Backup and restore
planning and associated processes could conceivably keep people busy for
> more time than you want to
spend.
Hey now Al, I would never tell someone a single domain
admin is a good thing except for the DA of joeware.net or more accurately,
joeware.local. ;o)
I think a good start point is 3 and a manager with DA
rights. Add another if you need additional pager coverage or vacation/holiday
coverage. Even with that few, one or more of them could spend most of their
time working on "development" type projects or consulting to other groups
for how best to use AD. With an AD that is properly configured so it just works
and properly delegated or provisioned it shouldn't take a lot of DAs which is
good because the level of trust you need for DA's is not something you usually
have in many people. Heck many places have trouble coming up with even 3 people
they would trust with it even if they have hundreds of thousands of users and
thousands or tens of thousands of admins.
I like to think of the DA position as the position that
has the buck stops here sign. When shit hits the fan, these are the people who
figure out what is wrong. Daily admin tasks should be minimal except for looking
things over to detect issues and patterns that aren't being detected by the
automated systems. If there are any daily tasks (because you won't immediately
have everything automated), it should all be scripted so admins aren't hunting
around in the GUI for things.
I push the concept of very few admins because of two
main reasons
1. I strongly believe anything else is insecure and
unmanaged.
2. I know it can be done in large orgs having done it
in a Fortune 5 company which started out with well over 100 Domain Admins and
who knows how many people with access to a generic, yes generic, domain admin ID
with a shared password.
Multiple domains definitely cause additional overhead,
however it shouldn't be enough to push you into needing more DAs unless things
are pretty unmanaged and ad hoc. The hard part is the initial spin up and policy
setting and making sure all of your recovery eggs are in the right places. After
that you get into status quo and work is maintenance based such as patching, etc
which really doesn't have anything to do with number of domains, but instead
number of DCs though adding a domain should add at least 2 DCs.
Multiple domains should be avoided if possible. The
biggest cases I see for it are security policy deltas and replication
boundaries. For security policy, take the tightest policy required and make that
the policy for everyone. I am not as nice as Guido in that respect. :o)
For replication boundaries, if you have a centralized Exchange deployment, a
separate forest for Exchange and keeping only NOS info in the NOS directory
makes it much easier to have a single NOS domain for everything because there is
much less data to replicate. The fat chatty attributes aren't the NOS based ones
(except the ridiculous userParameters attrib - MS FIX THIS), it is all the other
gunk that can live in the Exchange forest or in AD/AM.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Monday, August 01, 2005 12:49 PM To: [email protected] Subject: RE: [ActiveDir] Multiple Domain Trees in a Single Forest I hate to keep quiet
:)
This one struck a chord, Guido:
"Better division of _responsibilities_ for
Backup/Restore as "the different orgs are responsible for their own data" is one
of the worst reasons I've heard recently - not good, not good... - keep it
central!"
I can think of many times where a company
has deployed a root and several child domains to satisfy political requirements.
The fall-out is usually around the restore of the environment and comes later
when they either have a problem or want to create a DR plan after the
fact. Or maybe just want a lab environment that's like production.
Whatever. That's when they find out that they need that root domain.
Only now they can't have the restoration information because that's the root
domain and you don't control that domain. Your corporate resource does and they
don't have time to deal with you.
Generally, the more domains, the more
administrators you require. Not need, just require. I know Joe would argue
that one admin could do all of this, but I've typically seen that multiple
domains cause a lot more administrivia than you really want to put on one person
if you can help it. Backup and restore planning and associated processes
could conceivably keep people busy for more time than you want to spend.
It's not worth it. Domains hold very little
value over OUs in return for additional overhead. With the ability to more
granularly control replication, you really don't need additional domains in a
forest. They share the schema, so why bother with the additional expense
and overhead (see the pattern?)
To the original poster's question:
"The potential risk for the second option
that has been identified is
that the deep LDAP search against a regular DC instead of a GC in one domain for a resource in the another domain may not return any results. However, the client intends to take the risk and mitigate it by deploying enough Global Catalogs (GC). In a nutshell, we would like to go with a disjointed namespace for the multiple domains within the forest. However, I need pro\cons to this approach. In addition, does the introduction of conditional forwarding and stub zones mitigate many of the issues that plauged disjointed namespaces?" Deep searches? Can you give an
example of what you're after and why you would use the DC vs. the GC and expect
results from other domains? For what it's worth, you have the same risk that a
search of a GC in one domain may not provide the results you're looking for
because the GC only holds a subset of the data. You would have to place
the data into the GC for it to be there, unless it's there by default.
Stub zones and conditional forwarding are
great for name resolution. That's the not the same as LDAP data and in my
opinion doesn't really mitigate any more than zone xfers from the other domains
or just plain forwarding in a hierarchichal DNS architecture (it's supposed to
be hierarchical right? :)
Remind your client that if you deploy
multiple domains, it's much harder to later bring them back. Not
impossible, but much more work that you would be creating. I usually
remind my customers of this and suggest that if you really need multiple domains
(and not for legacy reasons) then maybe multiple forests would be better.
But I only do that because I like directory synchronization technologies and
pain. </sarcasm for part of that sentence>
-ajm
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] Sent: Mon 8/1/2005 12:17 PM To: [email protected] Subject: RE: [ActiveDir] Multiple Domain Trees in a Single Forest I have
to agree with Guido: I have not seen any reason for separate trees or even
domains that can't be accomodated with multiple OUs instead. Mergers,
acquisitions or divestitures might be one reason for separating structures, but
then it should only be temporary. Several years ago we did a divestiture
by creating a separate forest and migrating resources, but if I had to do it
again today, I'd use a cross-forest focused trust.
AL
Al Maurer -----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Grillenmeier, Guido Sent: Sunday, July 31, 2005 12:44 PM To: [email protected] Subject: RE: [ActiveDir] Multiple Domain Trees in a Single Forest I'd actually have to say that this is a battle worth
fighting because people would try to see something in AD which they shouldn't
=> a separate tree should certainly not be used simply to put an
organisational structure in place which is negative to the business in the
longrun. Neither applications which are deployed forest-wide nor the
stakeholders who are currently voting for a multi tree forest are really
gaining any added value out of this structure - all it does is looking good on
paper or a presentation-slide showing some sort of seggregation which doesn't
really exist.
As joe very well points out, there are basically no
benefits for the end-user (who couldn't care less about the name anyways) and
you'd merely have even more administrative burdon on those who have the
responsibility to keep your AD forest running.
So if you can't win the fight to keep everything in a
single domain (which more than anything else should be the first goal), I'd at
least put in the extra effort to keep all domains in a single domain tree in a
forest. Certainly a battle worth fighting.
Even better, go for a single domain and do everything via
OU structures - I've not found many good arguments recently NOT to use a
single domain.
A rare reason I did just have recently and had no argument
against was the technical neccessity to have the same logonnames
(samAccountName) for different regions of an outsourcer, due to some legacy
dependencies to a regionally split host system which used these names.
Won't go into details here, but this did actually require multiple domains
although the customer would have loved to make it all work in a single
one...
/Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sonntag, 31. Juli 2005 17:38 To: [email protected] Subject: RE: [ActiveDir] Multiple Domain Trees in a Single Forest Joe said: “WHY??? What do you feel the benefit is?”
In my experience, it’s been not what *I* think the benefit is – it’s more about what management WANTED for reason A, or reason B, or whatever whacked business justification that they had.
I’m not much into creating trees for the heck of it. However, it does interest me to a) keep my job b) try to convince people that this is purely a business decision, and technically I can provide an invisible ‘separation’ if that’s what they want.
However, as in all business – there is a time to make a decision. Fight or not. In the cases that I’ve had to implement additional trees, I’ve allowed it to happen because it wasn’t a battle worth fighting. However, I pushed to get the tree merged back into the main tree as time and emotions settled.
Sometimes, joe – the only benefit of doing something that you don’t find palatable is because it’s not technically bad enough to warrant the fight that will ensue.
Rick From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe
I seriously dislike multi-tree forests. They tend to confuse support admins and some programs just aren't written properly for them and break. For instance I have the domain joe.com, what is the DN for my configuration container? Well you would like to assume cn=configuration,dc=joe,dc=com, however, you look at the rootdse and see that it is actually cn=configuration,dc=someotherdomainname,dc=local. A properly written program or script will work fine with either but that is a hell of an assumption, I still run across scripts and programs that try to parse the domains out to figure out DNs. When you bring in new people to work on your environment, it is silly to have to train them on such silly decisions as it is one more thing that they have to keep in mind that is special for your company.
The main question I like to ask people when they propose a multiple tree forest structure[1] is WHY??? What do you feel the benefit is? It has nothing to do with your email address. It has nothing to do with your userPrincipalName for logon. NetBIOS names can be A whether you have A.root.com or A.com. So what, besides making your support staff have to work harder and recall special things is the purpose behind having multiple trees?
On the LDAP searching part. I have seen programs that assume that the forest root DN is where you can base a GC search and get everything in the forest. This is of course incorrect and can cause failures in multi-tree forests. This is easily corrected by using the null base for the full forest search.
Every time I have encountered a desire for a multitree forest it has been the result of political infighting or an architect that really doesn't understand the product and thinks they are getting something that they aren't. I had one guy once tell me that any admin at the top of a domain tree automatically had full admin rights on every domain in the tree hierarchy... I actually had to get up and walk out of the room for a moment to decide if I really wanted to get too involved with that deployment because heaven knows what other decisions were made on knowledge that was also that wrong. Instead of working out implementation details, it required a complete review of the entire architecture and to understand the end goals. A completely different thing than what I was there for.
joe
[1] Which this is, a disjoint namespace is a different thing. You can have two different disjoints in the name space. The first is between the NetBIOS and DNS names of the domain - say the domain joe.com has a NetBIOS name of UncleBob. The second is on the DNS Suffixes used on the clients. For instance a client of bob in the domain joe.com would normally have a FQDN of bob.joe.com but in a DNS Suffix disjoint could have something like bob.sanfran.cali.joe.com or even bob.somethingelse.local.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of
[EMAIL PROTECTED] Hello All,
Looking to decide on
an AD domain structure
Thanks!
Rob
|
- RE: [ActiveDir] Multiple Domain Trees in a Single Forest joe
