When an SAP Client Locks Its Own Door, ASETI Maps the Way Back In

ASETI Sp. z o.o. has published a detailed technical account of a scenario familiar to many SAP Basis teams: an internal client within an SAP ABAP system, whether running on R/3, ERP, or S/4HANA, that becomes inaccessible over time and cannot be reopened through standard SAP transactions. The account walks through why systems built with multiple clients for configuration, testing, or historical purposes eventually lose track of one, and it lays out the specific, database-level sequence required to regain entry when normal tools fail.

The Hidden Cost of an Inaccessible Client

An SAP ABAP system commonly holds several clients side by side, such as 000, 100, and 200, each serving a distinct configuration or testing purpose. Over time, one of these can slip out of active use, and the credentials needed to log into it disappear along with the people who once managed it. ASETI’s account notes that administrative passwords for these secondary clients are often never recorded in any secure document, so once access is lost, it can persist for years.

The consequences extend beyond inconvenience. A client that cannot be logged into also cannot be reviewed for security gaps, leaving open the possibility that someone could use tools operating independently of any single client to tamper with or erase database tables. That same client keeps consuming storage capacity and inflating every backup cycle despite doing no active work. Standard remediation is not available either: SAP’s SCC5 transaction, the normal route to delete a client, requires logging into the client being deleted, creating a genuine dead end for administrators.

This pattern reflects a broader feature of SAP’s client architecture. Because each client maintains its own user administration and configuration layer within a single technical system, access and security issues have to be resolved client by client rather than at the system level. Governance practices built around periodic security checks, using reports such as RSUSR003 or broader access-control tooling, exist specifically to surface orphaned users, default passwords, and unreachable clients before they accumulate into exactly this kind of exposure.

A Documented Path Back to Access

ASETI’s walkthrough describes a recovery route built on SAP’s built-in SAP* fallback mechanism, which becomes available only when two conditions are met simultaneously: the login/no_automatic_user_sapstar parameter is set to 0, and no SAP* user record exists in the client being recovered. The first step is diagnostic, running the RSUSR003 report from another client to check whether SAP* and DDIC users exist and whether standard passwords remain in place, with SAP Notes 8852 and 389530 cited as references for those default credentials.

When the standard SU01 user-management transaction is unavailable in the locked client, the SAP* user record must be removed directly at the database level, in the USR02 table where client numbers and usernames are stored. ASETI’s account documents a database-level recovery procedure using MaxDB’s sqlcli tool on Linux as a specific example, while noting that SQL syntax and tooling vary by database platform. A full database backup should precede any such operation, since a mistake, such as deleting all entries from USR02, would remove every user from every client in the system at once.

Once the SAP* condition is satisfied, change the login/no_automatic_user_sapstar parameter back through transaction RZ10 in another client, and restart the system instance for the change to take effect. With access restored, the recommended sequence continues: recreate a proper SAP* user in the recovered client, establish a new administrative user with correct authorizations, reset the parameter to its secure value, and restart the system once more. Direct database-table edits like this are generally treated across SAP environments as a last-resort intervention, reserved for senior Basis-level staff operating under strict change control, and periodic client cleanup is a recognized part of landscape governance during consolidations or migrations to limit this kind of technical debt.

What This Means for SAPinsiders

Orphaned clients quietly expand audit blind spots. Teams without visibility into every client in a landscape risk carrying unmonitored access points that could be used to alter or remove data outside normal oversight. Periodic client-level review helps close that gap before it becomes a years-long liability.

Basis-level expertise becomes a deciding factor. Because standard transactions like SCC5 and SU01 fail once a client locks itself out, organizations evaluating SAP partners should weigh depth of technical Basis capability alongside functional implementation experience. Database-level remediation is not a routine skill set.

Undocumented admin credentials raise governance risk. Relying on tribal knowledge for secondary-client access means staff turnover or oversight gaps can turn simple housekeeping into a multi-year unresolved exposure. Recording administrative credentials and access procedures reduces that dependency.