SPNEGO Problem in Netweaver old releases 6.40
During my last Netweaver 2004 migration from x86 Oracle 9 to x64 Oracle 11 I found many problems trying to reconfigure the SPNEGO configuration. Just for the context SPNEGO configuration allows you to authenticate your Windows account from the domain controller into the Portal without any password.
The main problem was that SPNEGO functionality only worked in server0 from the central instance server. Before all testings we were sure to apply all the previous steps requiered to enable SPENO functionality like set the SPN, create the valid keytab in the domain controller, modify the ticket properties in VA, execute the SPNEGO wizard, etc.
We tried several times with different configurations to solve the problem with no luck, the funny part is that it only worked for the server0 so when we add a new server process or start an application server the spnego fails. Because of this we tried to search any difference between the server0 from central instance and other server processes.
We look at the default trace for all the server processes that fails the SPNEGO functionality in this path /usr/sap/SID/INSTANCEID/j2ee/cluster/serverx/log and we found this particular error that was raising many times “Cannot load login module class (0).#1#com.sap.security.spnego.SPNEGOLoginModule”.
So we checked the values that LoginModuleClassLoaders has in the server0 configuration in configtool. Start configtool and navigate to this location: cluster-data -> instance_ID -> server_ID -> services -> security. The server0 has this property set in LoginModuleClassLoaders -> library:spnego.lm.
Then we checked this same property in the other server processes and application servers and Voila! The other server processes does not have this property applied.
Then we restarted all server nodes and the SPNEGO configuration worked fine!
Feel free to contact if you need any assistance. Don’t forget to like and rate the doc if was helpful.
Thanks. Did you ever create a customer incident to SAP support? It is clearly a bug, either with the system copy procedure or creation of additional server nodes.