Ignore Password Expiration when authenticating with SSO

One of the most annoying things about having multiple systems within an SAP environment is the fact that people have to remember passwords for every component system within the landscape.

SSO resolves this problem, for the most part, but there's still that annoying little fact that initial passwords must be changed at first login, and passwords may be set to expire every so often.

Well, you're options for avoiding these problems are as follows:

1. Deactivate passwords

2. Have the component systems ignore expired passwords when utilizing SSO

Option 1 is great, if your users will never need to enter a userID and password. This puts the entire authentication burden on some other application (like Active Directory).  But this is not necessarily the right solution for all clients.

Option 2 is what I choose, primarily.  In order to do this, you need to set profile parameters in all ABAP and Java systems in your landscape.

For the ABAP systems set the following profile parameter:

login/password_change_for_SSO

This profile parameter determines precisely how the system will react in the situation in which a user accesses the system through SSO and their password is expired (or initial).  Here are the values:

0 = Ignore password change request, and allow access

1 = Present a pop-up window with options 2 and 3 below

2 = Require the password be changed, including old password and new password

3 = Deactivate the password

This is a dynamically switchable parameter and can be turned on in RZ11 without the need for a restart, though you will have to modify the profile to make the change permanent.

For the Java systems, open Visual Administrator, and under the UME Provider service, set the following parameter to False:

               ume.logon.force_password_change_on_sso

This is not dynamically switchable and will require the cluster to be restarted.

Now both your ABAP and Java systems will ignore expired passwords.

Hope this helps…

NetWeaver Portal not behaving with Internet Explorer SSL and TLS settings…

NetWeaver Portal not behaving with Internet Explorer SSL and TLS settings…

Recently on a client site we ran into issues with the internal users being unable to connect to the portal while using the same SSL (3.0) and TLS (1.0, 1.1, or 1.2) settings necessary for other SAP or 3^rd party applications.  This may be related to Microsoft security updates KB2585542 and KB2618444, though the client does not have record of applying these.

This is specific to Internet Explorer 8 or higher.

The errors you may receive include “connection timed out” and “page cannot be displayed” though others have seen spurious other generic error messages.

There are two possible solutions:

1. Update your AS Java to the latest Support Package.  Unfortunately this was not an option at this client site, so we had to go with the work-around below.

2. To implement the workaround change the SSL server configuration as follows:
- Open Visual Administrator and log in
- Select Dispatcher -> Services -> SSL Provider
- Select the line with port number corresponding to your web server (default 5xx01)
- remove all cipher suites except the following:
  SSL_RSA_WITH_RC4_128_SHA

Keep in mind, if you implement this work-around, remember to add the appropriate TLS cipher suites back when you update AS Java.

Hope this helps…

SYSTEM_NOT_CONFIGURED_AS_XMB...

Typically when you get this message in SAP PI, it means that the system you are trying to send a message to is not setup to receive the message.  The way to correct this error is to go on the receiver system an set the Integration Engine Configuration in transaction SXMB_ADM.
Go to Edit >> Change Global Configuration Data.

Role of Business System:  Application System
Corresponding Integ. Server:  dest://[Integration Server RFC destination]

Save and retry.

Keep in mind that if you are doing this with messages from SRM to SUS (and SUS is a separate client on your SRM system) you will need to configure this in both clients.

Hope this helps...

SUS contact person password change is not synchronized to SRM…

The scenario is this: A temporary SUS user that was previously created through the self-registration process logs in and creates his permanent SUS user ID. At that point, the SUS user is created and it is synchronized to SRM, with an identical initial password.  When the SUS user logs in for the first time, he is prompted to change his password.  This is fine, and operates as expected. However, once this same user attempts RFx functionality (or any other function that makes a call to the SRM backend) the user is prompted again to change his password.  The confusion caused here is the password that needs to be changed is the original initial password from the SUS user creation, not the current SUS user password. From the user standpoint, they do not know this because it is not intuitive that they are passing from one system to another.

SAP has come out and said in note 1802240 that the password is not synchronized by design.  I will not venture to guess as to the reasoning behind this, however in researching ways to fix this from a functional standpoint for my customer I came across a very simple solution.

I was looking at our options, and came up with these:

1.      We could change the creation logic with a Z program to force the password to be deactivated in the SRM system when the user is created.

2.      We could change the synchronization function modules with a Z program that includes the logic to force the password change to be included with other user details when the synchronization occurs.

3.      We could just do nothing and provide detailed instructions for the customers on how to work with this design defect.

Each of these potential solutions also brought with them their own drawbacks, especially option 3, but each are valid solutions.  However, I ran across am option 4 that never occurred to me before.  I came across the following profile parameter

login/password_change_for_SSO

This profile parameter determines precisely how the system will react in the situation in which a user accesses the system through SSO and their password is expired (or initial).  Here are the values:

0 = Ignore password change request, and allow access

1 = Present a pop-up window with options 2 and 3 below

2 = Require the password be changed, including old password and new password

3 = Deactivate the password

So, the solution that was best for this customer was to choose option 0, which will allow the user access through SSO and not prompt for the password to be changed.  The customer loved the solution, and I will certainly add it to my bag of tricks.

Hope this helps…

Connecting two BW systems to the same ECC system...

Connecting two BW systems to the same ECC system (or any other SAP system) is (normally) very easily accomplished. You simply create a source system connection to the ECC system (or other SAP system) in RSA1 on each BW system.  Simple.
However, where this becomes difficult is if one of your BW systems was built as a system copy of the other BW system. Let's say you want your Training BW system to point to the same ECC system as the QA training system, and your Training system is a copy of your QA system.
When you try to restore the Source System connection in RSA1, the process will prompt you to delete the existing connection on the Source System side.  That works fine for the BW system that you are setting up at that time, however it severs the connection to the existing BW system.  I could go into great detail on why this occurs, but I am sure most of you are looking for a solution and want it quick.
So, here's the solution (all steps are performed on the new BW system unless noted otherwise):

1. Execute SM59 and delete the RFC connection to the Source ECC system (or other SAP system).
2. Execute RSA1 and delete the Source System definition
3. Execute RSA1 and create a new Source System definition, utilizing a different USERID for the RFC than what was previously used, since that user ID will already exist in the Source System and is tied to the existing BW connection. Keep in mind you will have to have the ECC client opened for changes in order to activate the connection.

Now both the original BW system and the newly copied BW system can connect to the same ECC system.

Hope this helps...

ConfigTool Will Not Start: System Cannot Find the Specified Path...

I ran into an issue recently that has me a little puzzled. Although I have the solution, I have yet to determine the root cause.  This morning I had a problem restarting an SAP Java system, and the errors contained in the logs seemed to be pointing to missing elements in the binary files. This would cause the Java Server process to fail when it attempted to synchronize the binaries (one of the first steps in starting the system).
So I tried to open the ConfigTool, and it immediately came back with the error:

System cannot find the specified path

So being the good little Basis boy I am, I opened up the ConfigTool.bat file to see what path it was looking for. Lo and behold, the batch file was simply looking for the contents of Java_Home (environment variable).
So I opened up the location only to discover that someone, or something, has gutted the Java folder. All that was left was the JRE subfolder.
Then I remembered this has happened before. About 7 or 8 months ago the same thing had happened.

The fix is quite simple, just reinstall Java in the same path.  The system will come back up just fine.

Now I just need to figure out who, or what, has been deleting OS-level files. That is not good.

Hope this helps...

Setting Up NetWeaver Portal for Simple External Access...

When you want to setup your portal to be accessed externally through a Web Dispatcher, you need to consider several things.  Simply opening up the correct ports and pointing the Web Dispatcher to the Portal and backend systems is not going to be sufficient. Every link within the portal that you click on, and every page redirect and pop-up will need to establish communication with a system that resides within your network that is not externally visible on it's own.  When the portal attempts to connect you, it will use an internal address which will only produce a "Page cannot be displayed" error in the end user's browser, or a "Portal domain differs from Application domain" error when trying to utilize single sign-on.

In an environment where the Web Dispatcher resides in a DMZ and all portal/application servers are internal these are some of the steps I take:

1. Validate that all necessary ports are open: The port coming into the Web Dispatcher from the outside, the ports from the Web Dispatcher to the portal and application servers, and the ports between systems that will need to communicate.

2. Validate internally that all connections (SSO, ITS, and WAS at least) are working from the portal. I use only HTTPS, even internally. This makes sure that SNC is configured correctly and certificates are in place.

3. Validate Web Dispatcher certificate is valid and present. This is simple: just connect to the Web Dispatcher with a browser and look for the secure icon or certificate error.

4. After you know that all communication between the portal and the application servers are working, you need to re-point the portal's system definitions to the outside address.  If the external URL for your Web Dispatcher is https://portal.mycompany.com, then that is what you need to point the system definitions to within the portal.  This will likely cause your connection tests to fail, however the actual scenario will work. Instead of your portal links trying to reach internal addresses externally, it will route that traffic through the Web Dispatcher as long as you have the correct systems defined within the WD profile.

5. Change all external facing URLs configured in your backend systems to also use the external link (SUS emails, approval links, etc.).  Anything that is designed to be seen or clicked on externally needs to point to an address that is accessible from outside your firewall.

Following these steps should get you well on your way to getting your portal accessible from the outside world.

Hope this helps...