VB6 Kann man bestimmte Befehle eines Programms unter einem anderen Account ausführen ?
Hallo,
hoffe Ihr könnt mir bei meiner Frage / Problem weiterhelfen....!?
Ich habe ein VB6 Programm welches neue Benutzer im AD anlegt, einige Einträge in eine SQL-DB einträgt, Ordner anlegt usw.....
Das Programm wird mit einem Admin-Account aufgerufen da ein normaler Benutzer keine Rechte hat neue Benutzer im AD anzulegen.
D.h. alles was mit dem Programm gemacht wird läuft unter diesem Admin-Account.
Beim Eintragen von Daten in die SQL-DB wird dieses mitgelogt. Nur steht dann da als Ausführender der Admin-Account mit dem das VB Programm aufgerufen wurde.
Ich würde es jetzt gerne so haben das der Name des tatsächlich Ausführenden da steht.
Ist es möglich den Abschnitt wo die Verbinding zur SQL-DB gemacht und die Daten geschrieben werden unter dem normalen User-Account gemacht wird und es danach wieder mit dem Admin-Account weitergeht ?
Es wäre auch möglich das Programm mit dem normalen User aufzurufen und die Einträge im AD dann mit einem Admin-Account machen zu lassen.....
Vielleicht hat einer ja eine Idee....
Gruß
SKID
hoffe Ihr könnt mir bei meiner Frage / Problem weiterhelfen....!?
Ich habe ein VB6 Programm welches neue Benutzer im AD anlegt, einige Einträge in eine SQL-DB einträgt, Ordner anlegt usw.....
Das Programm wird mit einem Admin-Account aufgerufen da ein normaler Benutzer keine Rechte hat neue Benutzer im AD anzulegen.
D.h. alles was mit dem Programm gemacht wird läuft unter diesem Admin-Account.
Beim Eintragen von Daten in die SQL-DB wird dieses mitgelogt. Nur steht dann da als Ausführender der Admin-Account mit dem das VB Programm aufgerufen wurde.
Ich würde es jetzt gerne so haben das der Name des tatsächlich Ausführenden da steht.
Ist es möglich den Abschnitt wo die Verbinding zur SQL-DB gemacht und die Daten geschrieben werden unter dem normalen User-Account gemacht wird und es danach wieder mit dem Admin-Account weitergeht ?
Es wäre auch möglich das Programm mit dem normalen User aufzurufen und die Einträge im AD dann mit einem Admin-Account machen zu lassen.....
Vielleicht hat einer ja eine Idee....
Gruß
SKID
Antworten
- Mehr
Auf Facebook teilen
Auf Twitter teilen7 Antworten
- LÖSUNG Karo schreibt am 02.03.2011 um 15:16:09 Uhr
- LÖSUNG SlainteMhath schreibt am 02.03.2011 um 15:44:06 Uhr
- LÖSUNG skid schreibt am 03.03.2011 um 08:26:29 Uhr
- LÖSUNG skid schreibt am 03.03.2011 um 08:26:08 Uhr
- LÖSUNG Karo schreibt am 03.03.2011 um 10:07:41 Uhr
- LÖSUNG skid schreibt am 04.03.2011 um 09:00:30 Uhr
- LÖSUNG Karo schreibt am 04.03.2011 um 16:17:28 Uhr
- LÖSUNG skid schreibt am 04.03.2011 um 09:00:30 Uhr
- LÖSUNG Karo schreibt am 03.03.2011 um 10:07:41 Uhr
- LÖSUNG SlainteMhath schreibt am 02.03.2011 um 15:44:06 Uhr
LÖSUNG 02.03.2011 um 15:16 Uhr
Hi,
wieso wertet das Proggie nicht die Umgebungsvariable USERNAME aus und trägt diesen in die LOG-Table?
bye
Karo
wieso wertet das Proggie nicht die Umgebungsvariable USERNAME aus und trägt diesen in die LOG-Table?
bye
Karo
LÖSUNG 02.03.2011 um 15:44 Uhr
Moin,
oder wie wär's wenn Du dem richtigen User Verwaltungsrechte auf den/die entsprechenden OU's deligierst? M.E. die sauberste Methode
lg,
Slainte
oder wie wär's wenn Du dem richtigen User Verwaltungsrechte auf den/die entsprechenden OU's deligierst? M.E. die sauberste Methode
lg,
Slainte
LÖSUNG 03.03.2011 um 08:26 Uhr
Zitat von @Karo:
Hi,
wieso wertet das Proggie nicht die Umgebungsvariable USERNAME aus und trägt diesen in die LOG-Table?
bye
Karo
Hi,
wieso wertet das Proggie nicht die Umgebungsvariable USERNAME aus und trägt diesen in die LOG-Table?
bye
Karo
Hi,
das hatte ich mal probiert, aber da wird dann nur der USERNAME des Admin-Accounts genommen.
SKID
LÖSUNG 03.03.2011 um 08:26 Uhr
Zitat von @SlainteMhath:
Moin,
oder wie wär's wenn Du dem richtigen User Verwaltungsrechte auf den/die entsprechenden OU's deligierst? M.E. die
sauberste Methode
lg,
Slainte
Moin,
oder wie wär's wenn Du dem richtigen User Verwaltungsrechte auf den/die entsprechenden OU's deligierst? M.E. die
sauberste Methode
lg,
Slainte
Moin,
das wäre vielleicht schon eine saubere Methode - ist aber nicht erwünscht.
Dieses Proggi wird von mehreren Personen ausgeführt die auch noch Bundesweit verteilt sind.
SKID
LÖSUNG 03.03.2011 um 10:07 Uhr
Moin,
klar, das Prog wird schließlich im Admin-Kontext laufen, dann ist die Umgebung auch die seine.
Es gibt sicherlich mehrere Möglichkeiten. Allerdings müsste man den Code und Deine Umgebung kennen
Ein Beispiel:
Wenn das Prog per RUNAS aufgerufen wird, könntest Du zuvor den normalen %USERNAME% in der CMD in ein LOG schreiben, welches dann wiederum vom Prog eingelesen und der Wert in die SQL DB geschrieben wird.
Ansonsten wäre es, abgesehen von der OU Geschichte, am saubersten nur den Code der tatsächlich als Admin ausgeführt werden muss auch unter dessen Kontext laufen zu lassen und alles andere mit dem normalen Useraccount.
Karo
klar, das Prog wird schließlich im Admin-Kontext laufen, dann ist die Umgebung auch die seine.
Es gibt sicherlich mehrere Möglichkeiten. Allerdings müsste man den Code und Deine Umgebung kennen
Ein Beispiel:
Wenn das Prog per RUNAS aufgerufen wird, könntest Du zuvor den normalen %USERNAME% in der CMD in ein LOG schreiben, welches dann wiederum vom Prog eingelesen und der Wert in die SQL DB geschrieben wird.
Ansonsten wäre es, abgesehen von der OU Geschichte, am saubersten nur den Code der tatsächlich als Admin ausgeführt werden muss auch unter dessen Kontext laufen zu lassen und alles andere mit dem normalen Useraccount.
Karo
LÖSUNG 04.03.2011 um 09:00 Uhr
Moin,
habe es bisher so das ich eine "start.exe" habe die dann das eigentliche Programm als Admin-User aufruft. In der "start.exe" wird der Username des tatsächlichen Anwenders ermittelt und in eine
Textdatei geschrieben die ich dann an einer anderen Stelle wieder verwende.
Es ist wohl so das mit dem "Hauptprogramm", welches mit dem Adminaccount läuft und die Einträge in die SQL-DB macht, der Username des Adminaccounts autom. mit in die DB geschrieben wird.....ist wohl so im SQL eingestellt ?!
Daher wäre es wohl am besten wenn das Programm mit dem Account des tatsächlichen Users gestartet wird und nur die Teile, wo der User keine Rechte hat was zu machen, diese mit einem Admin-Account laufen würden.
Ich habe den ganzen Code in einer Datei. Also keine externen Module usw.....
Könnte man evtl. bestimmte Teile "Auslagern" die man dann als Admin aufruft ? ....Programm wird gestartet, wird von oben her abgearbeitet, kommt an einen Punkt wo etwas "Extenes" aufgerufen wird und dann wieder in den Hauptcode springt....
Kenne mich leider nicht so gut mit VB aus.....
SKID
habe es bisher so das ich eine "start.exe" habe die dann das eigentliche Programm als Admin-User aufruft. In der "start.exe" wird der Username des tatsächlichen Anwenders ermittelt und in eine
Textdatei geschrieben die ich dann an einer anderen Stelle wieder verwende.
Es ist wohl so das mit dem "Hauptprogramm", welches mit dem Adminaccount läuft und die Einträge in die SQL-DB macht, der Username des Adminaccounts autom. mit in die DB geschrieben wird.....ist wohl so im SQL eingestellt ?!
Daher wäre es wohl am besten wenn das Programm mit dem Account des tatsächlichen Users gestartet wird und nur die Teile, wo der User keine Rechte hat was zu machen, diese mit einem Admin-Account laufen würden.
Ich habe den ganzen Code in einer Datei. Also keine externen Module usw.....
Könnte man evtl. bestimmte Teile "Auslagern" die man dann als Admin aufruft ? ....Programm wird gestartet, wird von oben her abgearbeitet, kommt an einen Punkt wo etwas "Extenes" aufgerufen wird und dann wieder in den Hauptcode springt....
Kenne mich leider nicht so gut mit VB aus.....
SKID
LÖSUNG 04.03.2011 um 16:17 Uhr
Hi,
sicher kann man das mit dem auslagern machen, muss man den Code halt modifizieren und neu kompilieren.
Ansonsten liefert sehr wahrscheinlich Dein Prog die Daten an SQL, die DB wird von sich wohl weniger machen.
Karo
sicher kann man das mit dem auslagern machen, muss man den Code halt modifizieren und neu kompilieren.
Ansonsten liefert sehr wahrscheinlich Dein Prog die Daten an SQL, die DB wird von sich wohl weniger machen.
Karo
