HOTSPOT
Yournetwork contains three Active Directory forests. The forests are configured as shown in the
following table.
A two-way forest trust exists between contoso.com and divisionl.contoso.com. A two-way forest
trust also exists between contoso.com and division2.contoso.com.
Youplan to create a one-way forest trust from divisionl.contoso.com to division2.contoso.com.
Youneed to ensure that any cross-forest authentication requests are sent to the domain controllers
in the appropriate forest after the trust is created.
How should you configure the existing forest trust settings?
In the table below, identify which configuration must be performed in each forest. Make only one
selection in each column. Each correct selection is worth one point.
Answer: 
Explanation:
<map><m x1=”477″ x2=”509″ y1=”70″ y2=”97″ ss=”0″ a=”0″ /><m x1=”350″ x2=”387″
y1=”245″ y2=”274″ ss=”0″ a=”0″ /></map>There will be a one-way forest trust from division1.contoso.com to division2.contoso.com
Division1 trusts Division2. Division2 must be able to access resources in Division1.
Division1 should not be able to access resources in Division2.
Can somebody explain me the question? what is needed? What does cross forest authentication mean here? and which one is appropriate dc?
0
1
Queeeestion is gon ded broked
0
3
We have 3 separate forests here, and that’s the problem here. If we were talking about different domains in the same forest then we wouldn’t have this problem.
We already have trusts between both divisions forests and contoso forest. Now we just need to create a one way forest trust between div1 and div2.
Based on this:
“When a Forest Trust is created a Name Suffix Route is dynamically added to both sides of the Forest Trust Properties. The Name Suffix Route is comprised of the DNS name suffix of the trusted forest root and a wildcard (*) precedes the DNS name suffix to allow for child domains to be trusted implicitly.”
Which means that we don’t need to creat a name suffix when create the one way trust, it will be automatically created. If we do create one, that will cause problems in authentication traffic.
So and also based on the statement below, we have to create exclusions in both divisions, despite the trust is only one way:
“When more than two Forest reside in the same DNS namespace, and the root of that DNS tree is also an Active Directory forest, logic must be added to the Name Suffix Route to ensure authentication traffic is routed to the correct forest root. This can be accomplished by adding Exclusions to the Name Suffix Routes.”
Correct answer should then be:
From division1.contoso.com: Add division2.contoso.com as an exclusion to the name suffix rounting entry of contoso.com
From division2.contoso.com: Add division1.contoso.com as an exclusion to the name suffix rounting entry of contoso.com
https://blogs.technet.microsoft.com/askds/2009/04/10/name-suffix-routing/
1
0
You right.
You dont need to add new NSRs, because it forest trust, and they add automaticaly (for example – in external trust they not add automaticaly).
So we need to add excludxion of divisionX. to *contoso.com routing suffix on both division sides
0
0
Any positive on this answer? I kinda follow what Wayne is saying but I don’t know if the Name Suffix is added to both sides automatically with a one way trust like the question states is setup between 1 and 2.
0
0
I think I get this now, but I would like confirmation from someone.
So, you need to create a Name Suffix Route on Div2 for the Div2 users to access the resources in Div1. Creating the Div2 exclusion on the Contoso.com Name Suffix Route is to make sure the authentication of the Div2 users happens on the Div2 DC’s. If it wasn’t for that exclusion, the Div2 users, because they don’t exist in Div1, would be re-routed to the forest root for authentication. This authentication path will fail as the Div2 user accounts don’t exist in the Contoso domain. Excluding Div2 on Contoso.com forces the authentication back to the proper domain. Right?
0
0
Answer should be:
x
x
x
x
Currently any attempt to authenticate a division1 user in division2 gets sent to contoso instead of division1 and visa versa.
You need to do the following:
1) block the request from going to contoso (add exclusion)
2) tell it where to route the authentication (Name Suffix Routing)
You add the values for the other forest to the forest you are in as division1 needs to know where not to send requests for division2 and where to send requests for division2.
0
0
Didn’t format properly:
OX
XO
OX
XO
0
2
It says to only make one selection in eac column so your answer is wrong.
0
0
Your right, one way trust.
Given answer is correct then.
0
1
Ok, so to put it to rest: the question says 3 forests, so regardless of the apparent link, these are three completely non-related domains. Which means that there’re no inherent trusts between them. Now, the question starts with two bidirectional forest trusts, so we know, that all routing entries are in place for the namespaces.
Having said that, we need to ensure, that the trusted domain (child2) can properly send its requests to the trusting domain (child1) resources, instead to the third domain, therefore, we need to create a routing entry for the name suffix in child2. Child1, also needs to be able to route back any authorization queries to the DCs of child2, so we need to set exclusions in child1 for child2, so they don’t get send to the DCs in contoso.com.
After all this, I hope you can see, that the provided answer is correct!
0
1
I don’t think what I’m reading is right. The question says “How should you configure the EXISTING forest trust settings?”
NOT the NEW forest trust we’re planning.
The EXISTING forest trusts both need to be configured not to send authentication requests for division?.contoso.com to the contoso.com forest. Because authentication requests for division?.contoso.com will go along the proposed NEW forest trust.
I don’t think it matters that the NEW trust will be one way, because each forest will still need to know how to get to the other forest’s computers.
So I’m going for:
0 0
0 0
0 X
X 0
2
0
This is the CORRECT Answer.
OO
OO
OX
XO
2
0
A bit more… I just created a one-way forest trust. Both sides had a name suffix created automatically for *.. Surprised me a bit that they both did.
I think the existing name suffixes are:
division1.contoso.com has a name suffix for *.contoso.com
division2.contoso.com has a name suffix for *.contoso.com
contoso.com has 2 name suffixes, for *.division1.contoso.com and *.division2.contoso.com
The new one-way trust will be from division1.contoso.com to division2.contoso.com (division2 is trusted). So I suppose both of these domains will get a new name suffix for the other domain.
What might be another clue is that in ADDT on the trust properties, Name Suffix Routing tab, the name suffixes are listed under the text “Name suffixes in the xyz forest”. So my guess is that regardless of the direction of trust it just needs to know which suffixes are in use in which forests. So I’ll stay with the same answer.
0
0
Provided answer is correct!
https://span.eu/en/2016/09/kerberos-conflicting-upns/
Read that website’s scenario. Explains perfectly why routing of division2.contoso.com would have issues unless routing exclusion input.
0
0
This question was in my exam today but they had changed the domain names. I passed with 793 on 8th nov 2017, this dumps are 100% valid but you need to understand the reasoning behind every questions. Thank you to those who spent their time in posting solutions here.
1
1