Wenn man sich mit der Einführung des Change Request Management mit dem SAP Solution Manager beschäftigt, kommt man sehr schnell dazu, die Eingabemasken für die Korrekturen anzupassen. Wie das geht, möchte ich in einem kleinen HowTo exemplarisch darstellen.

Dabei geht es in dem Beispiel darum, einige der Felder für die dringende Korrektur im ChaRM (Transaktion CRMD_ORDER) als Pflichtfelder zu definieren.

Das Customizing erfolgt über die Transaktion SHD0, der Transaktion zum Anlegen und Ändern von Transaktions- und Screenvarianten.

Das HowTo kann man hier finden:

HowTo_CRMD_ORDER

The post Customizing SAP ChaRM Eingabemaske appeared first on rz10.de - die SAP Basis und Security Experten.

Für Wartungsarbeiten wie zum Beispiel Upgrades oder das Einspielen von Support Packages kann es sinnvoll sein, alle nicht benötigten Benutzer eines Systems zu sperren. Dies kann über die SAP Transaktion SU10 durchgeführt werden.

Für die Verwendung der SU10 hilft es, standardisierte Vorgehensweisen zur Festlegung der Benutzer-Zuordnung und Gültigkeit zu haben.

Wir erstellen individuelle SAP Berechtigungskonzepte, die solche Themen berücksichtigen. Dabei verwenden wir eine standardisierte Vorgehensweise zur Einführung von neuen Berechtigungen, die wir bei vielen Kunden erfolgreich eingesetzt haben. Deshalb haben wir dafür auch ein passendes Angebot: SAP Berechtigungskonzepte entwickeln
Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.175403-22 oder per E-Mail info@rz10.deIn einem unverbindlichen Gespräch kann ich mit Ihnen über Ihre Ausgangslage sprechen und Ihnen Möglichkeiten aufzeigen. Selbstverständlich können wir danach auch ein unverbindliches Angebot unterbreiten. Fachbereichsleiter Tobias Harmes

Transaktion SU10 – Benutzerpflege Massenänderungen

„Nur nicht gesperrete Benutzer“, Ausführen (F8). Dies stellt sicher, dass nach dem Upgrade die nur die richtigen Benutzer wieder entsperrt werden.

Liste Sichern in Datei…

Aus der Excel-Datei die Spalte Benutzername in eine eigene Textdatei kopieren. Aus dieser Datei die User ADMIN, DDIC, J2EE_ADMIN,J2EE_GUEST, J2EE_DDIC,SAP* und den eigenen User entfernen!

Wenn man diese Liste erstellt hat, läuft das Sperren und Entsperren praktisch gleich ab. Wichtig: immer daran denken, dass der eigene User, der admin und ddic nicht in der Liste sind.
Wieder in der Transaktion SU10:

„Import aus Textfile“, danach auf „Übernehmen“

Alle Selektieren und „Übernehmen“

Dann kann man jeweils sperren oder entsperren auswählen.

The post Massensperren von Benutzern via SU10 appeared first on rz10.de - die SAP Basis und Security Experten.

Über das Berechtigungsobjekt S_DEVELOP kann man Debugging-Berechtigung im SAP erteilen. Diese Berechtigung erlaubt es über die Eingabe von „/h“ im OK-Feld der Gui den Debug-Modus zu aktivieren.

Während diese Funktion auf dem Entwicklungssystem ohne Frage zu den notwendigen Entwicklungsfunktionalitäten dazugehört ist es auf einem Produktions- oder Konsolidierungssystem höchst kritisch. Denn es erlaubt dem Anwender den normalen Programmablauf zu beeinflussen und Werte während des Programmlaufs zu ändern.

So kann ein Anwender ein Programm starten und z.B. einen AUTHORITY-CHECK überspringen. Damit erlangt er Zugang zu Daten oder kann Änderungen vornehmen, die im normalen Programmfluss nicht vorgesehen sind.

Ein prominentes Beispiel ist auch über den Debug-Modus das sapedit in der SE16 bzw. SE16N wieder zu aktivieren – dann kann man direkt in der Tabellenansicht Änderungen in der Datenbank durchgeführen. Diese Möglichkeit Felder zu ändern gefährdet den Grundsatz „Keine Änderung ohne Beleg“.

Wie kann man nun S_DEVELOP einschränken?

Zuerst muss man die Rollen identifizieren, die S_DEVELOP mit DEBUG Aktivität 02 enthalten. Dies kann man über die SUIM -> Rollen nach komplexen Selektionskriterien durchgeführt werden. Wenn man den Debug-Modus komplett deaktiveren will, muss man auch nach Aktivität 03 suchen.

Im Rolleneditor in der PFCG kann man nun die entsprechende Rolle einschränken.

Im Hinweis 65968 – ABAP-Debugging-Berechtigungen werden die möglichen Werten für S_DEVELOP dokumentiert:

The post SAP Debug Berechtigung einschränken appeared first on rz10.de - die SAP Basis und Security Experten.

Mit dem Funktionsbaustein SWNC_COLLECTOR_GET_AGGREGATES können vom System gesammelte Workload-Daten extrahiert werden. Die Ergebnisse entsprechen den Daten wie sie z.B. auch im Systemlastmonitor (ST03N) zu finden sind. Eine solche Liste von tatsächlich genutzten Transaktionen ist beispielsweise sehr nützlich für das Erstellen von neuen Rollen. Dem Anwender oder Keyuser kann man schon im Vorfeld „seine“ Transaktionen präsentieren und so die Rollenentwicklung deutlich beschleunigen.

Wenn man nicht gleich ein ABAP schreiben möchte, kann man auch folgende Schritte durchführen:

Funktionsbaustein SWNC_COLLECTOR_GET_AGGREGATES in SE37 ausführen.

Parameter für den Funktionsbaustein eingeben und „Ausführen“

Ergebnistabelle USERTCODE selektieren.

Die Liste als Lokale Datei abspeichern.

Der Benutzername befindet sich in der Spalte Account. Die Transaktionen und Programme stehen dann in der Spalte „ENTRY_ID“. Am Ende der gleichen Spalte (Zeichen 72) steht dann jeweils der Typ, also z.B. der Buchstabe T für Transaktion oder R für Report.

Tipp: Den Langtext der Transaktionen in der passenden Sprache kann man sich aus der Tabelle TSTCT besorgen.

The post Genutzte Transaktionen aus dem SAP Workload Monitor ST03N exportieren appeared first on rz10.de - die SAP Basis und Security Experten.

Es kommt immer wieder vor, dass man für die Neukonzeption von SAP Berechtigungen zunächst herausfinden muss: was macht der Anwender im SAP eigentlich genau? Diese Prozessaufnahme hat natürlich viele interaktive Elemente wie Interviews am Platz des Benutzers und Workshops zur Prozessaufnahme. Aber manche Informationen können auch schon im Vorfeld gesammelt werden, um die Gespräche auch für die Anwender zu erleichtern. Und dazu gehört das Auslesen von den SAP Favoriten.

Mit einem kleinen unten aufgeführten ABAP kann man für den aktuellen Benutzer alle Favoriten aus der Tabelle smen_buffc auslesen. Mit einer entsprechenden Selektionsmöglichkeit könnte man das auf andere Benutzer beliebig erweitern und zum Beispiel per ALV als Excel exportieren.

SAP Favoriten

SAP Favoriten als einfache Liste

*&---------------------------------------------------------------------*

*& Report  Z_SAP_FAVORITE_EXPORT

*&

*&---------------------------------------------------------------------*

*&

*& Demo program to export data from a user favorite menu

*&---------------------------------------------------------------------*

REPORT  Z_SAP_FAVORITE_EXPORT.

TABLES smen_buffc.

*TYPES: gtt_smen_c TYPE TABLE OF smen_buffc.

data: gt_smen_c TYPE TABLE OF smen_buffc,

      gv_smen_c like LINE OF gt_smen_c.

data: begin of gs_file,

        rtype     like smen_buffc-reporttype,

        parent_id like smen_buffc-parent_id,

        object_id like smen_buffc-object_id,

        tcode     like smen_buffc-report,

        text      like smen_buffc-text,

        sap_guid  like smen_buffc-sap_guid,

     end   of gs_file.

          .

  select * from smen_buffc into table gt_smen_c where uname = SY-UNAME.

*  check sy-subrc eq 0.

  loop at gt_smen_c into gv_smen_c.

    clear gs_file.

    gs_file-rtype     = gv_smen_c-reporttype.

    gs_file-parent_id = gv_smen_c-parent_id.

    gs_file-object_id = gv_smen_c-object_id.

    gs_file-tcode     = gv_smen_c-report.

    gs_file-sap_guid  = gv_smen_c-sap_guid.

    gs_file-text      = gv_smen_c-text.

    write:/ gs_file-rtype, gs_file-tcode, gs_file-text.

  endloop.

The post SAP Favoriten eines Benutzers auslesen appeared first on rz10.de - die SAP Basis und Security Experten.

Jeder Rollenbauer und Berechtigungsadmin kennt das Problem: wenn man eine kundeneigene Transaktion in der PFCG eingefügt hat, sieht es mit den Vorschlagswerte oft sehr schlecht aus. Dann geht das große Suchen los: welche Berechtigungsprüfungen kommen in der Eigenentwicklung hinter der Transaktion vor, welche Berechtigungsobjekte müssen eingefügt werden und mit welchen Werten muss man sie ausprägen damit die Transaktion in dieser Rolle funktioniert.

Entwickler können diese Informationen direkt bei Erstellung Ihrer Programme selbst oder über den zuständigen Administrator in die Vorschlagstabelle pflegen, und zwar über die Transaktion SU24. Damit dokumentieren sie sofort direkt im System ihre Berechtigungsprüfungen und runden ihre Arbeit somit auch aus Berechtigungssicht ab.

Und so geht’s:

In dem Beispiel wird für die Transaktion ZAUTHCHECKDEMO über die Transaktion SU24 zwei Vorschlagswerte gepflegt.

Standardmäßig wird bereits das Objekt S_TCODE eingefügt, dort muss man nur noch bei Vorschlag „Ja“ auswählen.

Das Demoprogramm macht eine Berechtigungsprüfung auf ‚S_CARRID‘, daher muss dieses Berechtigungsobjekt der Transaktion zugeordnet werden. Gegebenenfalls muss man also in dem Source Code nach dem Stichwort AUTHORITY-CHECK suchen.

Nun kann man für dieses Berechtigungsobjekt Vorschlagswerte machen.

Nach dem Sichern sieht das Hinzufügen dieser Transaktion im Rolleneditor dann so aus:

Das Objekt S_TCODE wird automatisch ergänzt, das Berechtigungsobjekt S_CARRID wird automatisch eingefügt und mit Aktivität 03 vorgeschlagen. Damit sind alle in der Transaktion genutzten Berechtigungsobjekte automatisch in der Rolle.

The post Pflege der SAP Berechtigungsvorschlagswerte in der SU24 appeared first on rz10.de - die SAP Basis und Security Experten.

Letzte Woche habe ich in dem Artikel Grafische Visualisierung von SAP Tabellen und Tabellenbeziehungen das Thema Abfrage von Tabelle mit dem QuickViewer erwähnt. Hier eine kurze Anleitung wie man eine entsprechende Abfrage bauen kann.

Hat man die entsprechenden Beziehungen der Tabellen ermittelt, kann man dann relativ bequem Join-Queries über die Transaktion SQVI machen. Das Beispiel soll die durch Rollen zugewiesenen Organisationsebenen eines Benutzers anzeigen. Diese Daten stehen in den Tabellen AGR_USERS und AGR_1252.

Title für QuickView anlegen und als Datenquelle „Table join“ auswählen

Alle relevanten Tabellen einfügen.

Bereits erkannte Fremdschlüsselbeziehungen werden automatisch dargestellt.

Jetzt kann man die Felder der Ergebnistabelle auswählen.

Danach wählt man aus, welche Selektionsfelder für die Eingrenzung der Ergebnisse verfügbar sein sollen.

Mit Ausführen kann man für den gewählten Benutzer…

… alle Rollen und Organisationsebenen ausgeben.

The post Abfrage von mehreren SAP Tabellen über den Quickviewer appeared first on rz10.de - die SAP Basis und Security Experten.

Immer mal wieder nötig, hier eine kurze Anleitung:

Die wichtigsten Transaktionen:

SCOT – SAPconnect Administration / SMTP Konfiguration

SOST – Übersicht Sendeaufträge

1. Mailserver ermitteln: es werden Hostname/IP und SMTP-Port benötigt, in der Regel Port 25

2. In die Transaktion SCOT gehen und Doppelklick auf den SMTP Knoten machen. Dabei beachten: die SCOT ist mandantenabhängig.

Wir übernehmen Betriebsaufgaben und führen SAP Basis Projekte für Sie durch.

Ob Sie ein Systemupgrade durchführen wollen oder einfach nur Unterstützung bei der Konfiguration Ihrer SAP Systemlandschaft benötigen, wir bieten Ihnen unsere kompetenten Berater an: SAP Basis Berater von RZ10
Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.175403-22 oder per E-Mail info@rz10.de In einem unverbindlichen Gespräch kann ich mit Ihnen über Ihre Ausgangslage sprechen und Ihnen Möglichkeiten aufzeigen. Selbstverständlich können wir danach auch ein unverbindliches Angebot unterbreiten.Fachbereichsleiter Tobias Harmes

Als Adressbereich „*“ auswählen, damit dieser Knoten für alle email-Adressen verwendet wird.

3. Default domain setzen, z.B. mindsquare.de

4. Trace setzen

5. In der SU01 seine eigene email-Adresse hinterlegen (und für jeden, der auch Mails versenden will)

6. Testmail versenden über SO01 oder SBWP

7. In die Transaktion SCOT wechseln, dort sollte die Mail bereits warten. Dort den Sendeprozess starten, damit die Queue abgearbeitet wird.

Den Trace kann man auf Wunsch direkt anzeigen oder später in der Transaktion SOST auswerten.

8. Wenn alles sauber läuft, kann man über die SM36 den RSCONN01 einplanen. Der startet dann regelmäßig den Sendeprozess und arbeitet die Mails aus der Queue ab. Wenn es einen Fehler gibt, dann kann man in der Transaktion SOST den Trace prüfen.

Übrigens: Empfängerauthentisierung („550 must be authenticated“) und erzwungene Verschlüsselung machen in der Regel einen Zwischenstopp über zum Beispiel ein internes Mailrelay notwendig. Diese Sicherheitsmechanismen sind leider noch nicht im SAP Standard angekommen.

Weiterführende Informationen:

Hinweis 455140 – Konfiguration Email,Fax,Paging/SMS über SMTP

Hinweis 607108 – Problemanalyse beim Versand oder Empfang von Emails

The post SAP Emailversand einrichten und testen appeared first on rz10.de - die SAP Basis und Security Experten.

Von einem Kollegen habe ich einen Tipp auf den Hinweis 1045019 bekommen. Dort wird ein Web-Diagnose-Tool zum Sammeln von Trace-Dateien angeboten. Nicht immer hat man einen Solution Manager Diagnostics mit Trace Analysis im Zugriff. Da das manuelle Tracen im AS Java Umfeld nicht wirklich Spaß macht (und teilweise mangels Zugriff auch nicht gestattet ist), habe ich mir das Tool mal auf einem Solution Manager 7.1 angesehen. Eines vorweg: man benötigt einen Flash-fähigen Browser.

Vor der Nutzung muss man das .sda-File aus dem Hinweis installieren. Bis 7.02 kann man das über den SDM deployen, für 7.10 und 7.11 geht man über die telnet shell. Für die Nutzung des Trace Collectors ist im Hinweis sogar ein Mini-Flash-Tutorial angehängt.

Nach dem Deploy geht man auf http://<Host>:<Port>/diagtool/tc

Nun kann man für ausgewählte Server Nodes die gewünschten Trace-Ablageorte auswählen, die gesammelt werden sollen. Danach genügt ein Klick auf den Start-Button und die Sammlung wird gestartet.

Hier habe ich während des Traces einen Login mit fehlerhaften Zugangsdaten durchgeführt. Nachdem man die Sammlung beendet hat, wird das Endergebnis und die Anzahl der ermittelten Fehler angezeigt. Mit einem Klick auf die Fehlerspalte gelangt man zu den Details.

Und tatsächlich erhält man eine relativ gut lesbaren Trace der freundlicherweise auch gleich die Fehler einfärbt.

Weitere Links: Hinweis 1045019 – Web-Diagnose-Tool zum Sammeln von Trace-Dateien Hinweis 1332726 – Troubleshooting Wizard

The post Traces sammeln und anzeigen für SAP AS Java 6.40 bis 7.11 appeared first on rz10.de - die SAP Basis und Security Experten.

Bei der Überarbeitung eines SAP Berechtigungskonzepts, der Pflege von bestehenden Rollenportfolios oder schlicht bei der Suche einer passenden Rolle für eine bestimmte Berechtigungsanforderung ist es oftmals erforderlich, alle ausführbaren Transaktionen mehrerer Rollen zu ermitteln.

Für die Ermittlung aller Transaktionen mehrerer Rollen gibt es verschiedene Möglichkeiten mit unterschiedlicher Ergebnisgüte. Im folgenden Beitrag werden drei Varianten vorgestellt. In den ersten beiden Abschnitten wird zunächst beschrieben, wie das Problem mittels SUIM angegangen werden kann und welche Probleme dabei potentiell auftreten. Anschließend wird erläutert, wie die Aufgabe durch die Nutzung der Transaktion SE16N gelöst werden kann. Bei beiden Varianten werden stets die Transaktionen MM01, MM02, MM03 sowie MM04 betrachtet, welche auf unterschiedlichen Wegen verschiedenen Rollen zugeordnet wurden.

Ermittlung aller Transaktionen mehrerer Rollen mittels SUIM

Diese Variante bietet sich an, wenn das zu überprüfende Rollenportfolio lediglich aus einer Rolle besteht. Die Ermittlung aller Transaktionen mehrerer Rollen erfolgt hier mittels der Transaktion SUIM.

Zunächst muss hierfür in der Transaktion SUIM die Variante „ausführbar für Rolle“ ausgeführt werden. Nähreres dazu finden Sie hier.

Anschließend wird lediglich die Rolle eingetragen, dessen zugeordnete Transaktionen angezeigt werden sollen. Im Beispiel ist dies die Rolle Test_Schmidt1. Bei dieser Rolle wurden die Transaktionen MM01 und MM02 im Menü der Rolle eingepflegt.

Nach dem Ausführen der Anfrage werden nun alle Transaktionen, die sich mit der Rolle Test_Schmidt1 ausführen lassen, angezeigt.

Wird die o.g. Variante jedoch mit der Rolle Test_Schmidt2 ausgeführt, bei der die Transaktion MM03 im Menü der Rolle, die Transaktion MM04 jedoch lediglich im Berechtigungsobjekt S_TCODE der Rolle gepflegt wurde, wird folgendes Ergebnis angezeigt.

Es wird lediglich die Transaktion angezeigt, welche im Menü der Rolle gepflegt wurde. Dies liegt daran, dass die genannten Varianten in der SUIM Anfragen auf die Tabelle AGR_TCODES durchführen. Diese enthält pro Rolle ausschließlich die Transaktionen, welche im Menü der entsprechenden Rolle gepflegt wurden.

Ermittlung aller Transaktionen mehrerer Rollen mittels Rollenzuordnung und SUIM

Möglich ist bei der Nutzung der SUIM zur Ermittlung aller Transaktionen mehrerer Rollen auch die Vorgehensweise, ausschließlich alle zu betrachtenden Rollen (hier also Test_Schmidt1 und Test_Schmidt2) zunächst einem Test-Nutzer zuzuordnen und anschließend die SUIM-Variante „ausführbar für Benutzer“ auszuführen.

Nun muss der entsprechende Test-Nutzer, dem zuvor ausschließlich alle zu betrachtenden Rollen zugeordnet wurden, in das Eingabefeld eingetragen werden.

Nach dem Ausführen der Anfrage werden nun alle Transaktionen, die der entsprechende Nutzer mit den ihm zugeordneten Rollen ausführen kann, angezeigt.

Auch hier zeigt sich jedoch, dass lediglich die Transaktionen angezeigt werden, welche im Menü der entsprechenden Rollen gepflegt wurden. Diese Variante bietet sich somit dann an, wenn das zu untersuchenden Rollenportfolio mehrere Rollen enthält, wobei alle Transaktionen im Menü der Rollen gepflegt wurden. Sollte dies nicht der Fall sein, empfiehlt sich die Nutzung der SE16N zur Ermittlung aller Transaktionen in mehreren Rollen.

Ermittlung aller Transaktionen mehrerer Rollen mittels SE16N

Diese Variante bietet sich an, wenn das zu überprüfende Rollenportfolio aus mehreren Rollen besteht, bei denen zusätzlich nicht alle enthaltenen Transaktionen im Menü der Rollen gepflegt wurden. Die Ermittlung der Transaktionen mehrerer Rollen erfolgt hier mittels der Transaktion SE16N über die Tabelle AGR_1251. Achtung: Mittels der Transaktion SE16N lassen sich Daten des SAP Systems auf Tabellenebene auslesen und über Umwege sogar bearbeiten. Deshalb sollten Berechtigungen für diese Transaktion lediglich an die SAP Basis Administratoren vergeben werden.

In der Transaktion wird zunächst die entsprechende Tabelle AGR_1251 eingetragen. Außerdem lässt sich die Begrenzung der maximalen Trefferzahl aufheben.

Anschließend werden sämtliche Rollen des zu untersuchenden Rollenportfolios eingefügt. Zusätzlich wird nach dem Berechtigungsobjekt S-TCODE gefiltert und die Ausgabe auf die Rollen sowie Objektwerte (das sind in diesem Fall die Transaktionen) beschränkt.

Nach dem Ausführen der Anfrage werden nun alle Transaktionen angezeigt, die mit den zuvor eingegebenen Rollen ausführbar sind.

Zusätzlich ist ersichtlich, durch welche Rolle jede Transaktion ausführbar ist, was bei Nutzung der SUIM in Variante 1 nicht der Fall ist. Außerdem sind hierbei auch die Transaktionen ersichtlich, die lediglich über das Berechtigungsobjekt S_TCODE zur Rolle hinzugefügt wurden.

Fazit

Es lässt sich konstatieren, dass für verschiedene Szenarien unterschiedliche Varianten zur Ermittlung aller Transaktionen mehrerer Rollen geeignet sind. Soll lediglich eine Rolle überprüft werden, bei der sämtliche Transaktionen im Menü der Rolle gepflegt wurden, bietet sich die Variante „ausführbar für Rolle“ der SUIM an. Sollen alle Transaktionen mehrerer Rollen ermittelt werden, bei denen sämtliche Transaktionen im Menü der Rollen gepflegt wurden, bietet sich die Variante „ausführbar für Benutzer“ der SUIM oder die Nutzung der Transaktion SE16N an. Sollen alle Transaktionen mehrerer Rollen ermittelt werden, bei denen nicht klar ist, ob sämtliche Transaktionen im Menü der Rollen gepflegt wurden, bietet sich stets die Nutzung der Transaktion SE16N an. Diese ist zwar universell einsetzbar, birgt jedoch durch die Möglichkeit der Einsicht bzw. Bearbeitung von Daten auf Tabellenebene auch erhebliche Gefahren und sollte daher mit Bedacht vergeben werden.

Welche Erfahrungen haben Sie mit der Ermittlung aller Transaktionen mehrerer Rollen gemacht? Kennen Sie weitere Varianten zur Lösung dieses Problems? Über Ihre Erfahrungen und Fragen zu diesem Thema freue ich mich sehr.

The post Ermittlung aller Transaktionen mehrerer Rollen appeared first on rz10.de - die SAP Basis und Security Experten.

Für die Berechtigungsanforderung eines Nutzers sollen entsprechend die bereits vergebenen Transaktionen mit Nutzerzuordnung ermittelt werden, um diese beim Heraussuchen einer passenden Rolle ausschließen zu können. Wie gelingt dies?

Für die Ermittlung bestimmter Transaktionen mit Nutzerzuordnung bestehen verschiedene Möglichkeiten mit unterschiedlicher Ausprägung des Ergebnisses. Im folgenden Beitrag werden zwei Varianten vorgestellt. Im ersten Abschnitten wird zunächst beschrieben, wie das Problem mittels SUIM angegangen werden kann und welche Probleme dabei auftreten. Anschließend wird erläutert, wie die Aufgabe durch die Nutzung der Transaktion SE16N gelöst werden kann. Wie schon im vorangegangenen Blog-Beitrag Ermittlung aller Transaktionen mehrerer Rollen werden hierfür die Rollen Test_Schmidt1 und Test_Schmidt2 genutzt. Diesen Rollen wurden jeweils zwei der Transaktionen MM01, MM02, MM03 sowie MM04 auf unterschiedlichen Wegen zugeordnet. Bei der Rolle Test_Schmidt1 wurden die Transaktionen MM01 und MM02 im Menü der Rolle eingepflegt. Bei der Rolle Test_Schmidt2 wurde die Transaktion MM03 im Menü der Rolle, die Transaktion MM04 jedoch lediglich im Berechtigungsobjekt S_TCODE der Rolle gepflegt. Dem Nutzer SCHMIDT_TEST wurden beide Rollen zugeordnet.

Ermittlung bestimmter Transaktionen mit Nutzerzuordnung mittels SUIM

Diese Variante bietet sich an, wenn lediglich eine Transaktion auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin geprüft werden soll. Die Prüfung erfolgt hier mittels der Transaktion SUIM.

Zunächst muss hierfür in der SUIM die Variante „Rollen nach komplexen Selektionskriterien“ ausgeführt werden.

Nach Aktivierung der Option „Mit gültiger Zuordnung von“ wird hier nun der entsprechende Nutzer und die zu überprüfende Transaktion eingetragen. Außerdem empfiehlt es sich, die Anzeige von Sammelrollen in den Suchergebnissen auszublenden.

Hierbei lässt sich nur ein Transaktionscode sinnvoll eintragen, da ansonsten stets eine einzige Rolle gesucht werden würde, die alle gesuchten Transaktionen beinhaltet und dem entsprechenden Nutzer zugeordnet ist. Da die Transaktionen dem Nutzer jedoch auch über verschiedene Rollen zugeordnet sein können, wäre dies nicht zielführend.

Bei Nutzung der o.g. Eingabevariante werden zudem lediglich Transaktionen betrachtet, die im Menü der Rolle gepflegt worden sind. Ist nicht sicher, ob die Transaktion im Menü oder im Berechtigungsobjekt S_TCODE der Rolle eingetragen wurde, können auch bis zu vier Transaktionen mittels der Suche über das genannte Berechtigungsobjekt S_TCODE überprüft werden. Wichtig ist hierbei die Beachtung und entsprechende Nutzung der UND-/ODER-Beziehung.

Nach dem Ausführen der Anfrage werden nun die Rollen angezeigt, welche die angefragte Transaktion beinhalten und dem Nutzer zugeordnet sind.

Bei Nutzung der Suche über das Berechtigungsobjekts S_TCODE wird folgende Ergebnisseite angezeigt.

Bei Betrachtung des Ergebnisses wird neben der Beschränkung der Anzahl an Transaktionen, die eingegeben werden können, ein weiterer Nachteil dieser Variante deutlich: Zwar werden beide zugeordnete Rollen angezeigt, auf den ersten Blick ist allerdings nicht zu erkennen, welche Transaktion in welcher Rolle enthalten ist. Hierfür müssten die Rollen nochmals einzeln betrachtet werden. Sollen gleichzeitig mehr Transaktionen mit Nutzerzuordnung ermittelt und direkt die Rollenzuordnung ersichtlich werden, bietet sich die Nutzung der Transaktion SE16N an.

Ermittlung bestimmter Transaktionen mit Nutzerzuordnung mittels SE16N

Diese Variante bietet sich an, wenn mehrere Transaktionen gleichzeitig auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin geprüft werden sollen.

Bei dieser Variante müssen zunächst sämtliche Rollen ermittelt werden, die dem betreffenden Nutzer bereits zugeordnet wurden. Dies erfolgt in der Transaktion SE16N über Eingabe der Tabelle AGR_USERS. Außerdem lässt sich in diesem Bild die Begrenzung der maximalen Trefferzahl aufheben.

Hier muss nun der betreffende Nutzer eingetragen werden. Außerdem sollte die Ausgabe lediglich auf die Rollen beschränkt werden.

Nach dem Ausführen der Anfrage werden nun sämtliche Rollen, die dem vorher eingegebenen Nutzer zugeordnet sind, angezeigt.

Diese werden nun komplett markiert und kopiert. Anschließend wird in der Transaktion SE16N wieder ein Schritt zurück gegangen und diesmal die Tabelle AGR_1251 gewählt.

Hier werden nun sämtliche Rollen, die zuvor kopiert wurden, eingefügt. Zusätzlich wird nach dem Objekt S_TCODE und den Transaktionen, nach deren Zuordnung gesucht werden soll, gefiltert. Achtung: Bei der Eingabe der Transaktionscodes ist auf Groß- und Kleinschreibung zu achten! An dieser Stelle kann außerdem die Ausgabe auf die Rollen und Objektwerte (das sind in diesem Fall die Transaktionen) beschränkt werden.

Nach dem Ausführen der Anfrage werden von den eingegebenen Transaktionen nun diejenigen angezeigt, die der Nutzer bereits ausführen kann. Zusätzlich ist ersichtlich, durch welche Rolle die Transaktion zugeordnet wurde.

Fazit

Abschließend ist festzustellen, dass sich die SUIM zur Ermittlung bestimmter Transaktionen mit Nutzerzuordnung nur bedingt eignet. Zwar lässt die Suche über das Berechtigungsobjekt S_TCODE auch die Betrachtung mehrerer Transaktionen zu. Da im Ergebnis allerdings die Zuordnung von betrachteten Transaktionen zu Rollen fehlt, lässt sich die Transaktion SUIM nur dafür sinnvoll nutzen, eine einzige Transaktion auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin zu überprüfen. Soll die Nutzerzuordnung mehrerer Transaktionen überprüft werden, bei denen nicht klar ist, ob sämtliche Transaktionen im Menü der Rollen gepflegt wurden, bietet sich stets die Nutzung der Transaktion SE16N an. Hier werden immer auch die Transaktionen betrachtet, die einer Rolle lediglich mittels des Berechtigungsobjekts S_TCODE zugeordnet wurden. Zudem wird im Ergebnis angezeigt, welche Transaktion in welcher Rolle enthalten ist.

Welche Erfahrungen haben Sie mit der Ermittlung bestimmter Transaktionen mit Nutzerzuordnung gemacht? Kennen Sie weitere Varianten zur Lösung dieses Problems? Über Ihre Erfahrungen und Fragen zu diesem Thema freue ich mich sehr.

The post Ermittlung bestimmter Transaktionen mit Nutzerzuordnung appeared first on rz10.de - die SAP Basis und Security Experten.