Hallo,
ich habe ein Problem mit RegDacl.Add.
Ich will folgende Berechtigung setzen:
RegDacl.Add(HKEY_CURRENT_USER,"Software\Microsoft\SystemCertificates\Root\ProtectedRoots","%$Everyone%", Grant, All, SUB_CONTAINERS_AND_OBJECTS_INHERIT)
Ich bekomme die Fehlermeldung 87. Falsche Parameter.
Welche Parameter muß ich setzen?
Viele Grüße
Jens
Probleme mit RegDacl.Add
-
Walter_Schulz
- Posts: 876
- Joined: 17. Dec 2004, 12:29
- Contact:
Re: Probleme mit RegDacl.Add
Das Problem liegt IMO nicht an RegDacl.Add:jkerkdyk wrote:Hallo,
ich habe ein Problem mit RegDacl.Add.
Ich will folgende Berechtigung setzen:
RegDacl.Add(HKEY_CURRENT_USER,"Software\Microsoft\SystemCertificates\Root\ProtectedRoots","%$Everyone%", Grant, All, SUB_CONTAINERS_AND_OBJECTS_INHERIT)
Ich bekomme die Fehlermeldung 87. Falsche Parameter.
Welche Parameter muß ich setzen?
Viele Grüße
Jens
Wenn der Empirum-Dienst das Teil ausfuehrt, dann findet er die HKCU des Benutzers nicht.
Wenn der Benutzer das ausfuehrt, kann er sich selbst nicht die Berechtigung "erhoehen".
AD vorhanden? Dann einfach die Berechtigung per GPO setzen.
Falls nicht vorhanden: Noch mal melden.
Ciao!
Walter Schulz
Exakt, und HKCU-Operationen werden unter dem Kontext des Benutzers ausgeführt.Das Problem liegt IMO nicht an RegDacl.Add:
Wenn der Empirum-Dienst das Teil ausfuehrt, dann findet er die HKCU des Benutzers nicht.
Wenn der Benutzer das ausfuehrt, kann er sich selbst nicht die Berechtigung "erhoehen".
Hund-Schwanz-Problem
@Walter, bin schon auf Deine Lösung gespannt.
Jens Beimel
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
-
Walter_Schulz
- Posts: 876
- Joined: 17. Dec 2004, 12:29
- Contact:
Das ist das grundsaetzliche Vorgehen, wenn man es mit Empirum machen will oder muss:
In der Setup.inf eine Batch aufrufen, die nach den Subkeys von HKU sucht und diese in Variablen schreibt. Jetzt kann man innerhalb der Batch z. B. SUBINACL (ResKit) aufrufen und die Permissions auf die richtigen Subkeys unterhalb von HKU\<SID> setzen. Oder man schreibt die Variablen in eine Datei oder temporaer in die Registry, springt in die Setup.inf zurueck, liest sie aus und setzt per RegDacl.Add.
Damit ist schon mal der angemeldete Benutzer erledigt. Jetzt geht es an die Einstellungen der Benutzer, die sich schon mal an der Maschine angemeldet haben. Leider koennen Sie hierzu nicht die Empirum-Funktionen fuer die automatische Trennung von Benutzer- und Maschinenteil nutzen. Das Setzen der Berechtigungen muss - wie schon erwaehnt - ueber den Kontext des Dienstes gehen, im Kontext des Benutzers funktioniert das nicht. Damit fehlt auch die Moeglichkeit, dass diese Installation je Benutzer im benutzerspezifischen Teil angestossen wird. (Ausnahme: Man kann eine Sektion CLIENT flaggen und darin einen Call auf die SETUPCLI (immer verschluesselt) loslassen ... wer's mag ...).
Also kommt am besten das gute REG LOAD zum Tragen, das man (wieder per Batch) auf die Subdirs unter %AllUsersProfile%\..\ loslaesst und dort die NTUSER.DAT jeweils temporaer in die Registry laedt. Sinnvollerweise unter HKU und vor dem Setzen der Berechtigungen wie oben beschrieben.
Nun noch die Einstellung fuer zukuenftige Benutzer. Wie gesagt: Kein Benutzerteil hilft einem hier weiter, da das Maschinensetup normalerweise nur einmalig durchlaufen wird. Oder man setzt das FORCE-Flag und bekommt bei jedem SWDEPOT /I-Aufruf das Teil installiert ... auch dann, wenn der Benutzer die Installation schon bekommen hat. Oder - wie oben erwaehnt - man nimmt SETUPCLI.
Fuer die zukuenftigen Benutzer liegt das Template aber in %AllUsersProfile%\..\Default User und ist damit bei obiger Aktion schon mitgeladen und umgestellt worden.
Nun die Frage: Wollen Sie wirklich einen solchen Aufwand betreiben? GPO - falls verfuegbar - ist bei dieser Aufgabenstellung schlichtweg im Vorteil.
Ich schreibe Ihnen die Batches und die INF, kein grosses Problem. Aber die Wartung kann ich nicht uebernehmen ...
Ciao!
Walter Schulz
In der Setup.inf eine Batch aufrufen, die nach den Subkeys von HKU sucht und diese in Variablen schreibt. Jetzt kann man innerhalb der Batch z. B. SUBINACL (ResKit) aufrufen und die Permissions auf die richtigen Subkeys unterhalb von HKU\<SID> setzen. Oder man schreibt die Variablen in eine Datei oder temporaer in die Registry, springt in die Setup.inf zurueck, liest sie aus und setzt per RegDacl.Add.
Damit ist schon mal der angemeldete Benutzer erledigt. Jetzt geht es an die Einstellungen der Benutzer, die sich schon mal an der Maschine angemeldet haben. Leider koennen Sie hierzu nicht die Empirum-Funktionen fuer die automatische Trennung von Benutzer- und Maschinenteil nutzen. Das Setzen der Berechtigungen muss - wie schon erwaehnt - ueber den Kontext des Dienstes gehen, im Kontext des Benutzers funktioniert das nicht. Damit fehlt auch die Moeglichkeit, dass diese Installation je Benutzer im benutzerspezifischen Teil angestossen wird. (Ausnahme: Man kann eine Sektion CLIENT flaggen und darin einen Call auf die SETUPCLI (immer verschluesselt) loslassen ... wer's mag ...).
Also kommt am besten das gute REG LOAD zum Tragen, das man (wieder per Batch) auf die Subdirs unter %AllUsersProfile%\..\ loslaesst und dort die NTUSER.DAT jeweils temporaer in die Registry laedt. Sinnvollerweise unter HKU und vor dem Setzen der Berechtigungen wie oben beschrieben.
Nun noch die Einstellung fuer zukuenftige Benutzer. Wie gesagt: Kein Benutzerteil hilft einem hier weiter, da das Maschinensetup normalerweise nur einmalig durchlaufen wird. Oder man setzt das FORCE-Flag und bekommt bei jedem SWDEPOT /I-Aufruf das Teil installiert ... auch dann, wenn der Benutzer die Installation schon bekommen hat. Oder - wie oben erwaehnt - man nimmt SETUPCLI.
Fuer die zukuenftigen Benutzer liegt das Template aber in %AllUsersProfile%\..\Default User und ist damit bei obiger Aktion schon mitgeladen und umgestellt worden.
Nun die Frage: Wollen Sie wirklich einen solchen Aufwand betreiben? GPO - falls verfuegbar - ist bei dieser Aufgabenstellung schlichtweg im Vorteil.
Ich schreibe Ihnen die Batches und die INF, kein grosses Problem. Aber die Wartung kann ich nicht uebernehmen ...
Ciao!
Walter Schulz
Hallo Walter,
Respekt
meine Idee ist dagegen richtig trivial:
Am Anfang wird mit LocalGroup.AddMember der angemeldete User in die Gruppe der lokalen Admins genommen, dann wird der RegDacl.Add durchgeführt und dann wieder mit LocalGroup.DelMember der User wieder raus aus den lokalen Admins.
ABER! Ich weise auf die folgenden Einschränkungen hin. Eine Deinstallation crasht, denn der LocalGroup.AddMember ist rekursiv, also bei der Deinstallation wird der User aus der Gruppe entfernt, während bei der Deinstallation der LocalGroup.DelMember komplett ignoriert wird. Weiterhin wird in der simplen Variante der User am Ende immer aus den lokalen Admins entfernt, auch wenn er schon vorher dort berechtigterweise drin war.
Das kann man zwar mit viel IF-Abfragen und DontDelete-Flags etc. alles abfangen aber lohnt es der Mühe wirklich?
Resumèe: Man kann zwar fast alles mit Empirum machen, muss es aber nicht immer
Respekt
meine Idee ist dagegen richtig trivial:
Am Anfang wird mit LocalGroup.AddMember der angemeldete User in die Gruppe der lokalen Admins genommen, dann wird der RegDacl.Add durchgeführt und dann wieder mit LocalGroup.DelMember der User wieder raus aus den lokalen Admins.
ABER! Ich weise auf die folgenden Einschränkungen hin. Eine Deinstallation crasht, denn der LocalGroup.AddMember ist rekursiv, also bei der Deinstallation wird der User aus der Gruppe entfernt, während bei der Deinstallation der LocalGroup.DelMember komplett ignoriert wird. Weiterhin wird in der simplen Variante der User am Ende immer aus den lokalen Admins entfernt, auch wenn er schon vorher dort berechtigterweise drin war.
Das kann man zwar mit viel IF-Abfragen und DontDelete-Flags etc. alles abfangen aber lohnt es der Mühe wirklich?
Resumèe: Man kann zwar fast alles mit Empirum machen, muss es aber nicht immer
Jens Beimel
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
Hallo,
vielen Dank für die schnelle und gute Antwort.
Ich bin auf RegDacl.Add gekommen, da wir hier eine Software im Einsatz haben, wo zusätzlich eine Zertifizierung (www.*.der) installiert werden muß. Genau diese Installation der Zertifizierung habe ich gedifft und bekam dann genau folgende Reg-Key´s:
HKCU,"Software\Microsoft\SystemCertificates\REQUEST",,0x00000010
HKCU,"Software\Microsoft\SystemCertificates\Root\Certificates\8752171F4FBADCF74F7D233BCCAB742D3F063D7E","Blob",0x00000001,Wert
HKCU,"Software\Microsoft\SystemCertificates\Root\ProtectedRoots","Certificates",0x00000001,Wert
Da habe ich gedacht, nehme ich doch RegDacl.Add.
Kann man denn die Zertifizieung unattended und userspezifisch installieren?
Ich habe eine Batch-Datei geschrieben, die die Subkeys des angemeldeten User in der HKU durchsucht und über den reg add Befehl (in XP vorhanden) den Key setze. Nun müßte aber diese Batchdatei userspezifisch ausgeführt werden.
Gibt es eine Möglichkeit eine Batchdatei userspezifisch ausführen zu lassen?
Viele Grüße
Jens Kerkdyk
vielen Dank für die schnelle und gute Antwort.
Ich bin auf RegDacl.Add gekommen, da wir hier eine Software im Einsatz haben, wo zusätzlich eine Zertifizierung (www.*.der) installiert werden muß. Genau diese Installation der Zertifizierung habe ich gedifft und bekam dann genau folgende Reg-Key´s:
HKCU,"Software\Microsoft\SystemCertificates\REQUEST",,0x00000010
HKCU,"Software\Microsoft\SystemCertificates\Root\Certificates\8752171F4FBADCF74F7D233BCCAB742D3F063D7E","Blob",0x00000001,Wert
HKCU,"Software\Microsoft\SystemCertificates\Root\ProtectedRoots","Certificates",0x00000001,Wert
Da habe ich gedacht, nehme ich doch RegDacl.Add.
Kann man denn die Zertifizieung unattended und userspezifisch installieren?
Ich habe eine Batch-Datei geschrieben, die die Subkeys des angemeldeten User in der HKU durchsucht und über den reg add Befehl (in XP vorhanden) den Key setze. Nun müßte aber diese Batchdatei userspezifisch ausgeführt werden.
Gibt es eine Möglichkeit eine Batchdatei userspezifisch ausführen zu lassen?
Viele Grüße
Jens Kerkdyk
selbstverständlich kann man eine Batch-Datei im Userkontext ausführen lassen
--Set:Irgendwas, CLIENT
[Set:Irgendwas]
CALL ... *.cmd
aber auch hier gilt wieder, wenn der User keine Rechte auf den Schlüssel hat, dann hat er keine - egal, ob die Registrykeys mit der Setup.exe oder mit einer Batch reingeschrieben werden sollen.
Wobei auf den hier beschriebenen Keys hat m.E. ein User standardmässig Vollzugriff...
--Set:Irgendwas, CLIENT
[Set:Irgendwas]
CALL ... *.cmd
aber auch hier gilt wieder, wenn der User keine Rechte auf den Schlüssel hat, dann hat er keine - egal, ob die Registrykeys mit der Setup.exe oder mit einer Batch reingeschrieben werden sollen.
Wobei auf den hier beschriebenen Keys hat m.E. ein User standardmässig Vollzugriff...
Jens Beimel
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
-
Walter_Schulz
- Posts: 876
- Joined: 17. Dec 2004, 12:29
- Contact:
Ich hoffe, Sie haben die PSexec per Packager "verpackt" und damit die Parameter wenigstens oberflaechlich versteckt, weil Sie bei diesem Vorgehen PSexec einen Admin-Account und ein Passwort mitgeben muessen, die normalerweise im Klartext sind.jkerkdyk wrote:Hallo Herr Beimel,
der User hat nur auf die ersten 2 Keys Vollberechtigungen. Bei dem letzten Key hat nur das System Vollzugriff. Die Batch-Datei müßte daher unter dem systemkontext laufen. Dazu verwende ich das Tool psexec. Werde morgen über die Ergebnisse berichten.
Viele Grüße
Jens
Ciao!
Walter Schulz
Der Sicherheitsaspekt ist wichtig, ich würde aber eher dazu tendieren, entweder die Passwörter in der Setup.inf mittels der Section [Encryption] zu verschlüsseln oder eine SetupCli.exe fest mit den Parametern zu patchen.
Jens Beimel
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
Hat es funktioniert?
Hallo,
ich habe gerade die exakt gleiche Situation - hat das hier beschriebene Verfahren funktioniert?
Gruß
Michael Fisahn
ich habe gerade die exakt gleiche Situation - hat das hier beschriebene Verfahren funktioniert?
Gruß
Michael Fisahn
-
Walter_Schulz
- Posts: 876
- Joined: 17. Dec 2004, 12:29
- Contact:
Re: Hat es funktioniert?
Exakt gleiche Situation -> exakt gleiche Empfehlung: Berechtigung per GPO setzen.mfisahn wrote:Hallo,
ich habe gerade die exakt gleiche Situation - hat das hier beschriebene Verfahren funktioniert?
Ciao!
Walter Schulz
Hallo,
eben DAS möchte ich nicht - ich möchte diese Berechtigungen aus Empirum heraus setzen (natürlich durchaus unter Zuhilfename externer Werkzeuge).
Hintergrund ist, dass diese Policies von anderen Admins gepflegt werden und ich nicht jedesmal für solche "Kleinigkeiten" abstimmen kann, wo diese Policies angepasst werden sollen.
Gruß
Michael Fisahn
eben DAS möchte ich nicht - ich möchte diese Berechtigungen aus Empirum heraus setzen (natürlich durchaus unter Zuhilfename externer Werkzeuge).
Hintergrund ist, dass diese Policies von anderen Admins gepflegt werden und ich nicht jedesmal für solche "Kleinigkeiten" abstimmen kann, wo diese Policies angepasst werden sollen.
Gruß
Michael Fisahn
Who is online
Users browsing this forum: No registered users and 8 guests