Security (Part-3) :-
As part of our daily activities we might receive the tasks as follows
1) Changes in form of tickets. (Various 3rd party tools are available)
2) Changes in form of CR
Each ticket has its own priority i.e. SLA. Based on the priority there will be response time and resolution time for each request.
SLA(Service Level Aggrement)
Priority Type Response Time Resolution Time
1 Very Critical 10 min 30 min
2 High 30 min 1 day
3 Medium 60 min 4 days
4 Low 4 hrs ----
Response time is time in which we acknowledge the user request, i.e. once a ticket comes into our queue the first major priority is to accept the ticket on our name, once this is done we have to send an acknowledgement to the user informing that someone is working on this issue via email, chatting tool or phone.
Resolution Time: This is the time in which we have to solve the issue.
Note: By default the status of any ticket is in Open status
Stages of ticket:
2) Working / In-progress + Assigned to our Name + Inform the user + Copy the comments in the tool under notes column.
3) Closed + Issue Resolved + Inform the user + communicate + Copy the comments in the tool under notes column.
4) Waiting + Needed some inputs from the user to solve the issue + inform the user + Copy the comments in the tool under notes column.
5) Hold + Waiting due to user unavailability i.e. user has gone for vacation + Copy the auto response regarding user unavailability and paste the notes
6) Cancelled: If there are duplications or same request being raised then we can cancel one of the requests by mentioning the previous request no under the notes column. (Or) If the user wishes to cancel his /her request then copy the confirmation under the notes and select cancel button.
Types of CR ( Change Requests)
Work bench / Customizing
1) New functionality CR: This CR carries new functionality changes which are done for the first time i.e. creation of totally new roles.
2) Operational CR: This CR carries the changes which are done on a day to day basis i.e. modification of roles and deletion of roles.
3) Defect CR: This comes in form of ticketing request i.e. based on the ticketing request raised by the user using the ticketing tool we decide whether we need to create a defect CR.
Eg: Some access is already there for a user, but it was lost due to some reason and we investigate and find out that these changes have to be there for users. In this scenario we raise a defect CR.
To rectify a defect CR
CR forms are created based on the quarterly release i.e. we have 4 quarterly releases in a year. During this release different people i.e. technical + functional consultants + security administrators get involve and analyze various roles based on the inputs provided by the auditors
This is where SOX policies come into play. In order to indentify the various defects and conflicts in roles and between transactions we use various SOD (Segregation of duty) tools like VIRSA, BIZRights. The process of identifying the defects or conflicts among the existing transactions and rectifying them as mitigation.
Ex: MM01 x MM02
1) Create X Change
2) Change X Delete
3) Create X Delete
Note: Default access is Display
HR Security Activities
There are two types of HR security Activity
1) Delegation of Authority
2) Structural Authorizations
Delegation of Authority:- Is a process by which a delegate delegates/assigns his/her access to a delegator for certain period of time i.e. during this period all the POS (Purchase Orders) or any items coming into owners inbox will go to the delegators inbox.
Note: The delegator can delegate the access only to a person to a same hierarchy or higher hierarchy.
The only issues which we get here is the problem with workflow. i.e.
Items not appearing in the inbox
An item appearing in inbox even after the period is expired
Don’t have access to approve the POS appearing in the inbox.
The first two problems are rectified by workflow administrator. The last issue is related with the approve access. Before we provide the approval access we have to identify that particular person having an access or not.
If he’s having an access then keep on email notifying him that as per the security policy any user can have either create/approve access and not both.
Steps related with delegation of Authority
1) Log into HR box, go to PA20, i.e. display HR master data
Enter the personal details
Select the organization assignment and period today
Output will be position number or personal number
Copy Position No, Go to PO13 (Maintain Position)
Paste under position number
Under Infotype (Select Name and Relationships)
Under Time period select All and Press Overview button
Select the Row where the object type=P and End date = 31-12-9999 and Press Copy button
Under related object change the type of related Object from person to user
Under ID of related Object, enter the delegates
User ID and Press Enter
Make changes in dates
Valid From to Valid To
Select Save Button
Structural Authorization: Is a concept under HR security using which we assign roles to user based on this organization object.
Structure of organization management:
1) Organization Unit
4) Task = Description of an activity i.e. performed within organization units. Here we assign any roles to positions and not to user.
The users are called as Holders; holders are assigned to position and not to jobs
Whenever we create an organization unit structure we have to create first the root, i.e. organization unit and then only create additional lower level organization units.
Steps Related with Assignment of HR Roles i.e. Structural Assign
1) Go to PFCG select over all under view.
2) Select inheritance hierarchy.
Go to PFCG, enter New Role Name, in maintenance
Go to -> settings -> Complete View (Org management and Workflow)
Go to User Tab -> Select org.mgt. Button
Choose create assignment button
Select the job [Object Type]
After completion select user comparison.
Special PFCG Roles:
1) Customizing roles: We can assign projects/views of the implementation guide (IM) to this role.
2) Composition Roles
Go to PFCG -> Menu -> Go to Utilities, select Cust_Authorization -> Select Add Tab -> Img Project / Img Project view
Select the customized object based on our requirement Continue.
If a project/Project view has been assigned to view, we are no longer possible manually assign transaction to roles
This means that the role can only be used for generating and assigning customized authorizations.
Any role to which transactions have been manually assigned. These roles are used only during implementation period, we should maintain end date for the role. When it is assigned to the user, once implementation is completed normally we delete this.
Installation and Upgrade
The basic profile parameter Auth_no_check_in_some_cases=Y has to be set if we want to user profile generator (PFCG).
Q) Where do the default value in a Role comes from i.e. activities under auth object?
A) Tables USOBX_C and USOBT_C are the tables, that control the behavior of profile generator after the trans has been selected.
SAP delivers tables USOBX_C and USOBT_C. These tables are filled with default values and used for Initial fill of custom tables.
After the initial we can modify the custom tables.
Table USOBX_C table defines which auth are to be performed in a transaction and which should not be.
Table USOBT_C defines for each transaction and each authorization object, which default values and authorization created from the auth. Object should have in the profile generator.
During implementation we use transaction SU25 for security related settings besides this we also use SU24.
Note: Any workbench changes in security are done in SU24. Modifying values in SU24. Go to SU24, enter the transaction code and select execute.
Select the particular authorization object, which we want to modify.
Select the object and click on change button.
Go to proposal column and select “YES”.
Select the object again and change field values.
Under check indicator column if no check is there, then select the auth object and check indicator.
After changes in particular field select save. It will automatically prompt us to place a request under a transport.
Go to own request select the transport of type work bench.
Note:- If the transaction request number is created by another team member then go to Other requests button and enter the user ID
Output = All the requests created using the user id will be displayed.
Select the Workbench request based.
Select the button change owner and go to SC01 to release the request.
SU25:- Profile generator for upgrade and first installation.
This transaction code is used only during implementation and during an upgrade. The main purpose of this transaction code is to move the default changes which are maintained in the current version to new version.
Versions are 2 types
1) Version in which no PFCG tool
2) Version in which PFCG tool. (4.6 B)
Upgrade Scenario 1: Release without PFCG tool:
Always use step 6 in SU25 to convert manually created profiles and authorizations into roles
Scenario 2: Versions with PFCG
1) Execute the profile generator with comparison with SAP values i.e. comparing by tables USOBX_C, USOBT_C tables.
2) Add affected transactions
3) Update the existing roles with new authorization values
4) Display all values for where changed transaction codes
Note: Do not execute step 1 (Initially customer table)
Step 3: Once the above steps are done transport these changes using step 3.
Q) How do I deactivate authorization object globally?
A) Go to SU25 select step 5 deactivate authorization globally.
Will update soon... Check next post...