SAP Users

Every person (and technical process) needs a user master record to log in. Administrators create these in SU01, set the user type, assign roles (which grant authorizations), manage passwords, and lock/unlock or delete accounts as people join, change roles or leave. This lifecycle is the SAP equivalent of joiner-mover-leaver.

• Dialog: normal interactive users.
• System / Communication: for interfaces and RFC (no interactive logon).
• Service and Reference: for shared or template purposes.

The distinction matters more than it appears. A dialog user can log in interactively and is subject to password rules and expiry. A system user cannot log in at all and is for background processing and interfaces, which is why its password does not expire and why it must never be usable for a dialogue logon. Communication users are for external calls, service users for shared anonymous access, and reference users exist only to carry authorisations that other users inherit.

Getting the type wrong is a security finding rather than an inconvenience: an interface account set up as a dialog user is a credential somebody can log in with.

SU01 creates and maintains a user, SU01D displays one, and SU10 makes the same change across many at once, which is the transaction for a mass role assignment or a mass lock.

SUIM is the user information system, and it is the most useful of the set. It answers who has a transaction, who has an authorisation object with a particular value, which roles contain something, and what changed. Any access review starts here.

SU53 and STAUTHTRACE diagnose failures. SM04 and AL08 show who is logged in now.

The user master itself has tabs worth knowing: Logon data holds the type, the password status and the validity dates, Roles and Profiles hold the access, Parameters hold personal defaults, and Licence data holds the classification that licence measurement reads.

One more worth knowing: SU3 lets a user maintain their own defaults, and the parameters there are genuinely useful. Setting a default company code or plant means a user is not typing it on every screen, and a request to "make it remember my plant" is a parameter rather than a development.

The user record identifies the person; the roles assigned to it (via PFCG) grant what they can do. Keeping this separation clear, and following least privilege, is central to good security.

Twenty minutes, and it covers the controls that matter most.

1. Create a dialog user with SU01. Assign one role.
2. Set a validity end date a few days out. This is the single most useful field for contractors and temporary access, and it is frequently left blank.
3. Log in as that user and run something the role permits, then something it does not. Confirm SU53 shows the second.
4. Change the role in PFCG and generate the profile, then check whether the logged-in session sees the change. It does not, because authorisations are buffered per session.
5. Log out and back in. Now it does.
6. Lock the user, and confirm the roles are still assigned. Locking prevents logon; it does not remove access, which matters when the lock is later lifted.

For scale, SU10 handles mass changes and Central User Administration (CUA) or an IGA tool manages users across many systems. Prompt deactivation of leavers is a key control and audit point.

The question central administration answers is what happens in a landscape of ten systems. Without it, a leaver must be removed ten times, and the one that gets missed is the risk. With it, users and role assignments are maintained in one place and distributed. The alternative in newer landscapes is an identity management product doing the same job across SAP and everything else, which is usually the better answer where the organisation already has one.

Password policy is configured through profile parameters and it is one of the areas where defaults are weaker than most security policies require.

The parameters control minimum length, required character classes, how many previous passwords are remembered, expiry interval, and how many failed attempts lock the account. They are set per system, and a landscape where development has one policy and production another is common and worth checking.

The more significant question is whether passwords are used at all. Single sign-on, usually through Kerberos or SAML, means the user authenticates once against the corporate directory and SAP trusts that. It removes the password from the user's experience entirely, which is better security and better usability at the same time, and it is one of the few changes that is both.

Where single sign-on is in place, the SAP password still exists as a fallback, and leaving it weak because "nobody uses it" is exactly the gap an attacker looks for.

Technical users are the other half of this. Their credentials sit in interface configuration and RFC destinations, they rarely rotate, and they frequently hold wide access. Treating them with the same seriousness as human accounts is unusual and correct.

Every user carries a licence type, and it is maintained on the user master where it is easy to ignore because nothing breaks when it is wrong.

The classification determines what the organisation is billed for, and SAP measures it periodically through a system measurement run. Users classified generously cost money; users left unclassified are usually counted at the most expensive rate by default.

The practical work is keeping classification aligned with what people actually do. Somebody who only approves requests through a mobile app does not need the same licence as a full configuration user, and the difference at scale is substantial.

Two habits keep it honest. Classify at creation, as part of the joiner process, rather than as a cleanup exercise before a measurement. And lock or delete users who left, because an active account is usually counted whether or not anyone has logged into it this year.

Consolidation across systems matters too: one person with accounts in five systems should be counted once, and that only works if the accounts can be matched, which means consistent naming.

• Not deactivating leavers promptly, orphaned accounts.
• Over-assigning roles instead of least privilege.
• Wrong user type (e.g. dialog for an interface account).

• Validity dates left blank for temporary access. The field exists precisely so that access expires without anybody remembering.
• Locking a leaver instead of removing roles. A lock can be lifted; the access is still there.
• Shared accounts. They defeat every audit trail in the system. See client administration and authorisations for the surrounding pieces, and background processing for where system users are used.

• Technical user passwords never rotated. They sit in RFC destinations and interface configuration, they usually hold wide access, and they are treated as infrastructure rather than as credentials.
• Licence type left at the default. It is invisible until a measurement run, and then it is expensive.

Creating a user is trivial, and running the joiner, mover and leaver process across a landscape so access is right and expires is the part you do in the course.

The field worth using more than any other is the validity end date. Contractors, temporary access and anything granted "just for this week" should carry one, because it is the only control that removes access without somebody remembering to.