Frage zu SIDs

[@@@]

Moin,

hab mal ne frage zu den Win NT/2000 SIDs (Signature IDentifier):

-Wo wird die SID gespeichert?

-Welche Daten stecken in der SID?

-Wo wird sie eingesetzt?

-Wenn ich NT mit Ghost clone, bekomme ich dann Probleme mit der SID?

[echo]

Original erstellt von @@@:

<STRONG>

-Wo wird die SID gespeichert?</STRONG>

in der registry

<STRONG>

-Welche Daten stecken in der SID?

</STRONG>

die eindeutige identifizierung der maschine, also nicht der computername ist entscheident sondern die SID

<STRONG>

-Wo wird sie eingesetzt?

</STRONG>

bei jeder authentifizierung der maschine im netz

<STRONG>

-Wenn ich NT mit Ghost clone, bekomme ich dann Probleme mit der SID?</STRONG>

in einer domäne ja, mit dem programm ghostwalker kannst du die SID der geclonten maschine ändern...

alo echo...

[exe]

Hallo,

in NT4 und W2k gibt es ziemlich wesentliche Unterschiede bezüglich Verwendung der SID.

Die SID wird verwendet, um Objekte zu identifizieren. Bekannteste Beispiele sind die Benutzer, die Gruppen und die Computer.

In NT4 stehen lokale Benutzer und Gruppen direkt in der Registry und werden per SID identifiziert. Netzwerkbenutzer stehen in der SAM-Datenbank(Security Account Manager). (Es ist übrigens ein Sicherheitsleck, wenn der Aministrator-Account "Administrator" heißt...)

In W2k werden auch SIDs benutzt, allerdings heißen die hier GUIDs. Das ist vor allem wichtig, um Objekte innerhalb eines Aktive Directories zu identifizieren. JEDES Objekt im ADS bekommt solch eine Nummer. Postfächer(Exchange), Benutzer, Gruppenrichtlinien usw. alles bekommt eine eindeutige Nummer zugewiesen. In W2k stehen lokale Benutzer nicht mehr in der Registry, sobald der Rechner zu einem DC wird. (Netzwerkbenutzer stehen erst recht nicht in der Registrierung.)

Probleme beim Clonen sollte es nicht geben, zumal Ghost ab Version 5.01 in der Lage ist, die entscheidenden SIDs selbstständig zu ändern(!).

Probleme sind ausschließlich beim Clonen von DCs bzw. PDCs zu erwarten. Beispiel: Ich nehme meinen alten PDC, das ist Rechner A und an dessen Netzwerk hänge ich Rechner B. Alle entscheidenden Daten von Rechner A kopiere ich auf Rechner B, auch die Benutzerkonten usw. Dann fahre ich Rechner A runter und Rechner B benenne ich um, so daß die Computerbezeichnung(NetBIOS Name) der des Rechner A entspricht. Nach einem Neustart können sie die Clients trotzdem nicht am PDC anmelden, obwohl er so heißt, wie Rechner A, die selbe IP hat usw. Das liegt daran, daß die SID nicht zum Computername passt...

Das Selbe habe ich auch in W2k. Computer werden mit dem DNS Namen und einer dazugehörigen GUID identifiziert. Da im ADS aber die Daten(Computernamen, Benutzerkonten usw.) auf mehreren Rechnern liegen(nämlich auf den DCs der ADS-Domäne), ist der Sachverhalt hier ein bißchen komplizierter als in NT4......

Wenn noch Bedarf besteht, dieses Thema weiter zu diskutieren, stehe ich natürlich zur Verfügung.

mfg

Exe

[-TP-Hawk274]

Warum ist es eine Sicherheitslücke, wenn der Aministrator-Account "Administrator" heißt?

- Kannst du das mal erklären?

- Ist das auch bei Win2k so?

- Muss ich dann den lokoalen (?) Administrator z.b. in ADM umbenennen :confused:

[Terran Marine]

Wenn der Administrator "Administrator" heißt, haben es Hacker leichter in das System einzudringen, da sie den Benutzernamen des Admininstrators schon kennen, und "nur noch" das Passwort rausbekommen müssen.

Wenn sie erstnoch den richtigen Benutzernamen finden müssen, ist das ganze gleiche eine Stufe schwieriger.

Gruß

Kevin

[exe]

Ein normales Benutzerkonto wird standardmäßig deaktiviert, wenn ein Login 3 Mal fehl schlägt. Aber genau das passiert beim Admin Konto nicht. D.h. ein Hacker braucht bloß ein Prog drüber laufen lassen, das 2304743508952403783 mal probiert, ein PW rauszubekommen. Irgendwann klappts und das Konto wird noch nicht mal gesperrt. Und genau deshalb benennt man das Konto um.

Das ist auch in W2k so!

Der lokale Admin ist relativ unwichtig. Weil ein Angreifer von außerhalb kann relativ wenig mit einem lokalen Admin anstellen.

mfg

Exe

[echo]

Original erstellt von ExE:

<STRONG>

Der lokale Admin ist relativ unwichtig. Weil ein Angreifer von außerhalb kann relativ wenig mit einem lokalen Admin anstellen.

</STRONG>

ola...

würd ich nicht so leichtfertig behaupten - sicherlich ist das domänenadminpasswd die krönung des angriffs, aber die vorstufe ist meist ein lokaler benutzer -> und wenns der lokale admin ist solls auch recht sein - wer von aussen bis hierher kommt, ist eigendlich schon drin...

hat ein unforsichtiger admin die "SAM" datenbank im verz. c:\winnt\repair stehen lassen - im gegensatz zur SAM datenbank in c:\winnt\system32, welche geschützt ist, braucht er nur noch ein wenig glück, der domänenadmin hat sich bereits schon mal angemeldet auf der maschine - und ein gutes tool, welches die SAM auslesen kann und das disater nimmt seinen lauf...

oder so ähnlich

alo echo...

[exe]

STIMMT! Ist vollommen richtig! Das mit der SAM hab ich nicht bedacht! In W2k fällt dieses Prob aber eh weg...

[-TP-Hawk274]

Sorry das mit "SAM" habe ich nicht ganz verstanden. Bei Win2k gibt es doch auch eine im Ordner C:\Winnt\Repair\ eine SAM Datei aber ohne Endung :confused: Was heißt SAM oder besser gesagt was ist das eigentlich

ß

Den Rest habe ich aber verstanden

[exe]

SAM steht für Security Account Manager. In dieser Datenbank stehen User Account mit dazugehörigem(verschlüsseltem) PW. Desweiteren findet man hier die Gruppen und -Zugehörigkeiten.

Da auf einem DC keine Lokalen Benutzer(und Gruppen) mehr existieren, sondern die Daten im (sicheren) Active Directory stehen, ist die SAM Datenbank in W2k nur unter bestimmten Umständen ein Prob...