What are the security requirements for building OCI in MM
thank you
What are the security requirements for building OCI in MM
thank you
Dear gurus,
I am confronted with a question where it seems there is no answer except trying, so thought it best to see if anyone has done this before...
Background is SAP notes 323817 and 727536 regarding demoting customer org.level fields.
Someone promoted 28 fields to org.levels in a system here. PFCG_ORGFIELD_CREATE has a transport connection, so at the time the USORG and USVAR table entries were also transported through the landscape.
Now I have degraded to the fields to normal fields again using PFCG_ORGFIELD_DELETE, which converts the SU24 and PFCG data and the USORG and USVAR tables, but it does not ask for a transport request...
New roles which include the now "normal fields" can be imported successfully into QAS and PROD systems, and the old roles will clear themselves out and are being completely replaced anyway.
So my question is: should I transport the USORG and USVAR tables through the landscape as well? If yes, then before the roles are transported would seem correct to me, but there is no dialog I can find to add these to a transport request, so I suspect that maybe SAP's intension was simply to leave the data there as "dead wood" in QAS and PROD. The only way I can think of is to manually insert the tables as "table contents" into a workbench transport and send that through - but that seems a bit suspect to me...
Has anyone done this before? Did you sync the tables in QAS and PROD or just leave them as inconsistent in the landscape?
Cheers,
Julius
Hello Julius
I used it some time ago (that was the 'Z' versions of the reports, such as ZPFCG_ORGFIELD_CREATE, in a 46C system). If my memory service me correctly there were no transport requests generated for the USORG or USVAR tables). So we executed the program in each 'tier' of our landscape. This has been executed several times in our company. In general we do the following:
The USORG/USVAR tables are not transported, but 'cleaned up' in each tier of the landscape.
I hope this information helps
I look for an option to use at the Password check procedure from Active Directory password instead USR02 password.
What is up to date the mostsimple and with BC740 at Win2008 or 2012 option to replace PW check at ABAP with AD PW check to for Business Uses. Are there Standard functions, Customer Exits or methods available to implement
an easy solution.
I found many discussions around the topic at SSO, IDM,GRC but once with much new functionality I do not request
at moment or discussions based on older releases.
What function can be used within BC 740 / ECC 617 running SAP at MS Win Server?
Details:
We started to implement Standard SSO (with Kerberos / SPNEGO for Portal and GUI User) but we have still lots of tickets from users not staying inside our central AD domain with their PC-Client.
We are a “small” organization but have facilities in 150 countries with also local AD domains. So often the uses are logged on with in the regional AD Domain and would like to access one of our new centralized SAP services via Portal or sapgui. Our Business Users have 2 accounts, first within AD for regional IT Services, second for all centralized IT services.
I asked, based on These conditions, our SAP-Basis Team how we can get a solution to check on NW ABAP
Stack server side the password with our central AD domain.
We run five productive functional different SAP instances and expect no benefit on centralized Role and User
administration within this organization. Only the different password per SAP-system-client
causes problems.
Our security team requires at systems with personal employee data a logon procedure with entering a password
(proposal is using AD PW) and for technical support stuff a higher frequent PW
change. All these could be done just by PW check against AD.
Hi Marc,
Thanks for stretching your memory all the way back to 46C for me... ;-)
Yep, it looks like the process you followed is the one which SAP left us with. But I don't want to run programs which change SU24 and Roles and config in PROD... something tells me that is not a good idea.
My problem is that someone accidenturely promoted all fields they wanted a * in to org.levels so that the auths are all standard. These are were now mostly "Changed" status and SU24 broken. Seems like they went to ADM940 but were not listening all the time...
So, it being a Sunday yesterday, I eventually fixed it so that I could test before the users arrive on Monday morning:
So this was my solution, but I would still be interested if someone has a better approach or whether there is an official way to correctly do this?
Cheers,
Julius
We are currently on ECC 6.0 SAP_BASIS Release 731, SP 4. We are upgrading to SP13. Is there a check off list (from a SAP Security perspective) available that can assist me with any and all changes or gotcha's with this upgrade or any upgrade? Something that could also tell me where to go for information specific for upgrade from one SP to another.
Hitting the print button solve the problem. Thanks a lot.
Hi All,
Wehad the same problem. The reason -the userhas beenassigned a rolewithoutcustomizedorganizational levels. However, neither theSU53,ST01noproblems withauthoritydid not show.The problem is inSAP!
Best regards,
Konstantin
Hi All,
We have a scenario below and required suggestion on this...Pls help
We have created 2 Employee Ids and One logged in to GUI and other Logged into Portal...
We have checked logged on information in SAP and we couldn't find the difference when login to SAP and when logged into portal...
Please suggest on how to check user logged into portal...
Hi Hima bindu,
Please try User Administration> Activity Reports. This will give you data of users logged into portal.
Regards,
Deva
Hi Tim, We can consider that approach of using AD user to authenticate as well. For that we need to check if all users have AD accounts in the Home domain or not and we need to pickup additional task of mapping the user accounts with AD accounts in SU01. I think this mapping is not required if we use the SAP User ID & Password approach. Correct me if I am wrong.
Would be helpful if you can through some light if we have any technical limitations other than password management overhead in enabling it through SAP User ID & Password.
Thanks
Jay
Jay,
There are two types of SNC library available. Firstly, there are SNC libraries that include support for mutual user authentication, data integrity and encryption. These libraries are often used for SSO. These libraries are most often sold with a license (e.g. they are NOT free), and can be made available from SAP partners or from SAP (the SAP NetWeaver Single Sign-On product). Secondly, there is at least one SNC library that I am aware of which is free, but it only offers encryption, and no user authentication. This library is called SNC Client Encryption and available from SAP.
The first type of SNC library would require mapping (e.g. in SNC tab in su01), but would reduce the number of passwords that a user needs to remember. Depending on which SNC library you use, the capabilities to allow SSO to be turned off and whether domain trust is required will differ. You would need to ask the SNC library vendor to get more details of this, and compare.
When the second type of SNC library is used (as described above), there is no user mapping required (e.g. in SNC tab in su01) since the library is not performing any user authentication. This kind of library would require you to use a SAP password during the logon. I am not sure if the SAP Client Encryption library allows the user to logon and get an encrypted session without having domain trust. Maybe somebody from SAP can confirm if the client encryption library supports this, or if domain trust is required for this client encryption library.
Thanks
Tim
Thanks Tim for providing the details to have clear picture on possible options we have here.
The current plan is to utilize the SAP Client Encryption library that is available from SAP and to enable encryption as a quick win for the communication between Gui and SAP Server. While trying for this we are looking for inputs on any technical difficulties w.r.t the different domains from where users access SAP System.
Any inputs here are highly appreciated.
Thanks
Jay
In the below blog this topic is discussed and as per that for domains other than Domain in which the SAP System service specific User ID/SPN is defined should trust this domain for this to work.
Configuring SAP SNC without Single Sign-On on UNIX/Solaris/Linux
In the context explained above..
All other domains from where users login should trust Domain B. I am about to test this and will post my findings back.
If any one has already implemented this approach please share your inputs.
regards
Jay
Based on my detailed understanding of how the Client Encryption library has been coded, and how it uses the Kerberos protocol, I think you will find that the SAP Client Encryption library won't allow you to configure encryption without any domain trust. However, you are welcome to try... I think you will have to go with a licensed SNC library that supports the functionality you require. You can then benefit from users having less passwords as well as having an encrypted DIAG protocol.
Update: I can confirm that it is quite safe to transport USORG and USVAR(T) as table entries and then also run SU25 steps in addition to PFCG_ORGFIELD_DELETE and transport that in step 3.
The roles in target systems still have profiles assigned and UST12 does not care about orgfields, but the auths tabs are all red. This means that if you ever entered change mode, it will force the read old / merge new option, which is also correct.
This is OK in my case as the 28 custom orgfields all had a * in them anyway, and the existing roles will soon be replaced by new sets of roles and deleted. We only need to bridge a small time gap where the users don't have the new roles and request something to be done to an old role.
So transporting the definitions through was correct as exporting them in "old status" does not work anyway, and I need to get my new roles live ASAP (which is not a problem - first users are live already).
If you however want to salvage the old roles after demoting orgfields and combining it with a release upgrade, then using this table entries solution to transporting is probably not an ideal approach.
Upgrades are normally a nice opportunity to start over anyway...
I will leave the thread open for a while still if there are other experiences with this or an official process shows up. But my own problem is solved.
Cheers,
Julius
Hi Bindu,
You can see this at transaction SM04 under "type"
Regards,
Deva
Hi,
Is it possible to setup up the password rules for NetWeaver ABAP, so that it's only possible to have password with digits?
Based on the password rules here https://help.sap.com/saphelp_nw70ehp1/helpdata/en/d2/141fb593c742b5aad8f272dd487b74/content.htm it ought to be possible.
For a six-digit password I would try:
login/min_password_lng = 6
login/min_password_digits=6
login/min_password_letters=0
login/min_password_specials=0
login/min_password_lowercase=0
login/min_password_uppercase=0
Any one tried this before?
Regards
Dagfin
Hi,
As part of a custom system login class (subclass of CL_ICF_SYSTEM_LOGIN), I would like to determine the method of authentication used.
Specifically I want to confirm that the logon method was SAML based.
Is there a way I can do this from the ABAP side?
Regards
Dagfinn
You can't do it just by setting minima. Your rules above allow me to have "123456abc" as a password. You need to be able to set maxima also, and there are no such parameters. As far as I know there are no user exits that happen at the right time either. I don't think there's a way to do what you want.
Steve.