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 Standardorgebenen.

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.

Orgebenen in Rollen

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 zu 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.

Rollen pflegen

Die Orgebenen werden in der PFCG in der Ansicht „Rolle ändern: Berechtigungen“ über den Button „Orgebenen…“ gepflegt. Die manuelle – das heißt, nicht über den Button ausgelöste – Pflege 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 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 SAP 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 SAP Benutzersperren?

In welchem Fall ist es nun möglich, dass sich ein User – wie eingangs erwähnt – trotz SAP 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 SAP 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 SAP 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 Transaktion 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 der Transaktion SU10 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 Transaktion SU10: Upload aus der Zwischenablage appeared first on rz10.de - die SAP Basis und Security Experten.

Was haben RFC Schnittstellen und RFC Sicherheit mit dem Theaterstück der „Hauptmann von Köpenick“ und dem Science-Fiction-Film „Minority Report“ zu tun? Vermutlich mehr als Ihnen lieb ist!

RFC Sicherheit und Theater?!

Deutschland, Berlin, 1906: Der sechsundvierzigjährige Schuster Wilhelm Voigt träumt von der Rückkehr in ein normales Leben. Nach diversen Verurteilungen und etlichen Gefängnisaufenthalten lebt er am Rande der Gesellschaft. Es sind nicht nur die finanziellen Mittel die ihm fehlen. Vor allem die fehlende Zugangsberechtigung zu seinem Sozialen System macht ihm zu schaffen. In Anbetracht seiner ausweglosen Situation entscheidet er sich für eine drastische Maßnahme.

Der ausgegrenzte Schuster zieht los und grast etliche Trödelhändler ab, um sich nach und nach eine militärische Uniform zusammenzustellen. Wenige Tage später schlüpft er in eben diese Verkleidung, wechselt erfolgreich seine Identität und schwindelt sich fortan als Hauptmann von Köpenick durch Berlin. Er kommandiert Soldaten, lässt das Rathaus stürmen und sogar den Bürgermeister festnehmen. An den Befehlen und deren Ausführung zweifelt zunächst keiner, denn seine wahre Identität ist verschleiert: Wegen einer simplen Verkleidung. Eine Verkleidung, die ihm alle notwendigen Berechtigungen gibt, die er für seinen Schwindel benötigt. Am Ende des Tages hat Wilhelm Voigt die Regierung Berlins erfolgreich kompromittiert.

RFC Sicherheit und Science-Fiction?!

USA, Washington, D.C., 2054: Die Washingtoner Polizei klärt längst keine Morde mehr auf: sie verhindert die Morde gleich im Voraus. Hierfür werden sogenannte „Precogs“ eingesetzt, die mittels Präkognition Morde in Visionen vorhersagen und diese melden, noch bevor sie passieren. Gleichzeitig nutzt die Regierung ein System aus öffentlichen Scannern, die alle Bürger jederzeit eindeutig durch Iris-Erkennung identifizieren können.

Als der Polizist John Anderton eines Tages selbst als Täter in einer Vision der „Precogs“ erscheint, flieht er aus dem Polizeigebäude und beschließt, der Ursache für die Vision auf den Grund zu gehen. Um den Kontrollen durch die Iris-Scanner und letztendlich seiner eigenen Festnahme zu entkommen, lässt er sich von einem Arzt illegal neue Augen  einsetzen und agiert fortan unter einer neuen Identität. Mithilfe der neuen Augen gelingt ihm letztendlich der Zutritt in den gesicherten Bereich der „Precogs“ und er kann mit seinen Nachforschungen beginnen. Durch dieses „Biohacking“  täuscht er nicht nur die biometrischen Sicherheitssysteme – er kompromittiert das höchste Kontrollsystem der Polizei.

Alles nur Geschichten!?

„Tolle Geschichten!“, denken Sie nun. „Aber: Auf eine einfach Verkleidung fällt doch heute keiner mehr rein. Und überhaupt: Biometrische Sicherheitssysteme und Augentransplantation? Es ist nicht umsonst ein Science-Fiction-Film! Was hat das nun mit RFC Sicherheit zu tun?“. In Ordnung, ich kann Ihre Zweifel verstehen. Aber, wie gefällt Ihnen denn beispielsweise die folgende Geschichte.

RFC Sicherheit und die Kunst des Identitätswandels

Deutschland, überall, 2017: Johannes Voigt ist seit einigen Jahren Mitarbeiter in einem mittelständischen Unternehmen. Er gilt als zuverlässiger und gewissenhafter Entwickler aus der IT-Abteilung. In Wahrheit fühlt er sich immer häufiger ungerecht behandelt. Er beschließt, dass er seinen Frust nicht länger mit sich herumtragen möchte.

Aus dem Tagesgeschäft in seiner Abteilung hat er bereits viele hilfreiche Informationen sammeln können: Die RFC Schnittstellen und die zugehörigen technischen RFC Benutzer kennt Johannes aus seiner Arbeit mit den Applikationen. Auch das Passwort für diverse technische RFC User hatte er schnell über den Flurfunk mitbekommen („Solange Passwörter nur per Telefon kommuniziert werden und niemals schriftlich ausgetauscht werden, sind wir sauber!“). Und dass die RFC User selbst in Produktivsystemen großzügig berechtigt sind, ist längst kein Geheimnis mehr („Lieber mehr Berechtigungen als zu wenig; die RFC Verbindungen müssen rennen, sonst gibt es Ärger aus den Fachbereichen!“).

Da Johannes als Entwickler Zugriff auf die SE37 hat, ist es kein Problem sich mithilfe des Funktionsbausteins BAPI_USER_CHANGE den notwendigen Zugriff zu erschleichen – getarnt als RFC User. Kurzum ändert er durch Aufruf des Funktionsbausteins den Benutzertyp eines technischen RFC Benutzers in einem Produktivsystem von <System> auf <Service>. Hierdurch wird der technische User zum Dialog-User und eine Anmeldung im SAP System ist uneingeschränkt möglich. Also meldet sich Johannes mit dem bekannten Passwort des RFC Users im Produktivsystem an. Dank sehr weitreichender Berechtigungen hat er fortan Zugriff auf allerlei kritische Tabellen, Transaktionen und Programme in Produktion. Mit der Identität des RFC Users beginnt Johannes mit der technischen Kompromittierung des Produktivsystems…

RFC Sicherheit: Alles nur erfunden – oder alltägliche Bedrohung?

Ob nun eine simple Verkleidung, veränderte biometrische Eigenschaften oder ein gekaperter, technischer User im SAP System: die Grundlage der Kompromittierung ist dieselbe. Eine Person nutzt eine andere Identität, um Zugang und Berechtigungen zu geschützten Bereichen zu bekommen. Außerdem hätte das Übel in allen drei Geschichten durch Pro-Aktivität verhindert werden können. Nur…, wann haben Sie sich das letzte Mal Gedanken über die Sicherheit Ihrer RFC Schnittstellen gemacht? Können Sie mit Sicherheit sagen, dass alle Ihre technischen RFC User nur die Berechtigungen besitzen, die sie auch tatsächlich benötigen? Und wissen Sie eigentlich wer genau die Passwörter dieser User kennt? Können Sie zu 100% ausschließen, dass nicht jetzt in diesem Moment ein SAP User mit falscher Identität Ihre Produktivsysteme infiltriert?

Change now: Es geht um Pro-Aktivität!

Doch bevor Sie jetzt beginnen und sich auf die Suche nach dem „Identitäten-Wandler“ begeben (was ich wirklich nicht empfehlen möchte!), schlage ich vor, dass Sie die Wurzel des Übels fassen und Ihre RFC Sicherheit proaktiv stärken. Wenn Sie also mehr erfahren möchten, habe ich hier folgende 3 Tipps für Sie:

1. Unser E-Book über SAP RFC-Schnittstellen
2. Unser kostenloses Webinar zum Thema RFC-Schnittstellen bereinigen
3. Tobias Harmes Blogbeitrag über unser Vorgehen zur Optimierung von RFC Schnittstellen

Wie immer freue ich mich auf Ihr Feedback und Ihre Kommentare direkt unterhalb dieser Zeilen!

The post RFC Sicherheit, Science-Fiction und Theater appeared first on rz10.de - die SAP Basis und Security Experten.

Obwohl Sie beim Administrieren von Berechtigungsrollen stets darauf achten, dass diese auch generiert sind, kommt es immer wieder vor, dass in den Produktivsystemen rote Ampeln in der Benutzerzuordnung zu finden sind. Haben Sie den Benutzerabgleich bedacht?

Problem: Benutzerabgleich nicht durchgeführt

Wann immer Sie eine rote Ampel auf der Registerkarte Rollen im Benutzerstamm in der SU01 finden – oder aber eine gelbe Ampel auf der Registerkarte Benutzer in der PFCG, können Sie das Problem für gewöhnlich mit einem einfachen Benutzerabgleich lösen. Dass ein solcher Benutzerabgleich notwendig ist, kann mehrere Ursachen haben. Unter anderem:

• nach einem Rollentransport
• nach / beim Zuweisen von Benutzer zu Rollen über die PFCG
• nach dem Einschränken der Gültigkeit von Rollen zu Benutzern
• wenn Rollen indirekt über das Organisationsmanagement vergeben werden.

Die Problematik eines nicht durchgeführten Benutzerabgleichs spüren die Anwender meistens recht zügig: Es fehlen Berechtigungen, obwohl diese auf den ersten Blick in den zugeordneten Berechtigungsrollen vorhanden sind. Denn dann ist einem Benutzer zwar die korrekte Berechtigungsrolle zugeordnet – das zur Rolle gehörende Profil ist jedoch nicht auf dem aktuellen Stand.

Wie das möglich ist? Rein technisch gesehen enthält jede generierte Berechtigungsrolle ein Profil, aus welchem ein User die tatsächlichen Berechtigungsobjekte und Berechtigungsausprägungen erhält. Wenn dieses Profil veraltet oder aber gar nicht erst zugewiesen ist, besitzt der User auch nicht alle in der Berechtigungsrolle enthaltenen Berechtigungsobjekte.

Besonders häufig entsteht das Problem übrigens nach Rollentransporten: Wenn eine Berechtigungsrolle im Entwicklungssystem verändert und anschließend in das Produktivsystem transportiert wird, wird nicht automatisch das aktuelle Profil an die User mit der jeweiligen Rolle vergeben. Hier muss also ein Benutzerabgleich durchgeführt werden.

Lösung: Benutzerabgleich durchführen

In diesen Fällen werden Sie das Problem mit einem manuellen Benutzerabgleich zügig unter Kontrolle bringen. Denn der Benutzerabgleich prüft, welche Rollen einem Benutzer zugeordnet sind und weist anschließend das aktuelle, passende Profil zu. Diesen Benutzerabgleich können Sie entweder manuell oder aber (meine Empfehlung!) automatisiert als Hintergrundjob ausführen:

1.) Benutzerabgleich manuell mit Transaktion PFUD durchführen

In der Transaktion PFUD (siehe Bild oben) können Sie den Benutzerabgleich manuell für alle Rollen (oder ausgewählte Rollen) durchführen. Sie können zwischen den Abgleicharten Profilabgleich, Abgleich indirekter Zuordnungen aus Sammelrollen und Abgleich HR-Organisationsmanagement wählen. Die Abgleiche unterscheiden sich laut SAP Dokumentation wie folgt:

• Profilabgleich: „Das Programm vergleicht die aktuell gültigen Benutzerzuordnungen der ausgewählten Einzelrollen mit den Zuordnungen der zugehörigen generierten Profile und führt notwendige Anpassungen der Profilzuordnungen durch.“
• Abgleich indirekter Zuordnungen aus Sammelrollen: „Benutzerzuordnungen zu Sammelrollen führen zu indirekten Zuordnungen für die in der Sammelrolle enthaltenen Einzelrollen. Diese Abgleichart passt die indirekten Zuordnungen der ausgewählten Einzelrollen an die Benutzerzuordnungen aller Sammelrollen an, in denen die Einzelrollen enthalten sind. Enthält die Selektionsmenge Sammelrollen, findet der Abgleich für alle darin enthaltenen Einzelrollen statt.“
• Abgleich HR-Organisationsmanagement: „Diese Abgleichart aktualisiert die indirekten Zuordnungen aller ausgewählten Einzel- und Sammelrollen, die mit Elementen des HR-Organisationsmanagements verknüpft sind. Der HR-Abgleich ist inaktiv und nicht selektierbar, wenn keine aktive Planvariante existiert oder durch Einstellung des Customizing-Schalters HR_ORG_ACTIVE = NO in Tabelle PRGN_CUST eine globale Deaktivierung vorgenommen wurde.“

Weiterhin ist die Option „Bereinigung durchführen“ interessant, die unabhängig von den drei Abgleicharten ausgewählt werden kann und sich nicht auf die Rollenselektion bezieht. Mit der Funktion Bereinigung durchführen können Datenreste beseitigt werden, die durch unvollständige Löschung von Rollen und den zugehörigen generierten Profilen entstanden sind. Die zwei Hauptaufgaben dieser Funktion sind:

• Löschen von Profilen samt Benutzerzuordnung, wenn keine passende Rolle existiert.
• Löschen von Zuordnungen zwischen Benutzern und Rollen, wenn entweder der Benutzer oder die Rolle nicht existieren.

2.) Benutzerabgleich als Hintergrundjob einplanen

Ich empfehle Ihnen, dass Sie den Hintergrundjob PFCG_TIME_DEPENDENCY mit dem Report RHAUTUPD_NEW einplanen. Als Best Practice hat sich das Einplanen des Reports RHAUTUPD_NEW mit zwei Varianten bewiesen:

1. Einmal täglich vor der ersten Anmeldung der Anwender (z.B. Mitternacht oder sehr früh am Morgen). Hierdurch werden die Benutzer einmal täglich abgeglichen.
2. Einmal im Monat (oder auch einmal pro Woche) mit der Option „Bereinigung durchführen“, sodass regelmäßig obsolete Profile und Benutzerzuordnungen bereinigt werden.

Ebenfalls praktisch: Wenn es die Namenskonventionen Ihrer Rollen zulassen, können Sie den Report auch nach verschiedenen Zeitzonen ausrichten. Ich habe bspw. einen Kunden, der den Benutzerabgleich für seine Anwender in den USA und Asien zu verschiedenen Zeitpunkten laufen lässt, damit das Tagesgeschäft der jeweiligen Anwender nicht gestört wird.

Ich hoffe, ich konnte Ihnen die Funktion des Benutzerabgleiches näher bringen und – falls noch nicht geschehen – Sie dazu motivieren, diesen auch regelmäßig in Ihrem System einzuplanen. Wie sind Ihre Erfahrungen mit dem (fehlenden) Benutzerabgleich? Ich freue mich auf Ihre Kommentare gleich unterhalb dieser Zeilen!

The post Benutzerabgleich als Job einplanen appeared first on rz10.de - die SAP Basis und Security Experten.

Ein Benutzername ohne eingeschränkten Zeichenvorrat kann ein Sicherheitsrisiko darstellen. Deshalb ist es ratsam, dass Sie den Zeichenvorrat der Benutzer-ID einschränken. Wo die Gefahren liegen, sollten sie keine derartige Begrenzung vornehmen, erfahren Sie in diesem Beitrag. Außerdem erläutere ich, wie sie dieses Sicherheitsrisiko eliminieren.

Benutzername ohne Einschränkungen – kritisch?

Je nachdem, welches Release die SAP_BASIS-Komponente in Ihrem System hat, können nicht sichtbare Sonderzeichen im Benutzernamen landen. Das ist insbesondere dann kritisch, wenn beim Anlegen eines neuen Benutzers für den Benutzernamen ausschließlich Leerzeichen oder alternative Leerzeichen verwendet werden. In Unicode-Systemen können neben dem normalen Leerzeichen (Hexadezimalwert 20) auch „alternative“ Leerzeichen, so genannte „wide spaces“ verwendet werden. So können zum Beispiel mithilfe der Tastenkombination „ALT+0160″ non-breaking spaces eingefügt werden. Wenn jetzt ein Benutzer angelegt wird, dessen Benutzername ausschließlich aus solchen alternativen Leerzeichen besteht, dann kann das verwirrend sein. Denn in Änderungsbelegen tauchen zwar Einträge zu dieser Benutzer-ID auf, allerdings entsteht der Eindruck, als sei der Eintrag durch einen nicht-vorhandenen / gelöschten Benutzer erzeugt worden. Dieser Umstand kann zu Verwirrungen führen.

Außerdem können bestimmte Sonderzeichen im Benutzernamen auch zu Fehlern, bspw. im Change and Transport System (CTS), führen. Denn der Benutzername wird im CTS-ORG auch dazu verwendet, eine gleichnamige Datei im Transportverzeichnis anzulegen.

Darüberhinaus gibt es Buchstaben / Zeichen, die in unterschiedlichen Alphabeten identisch aussehen, aber im Zeichensatz einen anderen Hexadezimalwert besitzen. Dadurch können Verwechslungen bei Benutzernamen nicht vollständig ausgeschlossen werden. Scheinbar gleiche Benutzernamen stehen dann für unterschiedliche Benutzer.

Benutzername mit Einschränkungen – wie?

Wenn Ihr System bereits über SAP NetWeaver-Release 7.0 liegt, dann müssen Sie entweder den SAP Hinweis 1731549 oder ein entsprechendes Support Package einspielen. Anschließend können bei der Neuanlage von Benutzern keine Benutzernamen mehr vergeben werden, die nur aus Varianten von Leerzeichen oder anderen nicht sichtbaren Sonderzeichen zusammengesetzt sind.

Wichtig: Änderungen an bereits bestehenden Benutzern mit diesen Namen oder deren Löschungsmöglichkeit sind davon nicht betroffen!

Durch den SAP Hinweis wird außerdem der Customizing-Schalter BNAME_RESTRICT eingebaut, woraufhin Sie selbst steuern können, ob alternative Leerzeichen an bestimmten Stellen im Benutzernamen vorkommen dürfen. Hierfür müssen in der Customizing-Tabelle PRGN_CUST folgende Werte gesetzt werden:

• NO = Die alternativen Leerzeichen sind weiterhin im Benutzernamen erlaubt.
• ALL = Der Zeichenvorrat wird auf einen definierten Bereich reduziert, wobei gewisse Sonderzeichen ausgeklammert werden, da diese in bestimmten Betriebssystemen oder Datenbanken bestimmte Bedeutungen haben. Dieser vordefinierte Zeichenvorrat ist: ABCDEFGHIJKLNMOPQRSTUVWXYZ_0123456789,;-§&()={[]}+#.
• FME = Die Buchstaben F, M und E stehen für Front, Middle und End. Mit einem ‚X‘ in diesem dreistelligen Schalterwert können Sie nun also explizit festlegen, an welcher Position im Benutzernamen keine wide spaces und Steuerzeichen auftreten dürfen. Es sind alle Kombinationen möglich, also z.B.:
  • XME = Im Benutzernamen darf am ANFANG keines dieser Sonderzeichen vorkommen.
  • XMX = Im Benutzernamen darf am ANFANG und am ENDE keines dieser Sonderzeichen vorkommen.
  • FME = Im Benutzernamen darf an jeder Stelle eines dieser Sonderzeichen vorkommen (Das entspricht der Standardeinstellung, also als sei für den Schalter kein Eintrag in der PRGN_CUST gepflegt!).

SAP empfiehlt übrigens die Verwendung vom Wert ALL.

Wie sieht es bei Ihnen auf dem System aus? Nutzen Sie den Customizingschalter BNAME_RESTRICT? Ich freue mich auf Ihre Kommentare!

Hier noch der Link zum SAP Hinweis 1731549:
Einschränkungen des Zeichenvorrates für Benutzernamen.

The post Benutzername im SAP System einschränken appeared first on rz10.de - die SAP Basis und Security Experten.

SAP Rollen massenhaft zuweisen? Das klingt nach Fleißarbeit! Wie Sie sich das Leben erleichtern können, stelle ich im folgenden Beitrag vor.

Sie arbeiten nur mit SAP Bordmitteln. Immer wieder müssen Sie viele Berechtigungszuweisungen an vielen Usern machen. Beispiel: Ein Kollege schickt eine Liste mit der Bitte die Rollenzuweisungen anzupassen. Häufig artet diese Bitte in nervige Fleißarbeit aus. Sie wechseln wild zwischen SU01, SUIM und SU10. Und entscheiden ob eine Rolle hinzugefügt oder entfernt werden muss.

Rollen massenhaft zuweisen mit dem XAMS Role Replicator

Ich zeige Ihnen, wie Sie schneller und mit weniger Aufwand vorgehen können. Hierfür empfehle ich Ihnen den Einsatz der XAMS. Insbesondere das darin enthaltende Tool Role Replicator. Dieser bietet unter anderem eine Funktion zum massenhaften Ändern von Rollenzuordnungen. Besonders effektiv wird der Role Replicator beim Einsatz auf einer ZBV. Von hier kann die massenhafte Änderung direkt auf alle logischen Systeme erfolgen.

Einstiegsmaske: Role Replicator

Rollen massenhaft zuweisen in 4 einfachen Schritten

1. Mithilfe des Role Replicators exportieren Sie zunächst eine CSV/Excel-Datei. Darin findet sich die aktuelle Rollenzuweisung aller betroffenen User aus dem System:

   Excel-Datei für Rollenzuordnung downloaden

2. Jetzt können Sie die Anpassung der Rollenzuordnungen direkt in der CSV/Excel-Datei vornehmen:

   Excel-Datei mit Rollenzuordnungen

3. Es folgt der Upload der CSV/Excel-Datei in den Role Replicator und die Auswahl des Verarbeitungsmodus:

   Rollenzuweisungen ändern – verschiedene Modi im Überblick

4. Abschließend müssen Sie nur noch die Erfolgsmeldung bestätigen:

   Rollenzuordnungen erfolgreich verändert

Außerdem kann durch Kombination von verschiedenen Excel-Dateien auch iterativ vorgegangen werden. Als erstes eine Datei für die Rollenzuweisung und diese im Verarbeitungsmodus A (= Hinzufügen) hochladen. Anschließend eine zweite Datei für den Entzug obsoleter Rollenzuweisungen im Verarbeitungsmodus D (= Löschen) hochladen. Alternativ erarbeiten Sie direkt den finalen Stand der gewünschten Rollenzuweisung. Dann benötigen Sie nur eine Datei und laden diese im Verarbeitungsmodus R (= Ersetzen) hoch.

Einführung in die XAMS Features

Welche Erfahrungen haben Sie bisher mit Fleißarbeiten im Tagesgeschäft gemacht? In der XAMS sind noch viele weitere Funktionen verborgen, die Ihnen den Alltag in der SAP Administration erleichtern können. Ich freue mich auf Ihre Kommentare direkt unterhalb dieses Beitrag!

XAMS Starter Workshop

Fachbereichsleiter Luca Cremer

Wir zeigen Ihnen die Software-Suite XAMS und dessen Mehrwert in unserem XAMS Starter Workshop

Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.9462 8572-25 oder per E-Mail cremer@rz10.de.

Interessant? Mehr auf rz10.de - alles zu SAP Basis & Security.

Die Pflege von SU24 Vorschlagswerten ist sinnvoll, ja! Aber was passiert eigentlich, wenn Sie zu einer Transaktion S_TCODE als Vorschlagswert pflegen?

Wozu eigentlich SU24 Vorschlagswerte?

Als Berechtigungsadministrator kennen Sie das Problem: Ein User gibt Ihnen Bescheid, dass er Zugriff auf die MM03 benötigt. Sie fügen den  S_TCODE MM03 in die Rolle ein. Vermutlich fehlen aber weitere, zugehörige Berechtigungsobjekte. Da kommen die SU24 Vorschlagswerte ins Spiel. Durch Pflege der SU24 Vorschlagswerte zu einer Transaktion, werden automatisch zugehörige Berechtigungsobjekte in eine Rolle eingefügt. Sie sparen sich jede Menge Arbeit. Eine detaillierte Beschreibung gibt es auch im Blogbeitrag meines Kollegen Tobias Harmes.

Beispielhafte SU24 Vorschlagswerte zu MM03

S_TCODE als SU24 Vorschlagswert?

Zu jeder Transaktion könnte jedes Berechtigungsobjekt als SU24 Vorschlagswert zugewiesen werden. Teilweise schlägt auch SAP vor, S_TCODE als Vorschlagswert zu einer Transaktion zu pflegen. Dies kann beispielsweise sinnvoll sein, wenn aus einer Transaktion regelmäßig in eine andere Transaktion abgesprungen wird. Eigentlich total praktisch. Schließlich werden die passenden Transaktionen dann automatisch in die Rolle gezogen. Oder etwa nicht?

S_TCODE als SU24 Vorschlagswert hebelt die SU24 Vorschlagswerte aus!

Allerdings passiert dann folgendes: Wenn ich eine Transaktion in eine Rolle hinzufüge, werden automatisch passende Berechtigungsobjekte in die Rolle gezogen. Wenn eines dieser Berechtigungsobjekte S_TCODE ist, dann werden weitere Transaktionen als Werte in S_TCODE gezogen. Das Problem: Für diese Transaktionen werden keine SU24 Vorschlagswerte gezogen! Die SU24 hebelt sich gewissermaßen selbst aus.

Strategieworkshop SAP Berechtigungen

Fachbereichsleiter Luca Cremer

Wir schauen gemeinsam mit Ihnen in Ihr System und vermitteln unsere Best Practices zu SAP Berechtigungen in unserem Strategieworkshop SAP Berechtigungen

Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.9462 8572-25 oder per E-Mail cremer@rz10.de.

Also S_TCODE nie als Vorschlagswert vergeben?

Klares Jein. So Pauschal würde ich das nicht sagen. Es kann ja schließlich bei bekannten Absprüngen in andere Transaktionen sinnvoll sein, diese Transaktionen direkt mit zu berechtigen. In diesem Fall empfehle ich aber die Transaktion nochmal über das Rollenmenü hinzuzufügen. Hierdurch werden dann auch die zugehörigen Berechtigungsobjekte als Vorschlag gezogen.

Welche Erfahrungen haben Sie mit SU24 Vorschlagswerten? Wo haben Sie vielleicht ähnliche, problematische Konstellationen festgestellt?
Ich freue mich über Ihre Kommentare, Anmerkungen und Fragen direkt unterhalb dieses Beitrags!

Interessant? Mehr auf rz10.de - alles zu SAP Basis & Security.

Ein skalierbares Berechtigungskonzept macht Ihre Prozesse rund um Berechtigungs- und Useradministration zukunftsfähig. Doch warum eigentlich und was macht ein Berechtigungskonzept skalierbar?

Langfristig geplant, statt kurzzeitig gelöst

“Der gute Vorsatz ist ein Gaul, der oft gesattelt, aber selten geritten wird.”. Ein, wie ich finde, sehr passendes Zitat in Hinblick auf Berechtigungskonzepte. Denn häufig gehen einem neuen Berechtigungskonzept viele gute Ideen und Vorsätze voraus. Leider bleibt es häufig dabei. Es werden dann schnelle Lösungen gesucht, um die Revision zu beruhigen. Statt das Berechtigungskonzept skalierbar und langfristig auszulegen. Doch wann ist ein Berechtigungskonzept eigentlich skalierbar?

Ein Projekt, viele Empfänger

Um ein Berechtigungskonzept skalierbar zu gestalten, sollten Sie von Anfang an das große Ganze im Blick behalten.
Wie viele User sind wirklich im Scope?
Welche Standorte werden in naher Zukunft ebenfalls von neuen Anforderungen an die Berechtigungen betroffen sein?
Welche Gemeinsamkeiten gibt es an verschiedenen Standorten hinsichtlich Funktionsrollen?

Die Skalierbarkeit eines Berechtigungskonzepts ist dann erreicht, wenn Sie große Teile bestehender Funktionsrollen einfach auf verschiedene Standorte ausrollen können. Im besten Fall müssen Sie sogar nur die Ausprägungen der OrgEinheiten anpassen. Statt einzelne Funktionen wieder und wieder für verschiedene Standorte anzulegen, fokussieren Sie sich auf die Gemeinsamkeiten. Der initiale Aufwand steigt entsprechend an. Im Umkehrschluss erreichen Sie mit einem Projekt allerdings viel mehr Empfänger.

Skalierbares Berechtigungskonzept ausrollen

Für die Erarbeitung eines skalierbaren Berechtigungskonzeptes empfehle ich zunächst den Blick aufs Organigramm. Sie sollten sich von vorne herein klar machen, welche Fachbereiche/Abteilungen/Teams Sie in den einzelnen Standorten haben. Denken Sie in standortübergreifenden Funktionen. Gruppieren Sie sinnvoll:

• Abteilungen und Fachbereiche an jedem Standort
• Gemeinsame Funktionen in allen Fachbereichen
• Transaktionen, die auch standortübergreifend in den gleichen Funktionen verwendet werden

Um all diese Informationen auf einen Blick zu bekommen, empfehlen wir ihnen bspw. den Role Designer der XAMS. Über den Role Designer können Sie die Transaktionsnutzung für eine Vielzahl von Usern übersichtlich auswerten, gruppieren und mit Meta-Tags vorgruppieren. Außerdem stehen zahlreiche Berichte zur Verfügung, die auch komplexe Sachverhalte auf Knopfdruck herausstellen. Die folgenden beispielhaften Berichte eigenen sich ganz speziell für eine Konzeptionierung des skalierbaren Berechtigungskonzeptes:

• Analyse passender Rollen für Benutzer
• User die Tcode x nutzten, nutzen auch
• Analyse Abdeckung der Benutzertracedaten

Skalierbares Berechtigungskonzept toolgestützt ausrollen

Mit der entsprechenden Vorarbeit kann Sie der Role Designer über den gesamten Projektverlauf begleiten. Ein skalierbares Berechtigungskonzept ausrollen wird über Xiting Times zusätzlich abgesichert. Durch die Simulationsphase können sie produktiv testen, ob die neuen Funktionsrollen auf die vorgesehen User passen. Und auch beim Go-Live schützt der Protected Go-Live vor bösen Überraschungen. Gerade bei umfassenden Berechtigungskonzepten wahrt die XAMS in allen Phasen die Übersicht.

Strategieworkshop SAP Berechtigungen

Fachbereichsleiter Luca Cremer

Wir schauen gemeinsam mit Ihnen in Ihr System und vermitteln unsere Best Practices zu SAP Berechtigungen in unserem Strategieworkshop SAP Berechtigungen

Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.9462 8572-25 oder per E-Mail cremer@rz10.de.

Welche Erfahrungen und Herausforderungen haben Sie beim Ausrollen ihres Berechtigungskonzeptes gehabt?
Falls Sie gerne weiterführende Informationen erhalten möchten, nutzen Sie gerne das Kontaktformular oder die Kommentarfunktion gleich unterhalb dieser Zeilen.

Interessant? Mehr auf RZ10.

Der Wirtschaftsprüfer war da und Sie planen ein SAP Berechtigungsprojekt? Um Ihnen die Planung des Projektes zu vereinfachen, erläutere ich einen typischen Projektverlauf und die einzelnen Projektphasen.

SAP Berechtigungsprojekt in 6 Monaten (Beispielhafter Projektverlauf)

Zunächst zeigt das folgende Schaubild die typischen Projektphasen im Überblick. Das Ziel des beispielhaften Projektes ist ein Redesign der SAP Berechtigungen für mehrere Bereiche eines Unternehmens. Im Anschluss an das Schaubild werden die einzelnen Phasen erläutert.

Der Projektstart

Zu Beginn eines SAP Berechtigungsprojektes sollte eine Bestandsaufnahme stehen. Wir prüfen gemeinsam, welche bestehenden Berechtigungskonzepte bereits umgesetzt werden. Häufig stoßen wir auf bestehende, kleinere Konzepte. Allerdings werden diese zunächst gar nicht als solche angesehen. Typische Beispiele sind bestimmte Abgrenzungen für Dokumente oder Kostenstellen. Die Summe der einzelnen Konzepte vereinen wir in einem übergreifenden Berechtigungskonzept.

Bereits zu Beginn dieser Phase sollte der Projekt-Scope festehen. Welche Fachbereiche bzw. Business-Bereiche sollen betrachtet werden? Wie viele SAP User sind betroffen? Wie lassen sich die Bereiche abgrenzen? Durch diese Fragestellungen wird deutlich, dass der Fachbereich von Anfang an ins Projekt involviert werden sollte. Ein SAP Berechtigungsprojekt ist eine gute Möglichkeit, die Verantwortung wieder stärker ins Business zu bringen. Es bietet sich an, eine gemeinsame Informationsveranstaltung für alle Stakeholder durchzuführen.

Konzeption der Funktionen bzw. Funktionsrollen

In dieser Phase steht der Projekt-Scope. Basierend auf den Erkenntnissen der ersten Phase, gruppieren wir User zu Funktionen. Hierfür ist die Zuarbeit der Fachbereiche notwendig. Wir erarbeiten gemeinsam die Datengrundlage für die kommende Projektphase:

• User im Fachbereich
• Funktionen im Fachbereich
• Welche User haben welche Funktion(en) im Fachbereich bzw. fachbereichsübergreifend?

Auf Basis dieser Informationen können wir erste Vorschläge für Funktionsrollen entwickeln.

SAP Berechtigungsprojekt: Workshops mit den Fachbereichen

Spätestens in dieser Phase wird die zukünftige Verantwortung der Fachbereiche deutlich. Wir setzen uns in einem Workshop mit Ansprechpartnern aus den Fachbereichen zusammen. Im Rahmen des Workshops erstellen wir den ersten Entwurf der Berechtigungsrollen. Wir analysieren die tatsächliche Nutzung von SAP Transaktionen. Jede SAP Transaktion ordnen wir dann den neuen Berechtigungsrollen zu. Keine Sorge: Ein Rückschluss auf die Produktivität einzelner User ist dadurch nicht möglich!

Am Ende des Workshops stehen neue SAP Berechtigungsrollen. Diese spiegeln die Nutzung von SAP Transaktionen in den jeweiligen Funktionen des Fachbereiches wider. Zu diesem Zeitpunkt sind die Berechtigungsrollen noch nicht zum produktiven Einsatz geeignet. Bisher befinden sich in den SAP Rollen einzig SAP Transaktionen. Zugehörige und ebenfalls benötigte Berechtigungsobjekte fehlen und sind in der Regel Informationen, die nicht aus dem Fachbereich kommen können.

Iterative Entwicklung der neuen Berechtigungsrollen

In dieser Phase geht es um die technische Umsetzung. Wir tracen die neuen Berechtigungsrollen im Hintergrund des Produktivsystems. Hierdurch finden wir iterativ die notwendigen Berechtigungsobjekte. Parallel nutzen wir die Ergebnisse, um Ihre SU24 Vorschlagswerte zu pflegen. Während dieser circa 3 Monate langen Phase entwickeln wir die vollständige Ausprägung der neuen Berechtigungsrollen. Der Vorteil unseres Vorgehens liegt auf der Hand. Es sind keinerlei aufwändige Tests mit Usern notwendig.

Mit Abschluss dieser Phase sind die neuen Berechtigungsrollen bereit für den Go-Live. Das SAP Berechtigungsprojekt geht in die heiße Phase.

Go-Live und Hyper-Care-Phase

Auch beim Go-Live kann iterativ vorgegangen werden. Sukzessive setzen wir die einzelnen Fachbereiche mit den neuen Berechtigungsrollen produktiv. Das Besondere an unserem Vorgehen: Sollte es während des Go-Live doch zu Berechtigungsfehlern kommen, können binnen Sekunden die alten Berechtigungen reaktiviert werden. Die Produktion wird im kleinst möglichen Ausmaß gestört. Während des Go-Live stehen wir weiterhin zur Verfügung und übernehmen bspw. die Lösung möglicher Störungen.

SAP Berechtigungsprojekt: Der Projektabschluss

Nach circa 6 Monaten ist das Projekt abgeschlossen. Im Rahmen des Projektabschlusses übergeben wir die neuen Berechtigungsrollen in den Tagesbetrieb. Gemeinsam erarbeiten wir Maßnahmen, um sicherzustellen, dass die neuen Berechtigungsrollen in Zukunft nicht verwässern.

Strategieworkshop SAP Berechtigungen

Fachbereichsleiter Luca Cremer

Wir schauen gemeinsam mit Ihnen in Ihr System und vermitteln unsere Best Practices zu SAP Berechtigungen in unserem Strategieworkshop SAP Berechtigungen

Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.9462 8572-25 oder per E-Mail cremer@rz10.de.

Sie planen aktuell ein SAP Berechtigungsprojekt? Melden Sie sich gerne bei uns und wir prüfen gemeinsam, inwiefern die oben beschriebenen Phasen auch zu Ihrem Zeitplan passen.

E-Book SAP Berechtigungskonzept

Wozu ein Berechtigungskonzept? Welche Elemente enthält es idealerweise & welche Tools erleichtern das Berechtigungsdesign?

Interessant? Mehr auf RZ10.

Letztens habe ich gemeinsam mit meinem Kunden geprüft, wie wir ein Berechtigungsfeld zur Orgebene erheben können. Dabei sind wir auf die Transaktion SUPO gestoßen. Welche Tücken und Herausforderungen diese Transaktion mit sich bringt, erkläre ich in diesem Beitrag.

Wie funktioniert das mit der Orgebene eigentlich?

Standardmäßig sind in SAP nur bestimmte Berechtigungsfelder als Orgeben deklariert. Dazu zählen beispielsweise die Berechtigungsfelder Buchungskreis (BUKRS) oder Einkaufsorganisation (EKORG). Durch das Erheben zur Orgebene können wir beeinflussen, dass ein Berechtigungsfeld innerhalb einer Rolle in jedem Berechtigungsobjekt gleich vergeben wird. Natürlich nur in solchen Objekten, in denen das Feld überhaupt vorhanden ist.

Eigentlich hat jeder SAP Administrator zumindest einmal gehört, dass auch eigene Berechtigungsfelder zur Orgebene erhoben werden können. Wenn es um die Umsetzung geht, stößt man jedoch erstmal auf Hürden.

Von SAP publizierte Reports zur Erhebung zur Orgebene sind obsolet

Bei der Recherche zum Vorgehen stoße ich zunächst auf die folgenden Reports:

PFCG_ORGFIELD_CREATE
PFCG_ORGFIELD_DELETE
PFCG_ORGFIELD_UPGRADE

Beim Starten der Reports erscheint aber unmittelbar die Fehlermeldung “Report PFCG_ORGFIELD* is obsolete”. Weitere Informationen gibt es aus der Fehlermeldung zunächst nicht.
Die Funktion dieser Reports wird in folgender SAP Note beschrieben: 323817 – Anlegen von Orgebenenfeldern für den Profilgenerator

Relativ präsent steht darin: “Achtung: Die Beschreibung der Funktionalität der Reports in diesem Hinweis ist obsolete. Nutzen Sie stattdessen die Zusatzinformationen im Hinweis 727536 (727536 – FAQ | Nutzung kundeneigener Organisationsebenen in der PFCG). Achten Sie insbesondere darauf, die aktuelle Korrekturversion der jeweiligen Reports zu nutzen.”

Erheben zur Orgebene mit Transaktion SUPO

Aus der SAP Note 727536 geht wiederum hervor, dass ab SAP Version SAP_BASIS 7.50 Supportpackage 09 die Transaktion SUPO für die Pflege kundeneigener Orgebenen genutzt werden soll.
Die Funktionsweise für die Transaktion ist in SAP Note 2535602 – SUPO | Dokumentation und Transportanschluss für OrgEbenenpflege beschrieben.

Wer sich entscheidet diese Transaktion aufzurufen, fühlt sich ein wenig wie der erste Mensch auf dem Mond und es wirkt auch ähnlich gefährlich. Statt den gewohnten Funktionsknöpfen arbeiten wir uns rudimentär mit OK-Kommandos durch die Funktion der Transaktion. Wie das funktioniert, schauen wir uns jetzt einmal an.

SUPO: Ein Berechtigungsfeld zur Orgebene erheben

Achtung! Bevor Sie sich jetzt entscheiden die aufgeführten Schritte mitzuklicken: Es gibt keinen einfachen Weg zurück. Außerdem können die Auswirkungen unvorhersehbar sein. Eine Testlauf-Funktion gibt es nicht!

Sobald die Transaktion SUPO aufgerufen wurde, sehen wir zunächst eine Tabelle mit allen aktuell definierten Orgebenen:

Um in den Bearbeitungsmodus zu wechseln, drücken wir wie gewohnt auf das Brille-und-Stift-Icon. Es ändert sich nur die Darstellung der Tabelle:

Sie werden nun feststellen, dass es keine Buttons wie “Neu anlegen” oder “Löschen” gibt. Diese sind nicht implementiert. Stattdessen arbeiten wir mit OK-Kommandos, die wir oben in das Transaktionsfeld eingeben. Laut SAP-Note stehen nur die folgenden OK-Kommandos zur Verfügung.

Orgebene hinzufügen (bzw. neue Zeile in Tabelle hinzufügen): =CREA_OLVL

Orgebene löschen (bzw. Zeile aus Tabelle löschen): =DELE_OLVL

Nachdem wir bspw. das Kommando “=CREA_OLVL” eingegeben haben, wird eine neue Zeile in der Tabelle eingefügt. In dieser Zeile können wir nun das gewünschte Berechtigungsfeld pflegen.

Nachdem die neue Zeile mit dem gewünschten Berechtigungsfeld gefüllt wurde, drücken wir auf “Speichern”. Es erfolgt die Abfrage eines Transportauftrages. Wenn der Transportauftrag erfasst wurde, ist das Erheben des Berechtigungsfeldes tatsächlich abgeschlossen. Damit sich die Transaktion aktualisiert, muss diese nur erneut aufgerufen werden. Nach der Aktualisierung werden auch die Spalten der neuen Berechtigungsfeldes aktualisiert. Es wird bspw. angezeigt:

• Spalte “Org. Level in Roles”: Maintain status des Feldes in Berechtigungsrollen des Mandanten (gelbes Dreieck = Nacharbeit notwendig!)
• Spalte “Objects”: Anzahl der Berechtigungsobjekte, die das Berechtigungsfeld im Bauch haben

Durch einen Klick auf das gelbe Dreieck in der Spalte “Org. Level in Roles” erfolgt ein Absprung in einer andere Sicht. In dieser Sicht sind alle Rollen aufgeführt, die durch das Erheben zur Orgebene betroffen sind:

Auswirkungen des Erhebens zur Orgebene

Bei bestehenden Rollen, in denen das Berechtigungsfeld zuvor bereits befüllt war, passiert zunächst gar nichts. Die Rolle funktioniert weiterhin. Die Werte des Berechtigungsfeldes werden nicht überschrieben. Allerdings erhält der Tab “Organizational levels…” natürlich eine entsprechende Zeile:

Wenn darüber nun ein neuer Wert gepflegt wird, werden zunächst nur die Berechtigungsfelder gepflegt, die zuvor leer waren. Die anderen Werte bleiben bestehen. Hierdurch ergeben sich schnell zahlreiche Inkonsistenzen. Inkonsistenzen, die wir durch Verwendung von Orgebenen eigentlich verhindern wollen. Die zuvor befüllten Feld-Instanzen werden also wie manuell gepflegte Orgebenen behandelt. Sie sind von der Funktion des Button “Organizational levels…” entkoppelt.

Um diese “manuell” gepflegten Felder pro Rolle zu bereinigen, empfiehlt die SAP den Report AGR_RESET_ORG_LEVELS.

Kein Weg zurück – Orgebene bleibt Orgebene

Bei meinen Tests der Funktion bin ich auch darauf gestoßen, dass das OK-Kommando “=DELE_OLVL” nicht funktioniert. Um eine kundeneigene Orgebene zurückzusetzen, wird von SAP der Report PFCG_ORGFIELD_DELETE empfohlen. Leider ist dieser Report obsolet. Das manuelle Löschen aus den zugrunde liegenden Tabellen kann ich ebenfalls nicht empfehlen. Somit habe ich in meinem Versuch keine Möglichkeit gefunden, die Orgebene wieder runterzustufen.

Allerdings gibt es in der SAP Note 2535602 – SUPO | Dokumentation und Transportanschluss für OrgEbenenpflege folgenden Hinweis:

“Symptom: Sie nutzen die Transaktion SUPO, um OrgEbenen zu ändern. Dabei stört sie folgendes Verhalten:
Die Funktion “OrgEbene Löschen” funktioniert nicht.”

“Lösung: Implementieren Sie die beigefügte Korrektur per SNOTE oder über das referenzierte Support Package.”

Eventuell lässt sich damit die Löschfunktion reparieren.

Fazit: Mit großer Vorsicht zu genießen!

Insgesamt hat mir der Ausflug in die Transaktion SUPO weniger gut gefallen. Allein durch die Verwendung von OK-Kommandos schreit die Transaktion förmlich: “Pass auf, was Du tust!”. Außerdem kann ich nur dringend davon abraten, spontan das Berechtigungsfeld RESPAREA zur Orgebene zu erheben. Bei meinem Versuch hat dies zunächst zu irreparablen Schäden in der Tabelle KBEROBJ geführt. Hier ist dann wiederum Nacharbeit mit den folgenden beiden SAP Notes notwendig: 698401 – RESPAREA als Org.ebenen-Feld und 565436 – PFCG: F4-Hilfe für spezielle Berechtigungsfelder.

Aber für genau solche Fälle haben wir ja die RZ10 Security Community: Welche Erfahrungen haben Sie mit kundeneigenen Orgebenen gemacht? Welche weiteren Erfahrungswerte haben Sie zum Umgang mit der SUPO? Ich freue mich auf Ihre Kommentare!

Interessant? Mehr auf RZ10.

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.

E-Book SAP Basis

Mehr als 100 ausgewählte SAP Basis Fachartikel von rz10.de seit 2011! Auf über 800 Seiten Tipps, Tricks und Tutorials mit Screenshots aus echten SAP-Systemen.

Jetzt anfordern

E-Book SAP Basis

×

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.

Fazit

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!

Interessant? Mehr auf RZ10.

Sie wollen herausfinden, wer einen Transport in ein SAP System durchgeführt hat? Über diesen Umweg können Sie den Transporteur eines SAP Transports ermitteln.

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.

E-Book SAP Basis

Mehr als 100 ausgewählte SAP Basis Fachartikel von rz10.de seit 2011! Auf über 800 Seiten Tipps, Tricks und Tutorials mit Screenshots aus echten SAP-Systemen.

Jetzt anfordern

E-Book SAP Basis

×

Transporteur eines SAP Transports 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.

Interessant? Mehr auf RZ10.

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.

E-Book SAP GRC

Roadmap zur Einführung Ihrer individuellen SAP GRC-Lösung - warum GRC mehr als nur lästige Pflicht ist.

Jetzt anfordern

E-Book SAP GRC

×

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!

Interessant? Mehr auf RZ10.

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.

E-Book SAP Basis

Mehr als 100 ausgewählte SAP Basis Fachartikel von rz10.de seit 2011! Auf über 800 Seiten Tipps, Tricks und Tutorials mit Screenshots aus echten SAP-Systemen.

Jetzt anfordern

E-Book SAP Basis

×

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!

Interessant? Mehr auf RZ10.

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

E-Book SAP Basis

Mehr als 100 ausgewählte SAP Basis Fachartikel von rz10.de seit 2011! Auf über 800 Seiten Tipps, Tricks und Tutorials mit Screenshots aus echten SAP-Systemen.

Jetzt anfordern

E-Book SAP Basis

×

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!

Interessant? Mehr auf RZ10.

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 *.

E-Book SAP Berechtigungskonzept

Wozu ein Berechtigungskonzept? Welche Elemente enthält es idealerweise und welche Tools erleichtern das Berechtigungsdesign?

Jetzt anfordern

E-Book SAP Berechtigungskonzept

×

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

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

Interessant? Mehr auf RZ10.

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!

Interessant? Mehr auf RZ10.

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.

Tabelle: Standardtabellen der Benutzer- und Berechtigungsverwaltung

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

Jetzt anfordern

Tabelle: Standardtabellen der Benutzer- und Berechtigungsverwaltung

×

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:

E-Book Fachartikel SAP Basis und Security

Das Kompendium SAP Basis und Security beinhaltet nützliche Tipps, Tricks und Tutorials mit Screenshots aus echten SAP-Systemen.

Jetzt anfordern

E-Book Fachartikel SAP Basis und Security

×

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.

Sie benötigen Unterstützung bei der Umsetzung? Unser Autor Dominik Busse ist Berater für dieses Thema. Fragen Sie ihn an über das RZ10.de Partnerprodukt Berater für SAP Berechtigungen und Security

Interessant? Mehr auf RZ10.