#SUIM

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 SUIMDiese 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 SE16NDiese 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.FazitAbschließ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.
Über die Transaktion SUIM – Benutzerinformationssystem können Sie zentral alle wichtigen Benutzerinformationen abfragen. Allerdings ist das Ergebnis der SUIM-Abfrage nicht immer so eingeschränkt wie Sie es gerne hätten. Ihnen reichen die vorhandenen Filter nicht aus und Sie würden die Liste gerne nach weiteren Kriterien filtern.In diesem Beitrag zeige ich Ihnen, wie Sie bei der Ergebnisliste weitere Spalten hinzufügen oder entfernen können und nach diesen dann auch filtern können.Einleiten der AbfrageAls Beispiel zeige ich Ihnen eine SUIM-Abfrage nach Benutzern, die das SAP_ALL Profil besitzen. Dazu gehen Sie zuerst in die Transaktion SUIM und wählen Sie die entsprechende Abfrage aus. Abbildung 1: Benutzer nach Profilen abfragenAls nächstes können Sie das abzufragende Profil eintragen (in diesem Fall SAP_ALL) und mit Ausführen (oder F8) die SUIM-Abfrage starten. Abbildung 2: Profil eintragenDas Ergebnis sollte bei Ihnen so ähnlich wie in Abbildung 3 aussehen. Es werden die Benutzer angezeigt, die im System vorhanden sind und das Profil SAP_ALL besitzen. Nach den vorhandenen Spalten kann die Liste auch sortiert werden. Dazu markieren Sie die entsprechende Spalte und benutzen die  und  Buttons um auf- bzw. absteigend zu sortieren.Sind Ihnen die angezeigten Spalten nicht genug, dann haben Sie die Möglichkeit sich weitere Spalten anzeigen zulassen. Dazu klicken Sie auf den Layout ändern Button , dann erscheint der Dialog in dem Sie die Spalten verwalten können. Abbildung 3: Erste Ansicht AbfrageergebnisHier sehen Sie auf der rechten Seite die Spalten, die Sie sich noch anzeigen lassen können. In diesem Beispiel wähle ich die Spalte Gesperrt um anzuzeigen, ob der User gesperrt ist oder nicht. Mit dem Linkspfeil fügen Sie die ausgewählte Spalte zu den angezeigten Spalten hinzu (s. Abbildung 4). Abbildung 4: Layout öndern – SpaltenauswahlJetzt wird die Spalte Gesperrt zusätzlich angezeigt. Mit einem kleinen Schloss wird markiert, ob ein Benutzer gesperrt ist oder nicht (s. Abbildung 5). Nun können Sie beispielsweise alle gesperrten Benutzer rausfiltern, sodass die Liste nur noch aktive Benutzer anzeigt. Abbildung 5: Ergebnisliste mit zusätzlicher SpalteUm die gesperrten Benutzer zu filtern, klicken Sie auf das Filter-Symbol  und wählen Sie die zu filternde Spalte in dem folgenden Dialog. Die zu filternden Werte müssen im zweiten Schritt (wieder das Filter-Symbol) festgelegt werden (s. Abbildung 6). Abbildung 6: Filter setzenUm die gesperrten Benutzer auszublenden, können Sie z.B. den Wert für das Schloss nehmen und als Vergleichsoption dann Ungleich auswählen (durch Doppelklick auf den Wert) (s. Abbildung 7). Abbildung 7: Wert und Vergleichsoperator auswählenJetzt werden alle Benutzer, die mit einem Schloss markiert sind, ausgeblendet.Ihre MeinungAuf diese Weise können Sie natürlich auch weitere nicht angezeigte Spalten hinzufügen und nach den Werten in diesen Spalten filtern.Was sind Ihre Erfahrungen mit SUIM-Abfragen? Ich freue mich auf Ihr Feedback.
Ü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:OBJTYPE ACTVTDEBUG 03 – AnzeigenDEBUG 02 – Ändern von Feldinhalten und ‘Zu Anweisung springen’DEBUG 01 – Kernel-Debugging (für Kunden nicht relevant, nur für  SAP-interne Zwecke)Sie benötigen Unterstützung bei der Umsetzung? Unser Autor Tobias Harmes ist Berater für dieses Thema. Fragen Sie ihn an über das RZ10.de Partnerprodukt Berater für SAP Berechtigungen und Security

Unsere Top-Downloads

Angebot anfordern
Preisliste herunterladen
Expert Session
Support