Windows-Maschine eindeutig identifizieren

Status
Nicht offen für weitere Antworten.
T

tuxedo

Gast
Hallo zusammen,

ich bin auf der Suche nach Merkmalen einer Windows (Vista) Installation die man dann kombiniert als "Windows-Identifikation" benutzen kann.

Sprich: Ich hab einen Java-Client der dem Java-Server eine ID mitteilt die die Windows-Maschine recht zuverlässig eindeutig identifiziert.

Ich weiß, eindeutig ist so ne Sache, erst recht wenn es um sowas wie eine Hardware-ID geht.

Die ID am Server generieren, dem Client übermitteln und der speicher sie sich dann fällt erstmal flach. Da kommt man doch zu schnell dahinter.

Was ich bisher habe:

Volumenseriennummer der Windows-Platte
kombiniert mit
Datum des Windows-Verzeichnisses.

Das hat bisher auch gut geklappt, nur tauchen jetzt die ersten mit Rechnern auf die vom selben Hersteller und Typ sind, und die geclonte Festplattenimages drauf haben.

Fällt hier noch jemandem etwas ein was man zurate ziehen könnte um die ID etwas eindeutiger zu machen? Wenn alle Stränge reissen muss ich die ID halt doch am Server generieren und der Client muss sie sich irgendwo versteckt merken.

Würde mich aber freuen wenn jmd. noch ne tolle Idee hat.

- Alex
 
M

maki

Gast
>> Das hat bisher auch gut geklappt, nur tauchen jetzt die ersten mit Rechnern auf die vom selben Hersteller und Typ sind, und die geclonte Festplattenimages drauf haben.

Wenn du erst auf Virtualisierte Clients triffst wird das ganze noch besser ;)

Glaube wirklich das es mittlerweile keine 100% Möglichkeit mehr gibt Maschinen immer und jederzeit an der HW oder SW zu identifizieren.
 
T

tuxedo

Gast
>> Das hat bisher auch gut geklappt, nur tauchen jetzt die ersten mit Rechnern auf die vom selben Hersteller und Typ sind, und die geclonte Festplattenimages drauf haben.

Wenn du erst auf Virtualisierte Clients triffst wird das ganze noch besser ;)

Glaube wirklich das es mittlerweile keine 100% Möglichkeit mehr gibt Maschinen immer und jederzeit an der HW oder SW zu identifizieren.

Naja, ne 100,0%ige Möglichkeit gibts sicher nicht. Aber 99% würden mir erstmal reichen. Bisher lieg ich geschätzt bei 70%.

Ne andere Idee kam mir gerade:

Ich nehm ein Merkmal vom lokalen PC und kombinier das mit einer zufälligen, eindeutigen ID vom Server. Das muss der Client dann halt versteckt speichern.

Da der Client-Login am Server noch zusätzlich mit Benutzername und PW läuft, kann ich ja dann steuern welchen/wieviele Rechner der User benutzen darf.

Gegenvorschläge? Bessere Ideen?

- Alex
 

fjord

Bekanntes Mitglied
Wie wäre es noch mit sowas wie Pfad zu deinem Programm, Username, PROCESSOR_IDENTIFIER, Computername und so weiter? Und das ganze dann natürlich durch eine Hashfunktion jagen.
 
T

tuxedo

Gast
>> Pfad zu deinem Programm

Bei Webstart ist das glaub etwas "schwierig"

>> Username

Loggt er sich mit nem anderen Namen ins Windows ein hat das dann eine andere ID zur Folge -> nicht brauchbar

Client-Server-Anwendungsbenutzername: Naja. Sehe da noch nicht den "Effekt" dahinter.

>> PROCESSOR_IDENTIFIER

Prozessor-ID? Gibts doch AFAIK nicht mehr und gabs nur ne Zeit lang bei Intel.
Und wenn damit die Prozessorbezeichnung gemeint ist: Zei OEM Systeme hätten da wohl die gleiche CPU ... Geht also auch recht schlecht

>> Computername

Ja, das wäre ein weiteres Beispiel. Allerdings können sich Computernamen bei Anwender-PCs doch hin und wieder mal ändern, was dann auch eine neue ID zur Folge hätte.

>> so weiter

Ja, ich höre ?! :)

Über solche Dinge hab ich mir schon den Kopf zerbrochen. Es müssen halt Merkmale sein die die allerwenigsten während der Lebensdauer einer Windows-Installation ändern.

Hab auch schon über die Windows-Seriennummer nachgedacht. Aber da sind ja trotz WGA noch ziemlich viele geklaute Nummern unterwegs, so dass man wohl schnell auf doppelte trifft. Wobei da die Frage ist wie verheerend das werden könnte. OEM Systeme haben i.d.R. ja alle eine echte Seriennummer für Windows...

Denke ich nehm die Variante aus Servergenerierter ID und lokalem Merkmal. Dann wirds zu 100,0% eindeutig. Muss nur die ID versteckt genug speichern.

- Alex
 
T

tuxedo

Gast
kA ob das besser/umsetzbar wäre, aber warum gibt der Server den Clients nicht ein eindeutiges Token mit?

Öhm :bahnhof:. Ist das nicht das was ich zuletzt als :idea: hatte? -->

tuxedo hat gesagt.:
Denke ich nehm die Variante aus Servergenerierter ID und lokalem Merkmal. Dann wirds zu 100,0% eindeutig. Muss nur die ID versteckt genug speichern.

??

Oder hast du was anderes gemeint?

Vielleicht noch etwas mehr Hintergrund:

Wie gesagt: Ich hab eine Client-Server-Anwendung. Jeder User hat einen Benutzernamen und Passwort. Um Account-Missbrauch und andere Dinge zu verhindern, möchte ich möglichst zuverlässig und "sicher" einschränken, dass der User seinen Account auf maximal x Computern benutzten kann (nicht einfach nur das "gleichzeitige" sondern das "überhaupt" verhindern). Und das ein Computer nur mit einem Account benutzt werden kann.

- Alex
 
M

maki

Gast
Oder hast du was anderes gemeint?

Vielleicht noch etwas mehr Hintergrund:

Wie gesagt: Ich hab eine Client-Server-Anwendung. Jeder User hat einen Benutzernamen und Passwort. Um Account-Missbrauch und andere Dinge zu verhindern, möchte ich möglichst zuverlässig und "sicher" einschränken, dass der User seinen Account auf maximal x Computern benutzten kann (nicht einfach nur das "gleichzeitige" sondern das "überhaupt" verhindern). Und das ein Computer nur mit einem Account benutzt werden kann.
So in der Art, aber verzichte noch auf das "lokale" Merkmal ;)
Lass die Ids/Token nur vom Server generieren, vom Client brauchst du nicht wirklich etwas dafür.
 
T

tuxedo

Gast
So in der Art, aber verzichte noch auf das "lokale" Merkmal ;)
Lass die Ids/Token nur vom Server generieren, vom Client brauchst du nicht wirklich etwas dafür.

Naja, das "lokale" Merkmal wäre nur dazu da damit nicht einer auf die Idee kommt die ID von Rechner A auf Rechner B zu benutzen ...(falls er rausfindet wo die ID steht und wie man sie ändern kann). Gültig wäre somit nur beides in Kombination.

- Alex
 
T

tuxedo

Gast
Sorry, hatte ich vergessen.

MAC Adressen sind toll. Problem ist nur: Es gibt unter den Anwendern auch Laptop-User. Und darunter gibts offensichtlich nicht wenige, die je nach Location ihre LAN-Karte an und die WLAN-Karte ausschalten (oder umgekehrt). Aus der Sicht von Java sind dann auf einmal MAC Adressen "weg" oder plötzlich "wieder da".
Sprich: Daheim hab ich nur die LAN-Karte an. Also hab ich eine MAC-Adresse sichtbar. Unterwegs benutz ich dann vllt. WLAN und schalte die LAN-Karte ab (bzgl. das Tool zum wechseln der Netzwerkeinstellungen macht das für mich). Die LAn-Mac ist dann "weg", dafür aber die WLAN-Mac da.
Andere wiederum benutzen einen UMT-Stick, den sie nur bei Bedarf anstecken. Dessen Mac ist dann auch nicht immer präsent.
"Zuverlässig" ist das also nicht wenn Laptop-User im Spiel sind. Leider...

- Alex
 

ice-breaker

Top Contributor
Mac Adresse würde auch JNI benötigen.
Und ich bezweifel einfach mal ganz frech, dass man mit den Platformunabhängigen wirklich ne gute Id basteln kann, denn an die Dinge, die Computer wirklich unterscheiden (Hardware) kommt man nicht ran.
 
T

tuxedo

Gast
>> Mac Adresse würde auch JNI benötigen.

Definitiv nein. Das ist was was Java von Haus aus kann.

>> Wie wäre es mit Motherboard-Id usw?

Hmm, gibts denn da einen herstellerweiten Standard? Also eine "genormte" Stelle an der sowas steht? Wenn eine Windows-Standard-DLL da dran kommt, wäre das recht geschickt.

Auf der anderen Seite: AFAIK macht vllt. jeder Hersteller seine eigene Seriennummer, aber "weltweit unique" ist die wohl auch nicht. Ist ja nicht gesagt dass die ID von Hersteller A nicht zufällig auch bei Hersteller B auftaucht?!

>> Und ich bezweifel einfach mal ganz frech, dass man mit den Platformunabhängigen wirklich ne gute Id basteln kann, denn an die Dinge, die Computer wirklich unterscheiden (Hardware) kommt man nicht ran.

Naja, die MAC Adresse ist da schon das beste was man kriegen kann, ohne sich zu sehr mit JNI/JNA zu beschäftigen und alle anderen Komponenten wie Grafikkarte, RAM, Festplatte, BIOS und Co. hinzuzuziehen. Aus all diesen Merkmalen ließe sich wohl eine 99,9%ige ID erzeugen, aber auf der anderen Seite: Verreckt einem nur mal die Grafikkarte oder ein RAM-Riegel, so ist man gleich wieder aufgeschmissen und muss dem User eine neue ID geben und die alte löschen.

Bei Linux und MacOS ist das alles kein Problem. Zumindest nicht so ein Problem wie in Windows. Mac's haben ne Apple-Seriennummer. Die kann man ganz einfach auslesen.
Linux: Nun, da gibts zahlreiche Möglichkeiten. Eine davon ist die Herstellerbezeichnung und Seriennummer der Festplatte. Wenn das nicht reicht, kann mans noch mit anderen Merkmalen kombinieren.

Gruß
Alex
 
S

Spacerat

Gast
MD5 THIS: "System.getProperties()" ...naja... ist vllt. übertrieben, aber immerhin ein oder mehrere Anhaltspunkte.
 
Zuletzt bearbeitet von einem Moderator:
T

tuxedo

Gast
Darin sind doch auch wieder benutzerspezifische Dinge enthalten, so dass jeder Systembenutzer seine eigene ID bekäme ... :-(
 
S

Spacerat

Gast
Ja... Genau das meinte ich mit "übertrieben". Andererseits könnte trozt der benutzerspezifischen Angaben ein Hash darauf von Maschine zu Maschine anders sein. Wenn's nicht reicht, nimmt man halt noch "getEnv()" dazu. Der Hash muss allerdings auch Clientseitig gespeichert werden, da sich Pfade usw. auch auf ein und der selben Maschine recht häufig ändern können. Eine Idee wäre es, wenn man beim 1. Connect (z.B. Registration) diese Informationen sammelt, hashed, auf dem Server speichert, eine Klasse oder ein Paket der Anwendung damit verschlüsselt und diese(s) dann dem Benutzer zukommen lässt. Soweit so gut. Der Benutzer könnte immer noch die gesammte Anwendung, sammt verschlüsselter Klasse / Paket auf einen anderen Rechner kopieren. Aber wir haben ja, wie du sagst, noch die MAC-Adresse (haben wir? k.A.) welche wir noch in den Hash mit einbeziehen können.
 
G

Gast2

Gast
Moin,

soweit ich weis versucht Windows jedem System eine eigene GUID zuzuweisen ... ich weis nicht wie das mit geclonten Pladden aussieht - also wann die GUID für das System erzeugt wird (Installation oder erstmaliger Start) ... jeder Benutzer bekommt ebenfalls eine eigene GUID basierend auf der vom System

am besten solltest Du mal bei einem Forum nachfragen die sich mehr mit Windows beschäftigen :)

hand, mogel
 

DellCapone

Mitglied
Ich bin mir grad nicht sicher wie es auf anderen Systemen aussieht. Aber z.B. auf Dell-Geräten hättest du die Servicetag die deinen 99% entsprechen könnte. Diese lässt sich auch unter Windows und Linux auslesen. Ich glaube so ein EINDEUTIGES Merkmal wird man nicht finden.
 
T

tuxedo

Gast
Warum wird eigentlich immer nur das letzte drittel des Threads gelesen?! Thread abhaken geht ja nun hier im neuen Forum auch nciht mehr *schade*

Wurde doch bereits geklärt dass es am sichersten ist die ID vom Server generieren zu lassen. Dann gibts keine Duplikate. Bzgl. der Sicherheit dieser Technik: Die ID muss beim Client gespeichert werden. In meinem Fall am besten so, dass der User sie

a) nicht findet
b) kein Plan hat was das sein soll
c) die ID, selbst wenn er sie gefunden hat, auf einem anderen System nicht einfach so benutzen kann.

Dazu einfach ein lokales Merkmal mit der servergenerierten ID kombinieren und fertig :)

Deshalb an dieser Stelle nochmal: Danke für all die Überlegungen und Tipps.

---->>>> PROBLEM GELÖST <<<<----

Gruß
Alex
 
T

tuxedo

Gast
*RE-OPEN*

Problem doch nicht gelöst. Grund:

Ich kann zwar via Server eine ID generieren: Aber wo speicher ich die Benutzerübergreifend OHNE Admin-Rechte?
Der Java Preference Store gilt pro Systembenutzer. D.h. jeder Systembenutzer würde eine eigene ID erhalten --> deckt sich nicht mit meinen Anforderungen.

Bin jetzt dann doch wieder n Stück zurück gegangen und hab wieder über ein Windows-Merkmal nachgedacht. Unter anderem auch über den Windows CD-Key den man bei der Installation eingeben muss. Wenn es sich nicht gerade um Firmenrechner dreht, die evtl. geklonte Images im Einsatz haben, so dürfte der CD-Key, in Verbindung mit meinen bisherigen Merkmalen (Volume-Serial + Zeitstempel von C:\Windows) ziemlich eindeutig werden. Zur Not noch den Hostnamen mit rein nehmen.

Problem ist nur:

a) Wie komm ich an diesen CD-Key?
b) Komm ich da überhaupt ohne Admin-Rechte ran?

Zu a): Steht in der Registry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion im Key "DigitalProductId". Mit The_29's Pure Java Registry Lib komm ich da nicht ohne Runtime-Exec-Regedit erweiterung dran da es sich um ein REG_BINARY handelt, welches von der java.dll nicht gehandhabt werden kann. Einsatz Regedit fällt erstmal flach.

Zu b): Werd gleich mal nen nieder privilegierten User anlegen und das testen. Aber wie's da bei Vista aussieht weiß ich auch noch nicht. Denke das könnte eine massive Hürde werden wenn ich da Admin-Rechte brauche (deckt sich nicht mit meinen Anforderungen).

- Alex
 

Ebenius

Top Contributor
Preferences bietet einen User- und einen System-Tree. Letzterer ist natürlich nur von Administratoren (oder anderen Super-Benutzern, keine Ahnung) schreibbar. Das heißt: Als Admin installieren und Key erzeugen. Auslesen sollten dann eigentlich alle Benutzer können; mutmaße ich aber nur.

Ebenius
 

thE_29

Top Contributor
Irgendwie kann man (wenn ich ein paar Aussagen glauben schenken darf) das Runtime.exec oder den ProcessBuilder dazu bringen, dass diese Admin Abfrage kommt! Dadurch würde es funktionieren...

Wie das aber geht, weiß ich auch nicht..
Desweiteren man kann die registry auch so sperren, dass da kein Admin User lesen darf. Dann hättest du sowieso ein Problem..

Und warum speicherst du das nicht Online wo ab? Oder sollte die App auch ohne Netz gehen?
 
T

tuxedo

Gast
Online speichern.. hmm. das wäre auch noch so ne idee. könnte man anhand des useraccounts in der eh schon exsitierenden DB speichern....

Aber quatsch... Macht doch keinen Sinn:

Ich generiere via Server für den Client eine ID. Und die speichere ich dann auf dem Server? Wie soll sich denn dann der Client damit am Server identifizieren? Geht dann ja gar nicht.

Aber was anderes:

Hab eben nen "User" in Windows XP erstellt. Mit dem konnte ich ohne schwierigkeiten und ohne "run as" folgendes ausführen:
Code:
regedit /e myfile.reg "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion"

Dann bin ich noch auf das hier gestoßen:

Code:
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v DigitalProductId

Letzteres liefert ein ebenso brauchbares Ergebnis. Ob das nun auch mit dem normalo-User geht hab ich nicht getestet. Aber da prinzipiell der lesende Zugriff auf die Registry auf diesen Schlüssel geht, denke ich wird der zweite Befehl auch funktionieren.

Jetzt ist nur noch die Frage bzgl. Vista...

Hat hier jmd. Vista und kann beide Befehle mal mit einem nicht-Admin User testen?
Was mich im Vista-Fall vor allem interessiert ist ob das UAC-Ding da im Weg steht.

Von Paranoia-Admins für gesperrte Registrys ("kein nicht-Admin darf lesen") fallen durch die Anforderungen durch. Sprich: Die können die Anwendung dann halt nicht benutzen. Denke nicht dass ich mir da viele "Feinde" machen werde. Mir persönlich ist in meiner Laufbahn sowas auch noch nicht unter gekommen (was nicht heisst dass es sowas nicht gibt), und ich war schon in ner handvoll Firmen mit sehr restriktiver IT.
Nebenbei ist die Anwendung auf eine spezielle Heimanwender-gruppe ausgerichtet.

Gruß
Alex
 
T

tuxedo

Gast
Preferences bietet einen User- und einen System-Tree. Letzterer ist natürlich nur von Administratoren (oder anderen Super-Benutzern, keine Ahnung) schreibbar. Das heißt: Als Admin installieren und Key erzeugen. Auslesen sollten dann eigentlich alle Benutzer können; mutmaße ich aber nur.

Ebenius


Das hab ich auch schon feststellen müssen. Anwendung aber erst als Admin laufen lassen geht aber nicht. Deshalb fällt die Option leider weg.

Was auch noch funktioniert hätte, jedoch mehr Aufmerksamkeit erregt hätte:

Eine Datei in C:\Documents and Settings\All Users\Documents anlegen. Die kann dann zwar nur vom ersteller nochmals geschrieben werden, aber es hätte ja gereicht wennsie überhaupt mal einer erstellt und die anderen sie nur noch lesen.

Allerdings: Wenn dann einer seine Platte aufräumt und dann diese Datei abhanden kommt, wäre die servergenerierte ID auch wieder hinüber.
 

Ebenius

Top Contributor
Hast Du das mit nem XP Professional probiert? Bei vernünftigen Policies wird regedit mit 0815-Benutzer nix.

Ebenius
 

thE_29

Top Contributor
Was ist beim Online speichern so schlimm?
Du "generiest" jedesmal den Key neu und guckst ob der in der DB vorhanden ist. Wenn nicht ist nicht erlaubt zu starten..
Ich habe daheim Vista, weiß aber nicht ob ich heute zum Testen kommen. Wenn es den ohne Admin funktionieren würde (was ich mir nicht so vorstellen kann), dann kann ich das ja im RegistryWrapper einbauen ;)
Vorallem kann ich mir dann das Puffern sparen, da ich ja bei regedit /e ziemlich viel rauskam..

Version 3.5 steht an ;)
 
T

tuxedo

Gast
Hast Du das mit nem XP Professional probiert? Bei vernünftigen Policies wird regedit mit 0815-Benutzer nix.

Ebenius

Jepp, war XP Prof SP3 auf einem Coorporate PC. Haben zwar DOmänenrichtlinien, aber die greifen ja bei einem nur lokalen User nicht.

Hab ergo ein Standard XP System ohne spezielle Richtlinien mit einem Normalo-User (kein Admin, kein Poweruser) getestet. Lief ohne Probleme.

@the_29

Weiß nicht ob du alles gelesen hast:

Ich will die ID um den Computer weitgehend eindeutig identifizieren zu können. Den Benutzeraccount soll man nur auf max. 2 Computern nutzen können.

Entweder ich schaffs dass ich eine sehr zuverlässige Merkmal im Windows-System finde und sich der Rechner damit jedesmal selbst am Server identifiziren kann (zusammen mit den Accountdaten),

ODER

ich generiere eine ID am Server und schick sie dem Client. Dieser speichert sie sich für alle Zukunft und nutzt diese bei jedem Login.

Wenn ich die ID jetzt am Server generiere und am Server speichere: Wie soll dann die Identifikation des Computers noch funktionieren? Verstehst du was ich meine?

Mac-Adresse und Co. fallen ebenfalls raus (wieso kann man weiter vorne nachlesen).
 
G

Gast2

Gast
Moin,

HKLM ist für jeden Deppen lesbar - aber nicht schreibbar ... da packe ich auch immer Rechner-Konfigurationen rein die Uswer nur lesen dürfen (unter HKLM/Software/<Firma>/<...>)

HKCU ist nur für den aktuellen Benutzer ... wenn sich ein anderer Nutzer anmeldet, stehen AFAIK andere Werte drinnen ... habe ich aber noch nie benutzt

hand, mogel
 
T

tuxedo

Gast
Das klingt prima und bestätigt meinen Test.
Danke für den Hinweis.

- Alex
 
T

tuxedo

Gast
Das mit der GUID ist mir glaube ich bekannt. Bin mir aber nicht 100%ig sicher. Wenn es das ist wofür ich es halte, dann hätte man bei teilgeklonten Windows-Installationen ein Problem...

Deshalb stellt sich mir die Frage: WANN wird diese GUID generiert? Was ist mit OEM Systemen? Viele Hersteller klonen die Windows-Installation um ihre Rechner vorinstalliert ausliefern zu können. Ist es sicher dass die GUID da definitiv Unique ist?
 
G

Gast2

Gast
Moin,

ich tippe hier auf Ja ... sonst würde die Volkszählung von Microsoft nicht funktionieren

hand, mogel
 
T

tuxedo

Gast
Das wäre prima.

Hab eben n kleines diagnose-Script gebastelt das mir die notwendigen Infos sammelt und zipped. Das geb ich mal meinen "OEM Problemkandidaten". Dann hab ich klarheit...
 

thE_29

Top Contributor
Wenn ich heute am Abend nicht vergesse, boote ich mal wieder Vista aufn meinem Macbook und teste ob reg.exe ohne Admin Rechte auskommt!
Dann baue ich die pur Registry eventuell um! Ich wusste halt nicht, dass der Befehl überhaupt existiert ;)
 
T

tuxedo

Gast
Wenn ich heute am Abend nicht vergesse, boote ich mal wieder Vista aufn meinem Macbook und teste ob reg.exe ohne Admin Rechte auskommt!
Dann baue ich die pur Registry eventuell um! Ich wusste halt nicht, dass der Befehl überhaupt existiert ;)

Auch RegEdit kommt da ohne Admin-Rechte aus. Habs ja selbst getestet.

Was ich aber auf Wikipedia gelesen hab ist, dass man einzelnen Programmen wie "regedit" die Nutzungsrechte entziehen kann. Und das wird auch ab und an von Admins gemacht. Das bezieht sich aber nur auf Schreibrechte. Lesen geht, wenn ich das richtig verstanden/gelesen hab IMMER.

- Alex
 

Ebenius

Top Contributor
Lesen geht, wenn ich das richtig verstanden/gelesen hab IMMER.
Kann ich so nicht bestätigen. Das hängt sehr davon ab, wie paranoid die IT-Abteilung in der jeweiligen Firma ist. Man kann sich teilweise nicht mal drauf verlassen, dass regedit überhaupt auf dem System vorhanden ist.

Ebenius
 

thE_29

Top Contributor
Naja, wenn ich regedit.exe in ausführen eingebe, kommt immer diese Admin Abfrage!

Bei Runtime.exec() kommt halt ne Exception, dass er das nicht darf..
 
T

tuxedo

Gast
Kann ich so nicht bestätigen. Das hängt sehr davon ab, wie paranoid die IT-Abteilung in der jeweiligen Firma ist. Man kann sich teilweise nicht mal drauf verlassen, dass regedit überhaupt auf dem System vorhanden ist.

Ebenius

Wer sagt dass du RegEdit brauchst?

Und wenn Wikipedia recht behält ist alles in Butter:

http://de.wikipedia.org/wiki/Windows-Registrierungsdatenbank#Sicherheit hat gesagt.:
Sicherheit

Da mit der Registry auch Optionen wie das Ausblenden des Taskmanagers oder Komponenten der Systemsteuerung vorgenommen werden können, ist es nützlich, die Registry z. B. in großen Netzwerken vor ungewollten Änderungen durch normale Benutzer zu schützen. Dies kann durch die Funktion „Berechtigungen” vorgenommen werden.

Tatsächlich ist dies aber schon getan, wenn das empfohlene Einsatzszenario in Firmen verwendet wird, wo Benutzer keine Administrationsrechte haben. Ohne Administrationsrechte hat man nur Leserechte auf HKEY_LOCAL_MACHINE und Schreibrechte nur in HKEY_CURRENT_USER (was die eigenen persönlichen Einstellungen widerspiegelt).

Stilllegen von RegEdit

Für Administratoren wurde die Möglichkeit implementiert, das Ausführen von REGEDIT.exe durch einen Registry-Eintrag im Policies-Bereich bei bestimmten Usern zu verhindern. In diesen Bereich kann ein Standarduser ohne Adminrechte nicht schreiben, die Einstellung kann z. B. durch Gruppenrichtlinien gesetzt werden. Das Vorhandensein dieses Keys verhindert selbstverständlich nicht das Verwenden anderer Tools (sonst würde wohl kein Programm mehr laufen). Wenn man verhindern will, dass bestimmte Keys verändert werden, ist daher der Einsatz der Berechtigungen und der Einsatz eines Standardusers ohne Adminrechte der einzig sinnvolle Weg.
 
G

Gast2

Gast
Hmm, letzter Post in diesem Thread behauptet dass Images ein Problem darstellen:
ja klar ... wenn die Maschine bereits lief wird auch die GUID im Image mit gespeichert ... ich vermute aber das bei OEM-Installationen das nicht der Fall ist und die GUID beim ersten System-Start erzeugt wird - sonst würde die Volkszählung noch weniger funktionieren :)

hand, mogel
 

thE_29

Top Contributor
Ich brauche aber regedit.exe um alle Einträge außer dword aus der registry zu kriegen ;)
Und da regt sich das UAC auf.

Die Frage ist, ob man eine Java App mit UAC starten kann..
 
T

tuxedo

Gast
was ist mit "reg"? Damit kann man doch auch die registry lesen. Okay, schreiben kann sein dass man dafür dann Admin-Rechte braucht. Aber zumindest lesen geht. Der CD-Key ist auch kein dword und kann damit gelesen werden...

@mogel

Klingt einleuchtend. Den Beweis hab ich wenn meine Problemkandidaten mein Diagnose-Script ausgeführt haben. Dauert nur noch etwas bis ich alle Daten hab.

- Alex
 
Zuletzt bearbeitet von einem Moderator:

thE_29

Top Contributor
Wie gesagt, ich fahre heute mal Vista hoch und schau mal wie sich reg.exe verhält! Wenn das beim Lesen (da ja Befehl query) keinen Adminzugang benötigt, muss ich meine Lib wohl ändern ;)
 

thE_29

Top Contributor
Jupidu!

reg.exe query geht ohne admin Rechte ;)
Konnte sogar HKLocalMachine und HKClassesRoot extrahieren
Najo, dh, ich muss meine Lib Updaten ;)
 
Status
Nicht offen für weitere Antworten.

Ähnliche Java Themen


Oben