SAP Knowledge Base Article - Public

2088150 - Troubleshooting Login Issues for SAP SuccessFactors HXM Suite

Symptom

  • A user is unable to login to SAP SuccessFactors.
  • One or multiple user(s) cannot login to SAP SuccessFactors.
  • How can I validate user data to ensure a successful login?
  • What to do if a user is unable to login to the SuccessFactors Application?
  • When you try to login into the instance you see an error message that says "The request operation is not available"

Environment

SAP SuccessFactors HCM Suite

Resolution

Note 1:

  • If you are seeing specific "System Unavailable" errors, HTTP 404 Error, and similar issues, then this may not be a 'login issue" but a system issue. Please also refer to our System Unavailable Solution.
  • There are many reasons why an end user may not be able to login to the SuccessFactors Application. This solution attempts to provide you the most common list of reasons for why a user or group of users may not be able to login. Please consider the current nature of the login issue, and then review the solutions that might apply from the list below.

Note 2: 

If your Company is using Single Sign On (SSO), please see the section towards the bottom for steps on how to resolve login issues.

Note 3: 

Users are getting re-directed to SuccessFactors Login Page after SSO login page. (one of the reason can be the "SAML Asserting Party Name" has space character in the name)

Section 1: Clients NOT Using Single Sign On (SSO)

# Error = "Invalid username or password. Please re-enter your login info:"

  • The number one reason a user is unable to login is that they are not entering the correct credentials. Note that the credentials for Username and Password can be case sensitive.

  • For usernames, make sure they enter their username correctly as was created (Dave, DAVE, and dave are all different usernames). Tip: Try exporting the user data via admin tools to see exactly the values for Username are.

  • For passwords, these can be set to be both case insensitive or case sensitive via Admin Tools > System Properties > Password Policies and Settings > Case Sensitive Settings. As with usernames, Password, PASSWORD, and password are all different values.

  • Company ID is always case sensitive.

  • Be sure to work with your end user to be absolutely sure that they are entering values correctly.

  • A user may be directed to use the "Forgot Your Password" hyperlink on the login page to retrieve their password if it seems they maybe using the incorrect password. Another option the company admin has is to reset the user's password from Admin Tools > Manage Users > Reset User Password > Reset individual user password (with supplied password). Please note: SuccessFactors customer support will NOT reset user passwords if a user is locked out for security reasons. We ask that the company administrator always perform this function after verifying the user is allowed access to the system.

  • If your company is using SSO, do NOT reset passwords unless you know the exact value your SSO system requires for each user. The Forgot Your Password functionality should be turned off. If it is still enabled, the user may have mistakenly reset their password using this feature. You may need to take very specific steps to reset the passwords. Please contact your SSO team or Customer Success for further help. Please see the SSO section below for more information.

  • For Active Users, confirm that the user is in the system. Go to Admin Tools > Change User Information > Uncheck "Active Users Only" > Enter username, and search for the user. This will return a list of both Active and Inactive users in the system that match that user. If the user is marked as Inactive, then reset the user account from Admin Tools > Set User Status > Uncheck "Active Users Only" > Search for username > Select the user, and set as Active > Click Save The Setting.

  • Note: If after an import was done where a user may have been assigned to an invalid manager, you then correct this user's manager, and where the employee is now getting the error "Invalid username or password. Please re-enter your login info:", it will be due to the fact the original invalid import also removed the user from the Default User Group because of the invalid manager data. You now need to reassign this user(s) back into the Default User Group. See below.

  • Default User Group Assignment: A user MUST belong to this group to access the SuccessFactors Application. Another common reason that a user may see this error is that they have been removed from the default user group. All new users by default are assigned to this group which provides access to the SuccessFactors Application. If a user for some reason is removed from this group they will be unable to login. To check or reset an user's status go to Admin Tools > Manage Security > Default User Group Assignment > It is suggested that since typically all users should be assigned to the default group that you simply select all employees and assign to group. If you use defined groups, be sure to select the Default User Group or the group you wish to assign them to. You will see a notification as to how many users were successfully assigned to the group. Then ask the user to attempt to login. Being removed can occur when someone imports using Enforce Manager-only Implementation, as explained below.

  • PASSWORD Column: When an administrator imports a User File that includes the PASSWORD column but the password column did not include anyone's passwords all passwords are set to NULL. When the user tries to use the "Forgot Password Feature" to retrieve their password, it also contains a NULL. The user will need to have their password reset (depending on the scope of who was affected, this could mean others need it as well by an additional upload). You can upload a file with a password for all, or reset individually. If you are using SSO, then you may need to take very specific steps to reset the passwords. If you are not using SSO, then please see the solution on "How to Force Reset Passwords".

  • Login method consistency: The user's login method should be the same in either the UDF and at the Manage Login Account feature, but, some improper login method update — such as via HRIS mapping (which isn't recommended) — can generate inconsistencies and jeopardize the sync. This can end up causing the inability to login.
    • On this scenario, the faster way to mirror the user's login method between both places is by simply switching the login account to another one and then switch back to the desired one so that a new sync will be triggered and the login method will be consistent again.
    • If the user only has only one login account (hence, the switching workaround won't be eligible), then it will be necessary to engage Engineering Team to correct this via script.
    • Important: this scenario only happen in very isolated cases, and the script correction should only be requested after validate the other standard variables (login permission, active status, valid manager and so on).

# Error = "You've reached the maximum number of login attempts. Your account is now locked. Contact your administrator for more details."

  • This message indicates to an end user that they have exceeded the limitations you have set in your password policies for invalid login attempts.

  • To change this limit:
    1. Go to Admin Tools > System Properties > Password Policies and Settings
    2. Change the value for Maximum Successive Failed Login Attempts
  • To unlock an account:
    1. Go to Admin Tools > Manage Users > Reset User Account
    2. Search for the user and click to reset.

# Error = "Login unsuccessful. Invalid manager detected. Please contact your local system administrator for assistance. Sorry for the inconvenience."

  • This message occurs when the user's manager has been set as inactive.

  • Valid Manager ID: Check to make sure their manager’s ID is valid. A user cannot login if they do not have a valid manager. Export your user file from Admin Tools > Employee Export and check the MANAGER field for the user. It must contain a valid Manager ID (check for spelling mistakes or incorrect numbers), or NO_MANAGER. These are the only acceptable values.

  • Broken Hierarchy: If you have encountered large numbers of your population that are getting this message, the likely cause is a recent user import that had errors and has broken your hierarchy. You will need to begin immediate discovery of recent user imports to correct any errors such as incorrect usernames or IDs, or setting someone at the top of the hierarchy as inactive causing all direct reports to now be locked out. Please log a case with Customer Success to have an expert help troubleshoot this with you if the error is not apparent. Please note that SuccessFactors cannot correct your data or revert your hierarchy to a previous state. This will require that you correct the original import file and re-import it.
  • See information on the help portal:

Note: As of 2h 2023, system no longer check for Valid Manager when user is trying to login. Further information can be found on WNV Removed Validation on Invalid Manager | SAP Help Portal.

# Error = "The requested operation is not available"

  • This error message is usually thrown in situations where there are some downtime or a temporarily network unavailability or instability.
    However, in some cases, it can also be noticed when some MDF-related feature (such as "Attachment Manager") is enabled but it's object definitions are out dated.
    To fix this behavior, run the job named "MDF Object Definition to DB Sync". More details on how to fix it are available in the KBA: 2534674 - How To Fix Inconsistencies In Metadata Framework (MDF).
    Once this job's running is completed, you'll be able to enable the feature and login within the instance without experience this message.
  • Another possible reason is because some data is missing on the user account: see KBA 3464127 - Users are not able to login and getting error with Fingerprint: e6f3bc26d091c025b8c9be4f211f20ef81dd4c7c

Enforce Manager-only Implementation:

  • Another common cause of large groups of employees to suddenly be locked out of the system is when a user import was done, and the administrator had accidentally checked the box: "Enforce Manager-only Implementation." If all the users locked out are non-managers, then this has likely occurred. Simply perform the import again making sure not to check the option for Enforce Manager-only Implementation.

  • Error = Page not found:
    • This error maybe due to the user trying to use an invalid URL. Please make sure the user is trying to access the system using the correct URL or login procedures.
    • Have the user clear their browser cache.
    • Verify the user is entering proper Company ID
    • Is the user clicking on a URL that was sent to them in an email, even if from the SuccessFactors Application? If so, have the user attempt to login normally to determine if the URL is invalid. If they can successfully login, then you may need to open a support case with Customer Success to determine why the link in the email is not working.
  • No Error Message. User is redirected to the default SuccessFactors login page:

    • Verify the user is entering proper Company ID. Note that the variable for Company ID is case sensitive so "SuccessFactors", "SUCCESSFACTORS", and "successfactors" are three different companies.

  • IP Restriction: Error - Your machine is not authorized to access this system:

    • Your company is using IP restriction to prevent unauthorized access to the SuccessFactors Application, and you are trying to access the system from an IP address that has not currently been authorized. Please log a case with SuccessFactors Support to have the new IP address added if this is an IP address that your company has authorized for access.

Section 2: Clients Using Single Sign On (SSO)

  • Companies using SSO are recommended to setup custom error pages so that users unable to access the system are directed to error pages that clearly indicate the nature of the error. Please let Support know the page your users are directed to. Note: Please see the solution on "Landing Pages" if you would like to use our default error pages.
      1. If your users are being directed to one of your custom error pages, please be sure to indicate to Customer Support the error and page that your user is landing on.
      2. If your users are being directed to the default SuccessFactors login page, then either your company has not yet set up the appropriate error pages or the current reason preventing login is not a standard issue. Please provide Customer Success the URL of the page the user is directed to.
         

 

  • To effectively troubleshoot SSO login issues, we require the support of your SSO experts, as only they can capture an SSO transaction before it is processed and encrypted and sent to the SuccessFactors Application for validation. Since most issues are a mismatch between the values you have imported into the SuccessFactors Application and the values you are sending in the encrypted URL, you need to have your SSO expert capture and provide the variables of a transaction in the server POST, before it is encrypted. We need to be able to see:
      1. the URL that is being generated
      2. the Username value before it is encrypted
      3. the Password value being used
      4. the Time stamp if used
      5. DO NOT simply provide these values from your records. We MUST see the actual values being processed in the actual SSO transaction via your system, pre and post encryption. Only then can we faithfully compare those with the values in the SuccessFactors Application being validated against.
         

 

  • The most common reason for users to be unable to access the SuccessFactors Application with SSO enabled is due to a mismatch in the username/password combination. 
    • Note that the variables for Username and Password can be case sensitive.
    • In the case of usernames, make sure your system is sending the EXACT username currently on record in the system.
    • Do NOT assume they are an exact match. "Dave", "DAVE", and "dave" are all different usernames.
    • Tip: Try exporting the user data via admin tools to see exactly the values for username in SuccessFactors and then compare these values to the values your SSO team has provided from the actual SSO transaction.
    • DO NOT simply go on the value the user is typing in, as that is not necessarily the value your system picks up from your LDAP etc. to send to us. You want to see absolute values and not assume consistency between sources

 

  • User Import: If all users are locked out, then find out if a user import recently occurred that might have changed passwords accidentally.
    • Note that SSO often uses the same password for all users or may be configured where username = password.
    • Performing a new import that is known to have the correct values is recommended as an immediate action as this may correct the issue if it was data related. 

 

  • Please do NOT reset passwords unless you know the exact value your SSO system requires for each user. You may need to take very specific steps to reset the passwords. Please contact your SSO team or Customer Success for further help.  

 

  • Reset Password: If you feel this might be the issue, you can test by using the "Reset Password with Supplied Password" feature in Admin Tools.

 

  • Password Change: If you force users to change passwords regularly (e.g., every 90 days), then your user may have changed their password today.
    • If you use an SSO method that validates the password in your system to match passwords in SuccessFactors, then the user may not be able to login to the SuccessFactors Application until that new value is fed into the SuccessFactors Application (usually via an overnight FTP import).
    • You can manually update their password by using the "Reset Password with Supplied Password" feature in Admin Tools, or the user can wait for the overnight feed to correct the issue if your import file includes a PASSWORD column.

 

  • Time Stamp: If your company is using a timeout variable, and all users are unable to login, then the synchronization of the server time between your SSO server and SuccessFactors is off.
    • To remove this as a possible cause, request that SuccessFactors disable "Expiration of SSO Request (in seconds)" in provisioning.
    • Even if the timestamp is disabled, the client may be sending the timestamp variable.
    • Make sure that this is synced to the correct time and using US/Eastern variable, not EST.

 

  • Was SuccessFactors working on your system? If you currently have Support working on an unrelated issue, let Support know this in case a setting was changed recently. Have Support confirm your Token and Key settings.

 

  • Do you use Partial Single Sign On? If you have Partial Single Sign On enabled on your instance, check if the login method of the user is set to PWD or SSO. If the login method is set as PWD, the user will be only able to login using Username and Password, not SSO. 

 

  • Did the person's USERNAME change? If the person's username changed and your configuration is set as username = password, then the password may be still set as the old username value. You may need to manually reset the password by using the "Reset Password with Supplied Password" feature in Admin Tools, or the user can wait for the overnight feed to correct the issue if your file includes a PASSWORD column.

 

  • Please have the administrator check the following settings for your instance. Go to Admin Tools > System Properties > Password Policies and Settings >
    • Disable the following:
      1. Set “Maximum Password Age (in days)” to -1. This will prevent passwords in our system from expiring and causing login issues for your users. If users are being prompted to change their password, set this to -1.
      2. Also Go to Admin Tools > System Properties > Company System and Logo Settings, check "Hide the Personal Password Tab from users". That will prevent the system from asking users to update their passwords. 
      3. Maximum Successive Failed Login Attempts Setting to 0 will disable this option. You do not want the SuccessFactors Application to lock out users once you are on SSO. Your own internal authentication will control security and login attempts.
      4. Enforce Password Encryption: Retrieve Password by providing Email Address. Forget Password feature will generate new Password for user
    • If these features have been enabled and the end user had mistakenly reset their password, then determine the value of the password that your company is using for all users, and reset their password.
  • To the error ""The request operation is not available"

    1. Go to the instance provisioning;

    2. Go to Company Settings;

    3. Disable the Feature "Role-based Permission (This will disable Administrative Domains)" and save it;

    4. Then go back to the Company Settings and re-enable the same feature;

    5. Now, you should be able to login in the instance

See Also

Keywords

sf, success factors, log in, error, SSO, loading, invalid manager, active status, login permission, login method, login method issue, login method sync, login account, can't log into, can't log in, non-SSO, Enforce Password Encryption , KBA , sf sso , LOD-SF-PLT-SEL , SSO Errors & Logs , LOD-SF-PLT-PWD , Password Policy Settings & Reset Password , How To

Product

SAP SuccessFactors HCM Suite all versions