|
Home > Archive > 70-217 > January 2004 > Which situation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| bigjon 2003-10-21, 2:34 pm |
| In which situation would use a child domain, a tree linked in the forest and an external trust | |
| jeff_j_black 2003-10-21, 4:14 pm |
| Child domains can be used to control repication or allow for a measure of administrative autonomy.
Some designs have a forest root domain that only has the forest level admins as members, then the user accounts and resources are in another domain (or domain tree) in that forest. This is to circumvent any users from being able to evelate their priviledges such that they can make configurations changes that effect the forest.
External trust are established when some type of interaction needs to take place between two autonamous organizations. You manage your network, they manage theirs, but users in each organization can be given permissions to access data in the other organization after authenticating in their own.
This is also used in the MUD (master user domain model) in NT. Because the SAM database had limitations in the number of objects (user accounts, resources) that it could contain. (had to be resident in memory) User accounts were put into one domain for central management and resource domains containing computers, data, printers, etc. trusted the user account domain, giving the users permissions to use computers, data, printers, etc. in the resource domain. | |
| curiousgeorge 2003-10-21, 11:52 pm |
| quote:
Child domains can be used to control repication or allow for a measure of administrative autonomy.
This is not true. Replication is a function of sites and site design. It has nothing to do with your domain structure. And administrative autonomy is handled through delegation of administrative control. Those are the two huge improvements from NT to 2000.
quote:
Some designs have a forest root domain that only has the forest level admins as members, then the user accounts and resources are in another domain (or domain tree) in that forest. This is to circumvent any users from being able to evelate their priviledges such that they can make configurations changes that effect the forest.
This is not true either. That is how domains were set up in NT, not 2000.
In NT days you had to set up multiple domains for administrative autonomy. In 2000 you can set up OU's and delegate administrative control to only that OU.
In NT days you separated your users in one domain and resources in another. In 2000 you can keep all of these (including your admins) in one domain.
The only need for child domains is if it is logical for a corporation or if a segment of the company requires different security standards than the rest of the company.
i.e. A conglomerate wants to have a corporate domain and then child domains for each of its companies. Or if each company in a conglomerate has their own security standards, separate domains would be required.
In that same example, maybe the conglomerate does not want one corporate domain and multiple child domains. Instead it can create domains for each company with each company's domain as a separate tree in the forrest.
Some examples of a need for an external trust would be two companies on a joint venture. If Ford and Chrystler want to have a joint venture in a new car concept, they would need to set up an external trust so each company can access the engineering data on the car they are creating together.
They can also be used for mergers. If a company buys another, they may immediately set up external trusts until the final AD design can be created and implemented.
The bank that I work for has used all of the above examples in their AD design.
Hope that helps. | |
| jeff_j_black 2003-10-22, 9:56 am |
| In instances where you cannot or don't want to replicate the Domain partition, you would use child domains. This is a form of controlling replication.
Administrative autonomy is not the same as administrative delegation. Autonomy would allow for different security settings such as password length, complexity and aging requirements, etc.
Administrative delegation is accomplished by setting permissions on Active Directory objects to allow different personnel within the organization to have different levels of control over those objects.
The vacant forest root domain is a legitemate design feature that you can read about if you review either the Deployment Planning Guide for Windows 2000 or 2003. It is not the same thing as the old NT MUD. | |
| curiousgeorge 2003-10-22, 9:41 pm |
| Jeff
I think you're getting your terms confused. Administrative autonomy means you want independent administrative control. That's not the same as establishing a separate security boundary. Security is only one small aspect of AD administration. That's why I explained that child domains are required if separate security standards are required.
quote:
Administrative autonomy is not the same as administrative delegation.
You are correct. Administrative delegation is HOW you grant administrative autonomy.
By delegating administrative control for lower level admins for their OU allows for administrators to have administrative autonomy without being able to control anyone else's area.
quote:
The vacant forest root domain is a legitemate design feature that you can read about if you review either the Deployment Planning Guide for Windows 2000 or 2003. It is not the same thing as the old NT MUD.
You are exactly right. That's why I gave the example of a corporate domain with child domains for the different companies.
The vacant forrest root design option is not intended for a single parent child design as your example stated. Your example was from the NT days of separating account and resource domains.
quote:
This is to circumvent any users from being able to evelate their priviledges such that they can make configurations changes that effect the forest.
Placing your enterprise admins in a separate domain won't prevent this from happening.
quote:
In instances where you cannot or don't want to replicate the Domain partition, you would use child domains.
I disagree. You do not create your AD design based on what will be replicated to other DC's. That is the RESULT of your design, not the REASON for your design. Creating child domains are not a form of controlling replication; it's a result of the design.
Your individual design facts were right, but your examples and reasons were wrong. | |
| jeff_j_black 2003-10-22, 11:17 pm |
| Cool dude... | |
| jeff_j_black 2003-10-23, 2:53 pm |
| quote:
autonomy means you want independent administrative control. That's not the same as establishing a separate security boundary. Security is only one small aspect of AD administration. That's why I explained that child domains are required if separate security standards are required.
We're saying the same thing, I'm just not the one posting statements saying you are wrong.
quote:
The vacant forest root design option is not intended for a single parent child design as your example stated.
My example did not state single parent child design. Take a breath and read again...
quote:
Some designs have a forest root domain that only has the forest level admins as members, then the user accounts and resources are in another domain (or domain tree) in that forest.
Not stated as parent/child, but separate domain in the forest.
quote:
I disagree. You do not create your AD design based on what will be replicated to other DC's.
So what about SMTP links?
Or what about a far off segment of the organization that has little need to have domain information from the other side of the world replicated to it?
Why would you keep that part of the organization in the same domain?
These are the design considerations I am talking about when I am refering to the creation of a child domain to avoid replication of the domain partition.
You have read DPG's for both 2000 & 2003?
I have reread my orginial post and stand by it. It's fine to disagree, it's fine to state your point of view, but I think your statements saying I'm out and out wrong is indefensible. | |
| curiousgeorge 2003-10-23, 11:07 pm |
| Jeff,
I think your pride is taking over. As I said before:
YOU'RE INDIVIDUAL DESIGN FACTS ARE RIGHT. However, the way you interpret them and try to use them are wrong.
quote:
Some designs have a forest root domain that only has the forest level admins as members, then the user accounts and resources are in another domain (or domain tree) in that forest.
Whether you are referring to a parent/child or a two tree design, THIS IS NOT what the vacant forrest root design is intended for. It is intended for large corporations with a neccesity for a multiple domain structure.
quote:
So what about SMTP links?
You proved my point for me! SMTP links are a perfect example of controlling replication. And again, AD design is NOT influenced by replication of DC's. Sites, site links, site design, replication schedules control replication. If AD design was dependent on how DC's replicate, there would be no need for sites, site links, site design, or replication schedules. By your theory, if a national company has offices in 400 different cities and they have slow connections, you would create 400 domains. And what if it was an international company with 1000 locations? Do you think M$ has 1000 domains in its AD design? I don't think so. Make that recommendation to a national company and they would fire you on the spot.
A geographic AD design may be logical because of the business structure, but it has NOTHING to do with replication. I'm sorry, you are reading the deployment guides but you aren't understanding what they are saying. Please give me a quote from the deployment guides that says that replication determines your AD design.
Your statements make me wonder if you've ever worked for a large company before. If you have, you would know what you were saying is just plain wrong.
It's okay to be wrong. But if you aren't willing to learn from it, you've got a LONG HARD career ahead of you.
I've seen a lot of your other posts, and they're right on. But this time you were so far off the mark, I had to correct you. | |
| jeff_j_black 2003-10-24, 9:22 am |
| I have posted numerous links to both DPGs, for your convenience. This is from the Windows 2000 Server Deployment Planning Guide. Please don't make me post both DPGs in their entirety, piece by piece.
Administrative Partitioning
More domains might be necessary depending on the administrative and policy requirements of your organization, described as follows.
Unique domain user security policy requirements You might want to have a set of users on your network abide by a domain user security policy that is different from the security policy applied to the rest of the user community. For example, you might want your administrators to have a stronger password policy, such as a shorter password change interval, than the regular users on your network. To do this, you must place those users in a separate domain.
Division requires autonomous domain administration supervision The members of the domain administrators group in a particular domain have complete control over all objects in that domain. If you have a subdivision in your organization that will not allow outside administrators control over their objects, place those objects in a separate domain. For example, for legal reasons, it might not be prudent for a subdivision of an organization that works on highly sensitive projects to accept domain supervision from a higher level IT group. Remember that all domains in the forest must share the Configuration and Schema containers.
Physical Partitioning
Physical partitioning involves taking the domains you have in a forest and dividing them up into a greater number of smaller domains. Having a greater number of smaller domains allows you to optimize replication traffic by only replicating objects to places where they are most relevant. For example, in a forest containing a single domain, every object in the forest is replicated to every domain controller in the forest. This might lead to objects being replicated to places where they are rarely used, which is an inefficient use of bandwidth. For example, a user that always logs on at a headquarters location does not need their user account replicated to a branch office location. Replication traffic can be avoided by creating a separate domain for the headquarters location and not replicating that domain to the branch office. | |
| jeff_j_black 2003-10-24, 11:26 am |
| quote:
I think your pride is taking over.
No, I am merely standing behind what I originally said, as it is correct.
You keep saying it is totaly wrong, using wild extrapolations that are not based on what I said, then resort to flawed observations about my employment, personality make-up, etc.
I think I have defended my point well, while refraining from these tactics, what else do you have? | |
| halosix 2003-10-24, 12:21 pm |
| From the MS Press 70-217 study guide:
"The following are some reasons to create more than one domain:
Decentralized network administration
Replication control "
Seems pretty straightforward to me. | |
| curiousgeorge 2003-10-25, 2:20 am |
| I tell you what...
why don't you email Bill Gates and tell him his company has their AD design incorrect. Tell him he should have 1,000+ domains because that's how you interpret the deployment guide.
Tell State Farm Insurance (I worked on their AD design project) that instead of having 12 domains in their AD design, they should have at least 800.
Tell SunTrust Bank (I worked on theirs too) that instead of collapsing 1,800 domains to 23, they need to go back to the 1,800 they originally had.
Tell AmSouth Bank (Guess what... I worked on theirs too) that instead of 17 domains, they need the 1,400 they used to have.
I would be more inclined to believe you if you had any real world experience in this area and if you were considered a subject matter expert in it, but you don't and you're not.
If you re-read the very quote you sited, you will see that the deployment guide DOES NOT say replication dictates your design, IT IS A RESULT OF YOUR DESIGN.
nuff said... if you aren't willing to learn from others who have actually done this, I have nothing further to say. | |
| jocampo 2003-12-12, 2:55 pm |
| WOW! i had not read this thread before. It was really HOT, hahaha...better than any Ali's fight, hahaha...
My 2 cents: do not "shoot" personal attacks, neither say "i work for" or "you don't work for", because that does not add any interesting value or knowledge to the initial question.
Peace & Love
 | |
| bluhen99 2003-12-21, 5:17 pm |
| I just read Jeff's first post, and have to agree with his points. Most of the post was cut from Technet articles and pasted in the post, straight from the horse's mouth you could say. While Setting up a domain structure to manipulate replication traffic may not the be the best way, remind me of a time when Microsoft's way was ever the best way. | |
| curiousgeorge 2003-12-22, 3:06 am |
| If someone only has book knowledge and someone else has real-world experience in a production environment, I would tend to believe the one who has the actual experience.
As I said before, his quotes and design facts are correct. The way he was interpretting them was incorrect.
When you put the book knowledge into practice, you understand much better. | |
|
| quote:
Originally posted by curiousgeorge
Tell State Farm Insurance (I worked on their AD design project) that instead of having 12 domains in their AD design, they should have at least 800.
Tell SunTrust Bank (I worked on theirs too) that instead of collapsing 1,800 domains to 23, they need to go back to the 1,800 they originally had.
Tell AmSouth Bank (Guess what... I worked on theirs too) that instead of 17 domains, they need the 1,400 they used to have.
I would be more inclined to believe you if you had any real world experience in this area and if you were considered a subject matter expert in it, but you don't and you're not.
800 domains, 1800 domains, 1400 domains!? Right..... Christ, no wonder SunTrust had to sell off their Credit Card portfolio to my company. I find it hard to believe that number or any of those numbers as accurate. And that statement is from someone whose been in the field for about 20 years and currently works for the largest independent credit card company in the world with regional offices throughout the US, Canada, UK, and Spain. Our current NT domain structure only has 10 domains, and that includes regional resources domains. The new AD structure will only have 2 domains (North America, Europe) with exisitng regional resource domains becoming OUs in the AD infrastructure, that domain number will move up to 3 if we establish a presence in the Pacific rim.
800, 1400, 1800 domains. Give me a break. What did they do, have a domain for every department in every regional site throughout the country equating to about 10 people per domain, who are you trying to kid? I'd be more inclined to believe that might have been the nubmer of explict 2-way trusts between single NT domains they had to maintain in their poorly designed NT infrastructure as opposed to actual number of domains.
Also, your AD domain design numbers of 12, 23, and 17 are a tad bit high (imho). They should probably fall more in the 2 to 10 range, but there may be some overall design requirements I'm not privy to.
If you want to slam someone fine, at least get your real world numbers believable, which they're not. | |
| B4yaman3 2004-01-02, 11:47 am |
| Well.. Well.. This thread seems to be Hott!!I don't think we should be slamming each other is here.
Curiousgeorge I think you took it a little far by talking about book knowledge. I think we all have book knowledge and we all placed it into practice. Not because you worked for those companies means that you know it all.
I also think you both are saying the same things but in different words. | |
| curiousgeorge 2004-01-06, 1:25 am |
| Actually, Spid, you are correct. AmSouth and Suntrust had a separate NT domain for every branch at their bank. AmSouth chose to migrate their design based on a corp level domain for administration and departments as child domains. Suntrust chose a design based on geographic region.
State Farm has a design based on region and division. I didn't say they HAD 800 domains. I said according to JB, he would have created 800 based on his book knowledge of AD design.
12, 23, and 17 are not high at all for national and international companies that have multiple divisions and hundreds to thousands of geographic locations.
You said your company is migrating to two domains. You guys really must be one big happy family. That's hard to believe that absolutely everyone on each continent is willing to have the exact same security settings. Remember- domains are a security boundary. If someone requires different security, they must be placed in a separate domain. I find it very hard that a credit card processing company doesn't require different security for each country or division. I think you might be a little misinformed on the future AD design.
I'm working at a University right now that has every department (about 30) in their university as their own FORREST! I've never seen ANYTHING this bad.
Once you get some real world experience at other companies, you'll see that the designers of directory services in some companies don't really grasp the concept of a well thought-out design.
Those numbers are actually very common in large companies. | |
|
| My apologies for being snippy, and misreading your post.
Yes we are one big happy family. I am involved in our enterprise migration, and no I'm not uninformed. 1 Forest Root, 2 Domain Roots (NA, Europe), and 4 levels/sublevels of OUs with the quantity of OUs per level/sublevel ranging from 4 to 20, I will not go into more detail as infrastructure design is confidential information.
As you have difficulty grasping our AD migration, I had difficulty grasping your experiences (well, I mean what I thought you were saying - collapsing 1800 existing NT domains to 23), but please don't preach to me about gaining more real world experience with other companies (*laugh*), as I have quite a bit, and not with one company as you eluded to, although I'm not naive enough to think I know it or seen it all. 
(Geez, 30 Forests!, that's crazy.)
Spid extends an olive branch in hopes of burying the hatchet | |
| em_ar_ducks 2004-01-06, 9:04 pm |
| The original intent of the initial question on this post was to understand a bit about when to use a "child domain, a tree linked in the forest and an external trust."
From my point of view, any design effort is an exercise in balancing varying "requirements" to reach a functional goal.
There are pretty clear statements and guidance from Microsoft on how they envision a system to be set up.
Experience also teaches us that you can't always do things "by the book".
"Greenfield" designs are generally easier than upgrades, unless they are done without adequate planning (sounds like how the university ended up with 30 forests). Based on some of the responses, upgrading a large existing infrastructure is probably the most challenging design exercise to perform.
In my experience, ascertaining the existing requirements is only the beginning of the process.
Anyway, Heath and Happiness to all in the New Year, and keep the discussions lively... | |
| Blubells 2004-01-19, 5:21 pm |
| Ummmmm...
Let me get this straight ( I sit the exam in 3 weeks by the way so SOMEBODY better be right on this one :P )
The way I read it.. I'm using the New Riders guide here, as well as my companies pathetic excuse for an AD setup.. \use child domains if you need to seperate trees in the forest:
i.e BluBells.com , RND.Blubells.Com, Examssuck.Blubells.com .... you get the picture.
Use OU's only if you want to keep a single domain tree, but want to DELEGATE some small part of the namespace to delegated administrators...
Am I right in my thinking?
The Difference Between Dreams And Accomplishments is Merely Desire | |
| jeff_j_black 2004-01-19, 7:43 pm |
| Ah the thread that will not go away!
Anyway, for 217 most of this thread is too deep. Sounds like you have a reasonable grasp of the basics.
Seperate domains can be used to allow for differing password or account policies; seperation of domain administration privilidges; or to control replication of the domain partition.
OU's are used for administrative delegation which is accomplished by setting permissions on Active Directory objects to allow different personnel within the organization to have different levels of control over those objects. (Manage user and computer objects, etc.)
Good Luck! |
|
|
|
|