Löschen von Änderungsbelegen
Berechtigungskonzept – Rezertifizierungsprozess
Wenn Sie Ihre Kriterien für die Ausführung des Reports festgelegt haben, können Sie verschiedene Varianten für den Report anlegen und entsprechende Jobs einplanen, um die inaktiven Benutzer automatisiert zu sperren bzw. für ungültig zu setzen. Sollten Sie den Report in einem System starten, das an eine Zentrale Benutzerverwaltung angeschlossen ist, müssen Sie die folgenden Punkte beachten: Sie können nur lokale Benutzersperren setzen. Sie können den Gültigkeitszeitraum nur setzen, falls die Pflege dafür in den Einstellungen der Zentralen Benutzerverwaltung auf Lokal eingestellt ist (diese Einstellung erfolgt in der Transaktion SCUM).
Definieren Sie kritische Berechtigungskombinationen, die in den überwachten Systemen nicht vergeben sein dürfen. Über eine Whitelist können Sie festlegen, welche Benutzer (z. B. Notfallbenutzer) Sie von der Auswertung ausschließen wollen.
Systembenutzer
Um einen Berechtigungssupport für Anwender anbieten zu können, sind Sie oft auf deren Auskünfte angewiesen. Es gibt jedoch auch die Möglichkeit, fehlende Berechtigungen für alle Anwender zentral einzusehen. Hat ein Anwender ein Berechtigungsproblem, wird in der Regel ein Ticket beim Support aufgemacht. Berechtigungsfehler sind für Supportmitarbeiter jedoch nur schwer nachzuvollziehen, da diese über andere Berechtigungen verfügen und häufig detaillierte Informationen zur Applikation, in der der Berechtigungsfehler aufgetreten ist, fehlen. In der Praxis helfen sich Supportmitarbeiter daher oft damit, den Anwender zu bitten, einen Screenshot ausder Transaktion SU53 zu schicken. Denn diese Transaktion zeigt die letzte fehlgeschlagene Berechtigungsprüfung an. In vielen Fällen sind die Informationen, die dort angezeigt werden, für den Berechtigungsadministrator jedoch gar nicht hilfreich. Sicher haben Sie es auch schon einmal erlebt, dass ein Screenshot aus der Transaktion SU53 eine fehlende Berechtigung für typische Basisberechtigungsobjekte anzeigt, wie z. B. S_ADMI_FCD, S_CTS_ADMI oder S_TRANSLAT, von denen Sie aber wissen, dass ihre Prüfung mit dem eigentlichen Berechtigungsproblem in der Anwendung gar nichts zu tun hat. Sie brauchen also die Möglichkeit, sich selbst ein Bild machen zu können.
Ihre Systemlandschaft entspricht keiner typischen Dreisystemlandschaft? Erfahren Sie, was Sie in diesem Fall bei Upgradenacharbeiten für die Vorschlagswerte von Rollen beachten sollten. Ihre Systemlandschaft kann sich von den typischen Dreisystemlandschaften z. B. dadurch unterscheiden, dass Sie mehrere Entwicklungssysteme bzw. Entwicklungsmandanten haben. Über Transporte werden dann alle Entwicklungen und Customizing-Einträge in einem Konsolidierungssystem zusammengefügt. Führen Sie Ihre Upgradenacharbeiten in der Transaktion SU25 durch, und transportieren Sie mit Schritt 3 Ihre Vorschlagswerte, d. h. Ihre SU24-Daten. Führen Sie diesen Schritt hingegen in allen Entwicklungssystemen aus, laufen alle Transporte in Ihrem Konsolidierungssystem zusammen, und nur der letzte Import der Tabellen wird verwendet. Gleiche Einträge werden außerdem als zu löschende Einträge erkannt. Ähnlich verhält es sich mit Ihren PFCG-Rollen. Pflegen Sie diese in mehreren Entwicklungssystemen bzw. –mandanten, und möchten Sie nun die Rollen mit ihren generierten Profilen transportieren, besteht die Gefahr, dass die Nummern für die Profile gleichlauten, da sich die Profilnamen aus dem ersten und dritten Zeichen der System-ID des Systems und einer sechsstelligen Nummer zusammensetzen. Stammen nun auch noch die Profile aus demselben System (auch wenn der Mandant ein anderer ist), kann es aufgrund der gleichen Profilnamen zu Importfehlern kommen. Außerdem kann die Herkunft des Profils im Nachhinein nicht mehr nachvollzogen werden. Daher brauchen Sie eine Möglichkeit, um die Daten für die Berechtigungsvorschlagswerte und die PFCG-Rollen in Y-Landschaften transparent und konsistent zu transportieren.
Im Go-Live ist die Zuweisung notwendiger Berechtigungen besonders zeitkritisch. Die Anwendung "Shortcut for SAP systems" hält dafür Funktionen bereit, so dass der Go-Live nicht wegen fehlender Berechtigungen ins Stocken gerät.
Erstere prüft, ob überhaupt Berechtigungsprüfungen im Quellcode vorhanden sind.
Dies kann verschiedene Gründe haben.