[W2003] 2 domeinen in 1 forrest

[Aakab]

Ik heb nu 2 domeinen draaien binnen de zelfde forrest (blabla.nl, blablb.nl). Ik wil dat de gebruikers , indien de DC van blabla.nl niet beschikbaar is, ook kunnen inloggen via de DC van blablb.nl. De AD's moeten dus op beide domeinen het zelfde zijn, of het moet regelbaar zijn dat een select aantal gebruikers zowel op blabla.nl als op blablb.nl kunnen inloggen (universal groups?).

Hoe pak ik dit aan?

De search helpt me met Windows 2003 niet verder. Ook op technet komt er vrij weinig uit.

[Aakab]

kleine kick!

[djluc]

Een trust lijkt mij een logische oplossing?

[Question Mark]

djluc schreef op vrijdag 22 juni 2007 @ 13:26:
Een trust lijkt mij een logische oplossing?

Kan niet, authenticatie zal altijd plaatsvinden door een DC van het domain waar de user lid van is. Bovendien heeft TS het over één forest, de domain hebben dus al een (transitive) trust.

De enige optie om redundant te worden is het plaatsen van extra DC's in beide domeinen, of beide domeinen naar één domein toe migreren.

[ Voor 10% gewijzigd door Question Mark op 22-06-2007 13:30 ]

[Ranja_Ranja]

Beide als GG inzetten?

[Aakab]

Ze zijn beide ook GC's.

[Aakab]

Question Mark schreef op vrijdag 22 juni 2007 @ 13:27:
[...]
Kan niet, authenticatie zal altijd plaatsvinden door een DC van het domain waar de user lid van is. Bovendien heeft TS het over één forest, de domain hebben dus al een (transitive) trust.

De enige optie om redundant te worden is het plaatsen van extra DC's in beide domeinen, of beide domeinen naar één domein toe migreren.

Hoe zit het dan met universal groups en als ze beide GC zijn?

[sanfranjake]

Toch zal een user een dc in z'n eigen domein moeten benaderen. Het password en andere attributen die nodig zijn voor een succesvolle login zijn nimmer nooit aanwezig op een dc in een ander domein, ook niet als dit een subdomein of andere tree in hetzelfde forest is. Misschien zou je wel kunnen synchroniseren, met externe tools en scripts.

Betere oplossing is beide domeinen samenvoegen, en middels OU's een logische herindeling van je netwerk maken? Dan heb je als de ene dc uitvalt nog de tweede voor logons

[Aakab]

sanfranjake schreef op vrijdag 22 juni 2007 @ 23:39:
Toch zal een user een dc in z'n eigen domein moeten benaderen. Het password en andere attributen die nodig zijn voor een succesvolle login zijn nimmer nooit aanwezig op een dc in een ander domein, ook niet als dit een subdomein of andere tree in hetzelfde forest is. Misschien zou je wel kunnen synchroniseren, met externe tools en scripts.

Betere oplossing is beide domeinen samenvoegen, en middels OU's een logische herindeling van je netwerk maken? Dan heb je als de ene dc uitvalt nog de tweede voor logons

Volgens mij klopt het niet volledig wat je zegt, aangezien je bij GC's de te synchroniseren attributen kunt aanpassen en ervoor kunt zorgen dat alles gesyncd word..

[sanfranjake]

Dat is voor mij geheel nieuw, kan iemand dat bevestigen...
http://technet2.microsoft...3fa885a1033.mspx?mfr=true

[Question Mark]

Aakab schreef op zaterdag 23 juni 2007 @ 06:28:
[...]Volgens mij klopt het niet volledig wat je zegt, aangezien je bij GC's de te synchroniseren attributen kunt aanpassen en ervoor kunt zorgen dat alles gesyncd word..

Een Global Catalog heeft een partial read-only copy van de domain partition van alle domains in hetzelfde forest (behalve van zijn eigen domain, daar is de GC immers authoritive en heeft een read/write domainpartition van zijn eigen domain). Het klopt dus dat een GC alle userobjecten en bijna alle attributen kent. Maar, objecten kennen is iets anders dan ze kunnen authenticeren.

Kerberos authenticatie werkt op basis van twee typen tickets.

• TGT - da's het intitiele ticket wat een user krijgt als deze zich aanmeld op het domein. De TGT kan alleen verstrekt worden door een Authentication Service (AS) die op een DC draait, van het domain waar het userobject zich bevindt.
• TGS - da's een sessie-ticket, welke verstrekt wordt als een user recources binnen een bepaald domain wil gaan benaderen. De TGS wordt gecreëerd aan de hand van de gegevens welke in het TGT staan.

Kijk ook even naar de volgende technet pagina: How Domain and Forest Trusts Work

If the client uses Kerberos V5 for authentication, it requests a ticket to the server in the target domain from a domain controller in its account domain. The Kerberos Key Distribution Center (KDC) acts as a trusted intermediary between the client and server; it provides a session key that enables the two parties to authenticate each other. If the target domain is different from the current domain, the KDC follows a logical process to determine whether an authentication request can be referred.

En zie ook deze technet pagina: Windows 2000 Kerberos Authentication

Authentication Service (AS). This service issues Ticket Granting Tickets (TGTs) good for admission to the ticket-granting service in its domain. Before network clients can get tickets for services, they must get an initial TGT from the authentication service in the user's account domain.