Every SAP user — the finance clerk posting invoices, the background job closing the month, the RFC connection pulling orders from a webshop — starts life in the same place: transaction SU01. It's the user master record, and getting it wrong is one of the quietest ways to create a security mess. This post walks through what SU01 actually maintains and the five user types, because picking the wrong type is a mistake that shows up in audits again and again.
What SU01 maintains
Think of SU01 as the HR file for a user ID. It doesn't hold authorizations directly — that's PFCG's job — but it holds everything the system needs to know about who is logging on.
The record is split across tabs. The Address tab is self-explanatory. Logon data is where the important stuff lives: the user type, the initial password, and the validity period. Defaults holds the logon language, date format, and decimal notation. Parameters stores SAP GUI parameter IDs (like a default company code). And the Roles and Profiles tabs are where you attach what the user is allowed to do.
Two related transactions are worth knowing. SU01D displays a user without any change authorization — handy when you need to look but must not touch. SU10 does the same job as SU01 but for many users at once, which you'll appreciate the first time someone asks you to lock 400 accounts before a go-live.
The five user types
This is the part that matters most. SAP has five user types, and each one changes how the system treats the account.
Dialog (A) is the normal, everyday user. A person sits at a screen, types a password, and works interactively. Most of your user base is type A. Dialog users can change their own password, and they're subject to the usual password rules.
System (B) is for background processing and internal RFC calls. A system user cannot log on through SAP GUI at all — the dialog logon is technically blocked. This is exactly what you want for the account that runs your nightly batch jobs or the technical user behind an interface. If that account's password ever leaks, nobody can sit down at a screen and use it interactively.
Communication (C) covers external RFC and CPIC calls — think third-party tools or web services calling into SAP. Like system users, communication users can't do a dialog logon. The password rules are also relaxed for them, since a human never types the password; it's stored in a destination or connector configuration.
Service (D) is the odd one. It's a dialog user shared by many anonymous people — the classic example is a training account or a kiosk in a warehouse where whoever walks up uses the same ID. Service users all share one initial password that never expires, which is precisely why auditors hate finding them in production with real authorizations.
Reference (L) can't log on at all, ever. It exists purely as a template: you attach roles to a reference user, then point real users at it so they inherit those roles automatically. It's a neat way to give an entire department the same baseline authorizations without assigning roles one by one.
Key takeaway: Dialog (A) is for people at screens. System (B) and Communication (C) are for technical accounts that must never log on interactively. Service (D) is shared and risky. Reference (L) is a template, not a real user.
Creating a dialog user: the practical steps
In SU01, enter a new user ID and choose Create. On the Address tab, fill in at least the last name — the system won't save without it. On the Logon data tab, set the user type to Dialog, assign an initial password, and — this is the step people skip — set a validity period. A user with no end date lives forever, including after the employee leaves.
Switch to the Roles tab and add the PFCG roles the user needs. Save. The user still can't do anything useful until a user comparison runs (transaction PFUD), which writes the role's generated profile into the user master. In most systems this runs as a scheduled background job, so new authorizations can take a while to kick in — a common source of "I just gave them the role, why can't they post?" tickets.
Common mistakes to avoid
The classic error is creating a dialog user for a background job "because it was easier to test with." That account can now log on interactively, bypassing every control you thought you had. Batch and interface accounts should always be type B or C.
Another is leaving the validity period blank. Tie it to the employment contract or the project end date wherever you can. And never, ever hand out SAP_ALL or SAP_NEW through SU01's Profiles tab directly — profiles assigned there bypass role maintenance entirely, which means nobody reviewing roles in PFCG will see them.
Get SU01 right and the rest of SAP security — roles, authorizations, audits — sits on a solid foundation. Get it wrong, and you're building on sand.