There are good and bad ways of doing this. Via BDC in production is certainly on the bad side of the spectrum...
A better idea is to create delta roles for each error in test systems and have logic in between which helps the program decide whether this is a good idea or a bad one to fix. That way you can test roles without interruptions.
That is (amongst other things) how SAP Note 1682316 goes about testing roles.
Cheers,
Julius
Hello
The impact will be that you will need to update sapsr3 password in table SAPUSER every time you will change it at Oracle level (using brconnect -f chpass -o sapr3 -p <new_password>).
If you forget (to change the password at Oracle level or to update it in SAPUSER) your SAP system won't be able to connect on the DB and thus won't work (not starting or suspended).
Even if you use SSF instead of OPS$ you will have the same problem.
So it is feasible but it will generate extra work and create a risk for your system.
It's a matter of finding a good balance between security requirements / extra admin work / system availability.
SAP considers that as the SAPSR3 account is not used by human and is then not subject to password disclosure so enforcing password change is not required.
1519872 - SAP Database User Profile SAPUPROF
There is no need for a database administrator to connect to the database as the user of the SAP application (except some rare support situations).
SQL scripts or shell scripts should never contain hardcoded passwords of the SAP application user.
Processes of the SAP application - and certain SAP tools like R3Load that belong to the SAP application- are the only programs that should connect to the database with the SAP application user.
By the way did you setup option "tcp.validnode_checking" in sqlnet.ora file ?
This is a far more important/efficient option for Oracle security than forcing password expiration.
(186119 - Restricting DB access to specific hosts)
Regards
1622837 - Secure connection of AS ABAP to Oracle via SSFS
562863 - FAQ: Logon mechanisms
1627312 - ORA-28001: the password has expired - during system startup
In SU24 you can not add objects to get verified.
You must do this using the ME_PROCESS_REQ_CUST badi . You must write a breakpoint in those methods and choose which one get activated where you need it.
I think that functionality doesn't exist, maybe Aviad Rivlin can confirm and comment whether it will be supported in the future. A possible workaround would be to bind the portal roles to a group that supports validity (ABAP, LDAP).
Hi,
it does not exist and I doubt it will be introduced. Honestly, you don't want to do a role assignment in Portal. You want to do it automatically with UME pointing to LDAP or ABAP or in more complex landscape to use IdM for role provisioning. Both these solutions allow you to restrict role assignment.
Martin
Exactly.
I noticed that the tag IDM 7.2 was added.
Provisioning should be done from IDM tasks and not locally.
If ABAP is user store then you can use PFCG_COMPRESS_TIMES to remove invalid roles (with all consequences for Java stack).
But the best solution is to have the whole identity pot and assignments centrally in an IDM and manage it there without local interferance, even if it is technically possible.
Cheers,
Julius7
Thank you Julius ..
At the moment this UME is not connected to any back end ABAP system. We are currently doing user admin and role admin activities in identity management. But i cant find any validity option for roles.
In recent audits our auditors were asking the system evidences for temporary role assignments and deletion of user accounts. Unfortunately i can not find any change documents or logs in this portal system.
Kindly advice how to get these information in a portal system which is not connected to Back end ABAP system.
Kind Reagrds,
Krish.
Hi,
as it was already mentioned SAP portal does not support expiry date on role assignments. All roles are assigned from today till they are manually removed from user/group. So if you need some control you have to build it outside of SAP portal. The best solution is that it allows automatic de-provisioning of roles after expiry day. We already mentioned pointing UME to ABAP/LDAP or implementing some kind of identity management solution. These solutions require some investment. So temporary you could implement a periodic manual process (e.g. weekly) that will remove roles that are not required anymore.
Cheers
These settings in SSM_CUST are active in PFCG only but not in SU01 or SU10.
Note 367660 - User exits in user and authorization management
http://service.sap.com/sap/support/notes/367660
SAP_BEFORE_PROF_GEN
SAP_AFTER_PROF_GEN
SAP_BEFORE_BATCH_GEN
SAP_EXIT_AGR_DELETE
SAP_EXIT_AGR_TRANSP
SAP_EXIT_USERS_SAVE
SAP_EXIT_USER_COPY
SAP_EXIT_USER_DELETE (called in SU01/SU10, too)
SAP_FULL_USERPROF
SAP_SAVE_AUTH_DATA
SAP_SINGLE_USERPROF
SAP_USERS_TRANSFER (called in SU01/SU10, too, )
Kind regards
Frank
First create a transport containing some PPOM objects to have an example, than use SE16 to have a look into table E070 (transport objects) E071K (keys).
Kind regards
Frank
Are you talking about CUA = Central User Management ?
Well, this CUA is an application in SAP_BASIS. I do not know about any issues concerning a release upgrade. For a long time we have said: newer=better.
Kind regards
Frank
Problem with SU3 (as with SU51 etc) is that switching back and forth between the tabs uses CALL SUBSCREEN so it will always return to the standard screen.
Cheers,
Julius
> Is there any way to prevent users from adding or changing this parameter in SU3?
No, if you allow to maintain user parameters, e.g. using transaction SU2 or SU3, than the user can choose all of them.
There are no checks restricting parameter names or user exits in module READ_TC_PARAM in include LSUU5I01.
Kind regards
Frank
Hi Meta,
I can see it quite often out there in the wild. If not in the normal roles, then at least in the developer or sys.admin roles meant for the DEV and TEST system. In such case there is a menu which pulls the SU24 proposals and stuff, so the role is built with a little bit of thought and purpose.
The Tcode ranges are there in addition (as manual objects S_TCODE) to provide "non-application" access ("entry point" access I mean...something like the ancient AIS roles if you're familiar with that) to things that the user is authorized to use with his/her "application access".
Because Jose got caught by SA38, I would say this is exactly his requirement.
Cheers Otto
Hi Frank,
That SAP note is no longer released. That is what I meant when I said that the documentation has been removed.. :-)
I was advised not to use these exits anymore as their future was uncertain and that BADIs were planned to replace them.
Cheers,
Julius
hi syed,
You can fill fields on screens with default values from SAP memory using parameter IDs. It is the same as SPA and GPA.
Parameter IDs are stored in the table <b>TPARA</b>. They can be created from <b>SE80</b>. Choose Edit Object->Choose tabstrip "More" and then choose the radiobutton Set/Get Parameter ID
Below example is from <b>SAP Help</b>.
For example, a user only has authorization for company code 0001. By entering the value '0001' in field COCD in the Parameter register in this user’s master record (SU01), the system automatically fills the field Company code with the value ‘0001’ on all screens he or she calls. If this company code is not predetermined using a parameter ID in the user master record, the system automatically adopts the first value entered by the user at the beginning of the transaction for the rest of the current terminal session. However, this value has to be re-entered the next time the user logs on to the system.
Regards
Alfred
<points_begging_removed_by_moderator>
Message was edited by: Julius von dem Bussche
Hi Julius,
I do not get your point: I've created a Standard Transaction variant for SU3 in SHD0.
Now I happily can switch between tabs in SU3 always getting the restricted screen.
Caution: you cannot create variants for SU0 / SU50, SU1 /SU51, SU2 / SU52 as these transactions are already Variant Transactions. You have to refer to SU3.
Kind regards
Frank
Yes, you are correct. It was the attempt to create a variant transaction and pass the variant which failed due to the subsequent subscreen calls. A transaction variant (other way around) works though as the standard screen is set and that is the one which is modified.
</confusion> :-)
Cheers,
Julius
Thanks Holger!
Hi Abbas,
the common name from the certificate needs to be the same as the hostname the users will have to enter as part of the URL. This is independant whether you forward the traffic or terminate the certificate at the webdispatcher. The difference is only where to install the certificate, as you need to install it on the system, where the SSL session started by the browser is terminated.
In your case, this should be abcportal.abc.com.
Did you configure webdispatcher to listen on port 443? Pleas check the docs for more details on this.
regards,
Patrick