Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Granting administration privileges

Administration privileges in applications with user IDs

In applications with user IDs, transaction codes for authorization level 2 can only be called under user IDs and partner applications to which administration privileges were assigned when they were entered in the configuration. User IDs and partner applications that are to administer the local application must be generated as follows:

USER ADMUS,[PASS=C'.....',PROTECT-PW=(...,....,...)], PERMIT=ADMIN.....
LPAP ADMPA,SESCHA=...,PERMIT=ADMIN....
OSI-LPAP ADMPAO,ASS-NAMES=...,CONTWIN=...,PERMIT=ADMIN....

Administration functions can also be carried out via an OSI TP partner application, if the OSI-LPAP does not have administration privileges. The application context of the OSI-LPAP must contain the abstract syntax UTMSEC in this case, and the partner has to pass on a user ID that has administration authorization in the local application.

User IDs with administration privileges can also be dynamically linked into the application configuration.

Applications without user IDs

In applications which do not have user IDs, any user or client that is connected to the application via an LTERM partner can execute administration commands and other administration TACs. Data access protection for these services can then only be implemented by means of the lock/key code and access list concept. To do so you will need to protect the administration commands with a lock code or an access list, and then only allocate a key set with a suitable key code to clients and terminals (LTERM partners) via which it should be possible to administer applications. Even in applications without user IDs, partner application can only execute administration functions with authorization level 2 if they were generated with PERMIT=ADMIN.