zwei gleiche Systeme erstellen

[Gulp 226]

Und wieso verliert dann z.B. der LOKALE Admin nicht seine Zugriffsrechte auf der Machine, wenn der Rechner in die Domain geschoben wird?

 

Seine SID ist nicht in der Domain gespeichert, die SID wird nicht geändert. Dennoch behält er alle Verwaltungfunktionen des LOKALEN Rechners.

 

Wo speichern denn DC's die SID's der Objekte? Doch in der ADS ... und nicht auf dem zu dem Objekt gehörigen Rechner.

 

Selbst die domänenrelevanten Teile der Registry werden doch, salopp gesagt, nur über die lokale Registry geladen (die lokale wird keinesfalls ersetzt).

 

Wo sollen denn nach Deiner Meinung die Kennwörter der LOKALEN User und Gruppen gespeichert sein, wenn die lokale Workstation nichts mit SID's am Hut hat.

 

Ich für meinen Teil meinte und meine immer noch die LOCALE WORKSTATION SID, die hat mit der Domain, den Betriebsmasterrollen und dem RID-Master so ziemlich gar nichts am Hut.

 

Aus Deiner Argumentation folgere ich lediglich, dass ich mich um lokale SID's anscheinend nicht kümmern muss, da es ja anscheinend keine gibt. Objekte wie neue lokale Benutzer und Gruppen kann ich ja eh nicht anlegen, da meine XP Pro ja kein RID-Master sein kann. Na herzlichen Glückwunsch ...

 

Trotzdem ... freundliche Greetz!

 

Gulp

 

P.S. Sicher gibt es für eine Workstation einen Computer Account und ja dieser hat auch eine unique SID, der bei dem Domänenbeitritt generiert wird. Dennoch wird dieser Account nicht auf der LOKALEN Workstation hinterlegt, sondern im ADS, genauso wie ein Domänen-USER und genau da ist doch der Hase begraben. Die Domain-SID hat nichts mit den lokalen SID's der Workstations am Hut.

[Velius 10]

Du kannst ja mit deinem XP auch nicht deiner XP Domain beitretten, oder?

 

Wenn du den zweiten Link, und deinen eigenen aufmerksam gelesen hättest, dann wäre dir aufgefallen, dass sogenannte built-in accounts immer die gleiche SID haben. Deswegen gibt es auch in einer Domäne eine Information mehr, nähmlich der Domänen Teil der SID. Somit ist es dem AD möglich, unter den verschiedenen Domain Admins beispielsweise zu unterscheiden, denn andernfalls hätten alle in dieser Gruppe in allen Domänen die gleichen Rechte.

 

Nur nochmals zu Klärung:

Standartmäsig hat ein ein Mitglied der Gruppe "Domain Admins" das gleiche Rechte, wie ein anderes Mitglied dieser Gruppe in einer anderen Domain. Allerdings, wenn man dieser Gruppe ein recht Verwehrt, oder explizit erteilt, auf NTFS beispielsweise, dann wird das nicht automatisch auf alle Domänen Admins einer Organisation übertragen, sondern nur dieser einen.

 

 

Na, ist jetzt alles klar?

 

Wenn du mir nicht glaubst, dann kannst du auch gerne hier unter Well-known SID´s nachsehen gehen.

 

 

Wie sich das Verhalten auf einen lokalen nicht built-in Benutzer auswirkt, wenn der Rechner einer Domäne beitritt kann ich jetzt nicht genau sagen, spielt aber inerhalb einer Domäne keine Rolle da in Domänen in der Regel nicht mit lokalen Benutzern (also in der lokalen SAM das Computers) gearbeitet wird.

[Gulp 226]

.... ich frag mich wirklich, ob ich hebräisch schreibe.

 

Wieso glaubst Du hebe ich eigentlich immer das Wort LOKAL hervor? Lokal ist lokal und nicht Domain! Ist es wirklich so schwer zu begreifen?

 

Ich habe nicht die Domain SID's im Blick sondern die LOKALEN auf der Workstation. Diese SID (und ja die haben eine - zufällig generiert beim Setup) ist bei geclonten Rechnern identisch.

 

Da in einer Domain diese SID NICHT für Prozess Tokens und Trust Relationships herangezogen wird, sondern die SID des im ADS gespeicherten Objetktes (User/Gruppe/Machine Account), kommt das Problem nur selten zu Tage.

 

Habe ich vorm Clonen der Workstation Useraccounts LOKAL erstellt können diese User untereinander auf Daten der geclonten Workstations zugreifen, da ihre lokale SID identisch ist. Genau das ist das entscheidende Problem. Wären die Benutzer auf verschiedenen Systemen erstellt worden, so wäre das nicht möglich, da sich deren SID unterscheidet.

 

Natürlich misslingt ein solches Szenario auch nach einer Änderung des Passwortes des Users TEST auf einer der geclonten Maschinen.

 

So ... jetzt alle Unklarheiten beseitigt?

 

Greetz

 

Gulp

[Velius 10]

Der schnellste Weg wäre natürlich wenn ich die Festplatte clonen würde sie wieder in den zweiten Pc einbaue Computername und Useranmeldung ändere und in dann ins Netz hänge, aber funktioniert das auch, gibt es da nicht Probelme mit einer ID, oder wie kann ich das noch lösen.

 

Deine Argumentation ist akzeptiert, nur spricht der TO von Netz. Ich schliesse daraus eine Domain, und ich habe schon im allerersten Thread meinerseits von einer Domain gesprochen:

 

Du brauchst kein Tool, um einen geklonten Rechner in eine Domäne aufzunehmen, denn jeder Rechner erhält bei der Aufnahme in eine Domäne eine neue SID. Probleme gibt's nur, wenn du eine PC der bereits Mitglied einer Domäne ist duplizierst.

 

 

Dann kam erst dein Einwand, welcher für eine Domain nicht richtig ist. Wenn wir von einer Workgroup sprechen, dann kommt's natürlich zu den von dir genannten Problemen.

Na? Ist jetzt alles klar?? ;)

 

 

 

EDIT:

 

Duplicate SIDs aren't an issue in a Domain-based environment since domain accounts have SID's based on the Domain SID. But, according to Microsoft Knowledge Base article Q162001, "Do Not Disk Duplicate Installed Versions of Windows NT", in a Workgroup environment security is based on local account SIDs. Thus, if two computers have users with the same SID, the Workgroup will not be able to distinguish between the users. All resources, including files and Registry keys, that one user has access to, the other will as well.

 

http://www.sysinternals.com/ntw2k/source/newsid.shtml

[Gulp 226]

Dann kam erst dein Einwand, welcher für eine Domain nicht richtig ist. Wenn wir von einer Workgroup sprechen, dann kommt's natürlich zu den von dir genannten Problemen.

Na? Ist jetzt alles klar?? ;)

 

Hehe, schon ... aber mein Einwand ist durchaus richtig ... denn das Problem ist eben nicht von einer Domain abhängig, es tritt dort nur weniger zu Tage.

 

Consequences of duplicate SIDs in a domain environment

 

If you had the same 500 disk-imaged desktop computers running in a domain model, all with the same SID, the impact is significantly lessened. All users are logging into a domain and are being assigned a domain-based user SID. This SID is, by nature of the domain model, guaranteed to be unique and can be used to secure files and resources within the network. The Security Account Manager has no problems distinguishing users because they are coming from a common, centralized domain security database and all processes and tokens are running within each user's security context. Note You will still have local security issues when dealing with local machine accounts (administrator, guest, etc.) as outlined above.

 

Also tut man durchaus gut daran die SID zu ändern ... und genau das war mein Einwand.

[Velius 10]

Ich kann jetzt nicht nachweislich wiederlegen, dass die lokale SID eines Rechners beim Beitretten einer Domäne nicht, sondern "nur" im AD angepasst wird, aber dein Einwand hat trotzdem keine Relevanz, da du egal welchen SID changer du einsetzen wirst, die SID der lokalen Benutzer Konten nicht ändern kannst:

 

http://www.sysinternals.com/ntw2k/source/newsid.shtml

 

NewSID

NewSID is a program we developed to change a computer's SID

 

 

 

http://www.microsoft.com/technet/archive/ntwrkstn/deploy/depopt/cloning.mspx

 

The System Preparation tool will modify the initial Unique SID section but will not traverse the SAM and change all of the user accounts' SID prefixes to match the new SID. Account Unknown errors will be generated, and the administrator will need to recreate all user accounts again. The System Preparation tool will not traverse an NTFS partition to modify file permissions with the new SID information.

 

 

Und mit lokalen, built-in Konten auf Ressourcen auf anderen, geklonten Rechnern in einer Domäne zu zu greiffen ist doch schwachsinn, oder?

[Gulp 226]

Ob Schwachsin oder nicht .. ;-)

 

Es ist ein Sicherheitsrisiko und kann tatsächlich zu Problemen führen, denn das habe ich schon mehrfach am eigenen Leib erfahren dürfen.

 

Ich denke Du hast meinen Gedankengang noch nicht ganz "gefressen".

 

Also Built-In-Accounts haben, wie Du richtig bemerkt hast alle die gleichen Benutzer-SID's. Maschinen-SID's sind verschieden (normalerweise, bei nicht geclonten Workstations). Die Kombination Benutzer+Maschinen-SID ergibt bei lokalen Zugriffen (standardmässig in einer Workgroup, dennoch möglich in einer Domain) grob gesagt die Berechtigung auf die Daten oder das Token. Sind die Maschine-SID's alle gleich, die Built-In Accounts sinds ja auch hast Du - Bingo - mit einem einzigen Useraccount Zugriff auf alle SID-Duplikate.

 

Na, und das soll in einer Domain keine Rolle spielen?

 

Ich gebe zu, dass es nicht ganz so einfach ist, aber ein Leck ist es allemal!

 

Greetz

 

Gulp

 

PS: .... und in Deinem Link steht es ja auch ganz klar:

 

The problem with cloning is that it is only supported by Microsoft in a very limited sense. Microsoft has stated that cloning systems is only supported if it is done before the GUI portion of Windows Setup has been reached. When the install reaches this point the computer is assigned a name and a unique computer SID. If a system is cloned after this step the cloned machines will all have identical computer SIDs. Note that just changing the computer name or adding the computer to a different domain does not change the computer SID. Changing the name or domain only changes the domain SID if the computer was previously associated with a domain.

[Velius 10]

Alles ****sinn :( (Wieso reden die auch immer so um den heissen Brei....??)

 

Ich hab's nachgestellt, und habe micht durch die Aussage "Every user account and workstation or server running Windows NT on your network is issued a unique SID when the account is first created or the computer joins a domain" irritieren lassen.

 

Scheinbar übernimmt AD die Computer SID, und hängt noch die RID dran oder so. Folgende Aussage trifft es am besten:

 

Wenn Sie jedoch beide Computer in derselben Domäne oder Arbeitsgruppe verwenden wollen, kann immer nur einer der Computer angemeldet sein, sofern Sie nicht die Identifizierung von einem der beiden Computer ändern, bevor Sie versuchen, den Computer in der Domäne anzumelden. In den folgenden Abschnitten wird erläutert, wie Sie die Identifizierung des Zielcomputers ändern können.

 

Einführung in das Duplizieren eines Windows NT-, Windows 2000- oder Windows XP-Computers

 

 

Folgendes habe ich versucht:

Zweite HDD in einen Rechner und ein disk-to-disk Image mit Ghost. Die zweite HDD habe ich dann wieder in den ursprünglichen Computer gepackt.

Anschliessend habe ich mich versucht mir beiden Rechnern an der Domäne anzumelden. Fehlanzeige, es geht nicht, denn es gibt nur ein Computerkonto für beide Rechner. Einer der beiden hatte immer Probleme wie "Computerkonto existiert nicht" usw.

 

 

Na ja, damals mit Ghost Corporate habe ich scheinbar ohne gross nachzudenken noch den Ghostwalker drüber rasseln lassen....

 

 

Fazit:

Es braucht irgend ein Tool, entweder Sysprep, NewSID, oder Ghostwalker oder wie sie alle heissen.

Allerdings wird damit nur die SID des Computers angepasst.

 

 

Grüsse

Velius

[Manichan 10]

Das nenn ich mal eine interessante Meinungsverschiedenheit:) Ist ja fast so spannend wie Star Wars:)

[Gulp 226]

Spannend? Ja, tatsächlich und ich muss echt sagen ich hab's auch noch genossen. Mit Kollege Velius kann man offensichtlich auch trefflich diskutieren.

 

Die Geschichte um die SID und wo diese kleinen possierlichen Tierchen (um es mit Grizmek's Worten zu sagen)überall auftauchen, ist auch nicht ganz so einfach, wie man es immer glauben möchte.

 

Wie man sieht hat sich Velius die Mühe gemacht und sogar dafür ein eigenes Testscenario aufgebaut. Da ziehe ich Mal meinen Hut ....

Dennoch macht es klar, dass die Computer-SID's keineswegs ignoriert werden sollte. Schliesslich gibt es immer wieder Anwendungsfälle in denen duplizierte Computer-SID's auftauchen (können) und sich nicht unbedingt zwingend an einer Domäne anmelden müssen, auch wenn die Computer Teil der Domäne sind.

 

Und ja, ich kann Velius bestätigen, die SID des im AD abgelegten Computerkontos besteht aus der lokalen Computer-SID und eines Teils der Domänen-SID.

 

Erstaunlicherweise kommt es bei duplizierten Computern aber nicht immer zu dem von Velius beschriebenen Problem, da ich auch schon in einer NT Domäne "erfolgreich" zwei geclonte Workstation gleichzeitig angemeldet hatte.

 

Bei Windows 2000 und 2003 scheinen mir allerdings Velius' Versuchsergebnisse (wohl wegen der konsequenteren Verwendung von SID , RID und der gesteigerten Objektmöglichkeiten im ADS selbst) ohne Ausnahme zuzutreffen, denn da konnte ich bisher nur die geichen Ergebnisse erzielen wie Velius.

 

Aprospos StarWars ..... da freue ich mich auch schon drauf!

 

Greetz

 

Gulp

[Velius 10]

Ja, das stimmt, denn ich war auch der Meinung, dass ich schon erfolgreich zwei geklonte Rechner (nicht mit SID changer Tool bearbeitet) an der selben Domäne hatte.

 

Bei Symantec steht das so (aber nur auf Englisch):

 

In a domain, Windows NT/2000 does not allow two computers having the same SIDs to log on to the domain. In addition, Windows 2000 domains rely more heavily on the SID as a unique token for administering and controlling security than Windows NT 4 domains, which base security access on domain user names and passwords.

 

 

Gruss

Velius

 

 

P.S.: So'ne grosse Mühe war's gar nicht; nur mal kurz zwei Rechner auseinander genommen.... :schreck: :p