Skip to Content

Design Considerations to reduce Password Self Service (PSS) Intruder Risk

3/Nov/2016 blog updated for re-tagging due to SCN migration

The aim of this document is to focus on the system controls for password self service to enable you to consider how best to design and configure SAP GRC Password Self Service in your environment. This topic was raised as part of feedback in the document Password Self Service & End User Logon Configuration – AC10 by Leo and requested as part of the GRC Collaboration Project. If you are interested in specific configuration steps, please refer to Leo’s document or search SCN space for your requirements.



The scope of the document is SAP standard configuration specific to the SAP GRC component. If anyone would like to add suggestions on how to add additional security layers (tokens, SSO, etc) please add your comments in the section below for discussion.




A PSS tool needs to go through the basic process which includes verifying the identity of the user before the password can be issued. A critical design requirement for PSS is the ability to prevent an intruder masquerading as a valid user to obtain access to their account.  Within GRC, there is more than way one to achieve this.


1 overall process.jpg


The above diagram is a conceptual view of the complete steps if all Password Self Service configuration steps are activated. Below is a summary on the intention of each step and impact if they are not used.


Network Perimeter


This is not so much a step in GRC configuration but recognises that network security will determine if the HTTP service for End User Login is Internet Facing. Assuming GRC system access is only accessible via internal network access, you have limited potential intruders to those who have network access. It has been included to recognise network perimeter security has a part in the GRC solution but will not be discussed in this document.


End User Logon


The GRC End User Logon functionality utilises a SAP Service Account to authenticate access for the HTTP service. This means, a SU01 Service Username and password is stored against the SICF web services and the end users do not require a SAP GRC account. The positive of this functionality is that end users do not need to be set up in SAP GRC component (simplify maintenance as well as license cost).


GRC makes use of Data Sources for User Authentication, Search and Details for end user functionality. Data Sources are configured via the GRC IMG (transaction SPRO) based on the use of connectors defined in the Integration Framework. Synchronisation jobs are then executed to import the user details. The End User Log-in page can be configured to force authentication against a specific data source. This means, when the user accesses End User Logon functionality, they will required to enter their password for a system defined in the authentication configuration (such as Active Directory or SAP ERP/ECC) and a real-time call is performed to authenticate the user. It is possible to use SAP GRC as an authentication system as well – although this would defeat the purposes in End Users not requiring a SAP GRC account.


2 End User Logon.jpg

Screen Shot: Impacts for configuration setting for Data Sources Verification



Risk #




End User Verification set to NO

Any user on the network can enter any valid User Id without need to know the password to access the password self service

Challenge Response requires the user to respond to questions with the correct answer. A registration process is necessary for the user to provide these details (refer further below)


Ultimately, the initial password or URL to retrieve password is sent to the user’s email address. If the email account is secured this prevents the intruder from accessing the account. However, if intruder has access to the user’s network login then this line of defense is broken.


End User Verification Relies on System Password being requested for

This creates a catch-22 situation where the user needs to know their password to request a password they cannot remember. For example, if the user cannot remember their ECC password and that is why they need to use PSS then your solution will not work if you require them to authenticate with their ECC password.

Data Sources configuration for Authentication would require more than one data source to provide back-up or Verification will need to be set to NO (refer back to Risk 1). If multiple data sources are used, you will need to consider user training impacts and update the login screen to provide some instructions. One possibility is to configure the Active Directory as a data source for authentication as users would need their network password to login to their computer.


Social Engineering/User

Password as an authentication method has a risk of an intruder obtaining it through social engineering means or User writing their password down or disclosing it.

Training users in the risk and consequences of sharing passwords or disclosing them to others is necessary to mitigate this risk.


Network Sniffing

A call to the plug-in system is performed to retrieve and validate password (synchronisation jobs do not store the other system passwords in GRC).

Implement strong system security controls. If using Active Directory connector, ensure a secure port is used for communication. Protect the system to system communication through secure network communication (SNC) to prevent eavesdropping as password will no be sent in clear text.


The service user account should also be restricted for permissions in the plug-in system to limit S_RFC access.





Challenge Response provides another way for a user to prove their identity through providing answers to pre-configured questions. The system issues a challenge (secret question) to which the user must respond (provide their answer). These questions and answers are stored in GRC tables with the answers in hashed form.


Challenge Response requires a registration step in which the use must provide this information. System configuration can provide template/global questions and the user can also create their own.


3 Challenge Response.jpg

Screen Shots: Impacts for configuration setting for Challenge Response in PSS Global Settings

Risk #




No Challenge Response

The GRC configuration for PSS Global Configurations Values allows you to set ‘PSS Disable Verification’ for Password Self Service or ALL. If you do this, the user does not need to answer special questions

Removal of challenge-response means there is one less security layer for password self service. This risk is reduced if you have End User Verification set to YES and/or can rely on the protection of the email account.


Social Engineering

Depending on the question, an intruder may be able to guess or obtain the answer. For example, if the challenge is the user’s pet name, date of birth, etc, an intruder may know this information already or be in a position to obtain it (social media, access to and misuses of HR information).

GRC configuration can be used to limited questions to pre-defined Administrator questions only. User will not have the option to create questions. They will be required to register and provide their answers.

Users need to be educated to choose questions and answers that are not publicly available. System Administrators can preview the challenge questions (answers are hashed but table should also be protected from access in SE16) and also system configuration can limit question creation to administrators only. Administrators are then in a position to set appropriate questions.



An intruder may guess the answers to the questions without using social engineering tactics. For example, if the challenge includes questions such as ‘What is your date of birth?’; ‘Where were you born?’; ‘What is your pet’s name?’, an intruder may have access to that information via social networks, knowledge about the user or even information user keeps on their desk.

The GRC Configuration allows you to specify the number of questions as well as attempts. To reduce the risk of guess-work, minimise the number of attempts and maximise the number of questions.


For example, only allow 3 attempts at an incorrect answer and require the user to answer 4 questions. The specific numbers needs to be weighted against usability – the actual user may struggle to remember that many questions (i.e. it is technically impossible to have up to 100 question but would that be feasible?).


Alternatively, train users to disregard the actual question and answer something different. Therefore, if the intruder knew the answer the question, they would still be incorrect. I found this idea in a news article (unable to locate source). However, in practise, this might be confusing for the user and make the solution unworkable.


Table Access

Questions and Answers by the user in the registration process are stored in table GRACQUESTION. Answers are stored in hash value.

GRC table GRACQUESTION must be restricted to prevent users from downloading and reverse-engineering the hash values.


Registration process

If a user has not registered their questions for Password Self Service then an intruder could access the account, register questions and then use those answers to request a password reset.

End User Verification would require the intruder to know the password for authentication. Secondly, there is still reliance on email address access being restricted. If you cannot rely on email address, then Verification should be used in the initial step.

Reset Password


Once a user has proven their identity (End User Logon or Challenge Response) they can now select the system they require a password reset for. Users will only see the systems for which PSS has been enabled (IMG configuration controls this) and the user has access to. In this document, the example of SAP ECC has bee chosen. Therefore, a BAPI is called via RFC connection to reset the user password.


Risk #




Network Sniffing

A remote function call executes a BAPI in the plug-in system to reset the password and return the information back to the GRC component to communicate to the user. If

Protect the system to system communication through secure network communication (SNC) to prevent eavesdropping as password will no be sent in clear text. The service user account should also be restricted for permissions in the plug-in system to limit S_RFC access.


Password Strength

Weak passwords can be guessed.

User RZ10 system parameters and PRGN_CUST table settings to control the length and complexity of the initial password as well as the validity before password expires. Use of security policy can be implemented to differentiate rules for difference user groups but this will not apply to the initial password set by GRC.


System/Service Accounts are reset

System functionality stops working as users fail on authentication

If End User Verification is not used (no password) there is risk that users could request reset of password for System/Services accounts. The user is unlikely to receive an email with the password information, however, system functionality will fail. For example, if the user for PSS password (stored in SICF) is reset then no users will have access to PSS.


To avoid this, use security authorisations to restrict access to the accounts. Ensure accounts that should not be reset via PSS are in a special User Group and exclude access on S_USER_GRP authorisation


Account is Locked

User account is locked when attempting to request new password

Accounts with a lock status of 128 (refer source system table USR02 for UFLAG field) will be automatically unlocked as part of the password reset.


All other lock statuses are deliberate actions by a system administrator. The GRC PSS functionality has an inherent system control to check lock status and prevent password reset/unlock. Users will receive an error message (refer to Can Password Self Service unlock User?) Accounts with a Administrator lock need to be handled via the ARQ workflows.


Emailing User


SAP GRC component will generate an email and send the login details to the user. System configuration can control if the password is specified in the email or if a URL is embedded instead. The URL example has been shown in this diagram.


Risk #




Network/Email Directory Access

System Administrators, etc may have access to the email directory and be in a position to access the users email

Do not include the password in the email but send the URL link instead (as depicted in this scenario). Refer to section below for URL link and Password Change.


External Email Accounts

Non-company email addresses may not be adequately secure for company policies

Limit configuration in transaction SCOT to specific domains only. Therefore, users will need to have a company email address. This solution will not work if your users have external accounts. You will also need to ensure the data sources for the user details contain the correct email address as per these rules.



Transaction SOST allows you to see email communication sent by the GRC system as well as forward the message to another account.

Restrict access to this transaction or prevent the administrator from viewing the contents of the message (can only see header instead)



URL Link and Password Change


The GRC configuration allows you to choose send a password URL link or the actual password. This is set within the configuration for User Provisioning. As part of sending URL link only, you will need to specify how long the link is valid for before it expires. If Yes is chosen,the initial password is sent to the user. If no is set, the user receives an email with the URL to launch to then obtain the password.


Email status.jpg



At the end of this process, the user is now able to login with the initial password and change it. The change password rules adhere to the plug-in system configuration (USR40 password dictionary, RZ10 configuration parameters and security policy). These rules are not specific to GRC but based on SAP login sequence.




When you design your PSS process you need to choose the appropriate combination of steps for your organisation. At a minimum, you must define at least one step where you have confidence that only the user will know the information. This may be the Initial Logon, Challenge Response or Email.


Feedback and suggestions are encouraged, Please add your comments below – especially if you can contribute any more risks that should be considered as part of the PSS design process.



Col and Ale

Review and input by Gretchen Lindquist and S A

You must be Logged on to comment or reply to a post.
  • Hi Colleen,

    Excellent document !! I was checking one issue raised regarding PSS and your document was just there to help!!

    We are facing one Risk related to PSS, which you may want to add. We are using SU01 as Data source, hence not practical to have authentication tuned on. Also, end users will have issue with registration etc, so challenge question was no no. We relied upon mail. But big issue is - if someone resets the password of system User IDs, systems using that ID will come to a halt, as RFC and other communications won't work !! Do you think any of work around for this, or only enhancement is an option?

    • Hi Sabita

      Have you looked at placing the Service User in a special User Group and limiting authorisation for S_USER_GRP? If you test this out, I can update the document?



      • Hello Colleen,

        Excellent document....I had some confusions of PSS and was planning to collect all the discussions and build a document for PSS....well, I dont need to do it anymore...Can't ask for more on PSS.....Great work and thanks for sharing your knowledge.

        But, a small doubt: In one of your previous post, you mentioned user should be of type system and here it is service and few people mentioning the same as internet user.

        1) Should I use Service or System user?

        2) Is Internet User and Service User one and the same?


        Deepak M

      • Hi Colleen,

        Thank you so much for quick reply with a solution !! Yes, I tested it and it is working!!

        I have added two nodes of S_USER_GRP - one with all activity + all Groups except SYSTEM

        another - All Groups + All Activity except 78.

        Best Regards,


          • Hi Colleen,

            Just to update you, there is one issue in this solution, that it is highly dependent on User Group being selected correct and existing ones being maintained same way. So we are considering enhancement option to restrict Non-Dialog users.

            Best Regards,


          • Hi Sabita

            I'm not sure what the risk is here. The User Group for Authorisation in SU01 was designed to segregate Administrators. However, GRC is doing that for us now

            My view is

            1. PSS via End User Logon (executed under the system user) should have access to all end user user groups as it's for those accounts only
            2. Other User Groups, which include SUPER, etc should then only be available as either:
              1. Access Request Management scenario that is requested by GRC Users (i.e. Security team could login and go to NWBC to complete a Password Reset for a service use). You would need to configure MSMP for this scenario and ensure the notification is sent to the request and not the user
              2. Firefighter access for System Admin or Security to go to SU01 and reset the password for those users. I like this option as there is little setup and you can capture information of why Password is being reset for the user)
              3. Normal SU01 business operations

            Have I misunderstood - what is your enhancement trying to achieve?

          • Hi Colleen,

            The User Group authorization restriction will work only when we put the User Group correctly at all places. If GRC10 is being implemented now. Back end systems are already in place and number of them are quite big, there is a chance that SYSTEM/ COMMUNICATION/SERVICE User IDs are not properly placed in correct user Group which we have restricted. In that case it will be easy to reset the password if authentication is also turned off and User Group wrongly maintained.

            Also, while creating request for new non-dialog users, if we don't put the correct user group, same issue will occur. So when we proposed this solution, client didn't want to have this gap. 

            So we think of an enhancement where system will check the User Type and only Type Dialog will be allowed to pass through password self-service check.

            I hope it clarifies the requirement.

            Best Regards,


        • Hi Sabita,

          You wrote;

          Sabita Das   Dec 2, 2014 4:55 PM  (in response to Colleen Hebbert) 

          Hi Colleen,

          Thank you so much for quick reply with a solution !! Yes, I tested it and it is working!!

          I have added two nodes of S_USER_GRP - one with all activity + all Groups except SYSTEM

          another - All Groups + All Activity except 78.

          Could you give me some information, where you put those S_USER_GRP.

          Is this in Service User ( Guest in SICF) of in WF-Batch.

          In GRC or ECC?

          Please example.


  • Hi Colleen,

    The option 'register Self-service questions', appears every time in EUL. So, any user can login through other user id, and register new answer, either by resetting User/Admin questions.

    How to tackle this.

    • Hi Plaban

      Do you mean the link appears on the End User Logon screen?. If so, you could look at configuring the screen to remove the links? If challenge response for questions is not being used, you could also deactivate the service in SICF so noone can launch it.

      If this is not what you mean, could you please provide some screen shots and steps of what your issue/concern is. Once a solution is identified I can then add it to the document 🙂



  • Hi

    Great Document.

    I have one issue which I just tested. If the user is locked by Administrator on the ERP side it does not allow to reset the users password, it gives message "Password reset failed - User is locked". This is perfect.

    However if the user is locked by "Too many incorrect logon attempts" It allows to reset the password and on the change logs I see the System user unlocked the user and reset the password.

    What is the control here? How do we avoid this from happening.



    • Hi Mustafa

      Just wanted to clarify what your concern here is:

      1. All change documents in SUIM for password resets are under a system user? OR
      2. Users can perform PSS when their account is locked due to incorrect logon?

      If it's issue 1 then they way to manage this is a dedicated/cut down system user for PSS. Therefore, any changes appearing in user change logs via SUIM can be linked back to GRC. This is no different to an actual user administrator appearing in the logs. If anything, I would then have more concerns if I saw an administrator performing the change instead of the system user as it means PSS is not being used (or possibly an administrator is misusing their access). Also, I would question if an admin needs passwords reset access outside of firefighter if PSS is place?

      If it's issue 2, I'm a little confused as this is what PSS is designed for

      Sometimes the control is not about prevention but ensuring that you design your solution to trust your analysis.



      • Hi Colleen

        Thanks for the response.

        I was talking about issue 2.

        We have set a parameter, lock account after 3 failed attempts.

        So if the user tries the password 3 times the account gets locked. The user can use PSS to have the account unlocked and reset. Correct?

        I was not aware that PSS unlocks account as well. Thought that only an Administrator can unlock the account.



        • Hi Mustafa

          In truth, I assumed a lock 128 (incorrect) login attempts would be via PSS but all other locks would need to be via ARQ. Otherwise, you lose most of the opportunity to to use PSS as incorrect password with 3 strikes would be a trigger for a user to go to PSS

          The 3 attempts is good to set as it forces them to complete a request (which has some form of challenge). Your SM19 Audit logs could capture incorrect logon attempts.

          Someone might need to jump into this thread and confirm if lock 128 is resolved via PSS as part of the password issue.



          **Update 24/01/2015 - Refer to this discussion as it confirms that PSS will resolve a 128 lock but no others. I will capture this as a scenario in the document Can Password Self Service unlock User?**

  • Colleen,

    This is a very interesting document, but in some ways a troubling one for me (not because of anything you did 🙂 )


    Why is it that there is so much overlap between IDM and GRC? For applications that are supposed to be compliment each other, I find it disturbing that GRC does some user provisioning and Password Self Service, while IDM has been doing user provisioning and Password Self Service for years, and is now doing some attestation/certification in the latest releases.

    I wish someone at SAP would come up with a clear road map for these two products and how they can work better together rather than compete with each other.

    From my side of the landscape (IDM) it sometimes seems easier to integrate with other compliance solutions rather than GRC and I find that a shame.



    • Hey Matt

      Good to hear from you

      The reality is this is what happens when SAP acquires companies. GRC a while back was VIRSA and it was all focussed around access risk (then evolved). SAP IdM was what MaXware? Each product evolved within their own space

      In the mean time SAP decides these products are great and buys them. But now they have customers on both. Need to continue to support the customers who invested.

      The sales brochures for these two products seem to imply that IdM should be used for provisioning but then integrates/hands over for GRC to completed Access Risk Analysis. IdM will and GRC are only overlapping on the Access Request Management. Both products have their unique functionalities... and now this is becoming the blog I've been wanting to write for the past year

      In short - two companies bought by SAP. Must support customer base. Lots more to say but insufficient knowledge to write it.

      Duplication is not good. But what I find more frustrating is that SAP is recommending I have two products to integrate to achieve the end to end process. It's hard enough to convince my clients to spend the money on 1 product let alone two. And then you add the integration complexity to it. Though it would be fun to do 🙂



      Ps - this blog will be written one day

  • Hi Colleen,

    Yes MaXware and the MaXware Identity Center, along with the MaXware Virtual Directory were purchased by SAP to become the IDM suite.  The original product was actually somewhat popular in your part of the world.

    I agree with you 100%, and can summarizing by saying, been there, done that, got the t-shirt!


  • Hi Colleen,

    Insightful like all your other posts!

    I have a doubt regarding you mentioning that user id need not exist in GRC for PSS. Well in that case how would the user be able to access the url(which is a GRC url) for Registering the challenge questions and then eventually answering it at a later stage?

    There is clearly something I am missing out here.



    • Hi VJ

      All end user services are authenticate against using a service user. The service user is specific in SICF transaction with username and password.

      Therefore, when clicking the link the SU01 account that is checked and then authorisations is for the service user. However, the program checks the IMG configuration for data sources and user authentication to determine if the user is recognised.

      If you go into the IMG for ARQ and read the help documentation for activating end user login you will get this information. There's a few older threads from 2013-2014 regarding end user login and pass which lists these services.



  • Hi Colleen,

    Great article - it has helped my team with PSS implementation.

    Do you know if it is possible to default the System selected in the PSS process in any way?

    The user community I support has been looking for this since their only option is a single Prod system, and for users that are less-frequent (ie. ESS-only) users they already don't have a good appreciation for things like SID or descriptions.

    Any ideas?  Even if you have advice on possible workarounds it may be an improvement over the current standard where users commonly leave the system blank or end up raising support tickets due to confusion.

    • Hi Rob

      Thanks for the feedback

      I was under the impression the user would only see the systems in their list that they have accounts. Depending on how complex your PSS system list is this might have some simplificiation

      If not, the only suggestion is to work with a developer to look at the webdynpro configuration to see if they can default the ESS system. If all users have this system then you won't have issues having it defaulted

      You could also look at going to Ideas Place and raising an improvement suggestion to have a default system for PSS via parameter or so. If enough people vote for it then the Product team will consider in next update (no guarantee though)



  • Hi Colleen,


    First of thanks for sharing document and really document is great help with the risk I was anticipating.

    Among such, I wanted to implement that Password URL Link should go to user rather password itself, Now I don't find an option EMAIL-Status where I can set 'No' in SPRO. Can you please help me with that?


    -Ravi Paul

  • Hi Coleen,


    Excellent article. One Question though.

    We are successfully registering the answers. But while using them for password reset the error coming as " the entered passwords do not match ". We are entering the exact same passwords as in registered.

    Sometimes it's taking only the alphabets, and some times same error.

    There are defined values in PRGN_CUST. Please let me know what to check and where. Your help is much appreciated.