SAP Basis Notes: May 2009

Profile Parameters for Client Login and password security (RZ10, RZ11)

Profile Parameters for Client Login and password security (RZ10, RZ11):

Creating System Parameters - RZ10

1. Log on to any client in the appropriate SAP system.

2. Go to transaction RZ10.

3. On the Edit Profiles screen, select the _DVEBMGS00_SAP Profilefrom the dropdown, or whatever instance profile you need to change. In theEdit profile section, click the radio button to the left of Extended maintenance. Click the Change button.

4. On the Maintain R/3 Profile screen, click the Add Parameter button.

5. On the next Maintain R/3 Profile screen, type in the new Parameter nameand Parameter val. Click the Copy button. Click the white arrow on green picture-icon twice.

6. On the Maintain R/3 Profile popup, click the Yes button to save your changes.

7. On the Edit Profiles screen, click the Save picture-icon.

8. On the Save profile popup, click the No button.

9. On the Activate profile popup, click the Yes button.

10. On the Edit Profiles popup, click the green √ button.

11. On the Caution! Caution! Caution! popup, click the green √ button.

12. If you receive a Possible Inconsistencies in OP Modes screen, double click over the unless you are unsure of why this message has been displayed.

13. You will not get a confirmation message. You may now leave the RZ10transaction.

What is Transport domain, Domain controller and Transport Layer?

Transport Domain: A transport domain consists of all systms that you plan to manage using the same TMS (Transport Management System). Within the transport domain, all systems must have unique System IDs (SID) and only one if these systems is identified as the (transport) domain controller.
The Trasport Domain Controller is the system where all TMS configuration settings are maintained. Any changes to the configuration settings are distributed to all systems in the landscape. This ensures that TMS configuration settings are consistent throught out the domain. The domain controller stores the referrence configuration and all other systems receive a copy of the referrence configuration.
Customizing and repository objects are assigned to a specific consolidation route by meands of a Transport layer.

Alert Monitoring T-codes

Alert Monitoring

AL01 SAP Alert Monitor

AL02 Database alert monitor

AL04 Monitor call distribution

AL05 Monitor current workload

AL16 Local Alert Monitor for Operat.Syst.

AL18 Local File System Monitor

Local Client Copy - SCCL

Step by Step Procedure to create a copy of a client locally in the same SAP server.

1. Logon to SAP server

2. Use Transaction Code SCC4

3. Go to change mode

4. Create a new client, assign client number & description as per request

5. Logoff from current client.

6. Login to newly created client using the following credentials :

i. Client Number : Newly created one

ii. User Id : SAP*

iii. Password : PASS

how to Kill the Work process

Stopping Run-Away or “Bad” Work Processes

1. Log on to any client in the appropriate SAP system.

2. Go to transaction SM50.

3. On the Process Overview screen, find the process which must be

stopped. Place a √ in the □ to the left of the process number

to be stopped by pressing Space. On the top-most menu bar,

click the Process → Cancel without core.

4. Click the blue arrow circle picture-icon to refresh the Process

Overview screen until the stopped process has cleared from the

display.

5. You may now leave the SM50 transaction.

If this does not kill the process, you can go to transaction SM04 and kill the user’s session. If this does not kill the process, you can log on to the server, open a Task Manager session, and End the Process. If this does not kill the session, there is an executable in the RUN directory on the server called sapntkill.exe. Run it providing the process ID number. If none of the above work, you have no choice but to “bounce” the SAP instance and/or possibly the serve.

Configuring SPNego with ABAP datasource

After writing three blogs about configuring and troubleshooting SPNego (Part 1, Part 2 and Part 3) I got several questions about what steps are necessary to use SPNego if your J2EE Engine is connected to an ABAP backend.
In this blog I will try to explain just that.

In general the setup is similar to the one mentioned in the video for dataSourceConfiguration_DB attached to the SPNego Wizard.

As in "Configuring and troubleshooting SPNego -- Part 1" the first thing to do is to create a service user in the ADS (even if you are using the ABAP System as the userstore for the J2EE Engine, the ADS still plays an important part).

Create a user like j2ee-SID in the ADS and make sure that the settings
* Password never expires and
* Use DES encryption types for this account
are set. (in the following screenshots I will use j2ee-hbr as the service-user.)

Then run the setspn command to assign the ServicePrincipalName to the user. (this was the URL that you use to access the J2EE Engine -- all these steps are explained in detail in the first blog).

A short ldifde reveals some important parameters that we are going to use later:
sAMAccountName: j2ee-hbr
userPrincipalName: j2ee-hbr@dev16
servicePrincipalName: HTTP/vmw2153

Now, if not already done connect the J2EE to the ABAP System:

In the next screen I also used the user j2ee-hbr to connect the J2EE to the ABAP system (for this I had to created this user in the ABAP system as well). You could also use a service user as mentioned here (Requirements for the System User for UME-ABAP Communication and here Configuring the UME to Use an AS ABAP as Data Source)

Now start the configtool and add the krb5principalname as an additional ume attribute

After a restart this property will be available to all user objects in the UME. Search for your service user (j2ee-hbr, which will now be found in the ABAP system) and set the krb5principalname to the same name as the userPrincipalName of the ADS user (see above) [this can be a little confusing: you now have two users j2ee-hbr. One in the ADS and one in the ABAP system]

Now we can start the SPNego Wizard:

Make sure that krb5principalname is used for Mapping Attribute and continue:

In the next screen make sure that the KPN Prefix is set to uniquename (which is defined in the ABAP dataSourceConfiguration file.)

After testing the resolution mode continue with the next step. I always prefer to create a new template and assign this template later on to my ticket component:

That's it.

Restart the J2EE Engine and you should be done with the wizard.

Now the final step left is to assign the spnego template we created to the ticket component via the Visual Administrator:

That should be it!

Now you should be able to access the portal via SPNego. If it is not working, then please have a look at the previous blogs mentioned above..

Configuring and troubleshooting SPNego -- Part 3

At first I will take a quick look (installation and start) at the diagtool, then continue with the web diagtool. In the end you get the results with both tools: detailed traces from which you should be able to see what is causing SPNego to fail.

Diagtool

The diagtool can be downloaded from here (Note 957666 - Diagtool for Troubleshooting Security Configuration). Just copy the file to your server and start it with

go.bat conf\spnego.conf c:\usr\sap\\jc00\j2ee\configtool

Now answer the questions (ldap server, hostname, a windows username and password, Kerberos username) until you get to the part where you are asked to reproduce the problem.

Do it (access the portal from your client) and click OK. Now a ZIP file is created which you can take a look at (we will deal with that later on).

Web Diagtool

The Web diagtool (Note 1045019 - Web diagtool for collecting traces) has the advantage, that you do not have to work on the server all the time. Just deploy the file web_diagtool.ear once (using SDM) and run the tool via http://server/diagtool.

Log Analysis

Let's take a look at the log files (I will concentrate on the log files created by the web diagtool, but all this information is also available in the diagtool). At first -- like always -- we will take a look at the scenario when everything is working.
Start the WebDiagtool and select security & all and click on Go.

Click Add all.

Click Start.

Now try to log on to the server
and click on Stop and an overview page is displayed.

Click on Show All Traces (of course you can download a ZIP file version which you could sent to SAP support).

A page is displayed with general information about the system. You can also take a look at the login modules if you extend the login.modules (if you do that, you should see your login modules which can also be seen in the Visual Admin). Also all ume.properties can be displayed (but we will skip that for now).

From now on all the logs recorded are displayed. It can be a little confusing, but just scroll down until you see something spnego related (warning and error messages will be displayed in a different color and are easy to find).

Below you can see one example screenshot (keep in mind: my login was successful, but I still can see Warnings -- so this is nothing to worry about).

The first important step for us is the step where the J2EE Engine is going through the SPNego template and is looking up the service user we created in the ADS as the very first step in Part 1 of this guide. ("Received no SAPLogon Ticket. Authentication stack: [spnego]" & "Looking for credentials for ...")

Here you can see that the J2EE Engine first checks if a SAP Logon Ticket is received (this is done because we have the EvaluateTicketLoginModule as the first module in our logon stack). This is not the case and the J2EE engine is now looking up the user defined in the krb5.conf file: j2ee-j2e-vmw2053@DEV16.DEV-WDF.SAP.CORP. Everything was fine (actually in this example the credentials were already cached, but you could see the acquisition in the Wireshark trace of the last blog) and the Credentials for realm DEV16.DEV-WDF.SAP.CORP were successfully acquired.

Now the J2EE Engine can continue with the next login module.

At first you will see an Access Denied error message. This is quite alright. As we could see in the HTTP traces of Part 2 the browser tries to access the J2EE engine not knowing that it has to authenticate itself. So no ticket is sent to the J2EE Engine right away and the SPNego login module cannot succeed. Only after this first call (and the received 401 -- access denied) is the client requesting a Kerberos ticket for this server from the Ticket Granting Server. So the next access to the J2EE engine (just scroll down in the logs) looks much better:

This time we still do not have a SAP Logon Ticket, but a token ("YIIE..." -- and we know from Part 2 that this is a Kerberos token) is sent along. The J2EE Engine can interpret this token and extract the servicePrincipalName (now knowing that this ticket is indeed for this J2EE Engine).
Also -- just scroll down a little -- the user credentials YANGE1@DEV16.DEV-WDF.SAP.CORP are found in the ticket.

With this information the UME can try to lookup this user. Since we used prefixbased authentication the username is split in two parts (kpnPrefix,kpnSuffix) = (YANGE1,DEV16.DEV-WDF.SAP.CORP) and the search for this user is unique: Unique search result USER.CORP_LDAP.yange1

That's it. Now the J2EE Engine can create a SAPLogonTicket and the next time we log on the EvaluateLoginModule will succeed right away!

Now to some examples when something is going wrong.

NTLM token received

This is quite easy to detect. You can see that a NTLM token and not a Kerberos token is sent. Please make sure that all the browser settings are correct and that you access the J2EE Engine with an URL that is also registered as a Service Principal Name (e.g. if you have any DNS aliases -- or even have added the servername to your local host file). For details take a look at the previous blog.

The error can also be "Error reading ASN.1 datastructure: java.io.EOFException". That's basically the same, just check the browser settings and the SPN.

Windows integrated authentication is not enabled

If you see only one call to the J2EE Engine (the access denied we talked about before), please check the settings for the Internet Explorer again. Make sure that Windows integrated authentication is enabled.

Clock skew too great (37)

When you take a look at the logs everything seems to be fine. But then -- after the GSS Context created -- you see an error:
GSSException: Failure unspecified at GSS-API level (Mechanism level: Clock skew too great (37)).

This means, that the time difference between the Client and the Server is to great (there is a default time difference for Kerberos which is usually about 5 minutes). Please check the time of both client and server. You can also try to issue a

net time /set /domain

on the client (and on the server). It will syncronize the time from the client with the one on the domain.

Integrity check on decrypted field failed (31)

If you receive this error in the log please make sure that the password of the service user has not changed. If you are unsure, delete the folder kerberos (see Part 2) and set the username / password again. Make also sure that you selected Use DES encryption types for this account and run the Wizard all over. Before trying again clean your ticket cache (e.g. by logging of and on again). It could be that the ticket cached is wrong and you have to request a new one from the TGS (acutally this took me quite some time to figure out when I was writing this blog :-).

Acquiring credentials for realm failed

Take a close look at the realm name. Is it really spelled correctly? What about uppercase / lowercase. This can also be a problem. In the logs you can see, that the realm the J2EE engine is looking for is in lowercase. But a closer look at the attributes of this user (remember: ldifde...) shows that it is in uppercase. Follow Note 1130190 - SPNego fails with "Failed to find any Kerberos Key" to correct this.
In gerneral: make sure that the data you enter is case sensitive. Take a look at the attributes of the users created and enter the data accordingly. A similar error can also appear if the Service Principal Name you entered (remember: setspn -A ...) is missing or wrong.

Wrong JDK

Unfortunately I do not have a screenshot for this just yet, but if you encounter an error like:

Error in some of the login modules.
[EXCEPTION]
com.sap.engine.services.security.exceptions.BaseLoginException: Error in some of the login modules.
...Caused by: java.lang.NullPointerException

please make sure that you are not using Java 1.4.2_14, 1.4.2_15 or 1.4.2_16. All these versions contain a bug (Note 1057474 - NullPointerException in KRB5LoginMoule)
Thanks to the comments from Marc Lehmann and Hermann Hans to my first blog it looks like we have a workaround (at least for _15 and _16). Please try to add isInitiator = false to the com.sun.security.auth.module.Krb5LoginModule in the com.sun.security.jgss.accept component via the Visual Administrator. I haven't tried this out yet, but it seems to work!

KDC has no support for encryption type

This error should not appear anymore, when you were using the Wizard. Before that you had to create the keytab file with a ktpass command and there were different versions available. If this problem occurs: please use the Wizard. If you do not / cannot do this, take a look at Note 942111 - KDC has no support for encryption type.

One last thing

While writing this blog I did also find something which was very irritating. I had setup my VMWare client once more when SPNego simply would not work. I was going through all my checks -- but it still would not work. I did traces on the J2EE Engine and with Wireshark but everything seemed to be working -- only the Kerberos ticket would not get created. Then I decided to remove the client from the Domain to a Workgroup, I restarted the client and connected it to the Domain again -- all of a sudden it was working.

That's it. As a last section I want to provide a list of notes which deal with SPNego:

Some Notes

Note 968191 - SPNego: Central Note

Note 994791 - SPNego Wizard
Note 1082560 - SAP AS Java can not start after running SPNego wizard

Note 958107 - Using Diagtool for Troubleshooting Kerberos
Note 957666 - Diagtool for Troubleshooting Security Configuration
Note 1045019 - Web diagtool for collecting traces

Note 934138 - IE browser sends NTLM token instead of Kerberos
Note 1130190 - SPNego fails with "Failed to find any Kerberos Key"
Note 1057474 - NullPointerException in KRB5LoginMoule
Note 1079609 - SPNego token cannot be decrypted
Note 956833 - Password logon and Kerberos authentication
Note 982044 - SPNego succeeds but overall logon fails
Note 1073458 - GSS exception during SPNego authentication
Note 986060 - Kerberos service user has userPassword LDAP attribute
Note 935644 - Configuring Kerberos on NW04 against Database User Store
Note 1005209 - Double Logon Screen

OK, I hope that I have covered the most important problems you can encounter when configuring SPNego. Please feel free to point me to other issues you have seen and I will try to add them here (maybe I will create a Wiki page where we can all consolidate SPNego related issues). Also, if you have other SPNego related questions, please feel free to comment and I will think about writing Part 4 ;-)

Configuring and troubleshooting SPNego -- Part 2

In the first part I explained how to configure SPNego with the help of the SPNego Wizard. Now, that everything is set up we are going to check the configuration. At first I will simply use some tools (see below to get a summary of tools used) to "verify" the configuration, e.g. I will use the tools but the results will always be OK. I think it is always good to have one working example and then see what is different / what it should look like if you acutally have a problem.
In this blog I will not use the diagtool or Web Diagtool. Instead I am going to concentrate on some basic things you can check on the client before using these tools. So let's get startet...

For all the screenshots and description I have used the same setup as in Part 1: my user is yange1 and the server is installed on the server vmw2053.wdf.sap.corp.

The server side

First let me show you what the SPNego Wizard has done. Start the Visual Administrator and take a look at Server -> Services -> Security Provider. A new component com.sun.security.jgss.accept was created which contains two LoginModules: Krb5LoginModule and SPNegoMappingLoginModule. Both contain the options you chose when clicking through the wizard. Among other settings the Krb5LoginModule contains the properties of the Kerberos Principal user (service user) and the SPNegoMappingLoginModule the user resolution mode.

Then there is also the spnego template which contains the login modules required for a succesful login. The first entry is the EvaluateTicketLoginModule (com.sap.security.core.server.jass.EvaluateTicketLoginModule). The Login module checks whether you already have a valid SAPLogonTicket (in a federated portal scenario this ticket could also come from another portal and if you have chosen to trust this portal then the check would succeed and because of the Flag "Sufficient" you would simply skip the next modules). If the Evaluate did not work, then the next login module will be used: SPNegoLoginModule. This module does the actual SPNego/Kerberos check. The flag is Requisite so that if it succeeds it will continue with the next login module. When this login module was successful then the last login module CreateTicketLoginModule will be executed. This time a SAPLogonTicket will be created so the next time you query the portal the EvaluateTicketLoginModule will succeed right away. (For a more detailed list of what the different Flags mean, please check: http://help.sap.com/saphelp_nw70/helpdata/en/d0/ee244134a56532e10000000a1550b0/frameset.htm)

On the file system a new folder has been created under \usr\sap\SID\SYS\global\kerberos. This folder contains the keytab file which allows the J2EE Engine to access the service user (you created in the very first step in the LDAP directory) and the krb5.conf file which contains all the information about the Key Distribution Center, the Realm and the encryption type.

Maybe you have started the SPNego Wizard a second time and were wondering why only four configuration steps (instead of five) were available. Just delete the folder kerberos and you can (almost) start from scratch.

If you start the config-tool you can see that the Wizard did also add some Java start-up parameters to the server node. Among them is the location of the krb5.conf file.

One last thing (that was not done by the Wizard, but by you) is the dataSourceConfiguration file. This file (if you are using the Microsoft ADS variant) is just an enhancement of the default dataSourceConfiguration_ads_readonly_db file that comes with the J2EE Engine. The new file includes new attributes which are used by SPNego (e.g. krb5principalname, kpnprefix, dn).

The Client side

First of all log on to the client and check if you have Kerberos tokens which can be sent to the J2EE engine. In order to do this, download the tool kerbtray from Microsoft. Kerbtray is part of the Windows Resource Kit and can be very helpful.
After running the tool you can see a small green icon in your task bar. Simply right-click on it and choose List Tickets. You will see your Client Principal in the first line. This name will be used for the lookup in the UME (in the screenshot it is YANG1@DEV16.DEV-WDF.SAP.CORP).

Before explaining what is done with this ticket we want to check that a Kerberos ticket and not a NTLM ticket is sent to the J2EE Engine. The easiest way to do this is to use a HTTP Tracer like HTTPWatch. Since HTTPWatch is not freeware you can also use other tools to collect HTTP traffic (if you are going to send log files to SAP Support you can still use this tool and save the full trace which can be evaluated by SAP). A very nice (freeware) tool is YaTT. This tool allows you to easily trace the traffic. Just download it from here and install it on your client. Now start the tool and enter the URL of your J2EE engine as a Name Filter (you can also specify the port).
The tool is collecting the TCP trafic to the J2EE Engine. So start a new browser and access the URL. The first request you will see is a 401: Access denied -- which is good! The J2EE engine tells the browser that it requires some kind of authentication. Now the Client can check the Ticket Granting Server (TGS) if a ticket for this engine is available (we will come to this later). When this check was successful the client can sent a Kerberos ticket to the Engine. This ticket can be identified by the starting string YII... [NTLM starts with TIRM...].

Now that we have accessed the J2EE Engine check the Kerbtray tool again (in order to see any changes, you have to close and open the tool). You should see a new entry HTTP/yourServername. This means that your Client has requested a ticket for the J2EE Engine on this servername, which it then could provide for authentication.

This ticket contains your user name (as seen before YANG1@DEV16.DEV-WDF.SAP.CORP). Since I have chosen prefix based in my SPNego configuration the name will be split in KPN-Prefix=YANG1 and KPN-Suffix=DEV16.DEV-WDF.SAP.CORP and the J2EE Engine will try to search for YANG1 first and if this is not unique will use the suffix information to get a unique user.

That's it. Now you should be logged in.

Provided that everything is going well, we have the above scenario. However, there are plenty of pitfalls that you might encounter. One problem I encountered pretty often is, that a NTLM ticket but not a Kerberos ticket is sent. This can have plenty of reasons and the first step would be to check help.sap.com
* Enable Windows Integrated Authentication in your Web browser.
* Enable automatic logon in Intranet zone.
* Add the AS Java’s DNS host name to the list of local intranet sites.

If you did all these checks and Kerberos is still not working try it from another client (just to be sure). Then check Note 934138 where some issues with (missing) Bug-Fixes from Microsoft are deal with (Hotfixes 885887 and 899587 from Microsoft).
If it is still not working, then you will have to do a more detailed traffic trace. I will cover this in my next blog.

If no ticket is sent at all then you might have to check whether the client is able to find the J2EE Engine in the ADS. In order to setup SPNego we had to create a service user and set certain Service Principal Names to it. If there was a typo or if the name is not unique the lookup will fail. So use the next tool also available from Microsoft (it may be already installed): ldifde. ldifde allows you to query the ADS and search for any attributes.
At first I will try to find the user I created for SPNego. This can be done by issuing the command

ldifde -r (samaccountname=j2ee-j2e-vmw2053) -f sam_output.txt

-r means that ldifde is searching recursivly and -f specifies a file into which the results are written (see http://support.microsoft.com/kb/555636/en for further details).

If you take a look at the output file you will (hopefully) see entries like:

sAMAccountName: j2ee-j2e-vmw2053
userPrincipalName: j2ee-j2e-vmw2053@dev16.dev-wdf.sap.corp
servicePrincipalName: HTTP/vmw2053
servicePrincipalName: HTTP/vmw2053.wdf.sap.corp

Now that I know that my user was created (and I can see that the ServicePrincipalName (SPN) are set and correct) I want to make sure that the SPN is unique. So I am going to issue the command:

ldifde -r (serviceprincipalname=HTTP/vmw2053.wdf.sap.corp) -f spn_output.txt

It is important, that you will only get the result "1 entry exported". If you get more than one entry, then open the file and see what other user is using this SPN.
(In order to get other information about a user in the ADS you can use a LDAP browser like Softerra. It is free and I find it very helpful to get a quick overview of your LDAP structure and the user configured.)

You might also have a problem, that you are accessing the portal not with the real physical hostname, but with a DNS alias. To check whether you have really added all relevant SPNs to the user do a nslookup on the servername. Make sure that all listed aliases are also added as a SPN.
nslookup vmw2053.wdf.sap.corp

If it is still not working ...

Well, then we should take a look at the Kerberos token acquisition. For this we are going to use Wireshark. Just start Wireshark on the client and (in order to decrease the amount of data being displayed) set the filters: ip.addr == YourKDCName.
Again, I will show screenshots where the acquisition is working. In the final blog I will deal with several issues by looking not only at the Wireshark traces, but also the logs from the J2EE engine.

Start the trace (Capture -> Start) and access the J2EE via the browser.
The first thing you will see is a TGS-REQ, where the client connects to the ticket granting server to request a ticket for the J2EE engine. The J2EE Engine is known to the TGS only via the URL you are accessing the Engine: http://vmw2053.wdf.sap.corp => HTTP/vmw2053.wdf.sap.corp. This can be seen in the trace:

The next step is the response from the TGS TGS-REP: it contains the ticket which will be sent to the J2EE engine.

Here you can see the client name (this is the user that logged on to the client) and you see the ticket in the response. This is the ticket for our user and the server which we requested the ticket for.
This ticket will now be sent to the J2EE engine and from there the client name will be used and extracted (yange1@DEV16.DEV-WDF.SAP.CORP) for authentication.

You can also run the Wireshark on the server. The J2EE Engine has to acquire a ticket for the service user. That's why a firewall cannot block the access to the KDC from the server. In the logs you can see the request for this user first:

Then the KDC sends the response and this ticket is cached by the engine:

OK, that's it for the second part. In the next part I will take a look at the log files from the J2EE engine. By increasing the log level you will get valuable information about what errors are causing SPNego to fail.

Configuring and troubleshooting SPNego -- Part 1

In the last few weeks I was asked by several customers and here on SDN about configuring and troubleshooting the SPNego-login module for the J2EE Engine. So I decided to write my first blog. Actually, since there are already several blogs available that deal with setting up SPNego I am planning to write at least three parts about SPNego

the first part will be about the configuration of SPNego and some general tips (this was dealt before quite some time, but I think it belongs to a complete troubleshooting series)
the second part will deal with common problems and some tools to figure out what went wrong
the third part will deal with a more detailed troubleshooting which you might find helpful when you were not able to solve the problem with the tools from part two

Even if you are not able to solve the problem with these three blogs, I hope to be able to shed some light on what is going on. And the logs and information you will collect here will most certainly help speed up messages you might have to create.

Documentation

First of all let me say that I think the documentation about the SPNego login module is rather good. I have been working on SPNego ever since it was first developed for a customer project at SAP. From that time (of course updated since then) is the documentation you can find here on help.sap.com.
But for several months now the SPNego Wizard is available which made configuring SPNego much easier. Instead of working on several sections in the Visual Admin, on files with a text editor and so on you can use a simple web based wizard -- and are (hopefully) done within about 30 minutes. I would always recommend to use the wizard and this is what this first part is all about. Of course it is not always that simple – I had plenty of installations where something did not work right away and then you have to troubleshoot.

SPNego Wizard

Take a look at Note 994791 - SPNego Wizard.
Here you can download the SPNego Wizard (if it is not already contained with your J2EE installation). There is also a ZIP file I strongly recommend containing videos about the installation. It is fast, but with the help of the pause button of your video-player you can see everything you need to know. Also contained in the ZIP files is a PDF document and sample dataSourceConfiguration files that you can use to configure your UME to connect to your LDAP directory.
[if you are using Sun JDK for your J2EE engine, please make sure that you are using a JDK with 1.4.2_13 and not _14, _15 or _16. Unfortunately all these versions contain a bug that fails Kerberos to work, see Note 1057474 - NullPointerException in KRB5LoginMoule]

Create SPNego Service User

The first step is to configure a service user in your LDAP directory. For my screenshots I used a J2EE engine that I (will) attached to a Microsoft ADS.
Create a user in the ADS and make sure that the properties
* Password never expires
* Use DES encryption types for this account
are set.

Now set the service principal names (SPN) for this user. The SPN has to be every URL / DNS-Alias you are going to use to access the J2EE Engine -- and of course the fully qualified computer name has also to be created. Simply repeat the steps
setspn -A HTTP/servername username

for each URL. You can do a quick check via setspn –L to see if your settings were successful (all entered SPNs should be returned)

Connect the UME

Then you have to connect the usermanagement engine of the J2EE engine to the ADS. In order to do this, upload the dataSourceConfiguration file attached to the Note via the configtool [click on Browser, select the file and click on Upload]:

Then select it from the drop down list and enter all the data required.

Now you can click on Browse to select the User and the Group path where your users and groups are stored in the LDAP directory:

Make sure to test the connection and the authentication.

After that restart the J2EE Engine.

Run the wizard

Now you are all set to start the SPNego Wizard. Simply open the URL http://servername:port/spnego

The first screen is just to remind you of what you have to do as a prerequisite.

Now you have to tell the wizard something about your Kerberos setup and the LDAP attached.

(you can use either Enter Principal or Retrieve Principal. Both options should work just fine)

In the next step you tell the wizard how the lookup will work. The J2EE Engine gets the Kerberos ticket which usually is the SAMAccountName and the Domain. So in order to find the user in the UME the best way is to split the name and first search for the first part (kerbprefix, e.g. SAMAccountName) and if the result is not unique the second part (KPN-Suffix, domainname). Of course you can also try the other options simple and basic, but I would first go with prefixbased.

The first thing I would do is select the "Create new" option in order to create a new template that can be used more flexible (e.g. if you want to use SPNego with the Portal and Duet). So create a new template "spnego" (this is the default option anyway), and if you want to you can now deselect Enable Basic Password Fallback (but make sure that "Enable SSO with SAP Logon Ticket" *is* enabled.

And we are done.

Now restart the J2EE Engine.

Assign the template to the components

The final step is to assign the template you created to the login component you are using (for the Portal usually this is the ticket stack, for Duet it is the osp_TicketIssuserComponent):

Test it…

OK. If you are lucky :-) everything is fine. When you try to test your configuration make sure to do this from another computer (and not the server) and using the fully qualified domain name. If it is not working then maybe my next blog will be of use.

Stay tuned…

Use Full Tips

FAQs

BASIS Topics

How to Earn Rs.25000 every month in internet without Investment?