7
Logonscript mit Adminrecht benötigt
Zunächst mal das Umfeld:
Win2k3R2-Server, XP-SP2 Clients, KIS: Siemens Medicos, Logonscript über kix, aktuell kein startscript
Für unser Krankenhausinformationssystem medicos muss bei PC-Start ein "medicoreg" durchgeführt werden, um einzelne Parameter zu setzen und bestätigen. Dummerweise muss dieses Script zwingend mit Adminrecht ausgeführt werden, und muss ebenfalls zwingend von einem gemappten Netzlaufwerk (H: ) gestartet werden. Und da liegt auch der Hund begraben...
Über ein RUNAS-Tool (runnas bietet auch die Möglichkeit einen Programmaufruf mit user und Passwort in ein Token zu verpacken... naja) könnte ich mir Adminrechte verschaffen, dabei verliere ich aber ja den Zugriff auf das bereits gemappte H: Laufwerk und RuNNas oder auch testweise RUNAS meldet, dass der Pfad nicht gefunden werden kann (logisch).
Gebe ich den Weg zum medicoreg aber per unc ein, scheitert medicoreg an der Prüfung selbigen Punktes. Startscript fällt auch flach, da ja dann die Laufwerke ebenfalls noch nicht gemappt sind und auch vorab nötige Variablen nicht für den User gesetz werden.
Soviel mal zur Erklärung... Faktisch brauche ich also [Adminrecht für das Logonscript] / [temporäres Adminrecht für den User]... [sonst eine gerissene Idee].
Bisher läuft das bei einem Dienstleister per ScriptLogic... Das setzen wir nicht ein. Bietet SL da deutlich interessantere Möglichkeiten als das pure kix??? Keine Ahnung - leider lässt sich das nicht so richtig erfragen
Ich hoffe doch, dass es noch die eine oder andere Idee hierzu gibt
Win2k3R2-Server, XP-SP2 Clients, KIS: Siemens Medicos, Logonscript über kix, aktuell kein startscript
Für unser Krankenhausinformationssystem medicos muss bei PC-Start ein "medicoreg" durchgeführt werden, um einzelne Parameter zu setzen und bestätigen. Dummerweise muss dieses Script zwingend mit Adminrecht ausgeführt werden, und muss ebenfalls zwingend von einem gemappten Netzlaufwerk (H: ) gestartet werden. Und da liegt auch der Hund begraben...
Über ein RUNAS-Tool (runnas bietet auch die Möglichkeit einen Programmaufruf mit user und Passwort in ein Token zu verpacken... naja) könnte ich mir Adminrechte verschaffen, dabei verliere ich aber ja den Zugriff auf das bereits gemappte H: Laufwerk und RuNNas oder auch testweise RUNAS meldet, dass der Pfad nicht gefunden werden kann (logisch).
Gebe ich den Weg zum medicoreg aber per unc ein, scheitert medicoreg an der Prüfung selbigen Punktes. Startscript fällt auch flach, da ja dann die Laufwerke ebenfalls noch nicht gemappt sind und auch vorab nötige Variablen nicht für den User gesetz werden.
Soviel mal zur Erklärung... Faktisch brauche ich also [Adminrecht für das Logonscript] / [temporäres Adminrecht für den User]... [sonst eine gerissene Idee].
Bisher läuft das bei einem Dienstleister per ScriptLogic... Das setzen wir nicht ein. Bietet SL da deutlich interessantere Möglichkeiten als das pure kix??? Keine Ahnung - leider lässt sich das nicht so richtig erfragen
Ich hoffe doch, dass es noch die eine oder andere Idee hierzu gibt
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 127030
Url: https://administrator.de/contentid/127030
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
trag das unter Scheduled Tasks ein, beim Systemsstart ausführen - und als erstes kommt ein Sleepkommando
Adminsacc als Starter
Speichern, gut iss
Gruß
24
trag das unter Scheduled Tasks ein, beim Systemsstart ausführen - und als erstes kommt ein Sleepkommando
Adminsacc als Starter
Speichern, gut iss
Gruß
24
Servus,
wenn du dir bitte die Mühe machst, und ein paar Zeilenschalter in deine Frage hinzufügst.
Dann kriegen wir auch keinen Augenkrebs
Ich tippe mal, es ist leichter via Kix zuerst den Wert auszulesen und dann zu ändern und damit dass auch als User klappt zuerst einmalig mit Setacl die rechte setzen.
Gruß
wenn du dir bitte die Mühe machst, und ein paar Zeilenschalter in deine Frage hinzufügst.
Dann kriegen wir auch keinen Augenkrebs
Ich tippe mal, es ist leichter via Kix zuerst den Wert auszulesen und dann zu ändern und damit dass auch als User klappt zuerst einmalig mit Setacl die rechte setzen.
Gruß
Zitat von @60730:
wenn du dir bitte die Mühe machst, und ein paar Zeilenschalter
in deine Frage hinzufügst.
Dann kriegen wir auch keinen Augenkrebs
Jajaja hast ja recht ;)wenn du dir bitte die Mühe machst, und ein paar Zeilenschalter
in deine Frage hinzufügst.
Dann kriegen wir auch keinen Augenkrebs
Ich tippe mal, es ist leichter via Kix zuerst den Wert auszulesen und
dann zu ändern und damit dass auch als User klappt zuerst
einmalig mit Setacl
die rechte setzen.
dann zu ändern und damit dass auch als User klappt zuerst
einmalig mit Setacl
die rechte setzen.
Hat einer von uns beiden falsch verstanden. Die medicoreg.exe überprüft ob der startende User Adminrecht besitzt. So wie ich ACL's kenne (Berechtigungen auf Fileebene) hat das damit eher nix zu tun. Oder wo gibts noch acl's?
merci so kann ich das auch besser lesen naja in der registrierung gibts auch Berechtigungen...
Und wenn du glück hast - dann versucht die medicoreg.exe nur auf einem bestimmten Bereich zu schreiben.
(Und nimmt dann an, der User hätte Adminrechte)
Besorg dir regmon von
Dann siehts du ja, was es ändert.
Ich würde (entgegegen 2Hard) ein Startupskript machen, wenn es unbedingt so sein muß.
Und damit da kein Username / Password drin stehen muss, einfach h:\ für jederman lesbar als Share definieren.
net use h: \\server\freigabe
start /wait "unamomento" h:\medicoreg.exe
net use h: /delete
exitGruß
Durch Eure Kommentare Motiviert habe ich noch etwas rumgebastelt, und mir die nötigen Einträge im STARTScript erzeugt... hat nun doch funktioniert.
[Zeilenumbruch für TB]
Offensichtlich werden einige benutzerabhängige Variablen zwar für die Programmstarts benötigt, für das medicoreg aber noch nicht... da wähnten wir die medicoreg.exe etwas komplexer als sie wirklich ist.
Heißt also: Startscript mappt sich H: führt medicroeg mit ein paar wenigen variablen aus, der Rest erfolgt wieder im Loginscript wie gehabt. Die von Siemens angestrebte Lösung ist das wohl nicht, aber es flutscht.
Vielleicht braucht das mal irgend jemand *hust*.
Vielen Dank für Eure Tipps!
[Zeilenumbruch für TB]
Offensichtlich werden einige benutzerabhängige Variablen zwar für die Programmstarts benötigt, für das medicoreg aber noch nicht... da wähnten wir die medicoreg.exe etwas komplexer als sie wirklich ist.
Heißt also: Startscript mappt sich H: führt medicroeg mit ein paar wenigen variablen aus, der Rest erfolgt wieder im Loginscript wie gehabt. Die von Siemens angestrebte Lösung ist das wohl nicht, aber es flutscht.
Vielleicht braucht das mal irgend jemand *hust*.
Vielen Dank für Eure Tipps!
Moin!
Ich grab das nochmal aus... wie sieht denn dein Script so ungefähr aus?
Muss jetzt auch Siemens Medico unter Win 7 ohne ScriptLogic/Desktop Authority basteln!
Umgebungvariablen setzten mit Gruppenrichtlinien kein Problem, Netzlaufwerke auch nicht, aber die Medicoreg ist schon ne Nuss...
have fun
Ich grab das nochmal aus... wie sieht denn dein Script so ungefähr aus?
Muss jetzt auch Siemens Medico unter Win 7 ohne ScriptLogic/Desktop Authority basteln!
Umgebungvariablen setzten mit Gruppenrichtlinien kein Problem, Netzlaufwerke auch nicht, aber die Medicoreg ist schon ne Nuss...
have fun
Empfehlung von Siemens ist hier kein Netzlaufwerk zu verwenden.
wenn man dies trotzdem tut, so muss man
net use h: "\\Server\Freigabe"
h:
cd kkh
cd dll
medicoreg.exe
ausführen, dann funktioniert es. Wenn eure Server allerdings virtuelle Maschinen sind empfehle ich die Einbindung einer SAN-Platte/LUN um die Anforderung des nicht lokalen speicherns zu erfüllen und die Gewährleistung von Siemens nicht zu verlieren.
wenn man dies trotzdem tut, so muss man
net use h: "\\Server\Freigabe"
h:
cd kkh
cd dll
medicoreg.exe
ausführen, dann funktioniert es. Wenn eure Server allerdings virtuelle Maschinen sind empfehle ich die Einbindung einer SAN-Platte/LUN um die Anforderung des nicht lokalen speicherns zu erfüllen und die Gewährleistung von Siemens nicht zu verlieren.
