Time and attendance Fiori app shows 'Authorization error: user locked' after password reset in S/4HANA 1909

ERP SAP S/4HANA
, , , , , , , ,
1

We’re having a strange issue with the time and attendance Fiori app in S/4HANA 1909. After our IT helpdesk performs password resets for employees, they can log into SAP GUI successfully but the Fiori app shows “Authorization error: user locked” when they try to submit timesheets.

In SU01, the user status shows as active and unlocked. The Fiori app authorization works fine if the employee changes their own password through the self-service portal, but not when helpdesk resets it using SU01. This is creating payroll processing risks because employees can’t submit time entries.

The helpdesk follows standard procedure: SU01 > Change user > Logon Data tab > New Password button. Is there some additional unlock step needed in the Fiori app configuration after password resets? This affects about 10-15 employees per week.

system 2

Your issue is caused by the interaction between SAP’s password reset mechanism and Fiori’s session management, specifically how the “User must change password” flag affects authorization checks. Here’s the complete resolution:

SU01 Password Reset Procedure: When your helpdesk resets passwords in transaction SU01, they need to follow this modified procedure:

  1. Navigate to SU01 > Change user > Logon Data tab
  2. Click “New Password” and enter the temporary password
  3. Critical step: UNCHECK the “User must change password at next logon” box
  4. Save the user changes
  5. Run transaction SU56 or use menu Environment > Reset Authorization Buffer to clear cached authorizations
  6. Communicate the temporary password to the user

The “User must change password at next logon” flag puts the user in a restricted state where they can authenticate but have limited system access until they complete the password change. SAP GUI detects this state and automatically prompts for password change during logon. However, Fiori apps don’t have this built-in password change dialog, so they interpret the restricted state as an authorization failure, displaying “user locked” errors.

Fiori App Session Management: Fiori apps maintain session tokens that include user authorization data. After a password reset, these tokens can become stale or invalid. The time and attendance app specifically checks user status before allowing timesheet submissions. If the backend still has cached data indicating the user is in password-change-required state, the app blocks access.

To resolve existing locked sessions:

  1. Have affected users log out of all SAP sessions (GUI and Fiori)
  2. Clear browser cache, cookies, and local storage (important for Fiori session tokens)
  3. In SAP, run transaction SM04 to verify no active sessions exist for the user
  4. If sessions persist, use transaction AL08 to terminate them
  5. Reset the user’s authorization buffer using SU01 > Environment > Reset Authorization Buffer

Automated Solution for Helpdesk: Create a custom transaction or script that wraps the password reset process and automatically performs all necessary cleanup steps. The script should:

  1. Reset password via BAPI_USER_CHANGE
  2. Ensure password change flag is not set
  3. Call BAPI_USER_ACTGROUP_RESET to clear authorization buffer
  4. Terminate any active sessions for the user
  5. Send notification to user with new password

This eliminates manual steps and ensures consistency across all helpdesk password resets.

Alternative Approach - Self-Service: Since you mentioned that self-service password changes through the portal work without issues, consider expanding use of the self-service option. Implement a “forgot password” flow that:

  • Sends a secure reset link to the user’s registered email
  • Allows users to set their own new password
  • Automatically handles all backend authorization updates

This reduces helpdesk workload and eliminates the authorization synchronization issues entirely. For users who must use helpdesk (new employees, locked accounts), train helpdesk to follow the modified SU01 procedure above.

Payroll Risk Mitigation: For your immediate payroll processing concern, implement a daily check before payroll cutoff:

  1. Run a report to identify users with recent password resets (last 7 days)
  2. Verify these users can access the time and attendance Fiori app
  3. For any failures, proactively perform the unlock procedure before payroll processing begins

This prevents last-minute payroll delays due to undetected authorization issues from password resets.

This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Check if there’s a cached authorization issue. Have the affected users clear their browser cache and cookies after the password reset, then try accessing the Fiori app again. Sometimes the Fiori launchpad caches authentication tokens that become invalid after password changes.

4

When the helpdesk resets passwords in SU01, are they checking the “User must change password at next logon” checkbox? If this is enabled, it can cause authorization issues with Fiori apps because the user is in a password-change-required state. The SAP GUI handles this by prompting for password change, but Fiori apps might interpret this state as a lock condition. Have the helpdesk uncheck that box when resetting passwords, or ensure users complete the password change in SAP GUI before accessing Fiori apps.

5

This could be related to the password change history. SAP tracks password changes and can lock users if there are too many changes in a short period, which is an anti-brute-force measure. Check profile parameter login/password_change_waittime - if it’s set too restrictively, frequent password resets by helpdesk might trigger automatic locks.

marcoconsultant 6

Confirmed this resolves the Fiori authorization error — unchecking ‘User must change password at next logon’ in SU01 Logon Data tab eliminated the session lock on our S/4HANA 1909 system.

7

Look at the Fiori app’s OData service authentication method. If the time and attendance app uses a different authentication mechanism than SAP GUI (like OAuth2 or SAML), password resets in SU01 might not properly synchronize with the OData service credentials. Check transaction /IWFND/MAINT_SERVICE and verify how the time entry service handles authentication after password changes. You might need to manually refresh the service credentials or restart the OData service after bulk password resets.

8

We’ve noticed that when we reset passwords, sometimes the user’s authorization buffer doesn’t clear properly. After the reset, we now run transaction SU01 and use Menu > Environment > Reset Authorization Buffer for the affected user. This seems to help but isn’t always consistent.

9

Thanks for all the troubleshooting ideas. I think we’ve narrowed it down to the password change flag and authorization buffer combination.