problem auf einem RODC - kann auf daten nicht zugreifen

[Jing 10]

Hi Leute eventuell kann mir wer bei dem Problem helfen. Ich schreibkurz die Vorgeschichte dazu:

 

Server bestehendes OS: WinSBS2003R2 - 2x Platten drinnen (1xSystem mit 3 Partitionen, 1x Raid 5 mit einer Datenpartition)

 

 

Ich hab nun das Win2008 EE R2 auf die leere Partition gespielt und auf einer neuen ESXI Kiste ein SBS2008 installiert. SBS 2008 läuft alles fein.

 

Anschliessend wollt ich einen RODC auf der Win2008 Kiste haben. Bis zu diesem Zeitpunkt konnte ich auf die Datenpartition zugreifen !

 

Nach installation vom RODC hatte ich null zugriff auf die Datenpartition.. Ich bekam als Fehlermeldung nur "Zugriff verweigert"

 

Was hab ich nun falsch gemacht ?

 

Als sofort Lösung hab ich nun die sbs 2008, den 2008 R2 durch das bestehende SBS2003R2 wieder ausgetauscht, weil der Ausfall mir zu lange wurde...

bearbeitet 5. Dezember 2009 von Jing

[Jing 10]

keiner ne antwort wie das zustande gekommen ist ?

[olc 18]

Hi,

 

Deine Beschreibungen lassen nur wenig Spielraum für eine Aussage. Wie bist Du denn genau vorgegangen, als Du den RODC installiert hast (Schema Upgrade, RODCPREP, Installation etc.)?

Wenden sich die Clients beim Zugriff auf die Shares unter Umständen an den RODC? Hat dieser Zugriff auf den SBS?

 

Viele Grüße

olc

[Jing 10]

siehst ich wusste gar nicht was man da noch für fragen stellen kann...

 

ok den sbs2008 beschreib ich nun nicht, das macht eh alles der assistent bzw die scripts

 

am 2008 r2 hab ich adprep /forestprp und grpprep ausgführt mit der win2008R2 dvd drinnen.

 

hat keine fehler ausgegeben

 

dann die rolle ad installiert und quasi als RODC angeklickt. dann hab ich nch das kennwort eingegeben und er wollte neu gestartet werden (nachdem er sich dupliziert hat etc..) Fehlermeldung kam keine. Als ich mich dann angemeldet hab, hab ich mir das Datenlaufwerk angesehen.. nur ich kam nicht mehr drauf.

 

Kann es eventuell daran liegen, dass noch freigaben drauf waren von der sbs 2003 maschine ?

[olc 18]

Hi Jing,

 

bei dem ADPREP fehlt das "RODCPREP". Hattest Du das auch durchgeführt?

Prepare a Forest for a Read-Only Domain Controller

 

Viele Grüße

olc

[Daim 12]

Servus,

 

ich werde zwar aus den Beschreibungen des OPs immer noch nicht schlau, doch unter normalen Umständen wenn kein RODCPREP ausgeführt worden wäre, hätte DCPROMO gestreikt und einen Fehler gemeldet.

[Jing 10]

hmm also ich bin mir nun nicht 100% sicher, aber ich glaub dass die fehlermeldung schon gekommen ist und ich es anschliessend nochmals ausgeführt hab und dann dcpromo erneut durchgeführt hab.

 

ich glaub auch nicht, dass es am rodc liegt... ich glaub das er die rechte der alten sbs2003 kiste mitgenommen hat, da ich ja die partitionen nicht neu angelegt hab und da ihm dann die rechte fehlten, zugrifen zu können.

 

als anmerkung muss ich noch sagen, dass der interne domain namen und die user alle gleich waren (auf sbs2003 und sbs2008)

[Jing 10]

hmm kann es das sein ?

 

SID und SID History

 

Sie haben nun schon mehrfach den Begriff der SID und der SID-History gelesen. Was hat es damit auf sich und warum ist das wichtig ?. Sie nutzen zwar einen Anmeldenamen und das dazu gehörige Kennwort, um sich anzumelden, aber für die verschiedenen Dienste des Netzwerks sind diese Daten nur sekundär. Intern arbeiten Computer mit Nummern oder Kennungen und so kommt es, dass jedes Objekt mit Berechtigungen eine eindeutige Kennnummer, die SID (Security IDentifier) hat. Alle Berechtigungen, z.B.: Auf Postfächer, Freigaben, Dateien und Ordner werden immer anhand dieser Nummer zugewiesen. Daher ist es auch kein Problem, einen Benutzer umzubenennen etc. Die Rechte bleiben erhalten.

 

Eine SID funktioniert natürlich nur dann, wenn diese eindeutig und einmalig ist. Daher besteht die SID aus einem domänenabhängigen Teil und einem relativen Teil. Der relative Teil ist beim Administrator immer eine -500. Auch andere besondere Gruppen und Objekte wie Gäste, LocalSystem etc. haben fest vorgegebene SIDs. Normaler Anwender starten mit einer 1000 und werden hoch nummeriert.

 

Wird nun ein Benutzer von einer Domäne zu einer andere Domäne migriert, so kann er seine SID nicht mitnehmen, da der erste Teil die Nummer der Domäne selbst ist. Wird ein Benutzer daher migriert, so wird immer ein neues Konto mit einer neuen eindeutigen SID am Ziel angelegt. Dieses neue Konto hat dann natürlich erst einmal nicht mehr die gleichen Berechtigungen wie das alte Konto, selbst wenn es gleich heißt und das gleiche Kennwort hat. Natürlich kann das neue Konto nun auch in die bisherigen Gruppen aufgenommen werden und erhält damit einen Großteil der Berechtigungen. Es ist aber für die alten Server nicht das gleiche Konto.

 

Seit Windows 2000 gibt es nun die Möglichkeit, die bisherige SID eines Kontos einem neuen Konto "zusätzlich" zu geben. Über die SID-History ist es damit möglich, dass ein migriertes Konto neben seiner neuen primären SID auch die früheren SIDs weiter erhält. Beim Zugriff auf eine Ressource werden dem Server alle SIDs (dazu gehören auch die SIDs der Gruppen, in denen der Benutzer Mitglied ist) präsentiert. Er kann also gar nicht unterscheiden, das der neue Benutzer ein "anderer" Benutzer ist. So ist es dem Anwender auch nach der Migration möglich, alle Dienste zu nutzen, die das alte Konto nutzen konnte.

 

Damit diese Funktion möglich ist, muss zumindest die alte Domäne der neuen Domäne vertrauen. Sobald solch ein Trust eingerichtet ist, besteht natürlich auch ein Risiko des Missbrauchs. So könnte der Administrator der Zieldomäne bei seinem Konto in die SID-History eines wichtigen Accounts in der Quelldomäne zuweisen und dann so arbeiten, als wäre er dieser Anwender. Damit dies nicht passiert, kennt Windows 2000 eine Funktion namens "SID Filterung". Damit können Sie steuern, welche SIDs der SID-History über einen Trust überhaupt genutzt werden können. Bei einer Migration mittels ADMT müssen Sie daher eventuell an dieser Stelle noch drehen