Der IDoc Status eines bestimmten IDocs soll manuell verändert werden. Dieses Ziel kann mithilfe eines Standard SAP-Reports erreicht werden.

Ausgangssituation:

Immer wieder gibt es Situationen, in denen ein IDoc Status manuell verändert werden soll. Ich erlebe es zum Beispiel häufig, dass ein IDoc zum Löschen markiert wurde (Status 68 bzw. Status 31), aber zu einem späteren Zeitpunkt die erneute Verarbeitung notwendig wird. In diesem Tutorial soll dieses Beispiel dargestellt werden.

Wir übernehmen Basisaufgaben 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 und SAP Security Berater von RZ10 buchen
Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.9462 8572-25 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

Übersicht über IDoc Status

Zunächst möchte ich Ihnen einen kurzen Überblick über die gängigen IDoc Status geben. Hierbei gilt zu beachten, dass die IDoc Status für ausgehende IDocs zwischen 01 und 49 liegen, während die Status für eingehende IDocs bei 50 beginnen:

Ausgehende IDocs:

• Status 02 – Fehler bei der Datenübergabe
• Status 03 – Datenübergabe an Port OK
• Status 30 – IDoc ist versandfertig
• Status 31 – Keine weitere Verarbeitung
• Status 33 – IDoc editiert

Eingehende IDocs:

• Status 51 – Anwendungsbeleg nicht gebucht
• Status 52 – Anwendungsbeleg unvollständig gebucht
• Status 53 – Anwendungsbeleg gebucht
• Status 64 – Idoc ist übergabebereit
• Status 68 – Keine weitere Verarbeitung
• Status 70 – IDoc editiert

Welchen IDoc Status sollte ich wählen?

Da das Ziel des Änderns des IDoc Status häufig die erneute Verarbeitung ist, bietet es sich an, das IDoc in den Status zu versetzen, in welchem es auf die Verarbeitung wartet. Bei ausgehenden IDocs wählen Sie den Status 30, während Sie für eingehende IDocs den Status 64 auswählen.

IDoc Status mit Report verändern

Zum Ändern des IDoc Status wird der Report RC1_IDOC_SET_STATUS verwendet. Dieser wird wie folgt bedient:

1. Transaktion SE38 aufrufen und Status ausführen:

2. Im Report selbst, müssen Sie die IDoc-Nummer(n), den Nachrichtentyp des IDocs, den aktuellen IDoc Status und den neuen Status des IDocs angeben. Weiterhin gibt es die Möglichkeit, die Umsetzung des Status zunächst nur zu Testen:

3. Das Ergebnis des Reports stellt sich wie folgt dar:

Wenn die Anzahl der umgesetzten IDocs nicht der Anzahl der umzusetzenden IDocs entspricht, kann der IDoc Status des IDocs nicht verändert werden (bspw. weil dieses gerade von einem anderen Benutzer gesperrt ist). In diesem Fall probieren Sie es zu einem späteren Zeitpunkt erneut.

Was sind Ihre Erfahrungen mit dem ändern des IDoc Status? Gab es bereits Situationen, in denen Sie den Status manuell ändern mussten?

Ich freue mich auf Ihr Feedback und Ihre Kommentare gleich unterhalb dieses Beitrags!

The post IDoc Status manuell ändern appeared first on rz10.de - die SAP Basis und Security Experten.

Sie haben keinen direkten Zugriff auf die Betriebssystem-Ebene eines SAP-Systems, möchten aber dennoch Betriebssystembefehle ausführen. Mit der folgenden Transaktion ist das Ausführen von Betriebssystembefehlen ohne direkten Betriebssystem-Zugriff möglich.

Wir übernehmen Basisaufgaben 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 und SAP Security Berater von RZ10 buchen
Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.9462 8572-25 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

Die Transaktion SM49 ermöglicht das Ausführen externer Betriebssystembefehle aus dem SAP-System heraus. Dabei können Sie einerseits auf vordefinierte Betriebssystembefehle zurückgreifen und andererseits weitere Betriebssystembefehle hinzufügen. Beide Szenarien werden im Folgenden erläutert.

Externe Betriebssystembefehle ausführen:

Führen Sie zunächst die Transaktion SM49 – Externe Betriebssystemkommandos aus. Sie sehen eine Übersicht über alle vordefinierten Betriebssystembefehle:

Um einen Betriebssystembefehl auszuführen, klicken Sie doppelt auf den gewünschten Befehl. In diesem Beispiel wählen wir den Betriebssystembefehl PING aus. Es öffnet sich die Detailansicht des Befehls:

In der Detailansicht werden die Grundinformationen zum ausgewählten Befehl angezeigt – so zum Beispiel der Typ des Betriebssystems (z.B. Windows) auf dem der Befehl ausgeführt wird. Nach dem Klick auf Ausführen kann der Befehl weiter spezifiziert werden. Im Beispiel des Ping-Befehls muss schließlich noch eine IP-Adresse oder der Name eines Rechners als Parameter übergeben werden. Daraufhin kann der Befehl entweder direkt im Dialog ausgeführt werden [Ausführen (F8)] oder (zeitversetzt) im Hintergrund [Ausführen im Hintergrund (F9)]. Im Folgenden wird der Ping-Befehl direkt auf localhost ausgeführt:

Mit dem Klick auf Ausführen wird der Befehl direkt ausgeführt und die Ausgabe des Betriebssystembefehls wird angezeigt:

Weitere Betriebssystembefehle selbst definieren:

Neben den vordefinierten Befehlen können Sie auch eigene/weitere Befehle – die im Rahmen des hinterlegten Betriebssystems möglich sind – definieren. Hierfür klicken Sie im Einstiegsbildschirm der Transaktion auf das Anlegen-Icon:

In dem Dialog zum Anlegen eines Betriebssystembefehls müssen Sie folgende Informationen hinterlegen:

Kommandoname: Der Titel des definierten Befehls, welcher in der Übersicht im Einstiegsbildschirm angezeigt wird. Wichtig: Der Name eigens definierter Betriebssystembefehle muss im Kundennamensraum liegen und mit Z oder Y beginnen.

Betriebssystem: Hier geben Sie das Betriebssystem an, auf welchem das SAP-System läuft. Wählen Sie hierfür das Feld aus und öffnen Sie die Wertehilfe mit F4. Anschließend können Sie ein bestimmtes Betriebssystem oder ANYOS auswählen, um den Befehl betriebssystemunabhängig zu hinterlegen.

Betriebssystem-Kommando: Hier geben Sie den eigentlichen Betriebssystembefehl an, welcher ausgeführt werden soll.

Parameter für Betriebssystem-Kommando: In diesem Feld können Sie feste Parameter hinterlegen, die mit dem Befehl ausgeführt werden sollen.

Zusätzliche Parameter erlaubt: Setzen Sie den Haken, um zusätzliche Parameter beim Ausführen des Befehls zu erlauben.

Zur Veranschaulichung zeigt der folgende Screenshot das beispielhafte Anlegen eines externen Kommandos für den Betriebssystembefehl help:

Letztendlich taucht der eigens definierte Betriebssystembefehl in der Übersicht im Einstiegsbild auf und kann wie oben beschrieben ausgeführt werden.

Sicherheitshinweis: Zugriff limitieren!

Der Zugriff auf die SM49 und das Ausführen von Betriebssystembefehlen aus dem SAP-System heraus ist aus sicherheitstechnischer Sicht natürlich höchst kritisch und sollte deswegen sehr limitiert werden. Beim Öffnen der Transaktion und Ausführen von Befehlen werden die folgenden Berechtigungsobjekte geprüft:

Neben dem obligatorischen S_TCODE für das Ausführen der Transaktion an sich, ist hierbei das Berechtigungsobjekt S_LOG_COM interessant, welches beim Ausühren eines Betriebssystembefehls geprüft wird. Es besteht aus den drei Berechtigungsfeldern:

COMMAND:  In der Transaktion definierter Name des Betriebssystemkommandos

OPSYSTEM: Betriebssystem des Zielsystems (bspw. WINDOWS NT, ANYOS, AIX, UNIX)

HOST: Hostname des Zielsystems

Über dieses Berechtigungsobjekt können Sie das Ausführen einzelner Betriebssystembefehle limitieren.

Welche Erfahrungen haben Sie mit dem Ausführen und Anlegen von Betriebssystembefehlen über die SM49 gemacht? Gab es bereits Situationen, in denen Sie auf diese Möglichkeit zurückgreifen mussten? Ich freue mich auf Ihre Kommentare und Antworten!

The post Betriebssystembefehle via Transaktion ausführen appeared first on rz10.de - die SAP Basis und Security Experten.

Auf dem SAP-System grassiert ein regelmäßiger Fehler. Mit folgendem Report können Sie die Systemauslastung automatisch aufzeichnen und den Fehler anschließend komfortabel analysieren.

Wir übernehmen Basisaufgaben 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 und SAP Security Berater von RZ10 buchen
Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.9462 8572-25 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

Mithilfe des Reports SDF/MON/ (Display Snapshot Monitoring) können Systemauslastung eines Systems und belegte Workprozesse sowie weitere Systemwerte für einen beliebigen Zeitraum detailliert festgehalten werden. Wenn das Problem also regelmäßig auftritt und sich sogar auf einen bestimmten Zeitraum eingrenzen lässt, können Sie mithilfe des SDF/MON/ komfortabel relevante Informationen sammeln. Dieser erstellt automatisch und zu frei wählbaren Zeitpunkten Snapshots von relevanten Systeminformationen.

Systemauslastung mit SDF/MON/ aufzeichnen

Den Report können Sie einerseits über die SE38 ausführen (entsprechende Berechtigungen vorausgesetzt) oder aber durch Eingabe des Transaktionscode /n/SDF/MON/ (bei Eingabe ohne /n wird die Transaktion nicht gefunden).

Hinweis: In manchen Systemen ist der Report nur in englischer Sprache verfügbar. Falls Sie den Report also Ausführen und keine Texte sehen, loggen Sie sich aus und geben Sie bei der Anmeldung am SAP GUI als Anmeldesprache EN (englisch) an. 

Über Schedule New Monitoring (Monitoring neu einplanen) können Sie eine neue Aufzeichnung der Systemauslastung planen und anlegen.

Geben Sie zunächst eine Description (Beschreibung) ein, unter welcher Sie die Aufzeichnung später aufrufen können.

Anschließend setzen Sie den Zeitraum der Aufzeichnung (Start time / End time) und den Verfallszeitpunkt der gespeicherten Auswertungsdatei (Do not delete before) fest.

Weiterhin können Sie den Intervall der Aufzeichnung (Interval in seconds) festlegen. Hiermit können Sie bestimmen, dass bspw. alle 10 Sekunden ein Snapshot der Systemauslastung in Ihrer Aufzeichnungsdatei gespeichert wird. Darüberhinaus können Sie die maximale Dateigröße (Restrict size) limitieren.

Nun können Sie noch festlegen, welche Informationen in dem Snapshot abgespeichert werden sollen. So können Sie beispielsweise alle 10 Sekunden Informationen über folgende Systemwerte sammeln:

– Workprozesse (List of workprocesses)

– Dispatcher Queue

– Auslastung CPU und Paging des Betriebssystems (CPU and paging activity)

– Prozesse mit höchsten CPU-Verbrauch (Top CPU processes)

– Speicherauslastung (Ext. and heap mem.)

– Anzahl der Benutzersitzungen (No. of logins/sessions)

– Einträge in In- und Outbound-Queue

– Freie RFC-Workprozesse (Free RFC WPs)

Abschließend können Sie noch den/die Server angeben, auf welchem/welchen Sie Systemauslastung aufzeichnen wollen.

Nachdem Sie die Einstellungen nach Ihren Anforderungen gepflegt haben, können Sie auf Ausführen klicken. Je nach angegeben Zeitpunkt, wird die Aufzeichnung entweder direkt gestartet oder es erscheint eine Meldung über die erfolgreiche Einplanung Ihrer Monitoring-Aufzeichnung:

Aufzeichnung der Systemauslastung analysieren

Wenn Ihre Aufzeichnung erfolgreich durchgeführt wurde, können Sie diese beim nächsten Aufruf der Transaktion /n/SDF/MON in der Einstiegsmaske auswählen:

Es erscheint eine erste Übersicht zu Ihrer Aufzeichnung der Systemauslastung:

Mit einem Doppelklick oder Klick auf das Brillen-Icon öffnen Sie die Details zu Ihrer Aufzeichnung. In den Details sehen Sie eine chronologische Auflistung von allen Aufzeichnungszeitpunkten innerhalb des definierten Zeitfensters. Auch in dieser Übersicht können Sie bereits relevante Werte zu der Systemauslastung sehen:

Zu jedem Aufzeichnungszeitpunkt können Sie weitere Detailinformationen abrufen. Hierfür markieren Sie einen Zeitpunkt und wählen über den Reiter „Goto“ oder die Iconleiste weitere Analysen aus. Je nachdem was Sie aufgezeichnet haben, können Sie sich die Liste der Workprozesse, den Speicherverbrauch oder die Prozesse mit der höchsten CPU-Auslastung anzeigen lassen. Mit WP List Aggregation können Sie die Auflistung der Workprozesse sogar nach auswählbaren Kriterien aggregieren.

Wenn Sie sich bspw. die Prozesse mit der höchsten CPU-Auslastung anzeigen lassen, können Sie die Systemauslastung rückwirkend sehr detailliert analysieren:

Insgesamt handelt es sich bei der Transaktion /n/SDF/MON/ bzw. dem Report SDF/MON/ um ein sehr mächtiges Werkzeug zur Aufzeichnung und Analyse der Systemauslastung.

Konnten Sie bereits Erfahrungen mit dem Aufzeichnen der Systemauslastung sammeln? Vielleicht konnten Sie hierdurch sogar endlich eine langwierige Fehlersuche abschließen? Ich freue mich auf Ihre Kommentare!

The post Systemauslastung aufzeichnen und analysieren appeared first on rz10.de - die SAP Basis und Security Experten.

In diesem Tutorial möchte ich erläutern, wie Sie als SAP Basisadministrator den CCMS-Alert-Monitor konfigurieren, um CCMS-Alerts per E-Mail zu erhalten.

Das SAP-eigene Überwachungstool Computing Center Management System Monitor (CCMS-Monitor) ist ein mächtiges Tool zum Überwachen des eigenen SAP-Systems. Um schnell auf (kritische) Ereignisse reagieren zu können, können Sie den CCMS-Monitor so konfigurieren, dass Sie CCMS-Alerts per E-Mail erhalten, sobald der Monitor Alarm schlägt.

In diesem Tutorial zeige ich, wie Sie E-Mail-Benachrichtigungen für einzelne Monitoring Tree Elements (MTE) aktivieren können.

CCMS-Alerts per E-Mail erhalten – die Konfiguration:

• Melden Sie sich zunächst im zu überwachenden System an und rufen Sie die Transaktion RZ20 auf. Sie erhalten eine Übersicht über Ihre CCMS-Monitorsammlung.
• Wählen Sie dann einen Monitor durch Doppelklick aus:

• Anschließend haken Sie das MTE an, für welches Sie CCMS-Alerts per E-Mail erhalten möchten und klicken auf Eigenschaften:

• Auf dem Reiter Methoden können Methoden für automatische Reaktionen definiert werden. Wechseln Sie nun auf den Reiter Methoden:

• Klicken Sie nun auf den Button Methodenzuordnung (siehe Bild oben) und wechseln Sie dann auf den Karteireiter Autoreaktion und aktivieren Sie den Änderungsmodus:

• Im Bildschirmbereich Methodenzuordnung wählen Sie Methodenname aus, klicken in das Textfeld und rufen via F4 die Wertehilfe auf. Es erscheint eine Liste aller verfügbaren Methoden. Um CCMS-Alerts per E-Mail zu erhalten benötigen wir die Methode CCMS_OnAlert_Email bzw. CCMS_OnAlert_Email_V2. Letztere unterscheidet sich insofern, als dass initial mehr Parameter zur Konfiguration der versendeten E-Mail bereitgestellt werden.

• Ein Doppelklick auf den Methodennamen im Textfeld öffnet die Konfiguration der Methode. Auf dem Karteireiter Parameter können Sie den CCMS-Alert per E-Mail konfigurieren:

Die Parameter der Methode CCMS_OnAlert_Email_V2 im Detail:

SENDER: SAP-Benutzer der Person, in dessen Namen die E-Mail versendet wird.

RECIPIENT: SAP-Benutzername, Verteilerliste oder externe E-Mail-Adresse. Falls Sie eine E-Mail an mehrere externe E-Mail-Adressen versenden möchten, müssen Sie zunächst einen Verteiler im Mandant 000 anlegen. Falls der angegebene SAP-Benutzername nicht im Mandant 000 existiert, müssen Sie zusätzlich System und Mandant wie folgt angeben: SYSTEM:MANDANT:USERID (z.B. S1D:100:BUSSE).

RECIPIENT-TYPEID: Kennzeichen für den Adresstyp in Abhängigkeit des angegeben RECIPIENT. „U“ für externe Internetadresse, „C“ für Verteilerliste, „B“ für SAP-Benutzername.

REACT_ON_ALERTS: Optionaler Parameter mit welchem Sie zusätzlich steuern können, in welchen Fällen die E-Mail versandt wird. Mögliche Werte sind YELLOW oder RED.

SUBJECT_ALERT: Betreffzeile der CCMS-Alert-E-Mail.

SUBJECT_ALERT_CONT: Inhalt der CCMS-Alert-EMail.

• Wenn Sie alle Parameter gepflegt haben, klicken Sie auf Speichern und die Methode ist aktiv.

Beim nächsten Alarm sollten Sie zur der betreffenden MTE CCMS-Alerts per E-Mail erhalten.

Haben Sie bereits Erfahrungen mit dieser Autoreaktionsmethode gesammelt? Vielleicht haben Sie ja Tipps für MTEs, bei denen ein CCMS-Alert per E-Mail besonders sinnvoll/praktisch ist? Ich freue mich auf Ihre Kommentare und Ihr Feedback!

The post CCMS-Alerts per E-Mail erhalten appeared first on rz10.de - die SAP Basis und Security Experten.

Sie wollen herausfinden, wer einen Transport in ein SAP System durchgeführt hat. Über diesen Umweg erfahren Sie den Transporteur zu einem SAP Transport.

Es gibt allerlei Transaktionen, über die Sie schnell und einfach Informationen wie zum Beispiel Inhalt, Inhaber oder Zielsystem eines Transportes erhalten. Immer wieder gibt es jedoch Situationen, in denen diese einfach zu erreichenden Informationen nicht ausreichen. Wenn beispielsweise nach dem Import eines Transportes unerwartete Fehler auftreten, kann es durchaus wichtig sein, wer den Import durchgeführt hat. Über die Transaktion STMS erhalten Sie Uhrzeit, Transportinhaber und Status eines Transports – den Transporteur zu einem SAP Transport erhalten Sie jedoch nur über Umwege. Denn der Inhaber eines Transportes muss nicht zwingend auch sein Transporteur sein.

Transporteur zu einem SAP Transport ermitteln

Die Grundlage zu dieser Information findet sich in der Funktionalität eines SAP Systems an sich – alles ist in Tabellen enthalten und kann über Umwege nachvollzogen werden. Um einen Transporteur zu einem SAP Transport zu ermitteln, ist die Tabelle TPLOG interessant. Sie können – entsprechende Berechtigungen vorausgesetzt – mit der Transaktion SE16 darauf zu greifen. Wer transportiert hat, finden Sie heraus, indem Sie die Transportnummer umrahmt von * (*TRANSPORTNUMMER*) im Feld CMDSTRING eintragen:

Als Ergebnis erhalten Sie die Zeilen der Tabelle TPLOG, die den entsprechenden Transport betreffen. In der Spalte USERNAME sehen Sie den Usernamen. In der Spalte CMDSTRING steht einerseits die Transportnummer andererseits der jeweilige Transportschritt, also bspw. der IMPORT. Der Username, den Sie in der Zeile mit IMPORT und Transportnummer finden, ist der Transporteur zu dem Transport:

Haben Sie bereits Situationen erlebt, in denen Sie gerne gewusst hätten, wer einen bestimmten Transport transportiert hat? Ich freue mich über Ihre Erfahrungen aber auch Fragen in den Kommentaren gleich unterhalb dieses Beitrags.

The post Transporteur zu SAP Transport ermitteln appeared first on rz10.de - die SAP Basis und Security Experten.

In der Kontrolleurzuordnung im NWBC (NetWeaver Business Client) der SAP GRC Service Map sollen Zuweisungen von Kontrolleuren zu Firefighter-Benutzerkennungen gelöscht werden. In der entsprechenden Konfigurationsmaske ist der Löschen-Button jedoch ausgegraut.

SAP GRC – Kontrolleurzuordnung lässt sich im NWBC nicht löschen

In dem auf den Screenshots dargestellten Beispiel sollen Kontrolleurzuordnungen zu obsoleten Firefighter-Benutzerkennungen im Konfigurationsdialog Einrichtung->Superuser-Bearbeitung->Kontrolleure (PAV-Kontrolleurzuordnung) entfernt werden.

Nach dem Filtern auf die zu löschenden Zuweisungen können diese jedoch nicht entfernt werden, da der Button zum Löschen ausgegraut ist und sich nicht aktivieren lässt:

Die Ursache scheint ein (Anzeige-)Bug im NWBC zu sein.

Bug in der Konfiguration der Kontrolleurzuordnung

Obwohl sich der Bug zu sporadisch reproduzieren ließ, scheint die Ursache mit dem Filter auf Spalten zusammenzuhängen. Der Bug tritt beispielsweise regelmäßig auf, wenn direkt nach Einstieg in den Konfigurationsdialog Kontrolleurzuordnung ein Filter auf die Spalte Firefighter-Benutzerkennung gesetzt wird. Wenn die Anzeige entsprechend des Filters aktualisiert wurde und anschließend ein Eintrag in der Liste ausgewählt wird, bleibt der Löschen-Button ausgegraut und die entsprechenden Einträge können nicht entfernt werden.

Grundsätzlich gilt: Beim Einstieg in das Fenster Kontrolleurzuordnung sind die Buttons Öffnen, Kopieren und Löschen zunächst ausgegraut. Erst wenn irgendein Eintrag in der Liste ausgewählt wird, werden die besagten Buttons aktiviert und bleiben dies auch.

Falls Sie also mit der Problematik konfrontiert sind, dass sich einzelne Kontrolleurzuordnungen nicht löschen lassen, da der Löschen-Button ausgegraut ist, probieren Sie folgendes: Wenn direkt nach Einstieg in den Konfigurationsdialog Kontrolleurzuordnungen zunächst irgendein Eintrag in der Liste markiert und erst danach ein Filter auf die Spalte Firefighter-Benutzerkennungen gesetzt wird, ist der Löschen-Button aktiv und kann verwendet werden. Dann lassen sich auf die gewünschten Einträge entfernen.

Fazit: Falls Sie Probleme beim Löschen von Kontrolleurzuordnungen haben, weil der Löschen-Button ausgegraut ist, markieren Sie nach dem Einstieg in das Fenster Kontrolleurzuordnung zunächst irgendeinen Eintrag in der Liste und setzen erst anschließend den Filter auf die zu löschenden Kontrolleurzuordnungen. Der Löschen-Button ist dann nicht mehr ausgegraut.

Haben Sie den Fehler/Bug in Ihrer SAP GRC Konfiguration ebenfalls bemerkt? Vielleicht haben Sie sogar einen SAP-Hinweis dazu gefunden? Ich freue mich auf Ihre Antworten und Kommentare!

The post Kontrolleurzuordnung kann nicht gelöscht werden appeared first on rz10.de - die SAP Basis und Security Experten.

Der Spool-Bereich ist vollgelaufen und muss bereinigt werden, da die Spool-Aufträge stillstehen. Im Folgenden erkläre ich Ihnen, wie Sie mithilfe eines Reports manuell aufräumen können.

 Spool-Aufträge mithilfe des Reports RSPO1041 löschen

Im Zuge der Bereinigung des Spool-Bereichs müssen obsolete Spool-Aufträge gelöscht werden. Hierzu verwenden Sie den Report RSPO1041. Führen Sie diesen zunächst mit der Transaktion SA38 aus:

Es erscheint die Eingabemaske zum Löschen alter Spool-Aufträge. In dieser Eingabemaske können nun die Kriterien zum Löschen der Spool-Aufträge festgelegt werden. Diese Kriterien beschreibe ich im Folgenden.

Kriterien zum Löschen von Spool-Aufträgen

Die oberen vier Bereiche in der Eingabemaske beziehen sich auf den Status der zu löschenden Spool-Aufträge:

• Ohne Ausgabeauftrag: Bezieht sich auf alle Spool-Aufträge, für die kein Ausgabeauftrag erstellt wurde.
• In Arbeit: Bezieht sich auf alle Spool-Aufträge, die sich im Status in Arbeit befinden.
• Fertige: Bezieht sich auf alle Spool-Aufträge, die erfolgreich bearbeitet (gedruckt und ggf. archiviert) wurden.
• Fehlerhafte: Bezieht sich auf alle Spool-Aufträge, bei deren Bearbeitung ein Fehler aufgetreten ist.

Für jeden Status kann nun einzeln festgelegt werden, ob und für welchen Zeitraum diese gelöscht werden sollen. Hierfür wird der jeweilige Kasten vor dem Status angekreuzt und anschließend eine Zeitangabe in Tagen (älter als … Tage) gemacht. Die Angabe „älter als … Tage“ bezieht sich dann auf alle Spool-Aufträge, die vor dem angegebenen Zeitraum erzeugt wurden. Zusätzlich kann auch angekreuzt werden, dass die Spool-Aufträge gelöscht werden, die veraltet sind. Das wiederum bezieht sich auf alle Spool-Aufträge, die das bei der Erzeugung erstellte Verfallsdatum bereits überschritten haben. Dieses Verfallsdatum beträgt im Standard 8 Tage.

Im darunter liegenden Bereich Kalender kann spezifiziert werden, welche Tage einer Woche für die Berechnung der Angabe „älter als … Tage“ herangezogen werden sollen. Hier wird zwischen allen Tagen oder nur Werktagen unterschieden. In jedem Fall muss ein Werkskalender im Feld Fabrikkalender-ID angegeben werden.

Im untersten Bereich Weitere Bedingungen können die Kriterien zum Löschen von Spool-Aufträgen weiter eingeschränkt werden:

Hierbei können Sie zunächst Systemname und Mandant eingrenzen. Außerdem lässt sich auch der Erzeuger (Username) der zu löschenden Spool-Aufträge einschränken. Noch genauere Einschränkungen können mithilfe der Kriterien Titel (des Spool-Aufrags), Spool-Auftragsname, Spool-Auftrag (Suffix1), Spool-Auftrag (Suffix2) und Ausgabegerät erzielt werden. Dadurch lassen sich ganz bestimmte Spool-Aufträge filtern:

• Titel: Der Titel, der auf dem Deckblatt des Auftrags erscheinen soll. (Nur verfügbar, wenn das Ausgabegerät das SAP-Standarddeckblatt druckt.)
• Spool-Auftragsname: Dreiteiliger Name eines Spoolauftrags, wobei der Name automatisch vom Spool-System bestimmt wird, kann aber auch vom erzeugenden Benutzer bzw. Programm eingetragen werden. Es gibt keine zwingende Namenskonvention.
• Spool-Auftrag (Suffix): Dieses Feld entspricht laut F1-Hilfe dem Feld Spool-Auftragsname. Ein Spool-Auftrag kann sowohl einen Spool-Auftragsnamen als auch einen Titel besitzen. Ersterer wird automatisch vom Spool-System erzeugt, letzterer muss explizit vom erzeugenden Benutzer bzw. Programm eingetragen werden.
• Ausgabegerät: Langer Name eines Ausgabegerätes. Der lange Name kann bis zu 30 Zeichen umfassen. Beachten Sie Groß-/ Kleinschreibung des Ausgabegeräts.

Nachdem alle Kriterien nach Ihren Wünschen festgelegt wurden, kann der Report ausgeführt (Ausführen – F8) werden und die entsprechenden Spool-Aufträge werden gelöscht. Wenn Sie zunächst nur einen Probelauf durchführen möchten, um zu prüfen, welche Spoolaufträge gelöscht werden sollen, finden Sie unterhalb des Bereiches Kriterien zur Auswahl der zu löschenden Spool-Aufträge noch die Option Nur Protokoll ohne Löschen?

Wie häufig sollten Spool-Aufträge gelöscht werden?

Das oben beschriebene manuelle Vorgehen ist besonders dann sinnvoll, wenn der Spool-Bereich bereits vollgelaufen ist. Eine periodische Einplanung des Löschjobs im Hintergrund ist oft sinnvoller. Es ist in jedem Fall empfehlenswert, die Spool-Aufträge regelmäßig zu löschen, wobei die Häufigkeit vom jeweiligen System abhängig gemacht werden muss. Allerdings sollten Sie bedenken: Je seltener die Spool-Aufträge gelöscht werden, desto länger wird der Löschvorgang dauern und desto eher wird sich dieser auf die Performance des Gesamtsystems auswirken. Folglich sollten Sie Spool-Aufträge regelmäßig und öfter Löschen, da dann mit jedem Löschvorgang auch weniger Spool-Aufträge auf einmal gelöscht werden müssen.

Wie sind Ihre Erfahrungen mit dem Löschen von Spool-Aufträgen? Führen Sie den Report zum Löschen von Zeit zu Zeit manuell aus oder haben Sie diesen bereits als Job im Hintergrund eingeplant? Ich freue mich auf Ihre Antworten und Kommentare!

The post Spool-Aufträge manuell löschen appeared first on rz10.de - die SAP Basis und Security Experten.

In der Transaktion SE71 (Form Painter) werden die Radio Buttons für Seiten und Fenster nicht angezeigt.

Natürlich werden zunächst die Berechtigungsadministratoren kontaktiert, da davon ausgegangen wird, dass diese die Berechtigungen falsch vergeben haben. Diesen Fall habe ich erst vor Kurzem selbst erlebt. Dass es nicht immer an den Berechtigungen liegt, beweist die Lösung des Problems eindrucksvoll.

Problem: SE71 zeigt Radio-Buttons für Seiten und Fenster im Einstiegsdialog nicht an

In der Einstiegsmaske der Transaktion SE71 werden im Bereich „Teilobjekte“ die Radio Buttons für Seiten und Fenster nicht mehr angezeigt:

Lösung: SE71 korrekt einstellen

Die Lösung des Problems ist nicht – wie zunächst von den Anwendern angenommen – die Anpassung von Berechtigungen. Stattdessen müssen für die SE71 folgende Einstellungen getätigt werden. In der obersten Menüleiste navigieren Sie via Einstellungen -> Form Painter… zum Tab SAPscript und entfernen den Haken unter Grafischer Form Painter:

Anschließend werden die Radio Buttons für Seiten und Fenster wieder angezeigt:

Letztendlich konnte ich den Anwendern helfen – und zwar ganz ohne Anpassung von Berechtigungen. In diesem Blogbeitrag geht es mir weniger um die Problemlösung, als vielmehr um diese kleine Anekdote an sich: Fehlende Berechtigungen sind eine häufige Fehlerursache – aber eben nicht immer!

Ich schrieb diesen Blogbeitrag, weil ich mich frage, ob Sie vielleicht ähnliche Erfahrungen bzw. Anekdoten aus Ihrem Alltag haben? Ich freue mich sehr auf Ihre Antworten gleich unterhalb dieses Blogbeitrags!

The post SE71 zeigt Radio-Buttons für Seiten und Fenster nicht appeared first on rz10.de - die SAP Basis und Security Experten.

Die SXMB_MONI lässt die Anzeige der Payload einer Message nicht zu, obwohl die Berechtigung vergeben zu sein scheint. Die Lösung liegt in einer missverständlichen Ausprägung des Berechtigungsobjekt S_XMB_MONI.

SXMB_MONI erlaubt Anzeige der Payload nicht

Beim Ausführen des Monitors für verarbeitete XML-Messages in der Transaktion SXMB_MONI kommt es bei der Anzeige der Payload zu einem Berechtigungsfehler: „Sie haben keine Berechtigung zur Durchführung dieser Aktion„.

Die zugehörige, detaillierte Fehlerbeschreibung gibt leider keinen Hinweis darauf, welche Berechtigungen genau fehlen. Stattdessen wird auf Meldungsnummer XMS_ADM304 verwiesen.

SXMB_MONI und das zugehörige Berechtigungsobjekt S_XMB_MONI

Das entscheidende Berechtigungsobjekt der Transaktion SXMB_MONI heißt S_XMB_MONI. Es besteht aus insgesamt sieben Berechtigungsfeldern:

ACTVT: Aktivität
SXMBPARTY: Kommunikationspartner
SXMBPRTAG: vergebene Agentur
SXMBPRTYP: Identifikationsschema
SXMBSERV: Service
SXMBIFNS: Interace Namespace
SXMBIFNAME: Interface Name

Für unseren Fehler ist – sofern Interface, Agentur, Schema etc. korrekt berechtigt sind – das Berechtigungsfeld ACTVT interessant. Die Ausprägungen von ACTVT sind bei S_XMB_MONI die folgenden:

02 – Ändern
03 – Anzeigen
16 – Ausführen
29 – Gespeicherte Daten anzeigen (Payload einer XML-Message anzeigen)
36 – Erweiterte Pflege
96 – Ablehnen
A3 – Status ändern

Ich bin davon ausgegangen, dass der Wert 29 zum Anzeigen der Payload ausreicht. Grundsätzlich ist das auch korrekt. Interessant wird es, wenn ein User bspw. aus einer anderen Rolle heraus den Wert 96 für ACTVT im Objekt S_XMB_MONI erhält oder wie im unten dargestellten Beispiel beide Werte in einer Rolle erhält:

Mit den oben dargestellten Berechtigungswerten 29 und 96 wird ein User keine Payload anzeigen können und stattdessen den in diesem Beitrag behandelten Fehler sehen. Der Grund ist, dass Aktivität 96 („-Ablehnen“) die Aktivität 29 („-Gespeicherte Daten anzeigen“) überlagert! 

Aktivität 96 steht für: Ablehnen, d.h. in diesem Fall die Payload einer Nachricht nicht anzeigen. Dieser Wert überlagert den Wert 29 („Anzeigen der Payload“), jedoch nicht die Gesamtberechtigung *.

SXMB_MONI: Wenn ein User mit mehr Rollen weniger anzeigen kann, als ein User mit weniger Rollen

Denn genau durch so einen Fall bin ich auf den Berechtigungswert 96 aufmerksam geworden. Ein User mit „scheinbar“ weniger Berechtigungen (d.h. weniger Rollen) konnte die Payload anzeigen – ein Notfalluser mit mehr Rollen konnte die Payload nicht sehen. Interessant war, dass der Notfalluser auch dann keine Payload anzeigen konnte, nachdem das Berechtigungsobjekt S_XMB_MONI in einer der Rollen im Berechtigungsfeld ACTVT um * erweitert wurde. Letztendlich kam ich durch einen SAP-Hinweis (SAP Note 1174305) auf den Berechtigungswert ACTVT = 96. Mithilfe der SUIM habe ich festgestellt, dass der Notfalluser aus einer anderen Rolle (!) explizit die Aktivität 96 erhalten hat. In diesem Fall hat der Wert 96 selbst die Gesamtberechtigung aus einer anderen Rolle überlagert! Erst nachdem dieser Wert entfernt wurde, konnte der Notfalluser die Payload anzeigen.

Falls Sie also aktuell mit genau diesem Problem kämpfen, empfehle ich die Rollen des betroffenen Users nach Berechtigungsobjekt S_XMB_MONI mit ACTVT = 96 zu durchsuchen – und diese, sofern gewünscht, zu entfernen.

Haben Sie bereits ähnliche Erfahrungen mit diesem Berechtigungsfehler gemacht? Oder haben Sie weitere Beispiele für „Wenn ein User mit mehr Rollen weniger anzeigen kann, als ein User mit weniger Rollen“? Ich freue mich auf Ihre Erfahrungen und Kommentare!

Links:
SAP Note 1174305

P.S. Wussten Sie schon, dass Sie SAP Notes ganz einfach mithilfe unserer Domain aufrufen können? Geben Sie einfach www.rz10.de/Nummer-der-SAP-Note in Ihren Browser ein und schon öffnet sich die SAP Note. Probieren Sie es aus: www.rz10.de/1174305

The post SXMB_MONI: Keine Berechtigung für Payload appeared first on rz10.de - die SAP Basis und Security Experten.

Doppelte und abgelaufene Berechtigungsrollen aufräumen kann sehr mühselig werden. Mit dem folgenden Report können Sie diese Tätigkeit zukünftig mit einem Klick erledigen.

Immer wieder kommt es vor, dass ich in meinem Tagesgeschäft auf User treffe, denen Rollen doppelt zugeordnet sind (bspw. mit unterschiedlichen Gültigkeitszeiträumen) oder bei denen der Gültigkeitszeitraum abgelaufen ist. In jedem Fall kann die Rollenzuordnung mitunter sehr unübersichtlich werden. Zum Glück gibt es eine einfache Möglichkeit, doppelte und abgelaufene Berechtigungsrollen aufzuräumen.

Report: Doppelte und abgelaufene Berechtigungsrollen aufräumen

Öffnen Sie die Transaktion SE38 und führen Sie den Report PRGN_COMPRESS_TIMES aus:

Die Selektionsmaske der Transaktion öffnet sich und Sie können im Bereich Selektionskriterien Benutzer, Benutzergruppen oder Rollen auswählen, für die doppelte und abgelaufene Berechtigungsrollen aufgeräumt werden sollen.

Wenn Sie lediglich doppelte Berechtigungsrollen aufräumen wollen, wählen Sie Benutzer, Benutzergruppen und/oder Rollen aus und wählen Sie Ausführen (F8).

Wenn Sie zusätzlich abgelaufene Berechtigungsrollen aufräumen wollen, setzen Sie auch den Haken bei Löschung abgelaufener Zuordnungen und wählen dann Ausführen (F8).

Bevor das Aufräumen der Berechtigungsrollen endgültig durchgeführt wird, können Sie auch den Haken bei Simulationslauf setzen und den Report ausführen, um zunächst zuprüfen, welche Berechtigungsrollen aufgeräumt werden.

Unabhängig davon, ob Sie die Transaktion im Simulationslauf oder final ausführen, erhalten Sie im nächsten Dialog eine Auflistung aller betroffenen Berechtigungsrollen und die vom Report ausgeführte (bzw. auszuführende) Aktion:

PFCG: Doppelte und abgelaufene Berechtigungsrollen aufräumen

Sie können den Report auch direkt aus der PFCG heraus aufrufen. Hierfür öffnen Sie eine beliebige Rolle in der PFCG und wählen anschließend Hilfsmittel -> Benutzerzuordnung optimieren. Der Report öffnet sich und trägt im Selektionsbereich Rolle automatisch die Rolle ein, über die Sie den Report aufgerufen haben.

Ab sofort kennen Sie einen einfachen Weg, um obsolete Berechtigungsrollen in Benutzerstämmen aufzuräumen. Egal ob Sie den Report bereits öfter ausführen  oder ob ich Ihnen mit diesem Beitrag tatsächlich etwas Arbeitsaufwand nehmen konnte – ich freue mich auf Ihre Kommentare gleich unterhalb dieses Beitrags!

The post Doppelte und abgelaufene Berechtigungsrollen aufräumen appeared first on rz10.de - die SAP Basis und Security Experten.

In diesem Blogbeitrag sind die häufig verwendeten SAP-Standardtabellen der Benutzer- und Berechtigungsverwaltung übersichtlich zusammengefasst.

SAP-Standardtabellen für Benutzer- und Berechtigungsverwaltung

Auch im Umfeld der Benutzer und Berechtigungen gibt es häufig verwendete SAP-Standardtabellen bzw. die Tabellen, auf denen die beiden Themenbereiche (technisch) aufgebaut sind. Die im Folgenden aufgeführten Tabellen sind beispielsweise elementare Grundlage für alle Auswertungen der Transaktion SUIM (Benutzerinformationssystem). Für uns Berechtigungsadministratoren sind diese Standardtabellen praktisch, um schnell und massenhaft Informationen über die bestehenden Berechtigungen aus den verschiedenen Tabellen zu ziehen. So lassen sich einzelne Tabellen mit der Transaktion SE16 (sofern berechtigt!) oder mehrere Tabellen gleichzeitig mithilfe der Transaktion SQVI auswerten.

Um sich einen ersten Überblick über die Standardtabellen zu verschaffen, lohnt sich ein Blick auf den Tabellennamen:

• Tabellen, die mit AGR beginnen, enthalten Daten über Rollen.
• Tabellen, die mit USH beginnen, enthalten Daten der Änderungsbelege (change document information).
• Tabellen, die mit USR beginnen, enthalten Daten über Benutzer (user master information).
• Tabellen, die mit UST beginnen, enthalten die Daten, die in der SUIM aufbereitet werden. Zu diesem Zweck synchronisieren sich UST*-Tabellen mit den USR*-Tabellen. Sie sind weniger präzise und dienen der SUIM als „voraufbereitete“ Datengrundlage.

SAP-Standardtabellen der Berechtigungsverwaltung

Die folgenden SAP-Standardtabellen sind elementar für die Verwaltung von Berechtigungen:

SAP-Standardtabellen der Benutzerverwaltung

Die folgenden SAP-Standardtabellen sind elementar für die Verwaltung von Benutzern:

SAP-Standardtabellen zur Steuerung der Benutzer- und Berechtigungsverwaltung

Die folgenden SAP-Standardtabellen sind im Gegensatz zu den zuvor genannten Standardtabellen keine Datentabellen, sondern Steuertabellen, welche zentral für die Benutzer- und Berechtigungsverwaltung stehen:

Ich hoffe sehr, dass dieser Blogbeitrag Ihnen geholfen hat, einen Überblick über die Standardtabellen der Benutzer- und Berechtigungsverwaltung zu erhalten. Wenn Sie noch weitere SAP-Standardtabellen aus den Bereichen Benutzerverwaltung und Berechtigungen kennen, die noch nicht oben aufgeführt sind, freue ich mich über Ihre Kommentare und Anregungen. Ich werde die oben stehende Übersicht dann gerne um Ihren Vorschlag erweitern.

The post Standardtabellen der Benutzer- und Berechtigungsverwaltung appeared first on rz10.de - die SAP Basis und Security Experten.

Sie wollen ein Berechtigungsfeld zur Orgebene erheben. Wenn das Berechtigungsfeld bereits gefüllt ist, müssen Sie dieses nach der Erhebung zur Orgebene erneut befüllen. Hierbei helfen Ihnen zwei Reports.

Kundeneigene Orgebenen befüllen

Ein Berichtigungsfeld wurde zur Orgebene erhoben und war bereits erfüllt. Nach dem Erheben muss das Berechtigungsfeld erneut befüllt werden. Dabei hilft der Report PFCG_ORGFIELD_ROLES. Dieser Report gleicht alle Rollen mit den Orgebenenfeldern bzw. mit den in den Orgebenenfeldern gepflegten Berechtigungsfelder ab.

Alle kundeneigenen Orgebenen anzeigen

Als Tipp vorweg: Mithilfe des Reports PFCG_ORGLEVEL_DELETE können Sie sich eine Liste aller kundeneigenen Orgebenen anzeigen lassen. Hierfür führen Sie den Report in der SE38 aus und nutzen anschließend im Eingabefeld  „Orgebene“ die F4-Hilfe. Da nur kundeneigene Orgebenen gelöscht werden können, zeigt die F4-Hilfe auch nur kundeneigene Orgebenen an und keine Stadardorgebenen.

Report PFCG_ORGFIELD_ROLES nutzen

Führen Sie den Report PFCG_ORGFIELD_ROLES in der SE38 aus. Es erscheint der Einstiegsbildschirm:

Im Eingabefeld „Berechtigungsfeld“ geben Sie nun das Berechtigungsfeld ein, welches Sie zur Orgebene erhoben haben, und führen den Report aus. Daraufhin erhalten Sie eine Liste mit allen Rollen, die das ausgewählte Berechtigungsfeld, das als Orgebene definiert ist, beinhalten.

Die Spalte „Status: Orgebene in Rolle“ gibt anhand von Ampel-Icons eine Information über den Status der Rolle. Folgende Zustände sind möglich:

• GRÜN = „Rolle ist konsistent zur Orgebene“.
• ROT = „Umsetzen erforderlich“ – Das Orgebenenfeld ist in der Rolle noch nicht umgesetzt.
• GELB = „Manuelle gepflegte Werte zur Orgebene“ – Weil die Orgebene andere Werte beinhaltet als die im Berechtigungsfeld angegebenen Werte, beinhaltet die Rolle manuell gepflegte Orgebenen.

Die Spalte „Status: Orgebenenwerte in Rolle“ zeigt anhand von Rot-, Gelb- und Grün-Icons den Zustand der Orgebene:

• GRÜN = „identische Feldwerte in Berechtigungen“ – Die Orgebene und der Berechtigungswert sind identisch.
• ROT = „$ORGEBENE ist in der Rolle ungepflegt“ – Die Orgebene beinhaltet keinen Wert.
• GELB = „ungleiche Feldwerte in Berechtigungen“ – Hierbei handelt es sich um manuell gepflegte Orgebenen, weil die Orgebene andere Werte enhält als die im Berechtigungsfeld eingetragenen Werte.

Mithilfe des Reports können nun alle manuell gepflegten Werte des Berechtigungsfeldes als Werte für die jeweilige Orgebene gesetzt werden. Hierfür gehen Sie die Rollen durch, bei denen eine rote Ampel angezeigt wird. Sie markieren die Rollen, in denen die Werte der Orgebenen nicht vollständig umgesetzt wurden, und klicken auf den Button „Orgebenenfeld in Rollen umsetzen„. Hinterher können Sie den Button „Transportaufzeichnung aktivieren“ klicken, um die Änderungen an den Rollen auch in einem Transportauftrag zu speichern.

Ich hoffe, ich konnte Ihnen mit meinem Blogbeitrag weiterhelfen und freue mich über Ihre Kommentare, Fragen und Anregungen gleich unterhalb dieses Blogs!

The post Gefüllte Berechtigungsfelder zur Orgebenen erheben appeared first on rz10.de - die SAP Basis und Security Experten.

Wenn Orgebenen in Rollen manuell gepflegt wurden, ergeben sich Probleme beim Abteilen von Rollen, da die Werte schlichtweg nicht mehr vererbt werden. Mithilfe eines Reports kann dieser Fehler behoben werden.

Orgebenen in Rollen pflegen

Die Orgebenen werden in der PFCG in der Ansicht „Rolle ändern: Berechtigungen“ über den Button „Orgebenen…“ gepflegt. Die manuelle Pflege – das heißt, nicht über den Button gepflegt – eines Orgebenen-Berechtigungsfeldes bewirkt folgendes:

• Die Berechtigungswertpflege über den Button „Orgebenen…“ verändert den Wert des Berechtigungsobjekts nicht mehr.
• Bei der Anpassung abgeleiteter Rollen wird der Berechtigungswert von der vererbenden Rolle überschrieben. Das Vererbungskonzept funktioniert also nicht mehr.

Fehlerhafte Werte in Orgebenen zurücksetzen

Wenn Sie auf Rollen gestoßen sind, die manuell gepflegte Orgebenen-Felder enthalten, versuchen Sie diese zu bereinigen, indem Sie die Werte aus dem Berechtigungsobjekt manuell löschen. Allerdings wird der über den Button „Orgebenen…“ gepflegte Wert trotzdem nicht übernommen. An dieser Stelle benötigen Sie den Report AGR_RESET_ORG_LEVELS, welchen Sie über die SE38 ausführen können. Der Report sorgt dafür, dass die Werte der zuvor manuell gepflegten Berechtigungsfelder zurückgesetzt werden, und nur die Werte, die über den Button „Orgebenen…“ gepflegt worden sind, gezogen werden.

Nach dem Aufruf des Reports über die SE38 müssen die lediglich die Rolle bzw. die Rollen angeben, für die der manuelle Status und der Inhalt der Orgebenen zurückgesetzt werden soll:

Ich hoffe ich konnte Ihnen mit diesem Blogbeitrag weiterhelfen und freue mich sehr über Kommentare, Fragen und Anregungen in den Kommentaren direkt unter diesem Blog!

The post Manuell gepflegte Orgebenen im SAP zurücksetzen appeared first on rz10.de - die SAP Basis und Security Experten.

In einem SAP-System gibt es verschiedene Arten von Benutzersperren. Wichtig ist, dass nicht alle Benutzersperren auch tatsächlich die Anmeldung verhindern.

Benutzersperren verhindern Anmeldung?

Es gibt verschiedene Sperrgründe für Benutzer und für gewöhnlich gehen Administratoren wie User davon aus, dass sie sich mit einem gesperrten Benutzer nicht mehr anmelden können. Doch erst neulich hatte ich einen Fall, wo ein Benutzer trotz Sperre Zugang zu einem System hatte. Wie kann das sein?

Gründe für Benutzersperren in SAP Systemen

a) Kennwortanmeldung nicht möglich (zu viele Falschmeldungen) Der Maximalwert für Fehlerversuche bei der Passwortanmeldung wurde erreicht. Dieser Maximalwert wird mithilfe des Profilparameters login/fails_to_user_lock gesteuert. Bei jedem fehlerhaften Anmeldeversuch eines Users wird ein individueller Falschanmeldezähler im jeweiligen Benutzerstamm erhöht. Wird der Maximalwert dieses Fehlers erreicht, wird der User für weitere Anmeldungen im System gesperrt.

ÜBRIGENS: Mithilfe des Parameters login/failed_user_auto_unlock können Sie festlegen, ob durch Fehlanmeldungen gesperrte User automatisch wieder entsperrt werden. Das heißt, wenn Sie den Wert des Parameters auf 1 festlegen, werden wegen Falschanmeldungen gesperrte User automatisch am nächsten Tag entsperrt!   

b) Kennwortanmeldung nicht möglich (Initialkennwort ist abgelaufen) Einem User (vom Benutzertyp Dialog oder Kommunikation) wurde ein neues Initialkennwort gesetzt. Dieses Initialkennwort wird gesperrt, sofern sich der User nicht innerhalb eines konfigurierten Zeitspanne anmeldet und das Initialkennwort somit seine Gültigkeit verliert. Die Zeitspanne der Gültigkeit von Initialkennwörtern wird mithilfe des Profilparameters login/password_max_idle_initial festgelegt.

c) Benutzer ist gesperrt („Gültig bis“-Datum überschritten) Jeder Benutzer sollte ein „Gültig von“- und „Gültig bis“-Datum hinterlegt werden. Wenn das „Gültig bis“-Datum überschritten wird, wird der Benutzer automatisch vom System gesperrt und eine Anmeldung ist dann nicht mehr möglich.

d) Benutzer manuell gesperrt (Administratorsperre) Zudem ist es jederzeit möglich, dass ein Benutzer vom Benutzeradministrator manuell gesperrt wird. In diesem Fall wird von der Administratorsperre gesprochen. Eine Anmeldung des Users ist dann nicht mehr möglich.

 Anmeldung am System trotz Benutzersperren?

In welchem Fall ist es nun möglich, dass sich ein User – wie eingangs erwähnt – trotz Benutzersperre in einem System anmelden kann? Die Antwort ist einfach: Nur dann, wenn nicht der Benutzer an sich (Fall c & d), sondern nur das Kennwort des Benutzer gesperrt ist (Fall a & b) und keine Anmeldung mittels Passwort erfolgt. Eine reguläre Anmeldung am System ist also nicht möglich. Allerdings gibt es noch andere Authentifizierungsverfahren, wie bspw. Single Sign-On oder auch interne Abläufe (wie zum Beispiel Hintergrundjobs). Diese Authentifizierungsverfahren sind nicht von der Passwortsperre betroffen, da keine Passwortanmeldung notwendig ist. Eine Ausnahme gibt es jedoch: Bei allen Anmeldeverfahren wird geprüft, ob das Passwort eines Benutzers geändert werden muss. Ist dies aktuell der Fall, wird der Benutzer auch bei anderen Authentifizierungsverfahren aufgefordert, dass aktuelle Passwort zu ändern.

ÜBRIGENS: Diese Aufforderung zum Ändern des Passwortes bei anderen Authentifizierungsverfahren können Sie mithilfe des Profilparameters login/password_change_for_SSO ein- und ausschalten.

 Und was ist nun Best Practice in Bezug auf Benutzersperren?

Ich empfehle Ihnen ausdrücklich, den Zugang von Benutzer zum System via Gültigkeiten oder manueller Administratorsperre zu steuern. In diesem Fall ist der Benutzer wirklich gesperrt und kann sich über kein Authentifizierungsverfahren am SAP System anmelden. Denn nur Sperren und Gültigkeiten des Benutzerkontos betreffen auch andere Anmeldeverfahren, wie bspw. SSO. Um einen User also endgültig vom System ‚auszusperren‘ entfernen Sie bestenfalls alle zugeordneten Rollen, deaktivieren das Passwort und – am wichtigsten – setzen das „Gültig bis“-Datum auf einen Zeitpunkt in der Vergangenheit.

Ich hoffe, dass ich Ihnen mit meinem Blogbeitrag die Benutzersperren in SAP Systemen verständlich machen konnte. Welche Erfahrungen haben Sie mit den verschiedenen Benutzersperren auf Ihren SAP Systemen gemacht? Ich freue mich schon auf Ihre Kommentare, Anregungen und Fragen direkt unterhalb dieses Blogbeitrags.

The post SAP Benutzersperren verstehen und Best Practice appeared first on rz10.de - die SAP Basis und Security Experten.

Ein einfaches Problem: Es sollen massenhaft User in der SU10 selektiert werden, z.B. als Vorgabe aus einer Excel-Tabelle. Leider ist der „Upload aus der Zwischenablage“-Button nirgends zu finden. Oder doch?

Das Problem: Kein Button zum Upload aus der Zwischenablage

Es kommt nicht selten vor, dass ich eine Excel-Tabelle zur Verfügung gestellt bekomme, in welcher eine Vielzahl von zu bearbeitenden Usern dargestellt sind. Wenn ich jedoch alle User auf einmal aus der Excel-Tabelle in die SU10 mit Copy-&-Paste kopieren möchte, werden nicht alle User übernommen. Es wird immer nur die Anzahl der User mitkopiert, die der Anzahl der Zeilen der SU10 entspricht. Ein Button zum Upload aus der Zwischenanlage wird mir nicht angezeigt:

Die Lösung: Oft übersehene Benutzerselektion zum Upload aus der Zwischenablage

Die „sicherste“ (da in den meisten Releases vorhandene) Möglichkeit, ist der Weg über die Benutzerselektion „Berechtigungsdaten“ oder „Anmeldedaten“ (es muss nicht immer beides vorhanden sein!):

Es öffnet sich eine Auswahlmaske, wie wir sie aus der SUIM kennen. Hier können wir nun über die Mehrfachselektion auf den Upload aus der Zwischenablage zugreifen:

Anschließend erfolgt eine Übersicht über alle ausgewählten User. Hier können Sie nun alle User, die Sie tatsächlich aus der Excel in die SU10 übernehmen möchten, mit Klick auf „übernehmen“ einfügen.

Upload aus der Zwischenablage einfach nutzen

Ich hoffe, dass ich Ihnen mit diesem Tipp helfen konnte. Natürlich wird dieser Beitrag für den ein oder anderen erfahrenen User banal klingen. Nichtsdestotrotz hätte ich mich damals gefreut, wenn ich diese schnelle Möglichkeit auf Anhieb gefunden hätte. Vor allem, wenn ich es aus anderen Dialogen im SAP-System gewohnt bin, auf diesen Button jederzeit zugreifen zu können. So kommt es immer wieder zu Situationen, in denen auf scheinbar banale Funktionen, erst über Umwege zugegriffen werden kann. Vielleicht kennen Sie solche Situationen oder SAP-Kontexte ja ebenfalls? Ich freue mich über Ihre Erfahrungen gleich unterhalb im Kommentarfeld.

The post SU10 Upload aus der Zwischenablage appeared first on rz10.de - die SAP Basis und Security Experten.

Der Spool-Bereich ist vollgelaufen und muss bereinigt werden, da die Spool-Aufträge stillstehen. Im Folgenden erkläre ich Ihnen, wie Sie mithilfe eines Reports manuell aufräumen können.

 Spool-Aufträge mithilfe des Reports RSPO1041 löschen

Im Zuge der Bereinigung des Spool-Bereichs müssen obsolete Spool-Aufträge gelöscht werden. Hierzu verwenden Sie den Report RSPO1041. Führen Sie diesen zunächst mit der Transaktion SA38 aus:

Es erscheint die Eingabemaske zum Löschen alter Spool-Aufträge. In dieser Eingabemaske können nun die Kriterien zum Löschen der Spool-Aufträge festgelegt werden. Diese Kriterien beschreibe ich im Folgenden.

Kriterien zum Löschen von Spool-Aufträgen

Die oberen vier Bereiche in der Eingabemaske beziehen sich auf den Status der zu löschenden Spool-Aufträge:

• Ohne Ausgabeauftrag: Bezieht sich auf alle Spool-Aufträge, für die kein Ausgabeauftrag erstellt wurde.
• In Arbeit: Bezieht sich auf alle Spool-Aufträge, die sich im Status in Arbeit befinden.
• Fertige: Bezieht sich auf alle Spool-Aufträge, die erfolgreich bearbeitet (gedruckt und ggf. archiviert) wurden.
• Fehlerhafte: Bezieht sich auf alle Spool-Aufträge, bei deren Bearbeitung ein Fehler aufgetreten ist.

Zeitangaben

Für jeden Status kann nun einzeln festgelegt werden, ob und für welchen Zeitraum diese gelöscht werden sollen. Hierfür wird der jeweilige Kasten vor dem Status angekreuzt und anschließend eine Zeitangabe in Tagen (älter als … Tage) gemacht. Die Angabe „älter als … Tage“ bezieht sich dann auf alle Spool-Aufträge, die vor dem angegebenen Zeitraum erzeugt wurden. Zusätzlich kann auch angekreuzt werden, dass die Spool-Aufträge gelöscht werden, die veraltet sind. Das wiederum bezieht sich auf alle Spool-Aufträge, die das bei der Erzeugung erstellte Verfallsdatum bereits überschritten haben. Dieses Verfallsdatum beträgt im Standard 8 Tage.

Im darunter liegenden Bereich Kalender kann spezifiziert werden, welche Tage einer Woche für die Berechnung der Angabe „älter als … Tage“ herangezogen werden sollen. Hier wird zwischen allen Tagen oder nur Werktagen unterschieden. In jedem Fall muss ein Werkskalender im Feld Fabrikkalender-ID angegeben werden.

Im untersten Bereich Weitere Bedingungen können die Kriterien zum Löschen von Spool-Aufträgen weiter eingeschränkt werden:

Hierbei können Sie zunächst Systemname und Mandant eingrenzen. Außerdem lässt sich auch der Erzeuger (Username) der zu löschenden Spool-Aufträge einschränken. Noch genauere Einschränkungen können mithilfe der Kriterien Titel (des Spool-Aufrags), Spool-Auftragsname, Spool-Auftrag (Suffix1), Spool-Auftrag (Suffix2) und Ausgabegerät erzielt werden. Dadurch lassen sich ganz bestimmte Spool-Aufträge filtern:

• Titel: Der Titel, der auf dem Deckblatt des Auftrags erscheinen soll. (Nur verfügbar, wenn das Ausgabegerät das SAP-Standarddeckblatt druckt.)
• Spool-Auftragsname: Dreiteiliger Name eines Spoolauftrags, wobei der Name automatisch vom Spool-System bestimmt wird, kann aber auch vom erzeugenden Benutzer bzw. Programm eingetragen werden. Es gibt keine zwingende Namenskonvention.
• Spool-Auftrag (Suffix): Dieses Feld entspricht laut F1-Hilfe dem Feld Spool-Auftragsname. Ein Spool-Auftrag kann sowohl einen Spool-Auftragsnamen als auch einen Titel besitzen. Ersterer wird automatisch vom Spool-System erzeugt, letzterer muss explizit vom erzeugenden Benutzer bzw. Programm eingetragen werden.
• Ausgabegerät: Langer Name eines Ausgabegerätes. Der lange Name kann bis zu 30 Zeichen umfassen. Beachten Sie Groß-/ Kleinschreibung des Ausgabegeräts.

Nachdem alle Kriterien nach Ihren Wünschen festgelegt wurden, kann der Report ausgeführt (Ausführen – F8) werden und die entsprechenden Spool-Aufträge werden gelöscht. Wenn Sie zunächst nur einen Probelauf durchführen möchten, um zu prüfen, welche Spoolaufträge gelöscht werden sollen, finden Sie unterhalb des Bereiches Kriterien zur Auswahl der zu löschenden Spool-Aufträge noch die Option Nur Protokoll ohne Löschen?

Wie häufig sollten Spool-Aufträge gelöscht werden?

Das oben beschriebene manuelle Vorgehen ist besonders dann sinnvoll, wenn der Spool-Bereich bereits vollgelaufen ist. Eine periodische Einplanung des Löschjobs im Hintergrund ist oft sinnvoller. Es ist in jedem Fall empfehlenswert, die Spool-Aufträge regelmäßig zu löschen, wobei die Häufigkeit vom jeweiligen System abhängig gemacht werden muss. Allerdings sollten Sie bedenken: Je seltener die Spool-Aufträge gelöscht werden, desto länger wird der Löschvorgang dauern und desto eher wird sich dieser auf die Performance des Gesamtsystems auswirken. Folglich sollten Sie Spool-Aufträge regelmäßig und öfter Löschen, da dann mit jedem Löschvorgang auch weniger Spool-Aufträge auf einmal gelöscht werden müssen.

Wie sind Ihre Erfahrungen mit dem Löschen von Spool-Aufträgen? Führen Sie den Report zum Löschen von Zeit zu Zeit manuell aus oder haben Sie diesen bereits als Job im Hintergrund eingeplant? Ich freue mich auf Ihre Antworten und Kommentare!

The post Spool-Aufträge manuell löschen appeared first on rz10.de - die SAP Basis und Security Experten.

In der Transaktion SE71 (Form Painter) werden die Radio Buttons für Seiten und Fenster nicht angezeigt.

Natürlich werden zunächst die Berechtigungsadministratoren kontaktiert, da davon ausgegangen wird, dass diese die Berechtigungen falsch vergeben haben. Diesen Fall habe ich erst vor Kurzem selbst erlebt. Dass es nicht immer an den Berechtigungen liegt, beweist die folgende Lösung.

Problem: SE71 zeigt Radio-Buttons für Seiten und Fenster im Einstiegsdialog nicht an

In der Einstiegsmaske der Transaktion SE71 werden im Bereich „Teilobjekte“ die Radio Buttons für Seiten und Fenster nicht mehr angezeigt:

Lösung: SE71 korrekt einstellen

Die Lösung des Problems ist nicht – wie zunächst von den Anwendern angenommen – die Anpassung von Berechtigungen. Stattdessen müssen für die SE71 folgende Einstellungen getätigt werden. In der obersten Menüleiste navigieren Sie via Einstellungen -> Form Painter… zum Tab SAPscript und entfernen den Haken unter Grafischer Form Painter:

Anschließend werden die Radio Buttons für Seiten und Fenster wieder angezeigt:

Letztendlich konnte ich den Anwendern helfen – und zwar ganz ohne Anpassung von Berechtigungen. In diesem Blogbeitrag geht es mir weniger um die Problemlösung, als vielmehr um diese kleine Anekdote an sich: Fehlende Berechtigungen sind eine häufige Fehlerursache – aber eben nicht immer!

Ihre Erfahrung

Ich schrieb diesen Blogbeitrag, weil ich mich frage, ob Sie vielleicht ähnliche Erfahrungen bzw. Anekdoten aus Ihrem Alltag mit der Transaktion SE71 haben? Ich freue mich sehr auf Ihre Antworten gleich unterhalb dieses Blogbeitrags!

The post SE71 zeigt Radio-Buttons für Seiten und Fenster nicht appeared first on rz10.de - die SAP Basis und Security Experten.

Die SXMB_MONI lässt die Anzeige der Berechtigung für Payload nicht zu, obwohl die Berechtigung vergeben zu sein scheint. Die Lösung liegt in einer missverständlichen Ausprägung des Berechtigungsobjekt S_XMB_MONI.

SXMB_MONI erlaubt Anzeige der Berechtigung für Payload nicht

Beim Ausführen des Monitors für verarbeitete XML-Messages in der Transaktion SXMB_MONI kommt es bei der Anzeige der Payload zu einem Berechtigungsfehler: „Sie haben keine Berechtigung zur Durchführung dieser Aktion„.

Die zugehörige, detaillierte Fehlerbeschreibung gibt leider keinen Hinweis darauf, welche Berechtigungen genau fehlen. Stattdessen wird auf Meldungsnummer XMS_ADM304 verwiesen.

SXMB_MONI und das zugehörige Berechtigungsobjekt S_XMB_MONI

Das entscheidende Berechtigungsobjekt der Transaktion SXMB_MONI heißt S_XMB_MONI. Es besteht aus insgesamt sieben Berechtigungsfeldern:

ACTVT: Aktivität
SXMBPARTY: Kommunikationspartner
SXMBPRTAG: vergebene Agentur
SXMBPRTYP: Identifikationsschema
SXMBSERV: Service
SXMBIFNS: Interace Namespace
SXMBIFNAME: Interface Name

Für unseren Fehler ist – sofern Interface, Agentur, Schema etc. korrekt berechtigt sind – das Berechtigungsfeld ACTVT interessant. Die Ausprägungen von ACTVT sind bei S_XMB_MONI die folgenden:

02 – Ändern
03 – Anzeigen
16 – Ausführen
29 – Gespeicherte Daten anzeigen (Payload einer XML-Message anzeigen)
36 – Erweiterte Pflege
96 – Ablehnen
A3 – Status ändern

Ich bin davon ausgegangen, dass der Wert 29 zum Anzeigen der Payload ausreicht. Grundsätzlich ist das auch korrekt. Interessant wird es, wenn ein User bspw. aus einer anderen Rolle heraus den Wert 96 für ACTVT im Objekt S_XMB_MONI erhält oder wie im unten dargestellten Beispiel beide Werte in einer Rolle erhält:

Mit den oben dargestellten Berechtigungswerten 29 und 96 wird ein User keine Payload anzeigen können und stattdessen den in diesem Beitrag behandelten Fehler sehen. Der Grund ist, dass Aktivität 96 („-Ablehnen“) die Aktivität 29 („-Gespeicherte Daten anzeigen“) überlagert! 

Aktivität 96 steht für: Ablehnen, d.h. in diesem Fall die Payload einer Nachricht nicht anzeigen. Dieser Wert überlagert den Wert 29 („Anzeigen der Payload“), jedoch nicht die Gesamtberechtigung *.

SXMB_MONI: Wenn ein User mit mehr Rollen weniger anzeigen kann, als ein User mit weniger Rollen

Denn genau durch so einen Fall bin ich auf den Berechtigungswert 96 aufmerksam geworden. Ein User mit „scheinbar“ weniger Berechtigungen (d.h. weniger Rollen) konnte die Payload anzeigen – ein Notfalluser mit mehr Rollen konnte die Payload nicht sehen. Interessant war, dass der Notfalluser auch dann keine Payload anzeigen konnte, nachdem das Berechtigungsobjekt S_XMB_MONI in einer der Rollen im Berechtigungsfeld ACTVT um * erweitert wurde. Letztendlich kam ich durch einen SAP-Hinweis (SAP Note 1174305) auf den Berechtigungswert ACTVT = 96. Mithilfe der SUIM habe ich festgestellt, dass der Notfalluser aus einer anderen Rolle (!) explizit die Aktivität 96 erhalten hat. In diesem Fall hat der Wert 96 selbst die Gesamtberechtigung aus einer anderen Rolle überlagert! Erst nachdem dieser Wert entfernt wurde, konnte der Notfalluser die Payload anzeigen.

Falls Sie also aktuell mit genau diesem Problem kämpfen, empfehle ich die Rollen des betroffenen Users nach Berechtigungsobjekt S_XMB_MONI mit ACTVT = 96 zu durchsuchen – und diese, sofern gewünscht, zu entfernen.

Haben Sie bereits ähnliche Erfahrungen mit diesem Berechtigungsfehler gemacht? Oder haben Sie weitere Beispiele für „Wenn ein User mit mehr Rollen weniger anzeigen kann, als ein User mit weniger Rollen“? Ich freue mich auf Ihre Erfahrungen und Kommentare!

SAP Notes

Links:
SAP Note 1174305

P.S. Wussten Sie schon, dass Sie SAP Notes ganz einfach mithilfe unserer Domain aufrufen können? Geben Sie einfach www.rz10.de/Nummer-der-SAP-Note in Ihren Browser ein und schon öffnet sich die SAP Note. Probieren Sie es aus: www.rz10.de/1174305

The post SXMB_MONI: Keine Berechtigung für Payload appeared first on rz10.de - die SAP Basis und Security Experten.

Doppelte und abgelaufene Berechtigungsrollen aufräumen kann sehr mühselig werden. Mit dem folgenden Report können Sie diese Tätigkeit zukünftig mit einem Klick erledigen.

Immer wieder kommt es vor, dass ich in meinem Tagesgeschäft auf User treffe, denen Rollen doppelt zugeordnet sind (bspw. mit unterschiedlichen Gültigkeitszeiträumen) oder bei denen der Gültigkeitszeitraum abgelaufen ist. In jedem Fall kann die Rollenzuordnung mitunter sehr unübersichtlich werden. Zum Glück gibt es eine einfache Möglichkeit, doppelte und abgelaufene Berechtigungsrollen aufzuräumen.

Report: Doppelte und abgelaufene Berechtigungsrollen aufräumen

Öffnen Sie die Transaktion SE38 und führen Sie den Report PRGN_COMPRESS_TIMES aus:

Die Selektionsmaske der Transaktion öffnet sich und Sie können im Bereich Selektionskriterien Benutzer, Benutzergruppen oder Rollen auswählen, für die doppelte und abgelaufene Berechtigungsrollen aufgeräumt werden sollen.

Wenn Sie lediglich doppelte Berechtigungsrollen aufräumen wollen, wählen Sie Benutzer, Benutzergruppen und/oder Rollen aus und wählen Sie Ausführen (F8).

Wenn Sie zusätzlich abgelaufene Berechtigungsrollen aufräumen wollen, setzen Sie auch den Haken bei Löschung abgelaufener Zuordnungen und wählen dann Ausführen (F8).

Bevor das Aufräumen der Berechtigungsrollen endgültig durchgeführt wird, können Sie auch den Haken bei Simulationslauf setzen und den Report ausführen, um zunächst zuprüfen, welche Berechtigungsrollen aufgeräumt werden.

Unabhängig davon, ob Sie die Transaktion im Simulationslauf oder final ausführen, erhalten Sie im nächsten Dialog eine Auflistung aller betroffenen Berechtigungsrollen und die vom Report ausgeführte (bzw. auszuführende) Aktion:

PFCG: Doppelte und abgelaufene Berechtigungsrollen aufräumen

Sie können den Report auch direkt aus der PFCG heraus aufrufen. Hierfür öffnen Sie eine beliebige Rolle in der PFCG und wählen anschließend Hilfsmittel -> Benutzerzuordnung optimieren. Der Report öffnet sich und trägt im Selektionsbereich Rolle automatisch die Rolle ein, über die Sie den Report aufgerufen haben.

Ab sofort kennen Sie einen einfachen Weg, um obsolete Berechtigungsrollen in Benutzerstämmen aufzuräumen. Egal ob Sie den Report bereits öfter ausführen  oder ob ich Ihnen mit diesem Beitrag tatsächlich etwas Arbeitsaufwand nehmen konnte – ich freue mich auf Ihre Kommentare gleich unterhalb dieses Beitrags!

The post Doppelte und abgelaufene Berechtigungsrollen aufräumen appeared first on rz10.de - die SAP Basis und Security Experten.

In diesem Blogbeitrag sind die häufig verwendeten SAP-Standardtabellen der Benutzer- und Berechtigungsverwaltung übersichtlich zusammengefasst.

SAP-Standardtabellen für Benutzer- und Berechtigungsverwaltung.

Auch im Umfeld der Benutzer und Berechtigungen gibt es häufig verwendete SAP-Standardtabellen bzw. die Tabellen, auf denen die beiden Themenbereiche (technisch) aufgebaut sind. Die im Folgenden aufgeführten Tabellen sind beispielsweise elementare Grundlage für alle Auswertungen der Transaktion SUIM (Benutzerinformationssystem). Für uns Berechtigungsadministratoren sind diese Standardtabellen praktisch, um schnell und massenhaft Informationen über die bestehenden SAP Berechtigungen aus den verschiedenen Tabellen zu ziehen. So lassen sich einzelne Tabellen mit der Transaktion SE16 (sofern berechtigt!) oder mehrere Tabellen gleichzeitig mithilfe der Transaktion SQVI auswerten.

Tabellen als PDF herunterladen

Um sich einen ersten Überblick über die Standardtabellen zu verschaffen, lohnt sich ein Blick auf den Tabellennamen:

• Tabellen, die mit AGR beginnen, enthalten Daten über Rollen.
• Tabellen, die mit USH beginnen, enthalten Daten der Änderungsbelege (change document information).
• Tabellen, die mit USR beginnen, enthalten Daten über Benutzer (user master information).
• Tabellen, die mit UST beginnen, enthalten die Daten, die in der SUIM aufbereitet werden. Zu diesem Zweck synchronisieren sich UST*-Tabellen mit den USR*-Tabellen. Sie sind weniger präzise und dienen der SUIM als „voraufbereitete“ Datengrundlage.

SAP-Standardtabellen der Berechtigungsverwaltung

Die folgenden SAP-Standardtabellen sind elementar für die Verwaltung von Berechtigungen:

SAP-Standardtabellen der Benutzerverwaltung

Die folgenden SAP-Standardtabellen sind elementar für die Verwaltung von Benutzern:

SAP-Standardtabellen zur Steuerung der Benutzer- und Berechtigungsverwaltung

Die folgenden SAP-Standardtabellen sind im Gegensatz zu den zuvor genannten Standardtabellen keine Datentabellen, sondern Steuertabellen, welche zentral für die Benutzer- und Berechtigungsverwaltung stehen:

Standardtabellen der Benutzer- und Berechtigungsverwaltung als PDF herunterladen:

Ich hoffe sehr, dass dieser Blogbeitrag Ihnen geholfen hat, einen Überblick über die Standardtabellen der Benutzer- und Berechtigungsverwaltung zu erhalten. Wenn Sie noch weitere SAP-Standardtabellen aus den Bereichen Benutzerverwaltung und Berechtigungen kennen, die noch nicht oben aufgeführt sind, freue ich mich über Ihre Kommentare und Anregungen. Ich werde die oben stehende Übersicht dann gerne um Ihren Vorschlag erweitern.

The post Standardtabellen der Benutzer- und Berechtigungsverwaltung appeared first on rz10.de - die SAP Basis und Security Experten.