Transaktionen ohne Berechtigung starten
Es gibt einen kleinen trick mit dem man etliche Transaktionen starten kann, auch wenn man keine Berechtigung hat!
Mit SE16 in der Tabelle TSTC nach dem Transaktionsnamen suchen und den Programmnamen herauskopieren.
Nun mit der SE38 (diese Berechtigung benötigt man!) oder SA38 diesen Report anstarten. Es funktioniert nicht mit allen, jedoch mit sehr vielen Transaktionen / Reports.
Bspw mit Transaktion SM66 -> Reportname SAPMSM66
Mit SE16 in der Tabelle TSTC nach dem Transaktionsnamen suchen und den Programmnamen herauskopieren.
Nun mit der SE38 (diese Berechtigung benötigt man!) oder SA38 diesen Report anstarten. Es funktioniert nicht mit allen, jedoch mit sehr vielen Transaktionen / Reports.
Bspw mit Transaktion SM66 -> Reportname SAPMSM66
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Das funktioniert nur dann, wenn der Transaktionscode "berechtigungsgeschützt" ist.
Viele Transaktionen/Programme haben interne Berechtigungsprüfungen oder fragen sogar den Transaktioncode ab, mit dem sie gestartet wurden.
Da kann ein Aufruf aus der SE38 ganz schön in die Hose gehen. Bei Modulpools geht es sowieso nicht.
(und im übrigen stellt sich immer wieder die Frage, warum man soetwas machen muß. Entweder ich brauch die Transaktion, dann bekomme ich die Berechtigung, oder ich kann die Aufgabe/den Job eben nicht machen. Ist doch nicht meine Entscheidung...)
mfg.
babap
Viele Transaktionen/Programme haben interne Berechtigungsprüfungen oder fragen sogar den Transaktioncode ab, mit dem sie gestartet wurden.
Da kann ein Aufruf aus der SE38 ganz schön in die Hose gehen. Bei Modulpools geht es sowieso nicht.
(und im übrigen stellt sich immer wieder die Frage, warum man soetwas machen muß. Entweder ich brauch die Transaktion, dann bekomme ich die Berechtigung, oder ich kann die Aufgabe/den Job eben nicht machen. Ist doch nicht meine Entscheidung...)
mfg.
babap
==> ganz einfach chrisu.. weil es Führungskräfte gibt die der Meinung sind.. da kann nichts passieren bzw. die Wahrscheinlichkeit sei so gering dass der Aufwand der einzelnen Reportberechtigung nicht durch den Nutzen gerechtfertigt würde (na ja... bis der Supergau kommt und ein Enduser einen Report startet der keine Berechtigungsprüfung beinhaltet)Chrisu hat geschrieben:Wieso sollte ich als Administrator jemandem ohne triftigen Grund die Berechtigung für die se16 und die se/sa38 geben?
Tja ja,
da habe ich meine eigenen leidvollen Erfahrungen
Petra
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Verstehe ich das richtig:Petra hat geschrieben:==> ganz einfach chrisu.. weil es Führungskräfte gibt die der Meinung sind.. da kann nichts passieren bzw. die Wahrscheinlichkeit sei so gering dass der Aufwand der einzelnen Reportberechtigung nicht durch den Nutzen gerechtfertigt würde (na ja... bis der Supergau kommt und ein Enduser einen Report startet der keine Berechtigungsprüfung beinhaltet)Chrisu hat geschrieben:Wieso sollte ich als Administrator jemandem ohne triftigen Grund die Berechtigung für die se16 und die se/sa38 geben?
Tja ja,
da habe ich meine eigenen leidvollen Erfahrungen
:roll:
Petra
Die Führungskräfte entscheiden das so, aber wenn was schiefgeht, ist der Admin schuld?
Die Führungskräfte entscheiden das so, aber wenn was schiefgeht, ist der Admin schuld?[/quote]
tja, DAS wird sich erst herausstellen wenn der Fall der Fälle eintritt. Nur hat man als Admin bzw. als die Person die für die Konzepte zuständig ist hier keinen Einfluss. Wenn die Empfehlungen nicht angenommen werden weil sie Kosten generieren und die Hinweise auf potentielle Gefahren mit dem Hinweis abtut die Wahrscheinlichkeit wäre zu gering als dass man bereit wäre für die Umsetzung in Personal zu investieren... was kann man da noch tun?
Bei 5 Systemen (mit ca. zwischen 1000 + 600 Usern) + den dazugehörenden Systemlandschaften macht es sich nämlich durchaus im Tagesgeschäft wenn man anfängt Reports über Transaktionen zu berechtigen und Tabellenansichten (se16 ist bei uns im Prod.-System keine Pflegeberechtigung .. d.h. systemseitig deaktiviert) restriktiv zu berechtigen. Wobei letzteres eine ewige Gradwanderung darstellt.
Du siehst...
du liest ne frustrierte
Petra
tja, DAS wird sich erst herausstellen wenn der Fall der Fälle eintritt. Nur hat man als Admin bzw. als die Person die für die Konzepte zuständig ist hier keinen Einfluss. Wenn die Empfehlungen nicht angenommen werden weil sie Kosten generieren und die Hinweise auf potentielle Gefahren mit dem Hinweis abtut die Wahrscheinlichkeit wäre zu gering als dass man bereit wäre für die Umsetzung in Personal zu investieren... was kann man da noch tun?
Bei 5 Systemen (mit ca. zwischen 1000 + 600 Usern) + den dazugehörenden Systemlandschaften macht es sich nämlich durchaus im Tagesgeschäft wenn man anfängt Reports über Transaktionen zu berechtigen und Tabellenansichten (se16 ist bei uns im Prod.-System keine Pflegeberechtigung .. d.h. systemseitig deaktiviert) restriktiv zu berechtigen. Wobei letzteres eine ewige Gradwanderung darstellt.
Du siehst...
du liest ne frustrierte
Petra
Hallo,
ein sauber aufgesetztes Berechtigungskonzept (Rollen!!!) auch für Entwickler und Power-User macht sich sehr schnell bezahlt. Der Aufwand für die Pflege hängt nicht von der absoluten Anzahl der Benutzer, sondern von der Anzahl der Benutzergruppen ab.
Die Pflege über SE16 beurteile ich per se als ziemlich unsauber, unsicher, und dazu noch fürchterlich unbequem.
Der Start von Programmen über SE38 sollte eigentlich der Vergangenheit angehören. Jeder produktiv genutzte Report sollte eine Transaktion besitzen.
Ich habe jetzt gerade eine relativ große Schnittstellen-Anwendung geschrieben, die über ca. 40 "eigene" Tabellen verfügt. Dabei sind viele Customizing-Tabellen, aber auch ca. 15 Datentabellen, die man sich ab und zu mal ansehen muß.
Keine Tabelle wird über SE16 gepflegt!
Alle diese Tabellen haben, wenn nötig, eine Pflegeview (SM30) und eine Transaktion. Alle Programme und Modulpools haben ihre Transaktion und alle Transaktionen sind in das zugehörige Bereichsmenü eingebunden.
Die Berechtigungen sind auch dazu da, versehentliche Änderungen zu verhindern. Wenn erst mal der Worst-Case von unzureichenden Berechtigungen eintritt, ist die Katastrophe da, denn i.d.R. werden bestimmte Datenfehler (oder Änderung) so spät bemerkt, daß sie schon x-mal gesichert wurden.
Etwas Organisation muß sein.
mfg.
babap
ein sauber aufgesetztes Berechtigungskonzept (Rollen!!!) auch für Entwickler und Power-User macht sich sehr schnell bezahlt. Der Aufwand für die Pflege hängt nicht von der absoluten Anzahl der Benutzer, sondern von der Anzahl der Benutzergruppen ab.
Die Pflege über SE16 beurteile ich per se als ziemlich unsauber, unsicher, und dazu noch fürchterlich unbequem.
Der Start von Programmen über SE38 sollte eigentlich der Vergangenheit angehören. Jeder produktiv genutzte Report sollte eine Transaktion besitzen.
Ich habe jetzt gerade eine relativ große Schnittstellen-Anwendung geschrieben, die über ca. 40 "eigene" Tabellen verfügt. Dabei sind viele Customizing-Tabellen, aber auch ca. 15 Datentabellen, die man sich ab und zu mal ansehen muß.
Keine Tabelle wird über SE16 gepflegt!
Alle diese Tabellen haben, wenn nötig, eine Pflegeview (SM30) und eine Transaktion. Alle Programme und Modulpools haben ihre Transaktion und alle Transaktionen sind in das zugehörige Bereichsmenü eingebunden.
Die Berechtigungen sind auch dazu da, versehentliche Änderungen zu verhindern. Wenn erst mal der Worst-Case von unzureichenden Berechtigungen eintritt, ist die Katastrophe da, denn i.d.R. werden bestimmte Datenfehler (oder Änderung) so spät bemerkt, daß sie schon x-mal gesichert wurden.
Etwas Organisation muß sein.
mfg.
babap
ja bapab.. irgendwie frustriert mich Dein Posting mehr als dass es mir gut tut. Auch wenn Du mir aus der Seele sprichst.
Und wenn man "nur" für die Berechtigungen diverser Systeme zuständig ist, aber auf die Entwickler keinen Einfluss hat, dann hat man da schon ab und an ein Problem.
Und gerade das Berechtigen über Transaktionen (zum Glück kann man ja inzwischen auch über den Profilgenerator TA's generieren) wird bei uns im Haus als zu aufwendig beurteilt. Die Gründe: Die Fachbereiche beschweren sich, dass sie einzelne Reports anfordern müssen und nicht, wie das früher der Fall war, einfach mal schauen können was die ABAP-Welt so her gibt.
Aber auch Deine Vorgehensweise über die SM30 ist nicht ganz sauber da auch über diese unerwünschte Freigaben erfolgen können. Korrekter wäre es, wenn Du auch die Pflege über eine eigenen Transaktion vergeben würdest und die SM30 nicht in die Berechtigungen der Enduser fallen würde.
Was mich aber mal so am Rande interessieren würde.... von wieviel Systemen mit welcher Anzahl von Sammelrollen und Usern sprichst Du denn?
Petra
Und wenn man "nur" für die Berechtigungen diverser Systeme zuständig ist, aber auf die Entwickler keinen Einfluss hat, dann hat man da schon ab und an ein Problem.
Und gerade das Berechtigen über Transaktionen (zum Glück kann man ja inzwischen auch über den Profilgenerator TA's generieren) wird bei uns im Haus als zu aufwendig beurteilt. Die Gründe: Die Fachbereiche beschweren sich, dass sie einzelne Reports anfordern müssen und nicht, wie das früher der Fall war, einfach mal schauen können was die ABAP-Welt so her gibt.
Aber auch Deine Vorgehensweise über die SM30 ist nicht ganz sauber da auch über diese unerwünschte Freigaben erfolgen können. Korrekter wäre es, wenn Du auch die Pflege über eine eigenen Transaktion vergeben würdest und die SM30 nicht in die Berechtigungen der Enduser fallen würde.
Was mich aber mal so am Rande interessieren würde.... von wieviel Systemen mit welcher Anzahl von Sammelrollen und Usern sprichst Du denn?
Petra
Hallo,
jetzt nur kurz zum Thema SM30:
Für jede Tabelle kann eine Berechtigungsgruppe vergeben werden.
Nur wenn im Berechtigungsprofil diese Berechtigungsgruppe eingetragen ist, kann mit SM30 diese Tabelle gepflegt werden.
Aus Berechtigungssicht absolut korrekt, genial und sicher.
mfg.
babap
jetzt nur kurz zum Thema SM30:
Für jede Tabelle kann eine Berechtigungsgruppe vergeben werden.
Nur wenn im Berechtigungsprofil diese Berechtigungsgruppe eingetragen ist, kann mit SM30 diese Tabelle gepflegt werden.
Aus Berechtigungssicht absolut korrekt, genial und sicher.
mfg.
babap
Und was geschieht mit Standardtabellen deren Standardberechtigungsgruppe geändert wurde und die in irgendwelchen Reports abgeprüft wird (z.B. Customizingtabellen)?babap hat geschrieben:Hallo,
jetzt nur kurz zum Thema SM30:
Für jede Tabelle kann eine Berechtigungsgruppe vergeben werden.
Nur wenn im Berechtigungsprofil diese Berechtigungsgruppe eingetragen ist, kann mit SM30 diese Tabelle gepflegt werden.
Aus Berechtigungssicht absolut korrekt, genial und sicher.
mfg.
babap
Bisher habe ich aufgrund dieser offenen Frage vom Standard die Finger gelassen und lediglich Eigenentwicklungen gepflegt.
Gruß
Petra
Hallo,
Standardtabellen pflegt man am besten über die zugehörige Anwendung oder über die zugehörige Customizing-Transaktion. Diese sind i.d.R. auch über Berechtigungsobjekte schützbar.
Der Gedanke, die Berechtigungsgruppe von Standardtabellen (oder Views) zu ändern und diese über SM30 zu pflegen, bereitet mir kein gutes Gefühl (und das ist wirklich viel zu nett geschrieben).
mfg.
babap
das o.a. Verfahren eignet sich hervorragend für Eigenentwicklungen.Petra hat geschrieben: Und was geschieht mit Standardtabellen deren Standardberechtigungsgruppe geändert wurde und die in irgendwelchen Reports abgeprüft wird (z.B. Customizingtabellen)?
Bisher habe ich aufgrund dieser offenen Frage vom Standard die Finger gelassen und lediglich Eigenentwicklungen gepflegt.
...
Standardtabellen pflegt man am besten über die zugehörige Anwendung oder über die zugehörige Customizing-Transaktion. Diese sind i.d.R. auch über Berechtigungsobjekte schützbar.
Der Gedanke, die Berechtigungsgruppe von Standardtabellen (oder Views) zu ändern und diese über SM30 zu pflegen, bereitet mir kein gutes Gefühl (und das ist wirklich viel zu nett geschrieben).
mfg.
babap
ok, dann siehst Du das ja ähnlich wie ich. Nur leider gibt man mit dieser Restriktion auf Customizingebene unerwünschte Pflegeberechtigungen auf Tabellen da einige Customizingberechtigungen lediglich SM30-berechtigungen darstellen. Hinzu kommt leider eine unschöne Gruppierung auf Standardberechtigungsgruppenebene.babap hat geschrieben:Hallo,
das o.a. Verfahren eignet sich hervorragend für Eigenentwicklungen.Petra hat geschrieben: Und was geschieht mit Standardtabellen deren Standardberechtigungsgruppe geändert wurde und die in irgendwelchen Reports abgeprüft wird (z.B. Customizingtabellen)?
Bisher habe ich aufgrund dieser offenen Frage vom Standard die Finger gelassen und lediglich Eigenentwicklungen gepflegt.
...
Standardtabellen pflegt man am besten über die zugehörige Anwendung oder über die zugehörige Customizing-Transaktion. Diese sind i.d.R. auch über Berechtigungsobjekte schützbar.
Der Gedanke, die Berechtigungsgruppe von Standardtabellen (oder Views) zu ändern und diese über SM30 zu pflegen, bereitet mir kein gutes Gefühl (und das ist wirklich viel zu nett geschrieben).
mfg.
babap
Kurz gesagt, der Standard ist leider nicht optimal schützbar.
Gruß
Petra
Bei uns in der sehr grossen Firma, gibt es GRUNDSÄTZLICH keine Berechtigung für SM50.
Also muss man als Entwickler das Programm: RSMON000 aus der SE38 aufrufen.
Ich hatte selbst als Entwickler NICHT die Berechtigung für SLIN bekommen.
SLIN ist aber NUR für Entwickler von Nutzen. "erweiterte Prüfung von ABAP-PRogrammen".
Die Admins sind teilweise wie Beamte.
Also muss man als Entwickler das Programm: RSMON000 aus der SE38 aufrufen.
Ich hatte selbst als Entwickler NICHT die Berechtigung für SLIN bekommen.
SLIN ist aber NUR für Entwickler von Nutzen. "erweiterte Prüfung von ABAP-PRogrammen".
Die Admins sind teilweise wie Beamte.
Vergleichbare Themen
0
Antw.
Antw.
1160
Views
Views
Transaktionen und Reports starten mit WAS
von sap_all » 23.08.2005 16:10 • Verfasst in Web Application Server
von sap_all » 23.08.2005 16:10 • Verfasst in Web Application Server
0
Antw.
Antw.
1223
Views
Views
Transaktionen und Reports starten mit WAS
von sap_all » 23.08.2005 16:09 • Verfasst in Web Application Server
von sap_all » 23.08.2005 16:09 • Verfasst in Web Application Server
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
ADT - Änderung an einzelner Methode sperrt die ganze Klasse im Trapo
vor 6 Stunden von 19KnarfRed81 1 / 50
vor 6 Stunden von 19KnarfRed81 1 / 50
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
ADT - Änderung an einzelner Methode sperrt die ganze Klasse im Trapo
vor 6 Stunden von 19KnarfRed81 1 / 50
vor 6 Stunden von 19KnarfRed81 1 / 50
Unbeantwortete Forenbeiträge
ADT - Änderung an einzelner Methode sperrt die ganze Klasse im Trapo
vor 6 Stunden von 19KnarfRed81 1 / 50
vor 6 Stunden von 19KnarfRed81 1 / 50