09-14-2010 1:31 PM
Dear SAP colleagues,
We do have 2 SAP SRM systems :
1. DL1 is our SRM-ABAP system
2. DJ1 is our SRM-JAVA system
A user is created in DL1 (ABAP) system.
The DJ1 UME links to DL1. In other terms, a user is created in ABAP system (DL1) and automatically replicated to JAVA system (DJ1).
My question :
We want to give access to our user only to DJ1 (SRM-JAVA) system.
User must not be able to connect on SRM-ABAP system (DL1).
If I lock the user in DL1 (ABAP), it is automatically locked on JAVA system (DJ1), which is normal.
User has ABAP roles and JAVA roles.
Is there a solution to give access to a user on JAVA system (DJ1) and lock the same user in DL1 ?
Thanks in advance for your suggestion, even if it is a strange request ...
CP
09-15-2010 1:39 AM
Hi,
you can disable password logon using parameter login/disable_password_logon and not to set up SSO. So normal users won't be able to log on. I am not sure if this parameter affects Java stack but it looks like DJ1 is a separate system.
you could use an user exit SUSR0001 which is called after dialog log on to ABAP stack. But be careful about it. Probably you don't want to lock out all users.
Another approach could be to put firewall in front of your ABAP stack and allow dialog logon only from limited range of IP addresses.
BTW if you don't give authorization to run any transaction to users (S_TCODE) then you don't care if users can log on or not. They won't be able to do anything.
Cheers
09-14-2010 9:08 PM
Think this way
U1=user1
R1= role 1 in java stack
R2 = role 2 in ABAP stack
How will the user get access to R2? if you remove the relationship between R2 and U1?
with your present installation model.
I have seen UME/portal UME connected to ABAP database ( ABAP SRM ) only
or
You have the Netweaver install pointing to UME only ( my knowledge is it will be java only stack )
in that case your NW SRM ABAP side which will be independent , the user can be locked forever!!
09-15-2010 1:39 AM
Hi,
you can disable password logon using parameter login/disable_password_logon and not to set up SSO. So normal users won't be able to log on. I am not sure if this parameter affects Java stack but it looks like DJ1 is a separate system.
you could use an user exit SUSR0001 which is called after dialog log on to ABAP stack. But be careful about it. Probably you don't want to lock out all users.
Another approach could be to put firewall in front of your ABAP stack and allow dialog logon only from limited range of IP addresses.
BTW if you don't give authorization to run any transaction to users (S_TCODE) then you don't care if users can log on or not. They won't be able to do anything.
Cheers
09-15-2010 9:16 AM
Dear,
Thanks for your input.
DL1 (SRM-ABAP) is the UME source system of DJ1 (SRM-JAVA), through SAPJSF user.
I need to keep the connection between both systems.
Maybye I was not precise enough in my problem description :
1. DL1 - SRM-ABAP system - contains all users.
All users are created in DL1 and then automatically replicated to DJ1 (SRM-JAVA).
2. We do have 300 users. Among them, only 2-3 users must have access to ABAP system (DL1) for certains activities.
Theses 2-3 users will be SAP Basis Administrator, SRM Admin, SRM Manager, SRM-Catalog Manager.
They need to have access to DL1 to work on ABAP system.
But all other users (key users, assistants, ...) must not have access on ABAP system (DL1), but only
on JAVA (portal) system (DJ1).
My goal :
1. I do not want autorize all this users to have access on ABAP system (DL1) but only on JAVA system (DJ1).
Any idea or suggestion ?
Best regards
CP
09-15-2010 9:31 AM
The easiest way would be to use network restrictions: e.g. block SAPGui between the client network and the server network, and / or deny access from all hosts except the Java instances. When the maintenance window is over, you just open the access again.
Without knowing your setup it is hard to recommend where you should do this (e.g. firewall, SAProuter, message server, etc).
Cheers,
Julius
09-15-2010 9:10 PM
If you have SSO configured between them ( ABAP & JAVA ) you can achieve your goal
and allow GUI access for those 2-3+ users to perform admnistrative activities
but in this case remember the user will still be unlocked.
if the user needs to view data from the backend system