[SCN NetWeaver Basis Architecture Space] Change AD Users Encryption from DES to RC4 for Portal Kerberos – SPNego
Introduction:
As of Windows Server 2008 and Windows Server 2012 Active Directory will not be supporting DES encryption by default, in favour of stronger encryption eg RC4. This is explained in Microsoft (MS) Knowledge Base Article (KBA) : http://support.microsoft.com/kb/977321 .
SPNego/Kerberos in SAP NetWeaver 7.0x systems has been supporting DES encryption by default.
For any SAP NetWeaver 7.0x systems which use SPNego/Kerberos with an Active Directory (AD) Service User which is using DES encryption, if the AD is upgraded to Windows Server 2008 or Windows Server 2012 the Kerberos/SPNego from SAP NW 7.0x will no longer work because of DES encryption not being supported by default.
This procedure explains all of the steps to change the AD Service User from DES encryption to RC4 encryption and restore the successful Kerberos/SPNego implementation on the SAP NW 7.0x system.
There is a work around from Microsoft for the AD to continue supporting DES and it is explained in MS KBA: http://support.microsoft.com/kb/977321
These are the most useful SAP OSS Notes relating to this activity:
. SAP Note 1396724 – SPNEGO fails with Vista SP2,Windows 7,Windows Server 2008 R2
. SAP Note 1457499 – SPNego add-on – checkout attached zip file relating to you NW version,
as it contains the Addon binaries and a pdf describing the steps involved
This procedure is oriented towards SAP NW EP 7.0x.
Please note this procedure is time critical and will cause a temporary outage of SPNego in the Portal, therefore, this procedure needs to be executed in close cooperation with the AD Team, especially the step of deleting the existing AD User and creating the new AD User, because when the old User is deleted SPNego will stop working and will not work until the whole procedure is completed.
Nb. This procedure involves deleting the AD User and creating new AD User, this is because the AD User cannot be copied to a new AD User because two AD Users cannot have the same SPN’s according to
. OSS Note 1313880 – SPNego with DNS aliases
Step 1, Prepare the AD User
1a, Check and Confirm which AD User you are using in the Portal UME.
Logon to Portal, Navigate -> System Administration -> System Configuration -> UME -> LDAP ->
There you can see the name of the AD User.
1b, Make a note of the password for the AD User
1c, Contact the AD Team and ask them to make a note of the SPN’s (Service Principal Names) configured in AD for this User
**************** NB, once you do step 1d) you have a system outage and certainly SPNego will not work until
You complete this procedure, therefore take care before doing step 1d) ******************************************
1d, Ask AD Team to
. DELETE this User
. Make a NEW CREATION the SAME User
. Give the NEW User the original Password
. Give the NEW User the original SPN’s
Step 2, Remove SPNegoLoginModule from Ticket Authentication Stack
. Open the Visual Administrator, navigate -> Server -> Services -> Security Provider -> Ticket -> Remove SPNegoLoginModule from the Ticket authentication stack and SAVE:
Step 3, Undeploy SPNego using the Software Deployment Manager
. Open the Software Deployment Manager – SDM
/usr/sap/SID/JCxy/SDM/program/RemoteGui.sh
Connect to your Instance SDM Port using SDM Password
Click on theUnDeployment tab
Select ‘sap.com/tc~sec~auth~spnego~wizard’ for UnDeployment and UnDeploy
. After successful UnDeployment then RESTART Java, purists might argue this is not necessary but a restart
never hurts after an undeployment
Step 4, Delete the KeyTab and Instance KRB5 files
cd to /sapmnt/SID/global/Kerberos
rm the keytab and the Instance directory – rm everything in /sapmnt/SID/global/Kerberos
Step 5, Use the SDM to Deploy the New SPNego Addon files
. Open the Software Deployment Manager – SDM
/usr/sap/SID/JCxy/SDM/program/RemoteGui.sh
Connect to your Instance SDM Port using SDM Password
Deploy these files in this order one by one:
- sap.com~spnego.cfg.wd.ear
2. spnego.cfg.sda
3. spnego.lm.sda
After successful Deployment, RESTART Java
Step 6, Install Oracle/Sun JDK 1.6
Download the Oracle/Sun JDK 1.6 from this link:
http://www.oracle.com/technetwork/java/javase/downloads/jdk6downloads-1902814.html
Download the version for Windows x86
Install JDK 1.6 on YOUR pc
Step 7, Use the Oracle 1.6 JDK on YOUR pc to create a KeyTab file
(you will need the password for the AD Service User for this step)
. open a command cmd window on your pc -> START -> run -> cmd
. cd to the Oracle JDK 1.6 / jre / bin / directory
. execute the following commands and enter the AD Service User password when requested:
ktab -a SPN -k keytab
ktab -a SPN -k keytabktab -a SPN -k keytab
PLEASE NOTE – these commands are respective to EACH SAP Portal you work on
Step 8, Copy the keytab File from YOUR PC to SAP Portal Unix/OS
. the keytab file which you created in Step #7, copy that file to
/sapmnt/SID/global/Kerberos
Step 9, Add Back The SPNegoLoginModule from Ticket Authentication Stack
. Open the Visual Administrator, navigate -> Server -> Services -> Security Provider -> Ticket -> ADD SPNegoLoginModule from the Ticket authentication stack and SAVE:
Step 10, Run the SPNego Wizard in the Portal
. Logon to your Portal using the NEW SpNego url
http://HOSTNAME:PORT/spnego2/cfg
Click ADD
Enter the name of the Realm
Click OK
Click EDIT
Configure the UserMapping Mode and Source as shown in the picture below
Now click on the KEYS tab as shown in the picture below:
Next Step, IMPORT the KeyTab which you created on your PC
a) Click ADD
b) Click Browse and browse to the location of the keytab file
c) Click IMPORT
d) Using the CheckBoxes select ALL of the RC4 keys
e) Click OK
Next, click ENABLE and then click SAVE
And then you should see the green light as shown in the screenshot below:
and now you’re done 🙂
Now you can test the Kerberos Single Sign On eg, from Citrix.
Have fun with the Portal.
All the best,
Andy.
Thanks Andy for steps ! Right now I am shifting RC4 encryption and this blog will surely help me 🙂
Hi Supriya,
I’ve just been through this fun and I thought it would make a useful blog for others, because for sure, there are going to be a lot of people affected by this, and I wonder how many of them are really aware of what is coming when their AD Teams upgrade AD to Windows Server 2008 & 2012.
All the best,
Andy.