Massensperren von Usern mit SECPOL
Autor: Tobias Harmes | 8. Mai 2019
Bei komplexen Updates oder Wartungen in SAP-Systemen kann es notwendig sein, dass eine große Anzahl an Usern kurzfristig gesperrt werden muss. Wie das mit der Nutzung der Security Policy funktionieren kann, erklärt dieser Beitrag.
Die Ausgangslage
Bei einer Wartung sind von der Sperre lediglich Admins und einige technische User ausgenommen. Nach der Wartung und der vorübergehenden Sperrung können die User wieder entsperrt werden. Dabei ist wichtig, dass Nutzer, die vor der Wartung schon gesperrt wurden – zum Beispiel durch Adminsperren – nicht wieder automatisch freigeschaltet werden. Wie das gelingen kann, ist auf verschiedenen Wegen möglich. In einem manuellen Prozess über SU10 funktioniert das, wenn man aktive Benutzer zuerst identifiziert und diese Liste dann um die Admins zum Sperren reduziert. Der zeitliche Aufwand ist je nach Sauberkeit der Daten überschaubar. Durch die manuelle Handhabung kann es allerdings unter Zeitdruck schnell zu Fehlern kommen. Wie kann man diesen Prozess also automatisieren?
Neues SAP Berechtigungskonzept vom führenden SAP-Security Berater
Wir helfen SAP Kunden, ein neues Berechtigungskonzept einzuführen, dass den Prüfer zufriedenstellt und im Betrieb reibungslos funktioniert.
Hilfe durch die Security Policy
Ab SAP_BASIS Release 7.31 kann über eine Kombination aus Profil-Parameter und Security Policy gesteuert werden, ob sich ein User anmelden kann oder nicht. Alle Admins, die einen bestimmten Wert in der ihnen zugeordneten Sicherheitsrichtlinie haben, können sich dann anmelden, alle anderen User nicht. Wiederholbar und ohne ständiges Ermitteln der relevanten User.
Schritt 1: Aufnehmen des Anmelde-Attributs in der Sicherheitsrichtlinie SECPOL
Für die Erstellung bzw. die Änderung der Sicherheitslinie, kann die Transaktion SECPOL genutzt werden. Nehmen Sie dafür das Richtlinienattribut „SERVER_LOGON_PRIVILEGE“ in die Sicherheitsrichtlinie auf und setzen den Wert auf „1“.
Schritt 2: Setzen des Profilparameters
Die Anmeldung von Benutzern kann durch das Setzen des Profilparameters „login/server_logon_restriction“ eingeschränkt werden.
Dabei werden drei Werte vergeben:
- Wert = “0“: Keine Einschränkungen. Alle Benutzer können sich am Anwendungsserver anmelden.
- Wert = „1“: Anmeldung am Anwendungsserver nur noch mit Sonderrecht erlaubt. Es können sich nur die Benutzer anmelden, deren zugeordnete Sicherheitslinie das neue Attribut „SERVER_LOGON_PRIVILEGE“ mit dem Wert „1“ enthält.
- Wert = „2“: Keine Anmeldung am Anwendungsserver erlaubt. Benutzer, die sich mit diesem Wert am System anmelden, erhalten die Meldung: „Server ist zurzeit nicht verfügbar“. Eine Anmeldung ist dann nicht erlaubt.
Schritt 3: Zuordnung der Policy zum Admin
Zum Schluss kann dann noch über die SU01 den ausgewählten Admins die entsprechende Security Policy zugeordnet werden.
Benutzer mit diesem Wert erhalten bei der Anmeldung am Server die Fehlermeldung: „Server ist zurzeit nicht allgemein verfügbar“. Eine Anmeldung ist dann eingeschränkt möglich.
Anmerkungen
Das Einstellen des dynamischen Profilparameters meldet die Benutzer am Anwendungsserver nicht automatisch ab. Um die Werte dauerhaft zu speichern, kann die Transaktion RZ10 verwendet werden. Im Benutzerinformationssystem kann festgestellt werden, welchen Benutzer eine Sicherheitslinie oder ein Richtlinienattribut zugewiesen ist. Dazu kann die Transaktion SUIM genutzt werden.
Für den Notfallbenutzer SAP* gilt, dass während einer laufenden Aktivierung die Anmeldung am System immer möglich ist. Das funktioniert allerdings nur, wenn der Profilparameter „login/no_automatic_user_sapstar“ auf den Wert „0“ gesetzt ist und der Benutzer SAP* in der SU01 nicht angelegt ist. (Keine Empfehlung für die Produktion ? )
Und: Eine Security Policy übersteuert die allgemeinen System-Profilparameter für den jeweiligen Benutzer. Egal ob entsprechende Policy-Werte gepflegt worden sind oder nicht. Es könnte also sein, dass ein Admin mit einer unvollständigen Security Policy auf die Policy-Default-Werte in einigen Bereichen wie Passwortlänge, etc. zurückfällt.
How to do it NOT
Ich habe bei Unternehmen auch weitere Möglichkeiten kennengelernt, um das oben genannte Problem anzugehen. Eine Möglichkeit wäre ein SQL-Skript zu schreiben, das die Werte für die Rollen zuteilt. Direkte Datenbank-Änderungen sind zum einen ohne Netz und doppelten Boden und zum anderen aus Compliance-Sicht schwer nachvollziehbar. Daher würde ich hier klar abraten. Eine andere Möglichkeit wäre die Logongruppe (SMLG) entsprechend zu pflegen und die Einträge, die bei den Usern im SAP GUI hinterlegt sind, kurzfristig zu löschen. Ein großer Nachteil hierbei ist aber, dass einige Schnittstellensysteme direkt auf die Applikationsserver gehen und es Benutzer gibt, die ihr SAP GUI selbst pflegen und den Eintrag dann abändern können.
Weitere Informationen
SAP Hinweis 1891583 – Anmeldung am Anwendungsserver einschränken: https://launchpad.support.sap.com/#/notes/1891583/D
Massensperren von Benutzern via SU10: https://rz10.de/sap-basis/massensperren-von-benutzern-via-su10/
SAP-Passwortregeln: Profilparameter und Security Policies via SECPOL: https://rz10.de/sap-berechtigungen/sap-passwortregeln-profilparameter-und-security-policies-via-secpol/
Update vom 09.05.2019: Hinweis auf Gefahr der ungewollten Übersteuerung der Profilparameter ergänzt.
3 Kommentare zu "Massensperren von Usern mit SECPOL"
Einfacher geht’s mit EWZ5 & EWZ6
War für die EURO-Umstellung gedacht, ist aber heute noch in jedem SAP System, zumindest bis ECC 6.0 mit EHP7 ( SAP NETWEAVER 7.40 )
Hallo.
Danke für den Hinweis. Wenn verfügbar sind diese Transaktionen nützlich, in neueren Releases allerdings nicht mehr vorhanden. Vielleicht könnte man sich ja das Programm EWULKUSR retten 😉
Viele Grüße
Tobias Harmes
Danke für den Tip – Programm EWULKUSR wird gerettet! Wir nutzen unter SAP Basis 7.0 auch noch die ewz5 mangels der neuen Transaktion secpol
VG