USR02 table — USR02 user logon and password data table
USR02 stores the authentication-relevant part of a user master record per client: the password hash, hash algorithm version, validity dates, user type, lock indicator, and last logon timestamp. It does not hold roles, profiles, address data, or personal details, which live in separate tables. It is the table to check for lockouts, expired validity, and last-logon evidence, never to edit directly.
USR02 is the client-dependent table behind SU01 that holds a user's logon security attributes rather than its authorizations or personal data. This page covers the fields worth reading during a lockout or password investigation, the joins that connect it to role and address data, and the recurring misreadings that lead consultants to the wrong root cause.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,101 words
What it stores
One row represents the security and logon status of a single user ID within a single client. It carries the password hash and hash algorithm version, the validity window during which the ID is allowed to log on, the lock indicator, the user type (dialog, system, service, communication, reference), and the timestamp of the last successful logon. It is one of several tables that together make up what SU01 displays as a 'user'; it does not carry the person's name, email, role assignments, or authorization profiles, those sit in other tables. A row existing here means an ID was created in that client at some point, not that the ID currently has any access.
Key fields
- MANDT - client
- BNAME - user ID, matches the name shown in SU01
- UFLAG - lock indicator; zero means not locked, nonzero indicates a lock of some kind (administrative, failed-logon, or CUA-imposed)
- GLTGV - validity start date for the user ID
- GLTGB - validity end date for the user ID
- USTYP - user type: A dialog, B system, C communication, L reference, S service
- TRDAT - date of the last successful logon
- LTIME - time of the last successful logon
- CODVN - password hash code version, indicates which hashing procedure was used to store the password
How it joins the data model
- USR02-BNAME = USR01-BNAME to reach general master data such as logon language and output settings
- USR02-BNAME = USR21-BNAME to reach the linked person/address record used for name and email
- USR02-BNAME = AGR_USERS-UNAME to see which roles are currently assigned to the ID and for what validity period
- USR02-BNAME = USR04-BNAME to see legacy direct authorization profile assignments, where still populated
- USR02-MANDT = USR02-MANDT (self-join across clients) when comparing the same BNAME's status in a CUA landscape, since lock and validity are set per client unless centrally managed
How to read it safely
The table is client-dependent; MANDT must always be part of the selection or the result mixes unrelated clients. BNAME is the natural key and gives fast, selective access; a lookup by BNAME plus MANDT returns a single row and is the normal pattern. Selecting on UFLAG, GLTGB, or USTYP alone across the whole table is a full scan and is expensive on systems with a large user population, especially in a central user administration landscape where the same BNAME repeats per client. Restrict by BNAME first whenever the investigation is about one person; only scan broadly for a proactive audit, and do that with a report, not ad hoc table display.
How to prove it in the data
Symptom: a user reports being locked out. Select USR02 with MANDT = the client and BNAME = the user ID. Check UFLAG first: zero means not locked by this table's own logic, so the block is coming from CUA, a Fiori/gateway layer, or a network-level restriction, not this ID's local status. A nonzero UFLAG confirms a lock exists here; cross-check GLTGB, since a validity date in the past produces the same denied-logon symptom without UFLAG being set at all.
ECC vs S/4HANA
USR02 continues to exist in S/4HANA in the same shape and role, still populated and read by SU01, SU01D, and the standard security reports. There is no compatibility view replacing it for this data; it remains a direct client-dependent table. Consultants moving from ECC can treat lookups against it the same way, with the same caution about not editing it directly.
Common pitfalls
- A nonzero UFLAG only says the ID is locked, not why; it can be an administrative lock set in SU01, an automatic lock from repeated failed logons, or a lock imposed centrally by CUA overriding the local client. Treating any nonzero value as 'wrong password lockout' skips the actual cause.
- GLTGB in the past produces a denied logon that looks identical to a locked account or a password problem, but UFLAG can be zero the whole time. Checking only the lock flag and missing the validity dates is a common misdiagnosis.
- TRDAT and LTIME reflect the last successful logon in that specific client only. In a CUA or multi-client landscape, 'the user has not logged on in months' based on one client's USR02 row can be wrong if the user is active elsewhere.
- CODVN, BCODE, and PWDSALTEDHASH are hashes, not recoverable passwords. There is no way to read or infer the plaintext password from this table, and attempting workarounds against it wastes time and raises audit concerns.
- Editing USR02 directly through table maintenance or a direct update bypasses password history checks, complexity rules, and the security audit log. It can leave the ID in a state SU01 cannot cleanly interpret, and it removes the evidence trail needed for any later investigation.
- USTYP tells you the technical category of the ID, not whether a human is actually using it day to day. Service and communication users sit in this table exactly like dialog users and get miscounted if a license or access review reads USTYP without checking real usage.
- A row existing for a BNAME confirms the ID was created, nothing more. It says nothing about whether the ID currently holds any role or authorization; that has to be checked separately.
Whose problem this is
The security or Basis team owns decisions about locks, validity dates, and password policy reflected in this table. Functional and technical consultants read it to diagnose a logon or lockout symptom but should raise the actual change, an unlock, a validity extension, a hash reset, through SU01 or the standard user administration process, not through direct table edits.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/usr02ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.