Gulp

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:

Wer lesen kann ist klar im Vorteil ;-) :

.. Whenever a domain controller ..... it assigns THE OBJECT ....

Hier ist das Objekt in der SAM/ADS gemeint und das hat tatsächlich eine unique SID.

Die Local Workstation SID tangiert das allerdings überhaupt nicht, richtest Du nämlich einen lokalen Benutzer ein, so hat dieser keinen Domänenanteil in seiner SID sondern nur den Deiner Maschine.

Daher spielt es sehr wohl eine, wenn auch untergeordnete, Rolle, ob man die SID's ändert oder nicht.

Die einzige Ausnahme sind die Domain Controller selbst, denn die ändern tatsächlich ihre SID, deshalb sollst Du laut MS auch niemals einen DC mit bereits installiertem ADS (oder bei NT der SAM) clonen.

Ausserdem ...

Deine angeführten Websites erzählen nur was von Rollen (beträfe nur DC's ) oder User/Gruppen, bei meiner Site ist ein explizites Beispiel der Local Workstation SID in einer Domain aufgeführt.

Greetz

Gulp

@Velius:

Ist leider nicht ganz richtig, denn die eigentlichen Rechner-SID (Local Workstation SID) wird nicht geändert, lediglich die User-SID wird für die Anmeldung und das relevante Security Token und die Trust Relationships verwendet.

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

Note: If two workstations have the same primary SID and are participating in workgroup/local authentication security, the first user account generated (and so forth) on each workstation is the same because the SID on both computers is the same. See "Consequences of Duplicate SIDs in a Workgroup Environment" for an example. More information: MS TechNet : 162001

.....

Consequences of duplicate SIDs in a workgroup environment

If a company has 500 cloned desktop computers—all with the same SID—running in a workgroup/peer-to-peer model, significant security challenges arise. Each workstation would have no way of differentiating a local account from a remote account. Restrictive access to secured files and directories through SID certification would be impossible, and tokens being used would all contain the same SID. The entire security structure based on SIDs and access tokens would be compromised. For more information see MS TechNet : 163846

Example:

\\WS1 and \\WS2 are two workstations at Netwerks Corporation. Deployed using a binary disk image–copying program, these workstations have duplicate security identifiers.

Eric on \\WS1 has a local machine account on WS1 of S-1-5-21-191058668-193157475-1542849698-1000.

Stephanie on \\WS1 has a local machine account on WS2 of S-1-5-21-191058668-193157475-1542849698-1000.

Eric is performing employee performance reviews and saving his information to C:\Data\Reviews on his local NTFS drive. He uses Windows NT Explorer to share the directory and to set the security rights so that he is the owner and only he has rights to access the files.

Stephanie is logged onto \\WS2 and is browsing the network using Network Neighborhood. She recognizes \\WS1 as Eric's machine and attempts to connect to a Reviews share that Eric created. She is given complete control over the contents because her SID (S-1-5-21-191058668-193157475-1542849698-1000) is identical to Eric's (S-1-5-21-191058668-193157475-1542849698-1000). As one can see, there is no way to differentiate WS1\Eric from WS2\Stephanie because the SIDs are identical.

Taking this to the next logical step, any data stored on removable media that are formatted using a secure NTFS scheme is no longer secure. Because duplicate SIDs exist, there is no way to completely secure sensitive data in an environment of binary duplicated machines that share an identical SID.

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.

Greetz

Gulp

Ja ist es, dazu gibts das CMD Tools ldifde (Microsoft KB Artikel 237677) .

Allerdings erfordert das in den meisten Fällen eine Anpassung der exportierten Daten.

Greetz

Gulp

Guck mal auf SYSINTERNALS, die haben recht gute (und freie) Tools zum Monitoring und mehr .... das was Du hier suchst ist RegMon ...

Greetz

Gulp

Da gibt's auch von sysinternals was kostenloses (NewSID), funzt einwandfrei und ist recht bequem zu bedienen.

Look HERE

Greetz

Gulp

GFI MailEssentials (guckst Du HIER )

kannst Du gleichzeitig als AntiSpam Suite verwenden.

Greetz

Gulp

Also ich habe erfolgreich 8 Server (win2k und win2k3) mit RemoteAgents, darunter 3 DC's (auch über RemoteAgents) auf einen Backup-Server an dem eine TapeLibrary hängt per IDR gesichert und getestet.

Funktioniert prima und ist kaum zu ersetzen.

Wenn man Data1701's Ratschläge befolgt ist's echt easy. Ich finde es deutlich schneller, da die OS Partition des 1. DC nach 20 Min voll funktionsfähig zurückgesichert war.

Die Wiederherstellungszeit hängt natürlich auch von den verwendeten Partitionsgrössen ab, aber ich spare mir 20-30 Minuten für eine rudimentäre OS Installation + 15 Minuten Installation Backup-SW .

Daher denke ich schon, dass es vorteilhaft ist IDR einzusetzen. Muss ja auch nicht bei allen Servern sein.

Greetz

Gulp

RAID 5? Da würde ich aber abraten oder mal mit ServerMagic probieren. Allerdings gibt's keine Garantie auf Erfolg.

Greetz

Gulp

Der normale 2003 Server hat ein Problem mit dem Beenden von Exchange 2003 Diensten (gibt's was in der KB dazu: MS KB Article ).

Greetz

Gulp

Du kannst nicht vom Band booten, sondern verwendest dazu die Disketten bzw die CD (sofern Du das *.iso auch gebrannt hast ;-) ).

Ich habe das mal getestet (allerdings noch mit der 9er) und es funktioniert erstaunlich gut, Diskette/CD zum Boot (bei den Disketten brauchst Du allerdings noch eine OS-CD), Verbindung zum Backup-Server wird hergestellt (sogar übers Netz, wenn Du mit RemoteAgents sicherst), Band auswählen und je nach Grösse Deiner OS-Partition (bei 8 GB brauchte es bei mir ca 20min) bist Du relativ schnell wieder voll einsatzfähig.

Greetz

Gulp