Hi All ,

I need some suggestion on how to identify the which Characteristic is authorization relevant for the respective infocube.

Example when a user execute a query  through BEX example U_ABC_MFA01_0006  in RSA1 the multiprovider assign to 3 info cube is they any table  or transaction where i can identify user required which relevant characteristic for the cube  (like company code , organizational key etc)  to execute the report . 

At the moment we are doing trace and finding the table RSECVAL   to identify the the role .

Hi,

We are using BW on HANA. In BW Devlopment system, we go to tcode RSA1, select the DSO (Info Provider) and have selected the check box

for "External HANA View for Reporting" for our DSOs. Activating this DSO for first time, is creating an analytical privilege and HANA role in HANA dev system. This is working properly.

So now the DSO is already activated in BW and in HANA we have the corresponding Analytical Privilege. The problem is, later if we activate this DSO in BW, the analytical privilege disappears from HANA. We have to activate the DSO once again and then only the privilege is re-appearing in HANA.

Shouldn't the analytic privilege be available in HANA after each activation of Info Provider (DSO) in BW? Do you know why the analytical privilege is appearing only after activating DSO twice? Is this how it works or is there something wrong in BW system?

Its working in same way in sandbox system also.

Thanks

Nitesh

How to translate PFCG Roles in other Languages?

When you create PFCG Role in English (or any other languages), the role and description is in English. The main language of the role becomes English and hence if you log on with any other languages the Description is greyed out and you cannot enter the translated description in PFCG. The same is shown in below screen shot..

For change in other languages, go to transaction SE63 > Translation > ABAP Objects  > Transport Object. Add the below entries

1. Entry of Object - Add R3TR, ACGR and the PFCG Role.
2. Translation
   1. Source Language – Add the main language
   2. Target Language – The language in which you intend to change

  Here we are translating from English to German

3. Click on edit button

Double click on Z_TEST_COMPOSITE under the node <ACGR>Roles

Add the translated description <Test Composite Role> and save it.

The same procedure has to be followed for long text.  But the option to be clicked is <AGL> Role Description.

To make transport the following procedure needs to be followed.

1. Create a transport
2. Go to sub Transport > Objects tab
3. Add the mentioned details
   1. Program ID – R3TR,
   2. Object Type – ACGR
   3. Object Name – Fill the PFCG Role name
4. Save it.
5. Make the transport.

Hi All,

We have created an authorisation object in the system which apply to all BW queries / reports. The  authorisation object restricts a field / infoobject 0COMP_CODE to a particular range of values.

The BW reports in the roles use this field 0COMP_CODE and restricts to an authorization variable which brings in the restrictions applied in the roles.

The above scenario works fine for users currently.

Now there is a new requirement that I need help with.

Suppose there are 10 BW queries assigned in the roles. We now want to remove the authorization variable / restriction from 5 out of the 10 BW queries.

When we do that by simply removing the variable from BW query and run the reports it gives us an authorization error message. I suppose this is because at the role level there is a restiction and at the BW query level there is no authorization variable to pick this.

If we move the 5 queries to a new role where there is no Authorization object applied and the 5 queries don't have an Authorization variable it still gives as an Authorization error.

So now we have the below scenario

Role 1: 5 Queries with Authorization variable and Authorization object restriction

Role 2: 5 Queries with no Authorization variable / Authorization object

Role 2 queries do not work because the same user is assigned Role 1 and Role 2 and the Authorization restrictions get pulled in from there !

Any suggestions on how to proceed here and make Role 2 work without any restrctions?

Thank you.

Hi Experts,

We have recently implemented BW. I have created some analysis authorizations in our BW system. But when I check in the table RSECVAL, I only see authorization 0BI_ALL that too with only special characteristics. Other auth relevant characteristics which are automatically added to 0BI_ALL are not visible in this table. Similarly the analysis authorizations I have created are also not visible in this table.

Could anyone suggest what is the reason behind this? Do we need to activate (or something else) this table? If yes, then how?

I tried to update 0BI_ALL, but that too didn't solve the problem.

Thanks

Nitesh Gupta

Dear security gurus.

I have 2 business roles in company and 2 subsidiaries under HQ.

Each company have

- Accout clerk

- Account manager

HQ's clerk&manager: be able to check all company's data.

Subsidiary's clerk&manager: be able to check ONLY their own company's data

In this case, I have to create these 6 roles, because

company code restriction can be controled only by role, not user.

Am I correct?

1.HQ's manager(Company code: *)

2.HQ's clerk(Company code: *)

3.Subsidiary1's clerk(Company code: 1)

4.Subsidiary1's manager(Company code: 1)

5.Subsidiary2's clerk(Company code: 2)

6.Subsidiary2's manager(Company code: 2)

Yoshi

Hi all,

I was unable to login in to the system using GUI so i delete the sap* user at the database level and then i login with sap* and password: pass.

But when i am not able to create new users now in sap* user login.

I am also not able to change the passwords of the existing users??

Plz suggest...

Thanks,

Pankaj

Dear Experts,

Currently we are planning upgrade from ECC5 to ECC6 EHP6. Could you please help me to find the revised T-codes for obsolete T-codes in ECC6.

I have checked in PRGN* tables and SU25 2D step as well. Here I can see the revised T-codes for old t-codes which are available in ECC6.

But my requirement is, I need the revised T-codes for invalid transactions in ECC6.

For ex: The T-codes which are available in ECC5 and not available in ECC6

Thanks in advance for your quick help!!

BR,

Sudhakar

Hello Guys,

I am looking for SRM and BI Security documents, Could you please guide me the path for getting necessary security related documents.

Thanks for your help!

Regards,

Hayath

Let’s start with S_TABU_DIS and _STABU_NAM

We still remember the times when it was not so easy to authorize for generic tools for the access to database tables (transactions such as SE16, SE17, SM30, SM31 or SM34). The only option was the authorization object S_TABU_DIS, which lets one authorize on the level of authorization groups (groups of tables). Just to summarize -> it means that you permit access to a certain group of tables which means that the user can either access all of these tables or none of them. Some people tried tricks with reassigning the tables to different groups

Then S_TABU_NAM object has been introduced which has made it possible to authorize for a single table which was something many MANY (!!) authorizations administrator wanted and prayed for. Now you can maintain parameter transactions for the tables you need to authorize for, maintain the S_TABU_NAM proposal for that parameter transaction in SU24 and via the role menu get the S_TABU_NAM instances all “Standard” in the role.

And how this S_TABU_NAM works exactly? In the module VIEW_AUTHORITY_CHECK, the system checks S_TABU_NAM only if the authorization check on S_TABU_DIS was unsuccessful. This procedure enables both the retention of the previous table access concept and the superposed use of both authorization objects. Notes 1500054 and 1434284 are provided for information regarding the optimum use of this enhancement.

If you build roles via menus and understand the benefit of SU24, you will never give any table access which is not necessary or which you cannot link back to why it had been given when your auditor asks (assuming you understand the “Standard” instance type and know “sun over the mountains” icon and its magic).

Technical details for the interested:

1. You can see what group the table is assigned in table TDDAT. The combination TABNAME and CCLASS is what you are looking for.
2. It is probably more convenient for you to find this information somewhere in the SAP standard screens. Then I can recommend you transaction SE11 > provide the name of the table and click “Display”. Then in the main menu Utilities > Assign Authorization Group.
3. Note that not every table is assigned to a group. Or a meaningful group. Note that table group &NC& is equivalent to “empty value”. Beware of SAP standard SU24 proposals that pull the &NC& value for S_TABU_DIS-DICBERCLS field. But that would be another story.
4. If you want to learn more about the authorization concept options for generic table access or simply want to have everything describe in one place, please find your way to OSS Note 1434284 - FAQ| Authorization concept for generic table access.
5. Avoid coding your own S_TABU_* objects’ (all objects in the family) authorization checks at all costs. Use function module VIEW_AUTHORITY_CHECK for this purpose every time. You can see OSS Note 1481950 - New authorization check for generic table access for some details (in combination with 1434284 above!!).
6. Note: changing authorization group of a standard table is a modification!
7. Warning: Be careful with banning the S_TABU_DIS object completely. It should not be used as a hardcoded authority check in the SAP standard code any more (if you find it, outside of VIEW_AUTHORITY_CHECK, please inform us about it here!), but you can still find it in TSTCA (check in SE93 – authorizations needed to start a transaction). Because the S_TABU_DIS/ NAM logic is implemented in the VIEW_AUTHORITY_CHECK function module, TSTCA mechanism does not know about it (does not use this way!) and so S_TABU_DIS in TSTCA must still be authorized for using the object not some “friend” object like with DIS and NAM. In case you find TSTCA in SAP standard transactions, you can also consider reporting it here and we can see if we can get rid of it once and for all somehow.
8. S_TABU_DIS and NAM get a little mention in Frank Buchholz’ blog ABAP Development Standards concerning Security. Unfortunately it does not mention the information about not using S_TABU_* checks hardcoded in the code and the need for VIEW_AUTHORITY_CHECK but maybe you can just believe me on that one.

I must also remind you about the blog by Greg Capps: Reduce the Risk of SAP Direct Table Access.

Then we got S_RFC, RFCTYPE = FUNC

We used to have the same problem with authorizing for S_RFC. You may have noticed that S_RFC gets generated automatically by the PFCG framework when you put a function module into a menu of a role (yes, that works!). Unfortunately what gets generated is a S_RFC instance with RFCTYPE = FUGR. This means that by putting a function module into a menu of a role your role will get S_RFC instance generated which will authorize for all function modules in the function group.

The good news is that there is better granularity possible here since RFCTYPE = FUNC has been introduced. It means you can (MANUALLY!) authorize for a single function module.

It works very much like S_TABU_DIS and NAM: At run time the first check is for the function group executed. If this check fails a second check for the function module is executed. By this behaviour no changes are to be expected during upgrade, but a more granular authority check can be activated on demand. It also share something with S_TCODE – generated entries you cannot edit (because they correspond to the menu entries): Note that the S_RFC standard authorizations discussed in this note are not authorization default values but automatically created start authorizations analogous to S_TCODE. Therefore, they cannot be edited.

If anyone from SAP reads this I would be interested to know if anyone plans to generate S_RFC type FUNC in PFCG either as a default option (after installation or upgrade of the system) or as a default option once a customizing switch is changed (PRGN/SSM_CUST?). That would be wonderful.

Let me share a workaround for type FUNC if you have the time (or the strict requirement) or the urge to make your roles super secure. What you can do is you can manually add new SU24 proposals to the function modules that you want to use (you already are using) in your roles: S_RFC with RFCTYPE = FUNC. Then when you create your role menus and SU24 gets pulled into the authorizations as well as S_RFC RFCTYPE = FUGR gets generated by the PFCG for you, you have the necessary authorization needed to use your functions modules covered twice. Once by FUGR, once by FUNC. Now if you deactivate the instance with RFCTYPE = FUGR, you have a role authorized for S_RFC values which it really needs and not all the function modules that happen to be in the function groups.

Technical details for the interested:

1. S_RFC type FUNC has been introduced with OSS Note 931251 - Security Note: Authority Check for Function Modules.
2. OSS Note 1640733 - PFCG: Additional S_RFC authorization describes the mechanism how PFCG generates standard instances for S_RFC object for (remote enabled) function modules in the menu of a role.
3. OSS Note 1749485 - PFCG: Problems when updating start authorizations mentions the generated instances for S_START and S_SERVICE objects based on the role’s menu entries just like we get for S_RFC.

Anyway I hope you see my point. Just like S_TABU_DIS got more granular with S_TABU_NAM, so did S_RFC (although within one object).

…and now we’ve got S_PROGNAM

And finally… here we are getting to the point why I reminded you about old and known facts above – as an introduction to the “get-more-granular” movement which now has a brand new member. Let me introduce you to S_PROGRAM’s younger brother S_PROGNAM. Please check the spelling to see the difference once again;-).

So what is this new S_PROGNAM? It is a possibility to authorize for individual programs rather than via program groups. Note that you must activate the feature to be able to use it, for existing customers using existing authorization concepts it does not change anything (backwards compatible).

The programmatic submit of reports is secured by the authorization group (old S_PROGRAM) the report is assigned to. In case the authorization group is empty, the report may be executed without an initial authorization check. How I see the new check (if active) it checks your authorizations every time (every time you start a program using the API which also takes care of S_PROGNAM). Which means it does not “just happen” when you call SUBMIT <program> in your custom code. If any of my assumptions is wrong, I will update the texts once I learn the facts (and can cite them via an OSS note).

As a consequence of this new granularity and flexibility you can authorize for only those programs that are really needed and if you work carefully and patiently (and manually), you may get up into a world where S_PROGRAM does not have * in the value and S_PROGNAM is used in combination with SU24 proposals and role menus. Happy hardening (of your security).

Technical details for the interested:

1. To learn more about the new S_PROGNAM object start with the note 1946079 - Initial Authorization Check in Function SUBMIT_REPORT. Note that this authority check IS OPTIONAL and you must turn it on (see point 3 below).
2. Note that although this S_PROGNAM object is quite new, it is back-ported all the way to NW 700 SP4 (which a LOOONG time ago!). In case you run an older system, you can consider importing the correction instructions if you can upgrade for whatever reason. If I am not mistaken, by default the mechanism and the object exist in the NetWeaver systems 740 onwards. Try transaction SACF and you will see.
3. To be able to use the new S_PROGNAM you need to have the SACF transaction (switchable authorizations framework installed first). For more information about what that is you can read OSS Note 1922808 - SACF: FAQ - Supplementary application information and Note 1908870 - SACF: Workbench for switchable authorization scenarios.
4. To read an interesting discussion about the old S_PROGRAM navigate here: http://scn.sap.com/message/6903382.

P. S.: Rumours have it that we can expect more granularity coming for other objects as well. A candidate that some people are waiting for (like DSAG – German User Group in its materials) is S_GUI that would give the admins the granularity to decide about export / import feature for each program separately. In case anyone has any updates on this one, I would love to hear about it.

Dear Experts,

I am currently using CUA to assign roles to users in all DEV, QA & PRD environments.

When I create a new role in DEV then send it to QA, I usually assign it to a user so then can test it.

The issue I'm having is the following :

It take a very long time (more than a day) for CUA to detect a newly created role.

Is the a job I can run that could speed up this process?

BR,

Ashod

Hi Experts,

During upgrade we have found switchable authorization object S_PROGNAM is getting checked in BW while trying to activate a data source through SE38. However, we have not found out any transaction in SU22 which is tied with this authorization object.

My question is for which transaction authorization object S_PROGNAM needs to be checked and maintained ?

Also, will this authorization object S_PROGNAM also needed in ECC and needs to be checked and maintained for any transaction?

Thanks

Somnath

Dear All,

We are unable to import RFC in ESR PI system due to missing authorization in source system ECC user id .

Can you some one suggest the required authorization objects/std roles  for RFC import ?

Thanks

Sathies

Hi All,

We see this info message for functional consultants.

Say there are four company codes like 1000,2000,3000,4000 and I have restricted user A with values related to company codes 1000,2000 .. It all worked but main thing when they execute tcode VKM1, they see info message as 

"No authorization for maintaining cred.limit used for cust.: Docs.ignored" I checked su53 and found that the auth check is looking if the user has access to other Company codes say 3000,4000.

How to overcome this? Why should there be a check for other company codes?

Thanks,

Mj

We have granted end users the ability to schedule and release their own jobs through S_BTCH_JOB RELE.   However, after:

1) Implementation of a note that adds a value of P to S_BTCH_ADM to prevent certain users from scheduling periodic jobs without going through our job scheduler

and

2) our internal control group going power hungry entering a ticket to remove S_BTCH_ADM with Y from certain roles

Our finance group has the lost the ability to start their month end job chains, which cannot be scheduled by our job scheduler as their is no rhyme, reason, or pattern to how or when they would be ready to release their jobs.  These jobs were scheduled by different people and one of the accounting managers had access to SM37 with S_BTCH_ADM to release their jobs when they were ready.

The problem I have been tasked with is to find a solution to allow the end users who create these jobs the ability to release their own jobs.  All users have access to SMX but unfortunately it looks like the SAP standard code for it greys out the release button.  Is there another transaction similar to SMX that would allow users to see and release their own jobs, is there a way to limit SM37 safely without causing controls or auditing to swoop down from their perches, or will basis need to release these jobs?   I am open to ideas here.

Good Afternoon All,

question, OSS Note 2067859 describes a security vulnerability, and if you read the OSS Note,

PLEASE do not quote the OSS Note here, just read it,

if you read the OSS Note it says in the Symptom...

     used by SAP NetWeaver Application Server (SAP NetWeaver AS) for ABAP and SAP HANA applications

we are debating, did the author intend this to mean,

a)

     SAP NetWeaver Application Server (SAP NetWeaver AS) for ABAP

          and

     SAP HANA applications

     (therefore meaning this vulnerability, if you have the described setup, would affect every ABAP Stack [regardless of db]

     in your landscape where you have that setup)

or, did the author intend this to mean,

b)

     SAP NetWeaver Application Server (SAP NetWeaver AS)

          for ABAP and (SAP) HANA (applications)

     (therefore meaning this vulnerability, if you have the described setup, would affect your systems where you

     have an ABAP Stack on Hana db)

What does the jury think, is it a) or b) ?

Please as requested do not publish here any more details from the OSS Note than have already been given.

Best regards,

Andy.

Hello,

In reference to SAP Note 1922808 on the use case for SACF in switchable authorization framework, I have a question on 'Object Status' = N.

I built a test scenario to include an authority object with check status N - "Check always passes" (always successful).

Extending the demo example, AUTH_CHECK_SPEC method is leveraged to invoke a check using the test scenario. The result is success with (return code 0).

I followed it up with an immediate authorization check with the statement AUTHORITY-CHECK on that same object and the check fails (RC is non zero). I ran this test on a system with basis component currently on NW74 SP07.

Is this the expected behavior? If so, I am trying to understand how is this useful to alter the program behavior in a business process scenario.

If you have tried the scenario, please provide inputs.

Thanks,
Pawan.

Hi All

We are implementing C4C at a customer, where OIM and GRC are access provisioning tools in production, right now from the information we have got and consider project scoping, GRC doesn't have a std. connector consumer web services in C4C and OIM also doesnt have a std. functionality to integrate with C4C, so we are using CRM on prem to push Identity and access mangement data pertaining to C4C users to C4C, so that OIM and GRC will talk with CRM on prem as a intermediate system which will then relay the required information to C4C. BP replication from CRM on prem takes care of employee and users (tied automatically to employe record) creation in C4C. What we require are update functionality on user in C4C.

We understand, there are no independent user records in C4C for business users, and they are rather Identity Business Object tied up to a employee id.

Requirement is to assign roles to this identity, and set its status (active/inactive - based on HR process trigger i.e employee creation/change/inactivation) and valid to dates.

As per std. documentation referred by CRM development team in project, Identity business object only allows for reading a user's role assignment, it doesn't allow updating user's role assignment, I havent checked with development team on other requirements related to changing user id status and valid to dates right now.

What we want is to understand/find a way of updating the required fields in C4C via a PI/PO interface which will send user access data from CRM on prem and update these fields in C4C accordingly. Has anyone worked on a similar requirement in past or now, can you please share you method, documentation, approach, anything that may be helpful. We would have more than 60K+ users in production environment and it would be high impractical to do manual administration of these users just because we dont have a method/utility that allows updating of user role assignment in C4C. Will also raise this post in C4C forum to reach out to their audience base also. Additionally, I hope SAP will not leave user provisioning in lurch, are there any developments coming up  in C4C from SAP in terms of integration with GRC/IDM? or at least with regards to publishing code for identity object's update functions because if we can manually assign role to an user in C4C it should be possible via code and I dont know how to put it but we just need it or find an alternate, manual administration is not an option.

Thanks

Prashant

Hi

We have a requirement for our Client to restrict Support team access in SAP Production environment, so that the Support team members are not able to view Employee Name/Address/Contact Details/DOB as well as Vendor/Customer Name, Address/Bank details.

These data can be viewed through various standard t-codes (BP, FD03, FK03, XD03, XK03 etc). Is it possible to restrict display access for these fields only in a t-code via authorizations?

Please advise if anyone has worked on such a requirement for their Clients or are aware if this is possible to be restricted via Security authorizations.

Thanks

Susmita Tripathy

With SAP NetWeaver Application Server ABAP 7.40 it is possible to synchronize ABAP Users to a DBMS system especially to SAP HANA . This blog describes the configuration steps that are necessary to set up the functionality and the different features.

Use Cases

• SAP NetWeaver Business Warehouse (SAP NetWeaver BW), needs a 1:1 user mapping to map analytic privileges of the database to the virtual analysis authorizations of the SAP NetWeaver BW
• Your users run applications that access the database directly. You must assign privileges to the user in the database.
• As an ABAP developer, to create SAP HANA objects, you must have a SAP HANA user.
• Use the DBMS user management function of SAP NetWeaver AS when you have the users of a single, standalone SAP NetWeaver AS ABAP to synchronize with the users of the DBMS.

Limitations

In more complex use cases, use SAP Identity Management (SAP ID Management). Such use cases include the following:

• You need to distribute user data across a variety of systems in a landscape.
• You want to synchronize the users of multiple clients of SAP NetWeaver AS ABAP with the underlying DBMS.

Configuration Steps

1. Create the Database User for the Database Connection

SAP NetWeaver Application Server (SAP NetWeaver AS) uses a database user to perform user management operations on database users. The database user requires the following attributes.

• The database user must log on with user name and password.

• The database user has a productive password.

• You have assigned the database user the following privileges

Necessary authorizations for SAP HANA user administrators:

You can also use several personalized DBMS user administrators instead of one fixed technical user that is configured in the database connection. In this case you need to create DBMS user administrators having the same user name as the ABAP user administrators. In the following step (Setup a database connection) you can select between these 2 options.

2. Add a Database Connection

In transaction DBCO: Add a database connection in table DBCON with Change View “Description of Database Connections”: Overview  for the database user and database type HDB:

Steps in Detail:

1. Start transaction DBCO.
2. Choose New Entries.
3. Enter a name for the database connection.
4. Enter „HDB“ for the database type.
5. Enter the name of the DBMS user for the connection.
6. Enter the password for this user. Note: The password must be productive.
7. Enter the connection information: <hostname>:<port>.
8. Save your entries.

Optional: Using a Personalized User Administrator in SAP HANA

If you do not want to use one technical user administrator in SAP HANA you can also define in the database connection that the current ABAP user administrator is authenticated in SAP HANA . Precondition is that the user administrator exists in SAP HANA having exactly the same user name as in the ABAP system and having the authorizations mentioned above. You can then set up the database connection as described in SAP Note 2005856

The current ABAP user is then forwarded to SAP HANA in an assertion ticket.

Alternative Steps in Detail (When Using the Personalized User):

1. Start transaction DBCO.
2. Choose New Entries.
3. Enter a name for the database connection.
4. Enter „HDB“ for the database type.
5. Enter <space>as name of the DBMS user for the connection.
6. Enter any password. (It will not be used)
7. Enter the connection information: @SSO;HOST=<hostname:port>;DBNAME=<name of DB>
8. Save your entries.

In both cases we recommend you protect the connection with Secure Sockets Layer (SSL).

For more information, see the SAP HANA Security Guide and SAP Note 1718944

3. Enter Database Connection in Table USR_DBMS_SYSTEM

Enter the name of the database connection and the client in the USR_DBMS_SYSTEM view with Maintain Table View (transaction SM30)

Steps in Detail:

1. Start transaction SM30.
2. Enter the USR_DBMS_SYSTEM table and choose Maintain.
3. Choose New Entries.
4. Enter the name of the connection and the ABAP client.
5. Save your entries.

Important:

Only customize one ABAP client. The same user ID on different ABAP clients can represent different users with different authorizations. It is not good practice to map user from different clients to the same DBMS user. If you need to support multiple ABAP clients, use SAP Identity Management (SAP ID Management). SAP ID Management has the tools to ensure that users in multiple client represent a single person or identity.

Administration of Users

You can use transaction SU01 for single user maintenance or the ABAP report  RSUSR_DBMS_USERS  for mass synchronization between ABAP and SAP HANA users.

Maintaining Users in ABAP Transaction SU01

In transaction SU01 a new tab named "DBMS" will appear if all configuration steps have been done correctly:

Creation  of Users

Steps in Detail:

1. Start transaction SU01.
2. Enter the user name and create the new user.
   SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP enters the given ABAP user ID for the DBMS user ID by default. Not all DBMS systems support the same user IDs as SAP NetWeaver AS ABAP. Other DBMS systems may have other restrictions. You can change the SAP HANA user name if needed. If the user name is left empty no SAP HANA user will be created.  If you desire other default values or blank user names for certain users you can implement the BAdI BADI_DBMS_USERNAME_MAPPING.  See also SAP Note 1927767.
   
3. Enter data as required, such as Last Name or Initial Password.
4. You must also enter an initial password for the DBMS user. 
   Note: SAP NetWeaver AS ABAP and the DBMS have independent security policies. We recommend that you make these security policies as similar as possible. For example: You can create all possible security policies in SAP NetWeaver AS ABAP to match any security policy in SAP HANA. You cannot create all possible security policies in SAP HANA to match any security policy in SAP NetWeaver AS.
   For more information, see chapter 7.1 Password Policy in thehttp://help.sap.com/hana/hana_sec_en.pdfSAP HANA Security Guide.
5. Save your entries.

Note: There is NO synchronization of productive passwords. As soon as a user changes his password on one side they are out of sync.

Editing Users

Changes to the ABAP user do not effect the DBMS user with the following exceptions:

• Administrative lock: Locking or unlocking the ABAP user locks or unlocks the DBMS user.
• Initial password: As the administrator, you set the initial passwords independently. Users change their own passwords in the separate password change facilities of the different systems.
• You cannot change the DBMS user mapped to the ABAP user directly. You must delete the DBMS user assignment and save before you can assign an existing DBMS user.
• Assignment of DBMS authorizations
  For SAP HANA, you can only add a remove system privileges for privileges that were assigned by the user configured for the database connection. If you try to remove system privileges assigned by a different user, there is no error message. Although the privilege appears to be removed, the next time you view the user in User Management (transaction SU01), the privilege is still assigned. Exception is repository roles, which are always assigned by the user _SYS_REPO. If you have the required privileges you can remove repository roles.

Deleting Users

When deleting an ABAP user, you are prompted to confirm the deletion of a corresponding SAP HANA user if it exists. Choosing Yes deletes the users in both systems.

Using the Report RSUSR_DBMS_USERS

The  report RSUSR_DBMS_USERS allows mass synchronization between ABAP and DBMS users. There are several user selection possibilities to exactly select the ABAP users that shall be synchronized to the DBMS system.  The report documentation in the system  is quite exhaustive. It is recommended to have a look at it.

Please also see SAP Note 1927767and SAP Note 2068639

Selection criteria for the report:

• User
• User type
• User group
• Users having a certain ABAP role assigned
• Users without corresponding SAP HANA users

It is recommended to first start the report in selection mode to check whether the right ABAP users are selected. Then several updates can be run on the DBMS users.

Available functions:

• Remove mappings to DBMS users
• Create and map DBMS users. As in SU01 the BAdI BADI_DBMS_USERNAME_MAPPING can be used to configure the name of the DBMS user that is created.
• Assign DBMS roles
• Remove DBMS roles
• Update user attributes   (Such as e-mail and SNC mapping)

Using the Check Report RSUSR_DBMS_USERS_CHECK

When you synchronize database management system (DBMS) user management with SAP NetWeaver Application Server (SAP NetWeaver AS) user management, you must periodically check that the users SAP NetWeaver AS expects are still available.
This can happen, for example, when a database administrator deletes a DBMS user without the SAP NetWeaver AS administrator knowing about it.

Steps in Detail:

1. Start report RSUSR_DBMS_USERS_CHECK with ABAP: Program Execution (transaction SA38).
2. Choose Select inconsistent users.
3. Enter a range of users.
   Note: To reduce the runtime of the report for systems with large numbers of users, you can specify individual user names or ranges to search for inconsistent data.
4. Choose Execute.
5. SAP NetWeaver AS ABAP returns the list of users that are inconsistent, if any. These users are SAP NetWeaver AS ABAP users for which a mapping is saved, but the user saved in the mapping does not exist in the DBMS.
6. Decide how to handle any inconsistent users.

7. Choose Back F3.

8. Enter users or ranges of users and select the appropriate action.
   Create the DBMS user: SAP NetWeaver AS ABAP creates a matching DBMS user. The user has an initial password. You must inform the owner of the users about the new DBMS user and the initial password.
   Remove the mapping: SAP NetWeaver AS ABAP deletes the mapping to the missing DBMS user. Any scenarios dependent on that user in both systems no longer work.

9. Choose Execute.