ERLEDIGT SID für User ändern (Benutzer-ID manuell belegen)

V

Vanillekipferl

0
Ich denke bei meiner Frage hab ich hier genau das richtige Forum gefunden.



Ich möchte für einen Windowsuser die Benutzer-ID selber setzen. Diesen Teil:

S-1-5-21-7623811015-3361044348-030300820-78042

Den schwarz markierten Teil, der Teil der die Domäne beinhaltet, kann man zb. mit Tools wie NewSID von Sysinternals ändern. Aber wie den Benutzer-Teil?
500 ist reserviert für den Administrator
501 für den Gast
Die selbst definierten Konten beginnen mit 1000. Legt man einen weitern User an, bekommt der die ID 1001. Aber das wisst ihr ja sicher bereits.

Nun will ich zb. einen User haben, der die ID 590132 hat.
also S-1-5-21-7623811015-3361044348-030300820-590132
Wie stellt man das am besten an?

Eine Variante ist mir spontan eingefallen ist, ich lege einfach so viele User an, bis ich bei der gewünschten ID bin.
Hab hierzu eine Batch-Datei geschrieben: for /L %%n IN (1,1,1000) DO net user dummy%%n /add
Die Schleife legt zb. 1000 Dummy-User an, ich erhöhe den Benuzter-ID-Zähler somit um 1000.
Ich könnte jetzt eine Schleife mit Schleifenzähler 590000 schreiben der 590000 Benutzer-Neuanlage-Befehlen durchführt, aber schon allein die Durchlaufzeit dafür beträgt mehrere 100 Stunden.

2. Variante: Kann man dem System nicht irgendwie sagen, dass der ID-Pool, nicht bei 1000, sondern erst bei 590000 starten soll? Bin da auf Schlagworte wie RID-Master, ntdsutil.exe und Konsorten gestoßen, bin mir aber nicht sicher ob damit das was ich will realisiert werden kann.

Verwende WinXP Pro Workgroup-Betrieb.

Könnte bei Bedarf auch auf ein Server Betriebsystem mit Domäne (NT 4 Server, Win2003 Server) umsatteln, falls das für mein Vorhaben unumgänglich ist.


(3. Variante)
In der SAM habe ich durch das Programm SAMinside gesehen wird auch noch die RID, also die Benutzer-ID gespeichert. Leider kann ich sie im SAMinside
1. nur bis max. 65535 raufkorrigieren (warum nur bis 65535?)
2. und selbst dann, kann ich die Daten nur aus der SAM exportieren und nicht damit zurückschreiben. Mit welchem Programm kann ich sie auch zurückschreiben?

Die SAM mit einem Hex Editor editieren:
Ich finde zwar im Klartext den Benutzernamen meines Users, danach kommt 3-4 Zeilen Sonderzeichen-Kaudawelsch. Welche Hex-Blöcke danach stehen für die RID?


Hat jemand eine einfachere, schnellere Idee als Variante 1?
 
Warum willst du die ID denn unbedingt festlegen? Evtl. lässt sich das eleganter lösen.
 
Hintergrund: Ich hab eine RDP Datei die ein gespeichertes Passwort hat und will diese benutzen.
RDP verschlüsselt das eingegebene Passwort aber mit der SID des Users, der das Kennwort eingespeichert hat. Somit funktioniert die RDP Verbindung nur wenn der User draufklickt, der sie erstellt hat. Bzw. nur wenn der User, der die gleiche SID hat, draufklickt.


Irgendwie muss man die SID (RID) doch beeinflussen können? Immerhin muss das Betriebssystem ja irgendwo eine Art "RID-Counter" speichern um zu wissen welche RID als nächstes vergeben werden muss. Und auch genauso speichern wer, welcher SID zugeordnert ist.
 
Original von Schlumpf2009
ich denke du bist nicht der user dem die rdp datei gehört kann das sein ;)
Zum Vergrößern anklicken....
Lass doch bitte dieses Hilfssheriff getue.

@Vanillekipferl:

Ich habe dein Problem nun verstanden und mich etwas umgeschaut.

Selbes Problem hier:
https://www.administrator.info/index.php?content=16378
http://www.delphipraxis.net/topic112211.html
Wahrscheinlich kommst du nicht darum herum, ein Tool zu schreiben welches in diese Richtung geht.


RDP File Format Informationen:
http://dev.remotenetworktechnology.com/ts/rdpfile.htm

Man könnte ein Tool schreiben, welches ein RDP File erstellt, und das PW mit der (vor Ort ausgelesenen) RID verschlüsselt. Das Tool müsste lediglich vom user ausgeführt werden - mehr nicht.
 
Original von 90nop

@Vanillekipferl:

Ich habe dein Problem nun verstanden und mich etwas umgeschaut.

Selbes Problem hier:
https://www.administrator.info/index.php?content=16378
http://www.delphipraxis.net/topic112211.html
Wahrscheinlich kommst du nicht darum herum, ein Tool zu schreiben welches in diese Richtung geht.
Zum Vergrößern anklicken....

Hallo

Den Quellcode auf der Delphi Homepage kenn ich schon.
Das ist nicht von diesem "Jerry", sondern das hat der junge, talentierte Programmierer "Remko Weijnen" gemacht:

http://www.remkoweijnen.nl/blog/2007/10/18/how-rdp-passwords-are-encrypted/

Das Problem ist aber, dass dieser Quellcode im Kern die Windows API-Funktion CryptProtectData verwendet, die Microsoft geschrieben hat. Und die Arbeitet leider so, dass sie das eingegebene Passwort mit der SID verschüsselt. Und die zugehörige CryptUnProtectData arbeitet so, dass sie fix die SID des gerade angemeldeten Users hernimmt und sie beim Dekrypten einfließen lässt.

Will man ein verschlüsseltes RDP Passwort entschlüsseln, ist das zwar keine große Hexerei, aber muss man der Benutzer "sein" der es verschlüsselt hat.
 
Das Problem ist aber, dass dieser Quellcode im Kern die Windows API-Funktion CryptProtectData verwendet, die Microsoft geschrieben hat. Und die Arbeitet leider so, dass sie das eingegebene Passwort mit der SID verschüsselt. Und die zugehörige CryptUnProtectData arbeitet so, dass sie fix die SID des gerade angemeldeten Users hernimmt und sie beim Dekrypten einfließen lässt.
Zum Vergrößern anklicken....
Dann verteilst du ein Tool an alle Clients, welches das RDP PW entschlüsselt enthällt. WIrd das TOol gestartet, erstellt es die RDP Verbindungsdatei, und verschlüsselt dabei das PW mit der RID das aktuellen Nutzers. :)
 
Original von 90nop
Das Problem ist aber, dass dieser Quellcode im Kern die Windows API-Funktion CryptProtectData verwendet, die Microsoft geschrieben hat. Und die Arbeitet leider so, dass sie das eingegebene Passwort mit der SID verschüsselt. Und die zugehörige CryptUnProtectData arbeitet so, dass sie fix die SID des gerade angemeldeten Users hernimmt und sie beim Dekrypten einfließen lässt.
Zum Vergrößern anklicken....
Dann verteilst du ein Tool an alle Clients, welches das RDP PW entschlüsselt enthällt. WIrd das TOol gestartet, erstellt es die RDP Verbindungsdatei, und verschlüsselt dabei das PW mit der RID das aktuellen Nutzers. :)
Zum Vergrößern anklicken....

Sorry das versteh ich nicht ganz.

Ein Tool das das PW entschlüsselt enthält? Aber ich hab das entschlüsselte PW ja nicht, das ist das Problem. Ich hab es verschlüsselt, in Form von vielen schönen buntgemixten Zahlen und Buchstaben
 
Original von Vanillekipferl

Ein Tool das das PW entschlüsselt enthält? Aber ich hab das entschlüsselte PW ja nicht, das ist das Problem. Ich hab es verschlüsselt, in Form von vielen schönen buntgemixten Zahlen und Buchstaben
Zum Vergrößern anklicken....


ne frage is das ein interner rdp account aus dem netzwerk oder einer der auch ausm internet erreichbar is ?

und habe ich es richtig gesehen das der user die nummer S-1-5-21-7623811015-3361044348-030300820-590132 haben soll
 
Sorry das versteh ich nicht ganz.

Ein Tool das das PW entschlüsselt enthält? Aber ich hab das entschlüsselte PW ja nicht, das ist das Problem. Ich hab es verschlüsselt, in Form von vielen schönen buntgemixten Zahlen und Buchstaben
Zum Vergrößern anklicken....
sorry, das habe ich anders aufgefasst. Du hast eine RDP Datei, und möchtes das PW darin knacken? Du weist die SID+RID des Users der die RDP Datei gehört. Dann hast du ja Zugang zu diesem Rechner - ---> http://wareseeker.com/Security-Privacy/remote-desktop-passview-1.00.zip/308902
 
Original von Schlumpf2009
ne frage is das ein interner rdp account aus dem netzwerk oder einer der auch ausm internet erreichbar is ?
Zum Vergrößern anklicken....

Es ist ein RDP File mit Account und Passwort, das in einem Netzwerk verwendet wird.

Original von Schlumpf2009
und habe ich es richtig gesehen das der user die nummer S-1-5-21-7623811015-3361044348-030300820-590132 haben soll
Zum Vergrößern anklicken....

Mja, die angeführte Zahlenfolge war mehr ein Beispiel, aber der User hat eine bestimmte, mir bekannte SID

Original von 90nop
sorry, das habe ich anders aufgefasst. Du hast eine RDP Datei, und möchtes das PW darin knacken? Du weist die SID+RID des Users der die RDP Datei gehört.
Zum Vergrößern anklicken....

Genau! Ich hab die RDP Datei, ich hab die SID des Users mit der das PW in der RDP verschlüsselt vorliegt.
Ich weiß nur nicht, wie ich meinen Computer dazu krieg, diese SID anzunehmen oder zu simulieren. (Außer x-tausend Dummyuser anzulegen, bis er auf die gewünschte SID hochspringt)

Original von 90nop
Dann hast du ja Zugang zu diesem Rechner - ---> http://wareseeker.com/Security-Privacy/remote-desktop-passview-1.00.zip/308902
Zum Vergrößern anklicken....

Das Tool kenne ich auch schon, funktioniert aber ohne die richtige SID auch nicht.
Steht sogar in der Readme des Tools:

Be aware that Remote Desktop PassView can only recover the passwords
created by your current logged on user. It cannot recover the passwords
of .rdp files created by other users.
 
Gibt es für Windows so etwas wie strace? Wenn ja, könntest du ja rein theoretisch die DLL, die für die User-Erstellung zuständig ist, tracen lassen während du einen neuen User erstellst. Dabei solltest du dann imho sehen können, wo die ID für den nächsten User gespeichert wird. Es könnte allerdings auch sein, dass sich das System einfach die IDs aller User ansieht und die höchste einfach um 1 erhöht, in dem Fall könnte das ganze komplizierter werden :)
 
Original von farhaven
Gibt es für Windows so etwas wie strace? Wenn ja, könntest du ja rein theoretisch die DLL, die für die User-Erstellung zuständig ist, tracen lassen während du einen neuen User erstellst. Dabei solltest du dann imho sehen können, wo die ID für den nächsten User gespeichert wird. Es könnte allerdings auch sein, dass sich das System einfach die IDs aller User ansieht und die höchste einfach um 1 erhöht, in dem Fall könnte das ganze komplizierter werden :)
Zum Vergrößern anklicken....
Dann könnte er das ganze ja gleich mit Olly debuggen und an der richtigen stelle die RID patchen. Nur muss man diese Stelle erstmal finden.
 
Ich werd aus dieser Registry nicht schlau!!!

Ich hab alle Dateien gesucht mit Änderungsdatum vor ein paar Sekunden, hab dann einen User mit net user angelegt und gleich nochmal Dateien gesucht. Die einzige Datei die sich seither verändert hat war die C:\windows\system32\config\SAM.log

ein paar Sekunden später überträgt sich diese datei in die Datei SAM und ist wieder auf 1kb leer.

D.h. -> Diese ganze Usergeschichten inkl RIDs usw. sind in der SAM Datei.

Soweit sogut, SAM Datei kopiert, mit Hexeditor geöffnet und RIDs gesucht.

Meine aktuellen Benutzer inkl RIDs:

davorrk5.gif


Also t22 der letzte User mit RID 1027

Ich hab dann 1027 im Hexeditor in der SAM Datei gesucht -> nichts.
Aber dann ist mir eingefallen, Windows hat doch einen Fetisch für Hexazahlen. Also 1027 ist in Hexa 403, 403 im Hexeditor gesucht und tatsächlich gefunden!
Sogar in einer recht nachvollziehbaren Struktur. so in etwa:

t20....TZ§$TG §
3%§"$TG§$ TZ§$TG § TZ§ $T§
3$T§" T§T§Z§ Z§z§%z35zt34%
§§§$%%%00000401

t21....TZ§$TG §
3%§"$TG§$ TZ§$TG § TZ§ $T§
3$T§" T§T§Z§ Z§z§%z35zt34%
§§§$%%%00000402

t22....TZ§$TG §
3%§"$TG§$ TZ§$TG § TZ§ $T§
3$T§" T§T§Z§ Z§z§%z35zt34%
§§§$%%%00000403


Also mir fällts nicht schwer zu kombinieren dass das am Ende die RID sein muss.

Hab dann probiert die RID vom letzten User, t22, von 403 auf 700C3 (=458947) auszubessern und zu speichern.

SAM ausgetauscht, gebootet, getsid auf User t22, er hat immernoch die RID 1027 X(
Neuen User mit net user t23 angelegt, er bekam die RID 1028.
Und wenn ich auf die Computerverwaltung->Benutzer klicke kommt ein Programmfehler
... sprich, die SAM Datei ist irgendwie kaputt / teilweise unbrauchbar durch mein Editieren geworden

ok, alles nochmal retour. Ich hab nochmal in die SAM Datei mit dem Hexeditor geguckt.

Nach diesen ganzen Usern bis einschließlich t22, kam danach noch eine Menge Kaudawelsch, und dann kamm die Zahl 00000404 Ich dachte mir, dass MUSS einfach der RID Counter sein! Was soll es sonst sein? Eine 405 hat es in der ganzen SAM Datei nicht mehr gegeben, 403 ist die RID meines letzten Users, und 404 steht ziehmlich am Ende der SAM Datei allein herum, dann kann eigentlich nur der RID Counter sein.
Hab den Counter von 404 auf 700C3 ausgebessert. Gespeichert, SAM Datei ausgetauscht, rebootet.

Hab einen neuen User net user t23 angelegt, in der Hoffnung, der Counter würde bei 700C3 ansetzen und meinem neuen User t23 700C3 bzw. 458947 als RID verpassen.
Falsch gedacht! Der t23 hat 1029 bekommen. Ein weiterer User t24 hat 1030 bekommen.

danachqm5.gif


Da frag ich mich, warum speichert sich dieses komische Betriebssystem überhaupt einen Counter mit, wenn es den Counter eh nicht verwendet???
Hab auch noch in den anderen Dateien SYSTEM und SECURITY nach RIDs gesucht, weit und breit kein "000403", "000404" oder "t22". Also die SAM ist der einzige Ort wo diese Zahlen vorkommen.

Was mich aber schon wundert, warum hat er nachdem ich den 404'er Counter manipuliert habe, bei 1029 weitergezählt, und nicht bei 1028? Normalerweise wäre ja 404 / 1028 die nächste freie RID gewesen. Naja, wahrscheinlich durch mein editieren. Aber eine Logik seh ich trotzdem nicht dahinter.




===================================




So, ich habs nun geschafft!
Diese Seite hat mir die nötigen Infos geliefert:
http://www.beginningtoseethelight.org/ntsecurity/


User number increment and are not reused when a user is deleted. A record of this is kept here: \HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\F Offset:48 - length:4 - Stored in reverse hex. This is the next user number that will be used. When is value reaches FF,FF,FF,FF it will rollback and starting incrementing from 00,00,00,00. 4,294,967,296 maximum accounts.


Also die SAM im Hexeditor geöffnet, die betreffende Stelle gesucht, und tatächlich, dort stand ein: 0504 0000 0000 0000, also ein 1029er, genau der Wert auf dem der Zähler bei mir gerade stand.

Also, Wert hinauf korrigiert, neue SAM ins System eingespielt und tatsächlich! Der nächste User den ich mit net user anglegt hab, bekam die hohe ID.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben