New SPNego login module – just around the corner
Almost always when Single Sign-On is required to Java SAP applications, the SPNego login module is the answer. After the SPNego Wizard was introduced some years ago it got really simple to configure the AS Java for Single Sign-On (See Note 994791 – SPNego Wizard and Configuring and troubleshooting SPNego — Part 1). When the AS Java was connected to an ABAP System it was possible to do the required mapping and SSO worked (Configuring SPNego with ABAP datasource — Part 2Configuring SPNego with ABAP datasource — Part 2). Even in scenarios where SSO to ABAP systems was required, the SPNego login model could easily be used to authenticate and create SAPLogon Tickets that would be accepted by the backend system (Single Sign On to BSP pages, Single Sign On to SAP NetWeaver Enterprise Search 7.2 Using Integrated Windows Authentication).
With Windows 7 and Windows 2008 R2 (and upcoming Vista SP3) there were some issues with the DES encryption that was required by the SPNego login module, but was no longer active by default. The reason for requiring DES encryption in the login module was that the APIs from Suns and IBMs Java 1.4.2 do not allow any other form of encryption. So the only workaround – if you wanted to use the SPNego login model – was to reactivate the DES encryption on Windows 7 and Windows 2008 R2 (see Note 1396724 – SPNEGO fails with Windows 7 and Windows Server 2008 R2 and SSO with SPNego not working on Windows 7 / Windows 2008 R2). Of course this was only a workaround and our development was working on a real solution. Update:
The new Login Module for 640 and 700 is here. Go to https://service.sap.com/sap/support/notes/1457499 and download the attached ZIP files. It also includes a PDF with installation instructions!
Thanks for this good news and the very interesting blog. The only problem for my company is that the new module comes too late and that we had to buy an external certified product to overcome the DES and AD 2008 limitations.
Anyway this a good move and I am happy to see that SAP listen to customers needs.
Regards,
Olivier
There is already a date when will it be available, and whether there patches for customers that doesn't want to upgrade?
Thanks
John
The host and port of the KDC (domain controller) are not necessary any more and are not entered in the wizard. Because the NW AS Java system only accepts Kerberos tokens and does not obtain such on its own there is no need to connect to the KDC. This is similar to the "isInitiator" option of Sun's KerberosLoginModule. This approach have several benefits:
- in case you have multi-realm setup but the KDC of ne realm is down this won't affect the users from the other realms
- there could be a firewall between the NW AS Java and the KDC (domain controller) and still you can configure SPNEGO authentication to the NW AS Java
To best of my knowledge the patches for the existing SPs will be released in the next few weeks (if not already released). I'll check the official release dates and update you accordingly. Later on the new SPNEGO implementation will replace the current one in the next officially released SPs.
Regards,
Dimitar
Thanks a lot.
Best Regards,
John
We implemented new add on tool to our AS Java system and started noticing issues with Windows XP SP2/SP3, Vista clients. The issue is-sometimes users get Netweaver login prompt screen and after rebooting the machine its resolved. Is there any clue why its happening? On a side note downloaded kerbtray.exe for viewing the ticket information when this is happening the kerberos ticket is expired , usually the kerberos tickets lifetime is by defualt 10 hours and when end time is reached SPNEGO SSO is failing and getting prompted for login.
with Windows XP SP2 I could explain this behavior (see https://service.sap.com/sap/support/notes/934138 and ->
"IE browser sends NTLM token when the Kerberos token has expired. IE browser must request a new Kerberos token but fails to get it due to Microsoft bug for Windows XP SP2 workstation.
Please apply Microsoft hotfix KB899587."
But this should be fixed with SP3 already...
Holger.
The colleagues have already released the add-on solution which should be applied if you do not want to upgarde to the latest SP. For details please check SAP Note 1457499 - https://service.sap.com/sap/support/notes/1457499.
Regards,
Dimitar
We are very happy to see the RC4-HMAC option for our Win7 clients, with a stronger cipher.
I downloaded and deployed the components attached to OSS 1457499 for 7.0 -
Unfortunately, the new wizard (/spnego2/cfg) and pdf doc do not resemble the screenshots in this article, and there is no option to generate a new keytab manually - only import from an existing file.
So I can add the old keytab in global/kerberos, but only have DES encryption keys from the previous SPNego implementation.
I run /spnego, and get the old wizard.
We can do a policy to enable DES on Win7, and the new SPNEGO login module works fine - which demonstrates that the new deployed module specified in the ticket login stack is working, but we seem to be stuck with DES, which is not desirable to the enterprise.
How do we generate keys for the RC4-HMAC encryption?? Is there a newer wizard forthcoming for NW70, as in the article above?
thanks
-Justin Burmeister
Update - was able to get RC4-HMAC encryption to work by running ktpass on a domain controller to generate a new RC4-HMAC keytab --JB
Hi Justin,Dimitar
Thanks
Kishore
The new login module does not use login module options for its configuration. The whole configuration is stored in the configuration manager.
You may proceed with the configuration - include the login module in the respective authentication stack.
Regards,
Dimitar
I went ahead and added the new SPNEGOLoginModule to ticket policy. I imported the keys from my existing keytab file which has only DES encryption. I am trying to login from my XP machine itself to test SSO now but I see a checksum error and SPNEGO invalid token errors in the default trace. I would like to validate with DES first before generating RC4 keytab and import the new keys. Appreciate your help
Thanks
Kishore
Hi Kishore,Dimitar
Thanks
Kishore
No, the new module does not use anything from the file system. The whole configuration is stored in the Configuration Manager (system database).
When you upload a keytab file with keys those are stored also in the database (Configuration Manager) and afterwards used from there. That's one of the reasons why the new module does not require restart when re-configuration is performed.
Regards,
Dimitar
I tried to install the new SPNEGO for another Portal now. I repeated every step that I took for the first system. The only difference: The old SPNego Module had NOT been installed on this system before.
Sorrily I now get the Checksum error, as well. I changed the LDAP service user password to a password that is similar to the one that works with the other portal, changed the UME configuration accordingly and recreated the keytab file. But nothing changed, I still get the checksum error.
Here's what the Diag Tool log says:
SPNEGO token extracted from header: SPNEGO Token [
OID: 1.3.6.1.5.5.2
NegTokenInit [
mechTypes: 1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2, 1.3.6.1.4.1.311.2.2.30, 1.3.6.1.4.1.311.2.2.10
reqFlags:
mechToken (binary): 60820ed006092a864886f71201[...]
mechListMIC (binary):
Mech Token [
OID: 1.2.840.113554.1.2.2
AP-REQ (Kerberos) [
pvno: 5
msg-type: 14
ap-options: 00100000000000000000000000000000
ticket: Ticket [
tkt-vno: 5
realm: EU.MERCKGROUP.COM
sname: [type: NT-SRV-INST, name: HTTP/deda1x0157.merck.de]
enc-part: EncryptedData [
etype: 23 (rc4-hmac)
kvno: 2
cipher: 0x9893a6529fec49ab[...]
]
]
authenticator: EncryptedData [
etype: 23 (rc4-hmac)
kvno: 0
cipher: 0xed472ff475921185e9[... (way shorter)]
]
]
]
]
]
Could the differing kvno be a cause for the checksum error? (What is the kvno?) What else could be the problem? Do you need any further information?
Thanks in advance!
Regards,
René
Check the following:
1. The token is issued for service HTTP/deda1x0157.merck.de. Is this the correct SPN that you have registered with the service user? Could it be that this one is associated with another user?
2. Have you used the correct password to generate the keytab and the RC4-HMAC? Please double check and in case of doubt re-generate the keytab and re-import the key.
3. Check that the imported key has 32 hex digits. There was bug in one of the previous versions which trimmed leading zeros and this leads to wrongly imported keys. In case of doubt download the latest version from the SAP Note and deploy it with "deploy any version" option in SDM.
If nothing of this helps open a support ticket, attach complete traces and send me the ticket number.
Regards,
Dimitar
thank you. The first point was what I hadn't recognized. I added the second SPN to the LDAP service user and now everything works fine.
The reason why the error came up was, because we're running two Portals on one server, using different ports. So we added the physical name of the server as SPN to the LDAP service user for the other portal, which caused the error. Now only the LDAP service user for this portal (the one that I tried to logon to) has the physical name of the server added as SPN.
Regards,
René
All SSO works fine with the new module but we do see intermittent login screen pops up instead of SSO. I see the error "Cannot load login module class com.sap.security.spnego.SPNEGOLoginModule." in NWA, followed by a warning message "getLoggedInUser[EXCEPTION] ... No loginmodule succeeded.." whenver SSO doesn't work. No more details after this. Will the note 1397872 help?
Thanks
Kishore
I believe you have more than one server nodes, is that correct? If yes, redeploy the add-on solution from the note (1457499) and run the wizard again (simply run it, you don't need to configure anything).
Best regards,
Dimitar Dimkin
What is the number of the support message you have opened?
Regards,
Dimitar
After correcting the load libraries, SSO is working fine on individual servers. When I try to access the portal URLs via a hardware logon load balancer (Citrix NetScalar), I see the error "NTLM token received". I made sure the alias hostnme I am using for loadbalancer is added as SPN to the Microsoft AD User.
Thanks
Kishore
Use Wireshark or similar tool on the client machine in order to check why it cannot obtain a Kerberos ticket. You have to clear the Kerberos cache on the system by logging off and on again or using "kerbtray" tool and purse the cached tickets.
Regards,
Dimitar
It appears as though the new login module, either when configured or deployed (via SDM), sets Local Properties in each Server Node, but does set anything at the Global Configuration Level. As a result, when you add a new server node, none of the SPNEGO functionality is carried over to the new node.
In our case, this results in intermittent SSO failures. SSO works fine on the server nodes that were there when SPNEGO was configured, but any added after do not work.
We'll be opening a SAP Message to have the issue looked at, so this is just a heads up to anyone who may be experiencing the same problem. Since we don't know exactly what Local Settings were added by the new LoginModule, we don't know what is missing.
Regards,
Paul
We have the requirement that we must deactivate SSO for some Users . f.e. ESS/MSS Scenario .
Is in the new SPNEGO Module a option for this ? Or any ideas how can we solve this issue ? . I think that more customers have this Problem ...
Regards Daniel
Do you mean SSO only with SPNEGO/Kerberos or also with other authentication mechanisms - e.g. client certificates?
The current SPNEGO solution does not support such feature. However there are several ways to restrict the users:
1. Depending on the user mapping mode you may not maintain user mapping data for the restricted users and thus they cannot login because they cannot be looked up by the login module
2. If the user mapping data is provisioned automatically for all users (e.g. ADS Data Source) you can implement custom login module that does enforce this restriction. It has to check who is the authenticated user and if not allowed to enter the system with SSO throw LoginException.
However it might make also sense to provide more general solution. I will discuss it with my colleagues. What version of AS Java are you using? In case we decide to extend the functionality with such feature we may consider your version with highest priority.
Regards,
Dimitar
We currently on NW7.01 SPS6. We use only SPNEGO/Kerberos and no other authentication mechanisms. The User Datasource is a Windows ADS Directory.
I think the best solution is a UME attribute or ldap attribute to enable or disable spnego for the current user .
Have you an example for a custom login module ?
If SAP decide to develop this our company would be rampup candidate
Regards
Daniel
I was thinking more in direction of assigning the restricted users to a group and then checking if they are members of this group. If one is a member then access to the system will be denied. Group assignment should be easily done also directly in the Active Directory. Is there a special reason to prefer user (LDAP/UME) attribute?
I don't have such ready to use custom login module but we can try to build one for test purposes.
Just from curiosity what is the reason to restrict SSO access for certain users? You need higher security level for users with special rights or something else?
Regards,
Dimitar
there is no special reason for the UME Attribute. But for us the best solution is that the users can decide to activate or deactivate the SSO.
The reason is that some user "need" a higher security level for the MSS Scenario. We have some discusion with our staff association about this problem ..
Regards
Daniel
if it is "just" about makeing access to MSS Scenarios more secure, the Authenticatino Schemes (http://help.sap.com/saphelp_nw70ehp2/helpdata/en/d3/1dd4516c518645a59e5cff2628a5c1/frameset.htm & http://help.sap.com/saphelp_nw70ehp2/helpdata/en/54/a334ed5bbfd5488b8cdd67b2c594a9/frameset.htm) in the portal might be an option. With this all users could log on to the "basic" portal pages via SSO, but once they try to access MSS iViews they would be prompted for username and password again.
However, I also think that there are cases where it definetly makes sense to disable SSO for certfain users/groups
Regards,
Holger.
the problem is with the Authenticatino Schemes all User must enter his password at the MSS IViews.
But only some user need to enter the password for MSS.
Regards
At help.sap.com you may find how to develop and deploy custom login module - http://help.sap.com/saphelp_nw70ehp1/helpdata/en/46/3ce9402f3f8031e10000000a1550b0/frameset.htm.
I'm attaching a source code of an example AccessControlLoginModule which I have tested successfully on AS Java 7.2 but cannot provide any warranty so you should use it on your own risk.
The example authentication stack that I have used is the following:
1. EvaluateTicketLoginModule SUFFICIENT
2. BasicPasswordLoginModule OPTIONAL
3. CreateTicketLoginModule SUFFICIENT
4. SPNegoLoginModule REQUISITE
5. AccessControlLoginModule REQUISITE
6. CreateTicketLoginModule OPTIONAL
Please note that this login module could be used only once in the stack and should be configured only after the last authentication mechanism - that's why SPNegoLoginModule is after BasicPasswordLoginModule.
The login module has the following options:
access.control.type=group|attribute - checks group assignment or user attribute
access.control.mode=deny|allow - either deny access or allow access if the user is member of the group or has the specified user attribute
access.control.group.name - the unique name of the group to check, e.g. "GRUP.PRIVATE_DATASOURCE.un:Restricted Users"
access.control.attribute.name - the name of the user attribute to check (currently only the default UME namespace is supported)
access.control.attribute.value - the value of the user attribute to be checked
Hopefully this will help you.
Regards,
Dimitar
Here is the source of the login module:
package com.sap.security.authn;
import java.util.Map;
import javax.security.auth.Subject;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.login.LoginException;
import com.sap.engine.interfaces.security.auth.AbstractLoginModule;
import com.sap.security.api.IUser;
import com.sap.security.api.UMException;
import com.sap.security.api.UMFactory;
public class AccessControlLoginModule extends AbstractLoginModule {
public static final String OPTION_TYPE = "access.control.type";
public static final String TYPE_GROUP = "group";
public static final String TYPE_ATTRIBUTE = "attribute";
public static final String OPTION_MODE = "access.control.mode";
public static final String MODE_DENY = "deny";
public static final String MODE_ALLOW = "allow";
public static final String OPTION_GROUP_NAME = "access.control.group.name";
public static final String OPTION_ATTRIBUTE_NAME = "access.control.attribute.name";
public static final String OPTION_ATTRIBUTE_VALUE = "access.control.attribute.value";
private String type;
private String mode;
private String groupName;
private String attrName;
private String attrValue;
private Map sharedState;
public void initialize(Subject subject, CallbackHandler callbackHandler,
Map sharedState, Map options) {
this.sharedState = sharedState;
type = (String)options.get(OPTION_TYPE);
mode = (String)options.get(OPTION_MODE);
groupName = (String)options.get(OPTION_GROUP_NAME);
attrName = (String)options.get(OPTION_ATTRIBUTE_NAME);
attrValue = (String)options.get(OPTION_ATTRIBUTE_VALUE);
}
private void processGroupMode(IUser user) throws LoginException {
if (groupName == null) {
throw new LoginException("Option " + OPTION_GROUP_NAME + " not configured correctly but mandatory for 'group mode'.");
}
boolean memberof = user.isMemberOfGroup(groupName, true);
if (MODE_DENY.equalsIgnoreCase(mode)) {
if (memberof) {
throw new LoginException("User [" + user.getUniqueName() + "] is a member of group [" + groupName + "]. Access denied.");
}
} else if (MODE_ALLOW.equalsIgnoreCase(mode)) {
if (!memberof) {
throw new LoginException("User [" + user.getUniqueName() + "] is not a member of group [" + groupName + "]. Access denied.");
}
} else {
throw new LoginException("Access control mode not configured correctly. Accepted values for option [" + OPTION_MODE + "] are 'allow' and 'deny'.");
}
}
private void processAttributeMode(IUser user) throws LoginException {
if (attrName == null) {
throw new LoginException("Option " + OPTION_ATTRIBUTE_NAME + " not configured correctly but mandatory for 'attribute mode'.");
}
if (attrValue == null) {
throw new LoginException("Option " + OPTION_ATTRIBUTE_VALUE + " not configured correctly but mandatory for 'attribute mode'.");
}
String[] attrValues = user.getAttribute(IUser.DEFAULT_NAMESPACE, attrName);
boolean matchingAttr = false;
if (attrValues!=null && attrValues.length>0) {
// in case of multi-value attribute only the first value will be considered
matchingAttr = attrValue.equalsIgnoreCase(attrValues[0]);
}
if (MODE_DENY.equalsIgnoreCase(mode)) {
if (matchingAttr) {
throw new LoginException("User [" + user.getUniqueName() + "] has attribute [" + attrName + "] with value ["+ attrValue +"]. Access denied.");
}
} else if (MODE_ALLOW.equalsIgnoreCase(mode)) {
if (!matchingAttr) {
throw new LoginException("User [" + user.getUniqueName() + "] does not have attribute [" + attrName + "] with value ["+ attrValue +"]. Access denied.");
}
} else {
throw new LoginException("Access control mode not configured correctly. Accepted values for option [" + OPTION_MODE + "] are 'allow' and 'deny'.");
}
}
public boolean login() throws LoginException {
String logonId = (String)sharedState.get(AbstractLoginModule.NAME);
if (logonId == null) {
return false;
} else {
try {
IUser user = UMFactory.getUserFactory().getUserByLogonID(logonId);
if (TYPE_GROUP.equalsIgnoreCase(type)) {
processGroupMode(user);
} else if (TYPE_ATTRIBUTE.equalsIgnoreCase(type)) {
processAttributeMode(user);
} else {
throw new LoginException("Access control type not configured correctly. Accepted values for option [" + OPTION_TYPE + "] are 'group' and 'attribute'.");
}
} catch (UMException e) {
throwUserLoginException(e);
}
return true;
}
}
public boolean abort() throws LoginException {
return true;
}
public boolean commit() throws LoginException {
return true;
}
public boolean logout() throws LoginException {
return true;
}
}
THANKS a LOT.
I will try the module and will share my experience
with this on this blog .
Best regards
Daniel
your LoginModule is working very well with my Ehp1 SPS6. I have created a user attribute "sso" and created a AbstractPortalComponent to set the attribute to true or false. As soon I have finished the creation of this Iview and LoginModule . I will post a reply with the source.
Best Regards
Daniel
Sry one more question .
I have change my J2EE autschemes.xml
geb_sec
and I have create a security provide with name geb_sec with your Abstract Login Module. And added this authscheme to portal iview. But it doesn't work . I receive only a IE Login Prompt for this IView.
Should this work ?
The idea is to protect special iviews with the Abstract LoginModule and the user can active / deactive the SSO Feature for this Iviews by own.
I hope it was not desribed to confuse 🙂
Best Regards
I cannot immediately say what could be the problem. Some obersvations:
1. Priority 99 (more than the default one - 20) means that when such iView is accessed for the first time re-authentication will be triggered.
2. Frontend target (basicauthentication) - it will be handled in a special way and instead of logon form an http header: "WWW-Authenticate: Basic" will be returned. This may conflict with the SPNegoLoginModule if configured in "geb_sec" because it tries to return http header with the same name but different value - "WWW-Authenticate: Negotiate".
In order to further troubleshoot the problem please check note 1045019 and apply example 3 (security -> authentication). Have a look at the collected traces if you can see the reason for the problem - search for the login module tables with LOGIN.OK/LOGIN.FAILED events and the traces before them. You may send me also the generated ZIP file at [dimitar . mihaylov AT sap . com]
Regards,
Dimitar
You have an example of the loginmodule ClientCertLoginModule? I found an example on page 6 of 24 on http://csc-studentweb.lr.edu/swp/Berg/Conferences/SAP_NW2008_and_Admin_2008/ADMIN/Track3/Track3_session5.pdf
Regards,
James
In the presentation you mentioned there is a general information what SSO technologies SAP supports as of 2008. I'm not sure about your concrete question - do you need an example how the ClientCertLoginModule is implemented?
Regards,
Dimitar
I'm trying to implement the new module in an enterprise portal 7 that is currently using the old fashioned way using a kerb5.conf file.
After reading your blog I was able to successfully configure the sso to work with users of one domain in the forest (the one I created the service user), but any try outs to validate users of other domains of the forest failed for now.
I still do not really understand what's neccessary for a sso in an AD forest. May be you can give a a hint.
In our env UME is configured for multiple-domain logon using ADS (from note 762419 using solution 1 -> we have more then 5 domains) -> is this really neccessary?
We have 7 domains in the forest, the root domain and 6 domains under it.
What I tried until now:
Try out 1: I use a service account in lets say 1.com and I create a realm in portal for it.
The service principal is set correct to the service account in this domain.
Login on with a user of 1.com to the portal sso works fine, using a user of another domain it fails.
Try out 2: I use a service account in the root domain com, and I create an additional realm for it. The service principal is set correct to the service account.
Login on with a user of com sso works fine, also logon on with a user of 1.com works fine. All other users of other domains fail.
Try out 3: I disable the realm for 1.com.
Users of com are loggedon with sso, all other users fail.
Viewing my try outs and the logs of webdiagtool I come to the result that maybe it is neccessary to have a service account in each domain. Am I right with my belief?
I red several notes of the older modules and it seems that it was possible with the old spnego module to have only one service account in one domain of a forest to get sso to work.
That's the configuration we currently use.
So, sorry for the long text. At the end I only want to get a hint on how to configure sso with the new spnego module in an active directory forest environment.
Many thanks in advance, Herwig.
What is the error that you see in the webdiagtool traces? Is it that the token cannot be decrypted or that the user mapping fails or something else? What user mapping mode have you configured?
I would propose that you open a CSS ticket in component BC-JAS-SEC-LGN and attach there webdiagtool traces from one working and one non-working test. Send me the number of the ticket at dimitar [dot] mihaylov [at] sap [dot] com.
Regards,
Dimitar
This reply is just to confirm that the new SPNEGO implementation works in AD forest. As before you need to create a single service user in one of the domains of the forest. In your particular case there were other reasons (wrong configuration) why it was not working from the beginning but after resolving them it works for you as well.
Regards,
Dimitar
Now my problem: The new SPNEGOLoginModule from the Attachment SPNego_AddOn_700.ZIP of note 1457499 works fine with DES encryption but we always get "Checksum error!" if we try to use RC4-HMAC.
As soon as I unmark "Use DES ecnryption types for this account" in the Account-tab of the service user in the ADS the Module "com.sap.security.spnego.krb5.crypto.Rc4Crypto" is involved and calculates a different checksum for the SPNEGO token.
Our portal server is based on NW 7.01 SP6, SLES10SP2 and "J2RE 1.4.2 IBM build j9xa64142ifx-20100706b (SR13 FP5)". Did anybody get RC4-HMAC-Encryption running in this environement? Could it be that RC4-HMAC encryption does not work with IBM-Java?
Regards
Günter
Hi Guenther,.
Hi Dimitar,
That's great that you got it running. I have the following requests to you:
1. Could you send me the number of the support ticket you have opened so that I can check why it was delayed?
2. Could you send me a password with which it is not working - not necessary the same if you use it for other system? Please put it in the secure logon area of the support ticket - do not post it here or send it via email. The RC4-HMAC key is generated only based on the password of the service user and I should be able to reproduce the issue by myself. My first guess would be that the ktab tool from the JDK does not work correctly with some special characters - were there 'umlauts' or other non-ASCII characters in the non-working password. Second thing could be that our import procedure does not read the key correctly. Third - some error in the decryption algorithm :).
Regards,
Dimitar
P.S.Please note that klist does not print the keys always correctly as you have already discovered this.
I'm also facing the checksum error message. The steps I've been following are equal to your steps but still no positive result.
I feel like I'm missing something small. Like you did, I changed the service user name and kept the password as simple as possible. Ëxported the keytab file and ran the SPNEGO wizard again. Unfortunately I'm still facing a checksum error.
When I look at the steps you performed. Can I conclude that you use sapldap for the UME LDAP connection properties, but also use sapldap for the "use UME unique id with unique LDAP attribute"?
Regards,
Rob
The problem that Guenther has experiensed was caused by a problem in reading keys which have leading zeros. You may check if you have the same problem by counting the hex digits of the RC4 key - they should be 32 (16 bytes).
Meanwhile I have attached to note 1457499
new "sap.com~spnego.cfg.wd.ear" in "SPNego_AddOn_700.zip" which fixes the problem. When deploying it select in SDM to deploy any version as the version is the same as before. If this does not solve the problem open a support ticket and send me the number.
Regards,
Dimitar
I suppose you mean the field
"Use UME unique id with unique LDAP attribute" in the UME LDAP data of the configtool. Here we use the LDAP attribute "samaccountname".
Regards
Günter
you are right to deactivate "Use DES encryption type for this account" in AD for the service user.
After you deactivate this option on the service user you have to create a new keytab file. Keep in mind that AD needs some time for replication the new setting, so wait some minutes before creating a new keytab file.
For the creation of the new keytab file you need at least a java runtime installation 1.5 or higher, because java runtimes older 1.5 doesn't support RC4-HMAC encryption. The java runtime can be installed on any computer, so it doesn't have to be installed on the portal box itself.
Now create the keytab file with e.g. command ktab.exe -a serviceuser@AD_DOMAIN -k Keytabfile.
After that go to spnego/cfg wizard and delete the old keys and import the keys stored in the new keytab. Save it and that's all.
Should work like this.
We run portal on Solaris, we have it running with DES and RC4-HMAC encryption.
thanks for your answer. It convinced me that I what I have done was right. The solution was to change the password of the serviceuser. With the new password the RC-HMAC encryption works as fine as the DES encryption ever did. My impression is that there are some passwords which lead to the generation of wrong keys. May be that the old password was too short (8 Bytes) or that passwords for RC4-HMAC encryption are not allowed to start with a number (which tho old password did). I don't know if there exists some password rules for that. But the problem is reproduceable. After I got SSO working with a RC4-HMAC key, I changed the password back and bang - I got the checksum error again.
Kind regards
Günter
I downloaded the SPNEGO add-on from sap note 1457499. I am trying to configure it for a client with Windows 2008 DCs and Clients running Windows 7.
I followed all the steps including removing the Djava.security.krb5.conf from the config tool, generating the new keytab with ktab on the JDK, remove the "Use DES encryption type" and update the ticket component to include SPNEGOLoginModule (old one is SPNegoLoginmodule, SPNEGO on the new one is all capitals).
I restarted the engine after that if I get "SPNEGO functionality is not enabled. All realms are disabled" wich tells me that is no longer taking the old configuration.
After that, went to creat the new realm with User Mapping mode = principal and REALM and source = ADS Data Source, enabling RC4 and DES encryptions.
I am getting the exception:
---------------------------
LOGIN.FAILED
User: N/A
Authentication Stack: ticket
2. com.sap.security.spnego.SPNEGOLoginModule OPTIONAL ok exception true Trigger SPNEGO authentication.
And on the next Login.Failed:
---------------------------
LOGIN.FAILED
User: N/A
Authentication Stack: ticket
2. com.sap.security.spnego.SPNEGOLoginModule OPTIONAL ok exception true NTLM token received in authorization header.
(Didn't include the other login modules on the stack since I don't think they are relevant, right?)
It is as if the usernams is not being send by the browser.
Any clues?
you get an " NTLM token received in authorization header" error. So probably your SPNEGO configuration is correct. Can you check the browser settings? (see http://help.sap.com/saphelp_nw70ehp1/helpdata/en/43/49a2aefd975f89e10000000a1553f6/frameset.htm).
If that is OK, is it possible that you have set the ServicePrincipalName for two users (see Configuring and troubleshooting SPNego -- Part 2 and search for "ldifde -r (serviceprincipalname=HTTP/vmw2053.wdf.sap.corp) -f spn_output.txt" -- make sure that you only get one result)
Thanks,
Holger.
Regards!
Hello together,René Schubert
Could you provide the full error message?
Does it contain something like this:
com.sap.security.spnego.SPNEGOLoginModule OPTIONAL Cannot load login module class. com.sap.security.spnego.SPNEGOLoginModule
------------------------- Loader Info -------------------------
ClassLoader name: [library:spnegoauthlib]
Parent loader name: [Frame ClassLoader]
...
If yes then this means that you have an old SPNEGO implementation configured as library (before 6.40 SP15) and you have to remove it because of conflicting class loaders.
Regards,
Dimitar
thank you for your quick response! That's almost exactly the way it looks like. The full message for the SPNEGOLoginModule is as follows:
2. com.sap.security.spnego.SPNEGOLoginModule OPTIONAL Cannot load login module class. com.sap.security.spnego.SPNEGOLoginModule
------------------------- Loader Info -------------------------
ClassLoader name: [library:ca.com~SiteMinderLoginModule]
Parent loader name: [Frame ClassLoader]
References:
interface:security
Resources:
/usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/fedutil.jar
/usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/fedsdk14.jar
/usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/servlet-api.jar
/usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/jsafeFIPS.jar
/usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/smwebasagent.jar
/usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/smjavaagentapi.jar
Loading model: {parent,local,references}
---------------------------------------------------------------
We're now trying to remove the SiteMinderLoginModule library and see whether it fixes the problem - and if not, we at least got a clue of what we have to do, if other messages like this come up.
I will keep you informed about the results.
Regards,
René
The new SPNEGO login module tries to automate the registration in the security service - see property "LoginModuleClassLoaders" in http://help.sap.com/saphelp_nw04/helpdata/en/d7/e08b17065b554ca57183a4c3a99340/frameset.htm
However it seems that if this property has non blank value it does not update it correctly. You should be able to keep SiteMinderLoginModule and configure the new SPNEGO one too. For that purpose the value of the property should be:
library:ca.com~SiteMinderLoginModule,library:spnego.lm
If this does not work then try only with:
library:spnego.lm
Regards,
Dimitar
thank you, that was a good hint. I did what you said and the problem is gone now AND SSO is working now with Windows XP. Unfortunately another problem occured, when trying to use SSO with Windows 7: The error message has changed to
2. com.sap.security.spnego.SPNEGOLoginModule OPTIONAL ok exception true Trigger SPNEGO authentication.
(and afterwards)
2. com.sap.security.spnego.SPNEGOLoginModule OPTIONAL ok exception true NTLM token received in authorization header.
This is the warning that follows:
getLoggedInUser
[EXCEPTION]
com.sap.engine.services.security.exceptions.BaseLoginException: Cannot authenticate the user.
[...]
I already took a look at
- https://service.sap.com/sap/support/notes/934138
- http://help.sap.com/saphelp_nw70/helpdata/en/43/49a2aefd975f89e10000000a1553f6/frameset.htm
But I am using IE8 and Win 7, so there shouldn't be any Win XP bugs. And the login is working with Win XP now, anyway. So most of the "global" problems can be excluded.
I found this comment here http://weblogs.sdn.sap.com/cs/user/view/cs_msg/66988, but as SSO works with Win XP, I don't think the 2nd point applies? I've also checked the IE8 settings - we only have one difference to what is recommended: We've selected "Automatic logon with current username and password" instead of "Automatic logon only in Intranet zone" - but that shouldn't make any difference in our case, or does is?
Do you have any further ideas? Thank you in advance!
One possible reason could be that the service user in the Active Drectory is still configured with DES encryption types. Windows 7 does not support DES by default and thus when requesting token woudn't send such encryption type as supported one. As a result the domain controller will respond with error that no token could be returned because it can return only encrypted with DES but Windows 7 does not support it. In end effect an NTLM token will be send to the AS Java.
The resolution is to disable DES for the service user and import valid RC4-HMAC key in the SPNEGO configuration.
If this is not your problem then try to check what is the Kerberos communication between the client and the domain controller. For that purpose use Wireshark and filter the network traffic on UDP ot TCP port 88. Also before collecting network traffic logout and login again to reset the local Kerberos cache.
Regards,
Dimitar
thank you VERY much. Disabling DES encryption for the service user was the final solution - SPNEGO is now working with Win XP & Win 7! I even didn't have to recreate the keytab file.
There's just this question left: If I disable the DES encryption, does that mean that Windows XP has to use a weaker encryption method, or no encryption at all? And the other way around: If I enable DES encryption for Windows 7, does that mean that the stronger RC4-HMAC encryption is no longer used by Windows 7 for the Kerberos authentification?
Is there a way to let Windows XP use DES and Windows 7 use RC4-HMAC encryption, or is this already the case?
Thank you so much for your support, again!
Regards,
René
- DES encryption is done with 56-bit key
- RC4 encryption is done with 128-bit key
DES is the weakest encryption algorithm supported by Windows and that's why in the past it had to be enabled explicitly and since Windows 7/Vista SP3/Server 2008 R2 it is not supported by default but only through workarounds.
In your current setup RC4 is used for both Windows XP and 7 and this is stronger then pure DES or mixed DES/RC4.
Regards,
Dimitar
As usual is this an another good blog.
We have already implemented the old SPNEGO in our double stack(NW7.0 SPS22) system. For Windows 7 users we have potential issue in the SPNEGO SSO.
As a workaround to support our windows 7 users, we have have followed the steps provided in the SAP note #1457499 and deployed the files in the SPNego_AddOn_700.zip and followed all the steps in the pdf, but the SPENGO behavior is not consistent in XP and not even working for Windows 7.
Inspite of this issue, we already have a ticket opened with SAP too, and not getting right assistance.
Kindly help us.
Kind regards,
Vijay
The following are few details from diagtool trace file during the test in Windows 7 system.
In that Windows 7 system, the kerberos setting as 'No Minimum' under Security option in GroupPolicy.
And, in the SPNEGO add-on wizard, we have the following keys
SPNEGOKey: code = 3,
SPNEGOKey: code = 23,
SPNEGO token extracted from header: SPNEGO Token [
OID: 1.3.6.1.5.5.2
NegTokenInit [
mechTypes: 1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2, 1.3.6.1.4.1.311.2.2.30, 1.3.6.1.4.1.311.2.2.10
reqFlags:
mechToken (binary): 6082066b06092a864886f71201020201006e82065a30820656a003020105a10302010ea20703050020000000a38204e6618204e2308204dea003020105a10c1b0a534552454e412e434f4da22b3029a003020102a12230201b04485454501b186f72642d7361707072746465762e736572656e612e636f6da382049a30820496a003020112a103020108a2820488048204842241968c5c30749b80756fad40ea7713f00f753df5de6640f230d3b88467bbb40f9d1f2764f47cf182eed0ae5f4d3d9885814e0a32df8dace3c6f0b132ca21ddf5cd920631bd9dcd8204785270a05bbcc55787301e8da47cb375e96f11016d967353fb2de79f960a400a9f40fbc238dc396e2e4498ca8f348aa71e04a77993fbd84eed20cb19723c49b6bc699bfe79b03d0fb5666c1baaa90f41d5bbb1e15889b4385491068f829abac4e79a7cee458b9417b8a61c749a56a65fda186acf67d3c2fcb8a03886a711ef3671e6838608b37416d2b338a5ca8f4b60ab4b409a21ad5c2695d541ed0e838e92f11dab82cc80a25c2c6fe06c27487f1703e7df6b705c13401b699da703ff726c53cba0ad6b3739457d5e9b0dddb82e8cf175dd4e08dbf4a2bdaf4f425e5c496a5d9d2ad9eaff66a7372768d62182af05e84c0e23ddfd58c624916aedbc15b489759bb880dc6d2cb2295e38cca80e90ce63b48f224261e6262af6d6c84eb0b832b31cbda6035c3a29740acefafab070b6765c9cb622e80e61b4c8a5d32d4d8ec94e98b35b32c4333ae6671ff1628208d534ec76ecddd307c106528c4a332120e524ff1a3710fa4e5164d4c4b00c0f95eac35dc318c0e9bd78607e8ed849afb945428b18f90b96f7dd7a987a1a40c4839781ad6d5c6c6493825818ac941fb11c180dfe8ccee017c905f737d1ccaa9f45fa0bde3a46afdf8c3ef398263372cad49f4e8bd00f0a860d188ffa03d42a5cdf52c36d7d82459716f07653862c38291f58d7dce782a31a9739e7abd973341f45f0d73e609cecf535f328c9577a3dcc0c692820d498eba161f64ac33ccdd228e3fe3a0a02758c8e78e6bc8fc6d84b5829abb7f2f3669eb19703776e7554f7e720c3435743d1458cfacc9bfc57e7ae2a9c44e6dcd7bf94ef0ea2cedba156795230f310717827c477d214ef7abfd486662a9e1214f843f0aa85ac9625b763f7b02d07636c8284fefbc28687f7d686c8ba92fbf9e8883fa5812280efdd5378fbdad86c46f0ab698f9bd842124677de6d05641a4a5d488b822c6bead00d5012c29c4c167afad1a728511c21dc46a8abc22683a71a6c415e1e9cedd16533d3bb70a48d32922bf4893d8a8a27ac0be9fcba052ebe8694e56f9df5645f0e21fe1bf0b89f1456ca9780dfc7536749e7b9539f30d487c918261c1fdf7421df75c4147816b3052379d58751a8b7d25939c565bf3cae7eb600f735a4961aed629589600ef43c5f021cc999e12c5d31beae3137021ebcce44b3ec545eac08f1feac6fe7a230e2ad04452fade816a450e52e2d5ae4afff28490b1f1d2b2bb11ab14da4714e13a9f4c9d18f198254e05ca7ce920411c35d293c3bcd0ee3955206d67b977a85e1f3288bfe443e21eb7882e6a502087c171346bbf682b27508faa808a263678fd2e4708b52c1b6bb156dafb8273d2502af6173b25e38bb7ce1196c249499c24a24bfe13e9fdb3499868c9a33ab5b16bc7c7bcc3fbd4d9db682a66ba7571607f19aac617a404a6cb1337ef452382bc7da7f5dfb9722ee5ef47c07210b53b8b98b44dd1f42d90f37414edb41c66516feec97e1b6d174a163c3a6cadb3567d4f24f0c3deb7d8352b915e1783f7049a482015530820151a003020112a28201480482014433cee50ba454392de08ebc4f48b0d40338ea00db8ee317c3e5ad5863b99f9d52f32493aed332d423f895b4390204450bbff7e81fb6f1d7afe2ac51b1acf72f3b3f56ceac5500e36f72fbb5a57879041b2ae00dca7aeaee4d650aa2d813cfa781a37a6c5f2b99a42dffbf935084afcb92e427ab49ecf20f99a14bf6400a66b8380382344baf56f378fff96100d9a324b17f50a7cd08887349f4d741c5756a39b6822866483388d23b4fde6656f28463a2d19602efd58b9bbda856cfd669ffb372f765dfb70476ec41619de619ef9d263a1fc548aebf8b9177bbb795754a974c412a921d3f32913dfe90e83024db476c2cb98ca58794542d7ae8a6af554025edd6fa23c4a0f0340f367bc8a9d9e659a95081b4c1d4c931b97d858ab09eb85ca7b01bc8c7bd7eadb56c08dd93a0369ea7d2d3a49b724dc607b5cbbacfd81fb939733ac4b50f
mechListMIC (binary):
Mech Token [
OID: 1.2.840.113554.1.2.2
AP-REQ (Kerberos) [
pvno: 5
msg-type: 14
ap-options: 00100000000000000000000000000000
ticket: Ticket [
tkt-vno: 5
realm: XYZ.COM
sname: [type: NT-SRV-INST, name: HTTP/xyzhost.XYZ.com]
enc-part: EncryptedData [
etype: 18 (aes256-cts-hmac-sha1-96)
kvno: 8
cipher: 0x2241968c5c30749b80756fad40ea7713f00f753df5de6640f230d3b88467bbb40f9d1f2764f47cf182eed0ae5f4d3d9885814e0a32df8dace3c6f0b132ca21ddf5cd920631bd9dcd8204785270a05bbcc55787301e8da47cb375e96f11016d967353fb2de79f960a400a9f40fbc238dc396e2e4498ca8f348aa71e04a77993fbd84eed20cb19723c49b6bc699bfe79b03d0fb5666c1baaa90f41d5bbb1e15889b4385491068f829abac4e79a7cee458b9417b8a61c749a56a65fda186acf67d3c2fcb8a03886a711ef3671e6838608b37416d2b338a5ca8f4b60ab4b409a21ad5c2695d541ed0e838e92f11dab82cc80a25c2c6fe06c27487f1703e7df6b705c13401b699da703ff726c53cba0ad6b3739457d5e9b0dddb82e8cf175dd4e08dbf4a2bdaf4f425e5c496a5d9d2ad9eaff66a7372768d62182af05e84c0e23ddfd58c624916aedbc15b489759bb880dc6d2cb2295e38cca80e90ce63b48f224261e6262af6d6c84eb0b832b31cbda6035c3a29740acefafab070b6765c9cb622e80e61b4c8a5d32d4d8ec94e98b35b32c4333ae6671ff1628208d534ec76ecddd307c106528c4a332120e524ff1a3710fa4e5164d4c4b00c0f95eac35dc318c0e9bd78607e8ed849afb945428b18f90b96f7dd7a987a1a40c4839781ad6d5c6c6493825818ac941fb11c180dfe8ccee017c905f737d1ccaa9f45fa0bde3a46afdf8c3ef398263372cad49f4e8bd00f0a860d188ffa03d42a5cdf52c36d7d82459716f07653862c38291f58d7dce782a31a9739e7abd973341f45f0d73e609cecf535f328c9577a3dcc0c692820d498eba161f64ac33ccdd228e3fe3a0a02758c8e78e6bc8fc6d84b5829abb7f2f3669eb19703776e7554f7e720c3435743d1458cfacc9bfc57e7ae2a9c44e6dcd7bf94ef0ea2cedba156795230f310717827c477d214ef7abfd486662a9e1214f843f0aa85ac9625b763f7b02d07636c8284fefbc28687f7d686c8ba92fbf9e8883fa5812280efdd5378fbdad86c46f0ab698f9bd842124677de6d05641a4a5d488b822c6bead00d5012c29c4c167afad1a728511c21dc46a8abc22683a71a6c415e1e9cedd16533d3bb70a48d32922bf4893d8a8a27ac0be9fcba052ebe8694e56f9df5645f0e21fe1bf0b89f1456ca9780dfc7536749e7b9539f30d487c918261c1fdf7421df75c4147816b3052379d58751a8b7d25939c565bf3cae7eb600f735a4961aed629589600ef43c5f021cc999e12c5d31beae3137021ebcce44b3ec545eac08f1feac6fe7a230e2ad04452fade816a450e52e2d5ae4afff28490b1f1d2b2bb11ab14da4714e13a9f4c9d18f198254e05ca7ce920411c35d293c3bcd0ee3955206d67b977a85e1f3288bfe443e21eb7882e6a502087c171346bbf682b27508faa808a263678fd2e4708b52c1b6bb156dafb8273d2502af6173b25e38bb7ce1196c249499c24a24bfe13e9fdb3499868c9a33ab5b16bc7c7bcc3fbd4d9db682a66ba7571607f19aac617a404a6cb1337ef452382bc7da7f5dfb9722ee5ef47c07210b53b8b98b44dd1f42d90f37414edb41c66516feec97e1b6d174a163c3a6cadb3567d4f24f0c3deb7d8352b915e1783f7049
]
]
authenticator: EncryptedData [
etype: 18 (aes256-cts-hmac-sha1-96)
kvno: 0
cipher: 0x33cee50ba454392de08ebc4f48b0d40338ea00db8ee317c3e5ad5863b99f9d52f32493aed332d423f895b4390204450bbff7e81fb6f1d7afe2ac51b1acf72f3b3f56ceac5500e36f72fbb5a57879041b2ae00dca7aeaee4d650aa2d813cfa781a37a6c5f2b99a42dffbf935084afcb92e427ab49ecf20f99a14bf6400a66b8380382344baf56f378fff96100d9a324b17f50a7cd08887349f4d741c5756a39b6822866483388d23b4fde6656f28463a2d19602efd58b9bbda856cfd669ffb372f765dfb70476ec41619de619ef9d263a1fc548aebf8b9177bbb795754a974c412a921d3f32913dfe90e83024db476c2cb98ca58794542d7ae8a6af554025edd6fa23c4a0f0340f367bc8a9d9e659a95081b4c1d4c931b97d858ab09eb85ca7b01bc8c7bd7eadb56c08dd93a0369ea7d2d3a49b724dc607b5cbbacfd81fb939733ac4b50f
]
]
]
]
]
and...
Login module com.sap.security.spnego.SPNEGOLoginModule from authentication stack ticket does not authenticate the caller.
and...
2. com.sap.security.spnego.SPNEGOLoginModule OPTIONAL ok exception true No key (etype: 18) for realm XYZ.COM available.
Kind regards,
Vijay
As far as I could see the ticket and authenticator are encrypted with etype: 18 (aes256-cts-hmac-sha1-96). This is not supported by the SPNEGO add-on version for AS Java 6.40 and 7.0. It is supported only on AS Java 7.2 and 7.3.
In order to resolve your issue you have to disable AES128 and AES256 encryption types for the service user in Active Directory. In this case RC4 will be used for all clients - Windows XP and Windows 7.
Regards,
Dimitar
Could you please suggest me.... Is there any way can I edit that content?, but I tried and could not see any options available.
Kind regards,
Vijay
We have disable the AESxxx encryption for the service user in ADS as per your suggestion, and now IE8.0 in windows 7 system works fine with the SPNEGO SSO, where as Firefox(v - 3.6.10) shows just the Portal login screen without any errors.
Note:
In firefox, userid and password were saved for the portal and we have done the configuration settings specified in the SPNEGO Configuration Guide.pdf for Firefox browser, in spite of this when we try to access the Portal URL using the Firefox it shows only the Portal login screen without any errors.
Please help.
Kind regards,
Vijay
This sounds line configurtion problem in Firefox. Please check the following:
1. The host name you use to access the server is entered in Firefox option "network.negotiate-auth.trusted-uris". Double check what host you do use - short name, FQDN, etc.
2. Use HTTPWatch or similar tool to check if the browser sends SPNEGO token to the server - e.g. HTTP header "Authorization: Negotiate Y...".
3. If the setting in FF are ok, the browser sends SPNEGO token to the server then collect server traces with the web diagtool from SAP Note 1045019 and try to analyze them. If you see some errors/warnings and think they are relevant please paste here.
Regards,
Dimitar
Hi Dimitar,<br/><br/>Thanks for your response.<br/><br/>I have used webdiagtool in both the cases such as when I tested using Firefox(3.6.10) and IE(8.0) in windows 7 system.<br/><br/>From the diagtool traces, I found the following<br/><br/>When I tested with IE8, I have found the following entry in the log as follows:<br/><br/>Authorization header read from HTTP request: Negotiate YIIHqAY....<br/><br/>When I tested with Firefox(Note: firefox configuration were OK as per the SPNEGO Configuration Guide.pdf), I have found only the following entry in the log as follows:<br/><br/>Authorization header read from HTTP request: Vijay
The missing auhtorization header means that Firefox does not send SPNEGO token to the server. There should be some configuration error in the Firefox browser. Could you please double check the value of option "network.negotiate-auth.trusted-uris". Is the host name you use to access the AS Java included there? If there are multiple entries could you please remove them and leave only this single host? Also check if proxy is used and temporary disable it.
Regards,
Dimitar
I have verified this entry "network.negotiate-auth.trusted-uris" in firefox and that is having right AS Java host name mentioned.
And, I have tried with disabling the proxy too.
But I have no chance in the behavior of Firefox Version(3.6.10) browser.
Kind regards,
Vijay
I'm running out of ideas. If you are sure it is not a configuration issue then:
- try from another computer joined in the domain
- freshly install FF 3.6.11 on another computer and try from there
- uninstall FF, reboot, and freshly install 3.6.11 on your computer and try again
However the symptom to not send any token (neither SPNEGO nor NTLM) is in most of the cases caused by a configuration issue in the browser.
Regards,
Dimitar
The user is the VPN user and does the VPN access influence in SPNEGO add-on behavior when the user is using Firefox browser while access the Portal?
Note:
IE8.0 works like charm, but the issue is with Firefox(V 3.6.11) only.
Kind regards,
Vijay
I do not know if the VPN setup affects the Firefox browser. Have you tried to use Firefox from the local Intranet? Does it work in this case?
Regards,
Dimitar
Thanks for your precise guidance to resolve our issues.
Now the Firefox issue has been resolved.
But, we wanted to go over the configuration steps once again before we implement this solution in our PROD landscape, Please provide us a consolidated steps that needs to be followed especially in the ADS side by our ADS admin.
FYI, we already have a service user in ADS but we wanted to remove that and we are planning to follow the instructions starting from service user creation,...etc and disabling the encryption types in ADS
Thank you.
Kind regards,
Vijay
If you start from scratch then just follow the steps described in this blog. I think the major problem that you have encountered was that the service user was enabled for DES encryption types. This setting prevented it from working with Windows 7. But if you create a new service user this won't be the case so just follow the instructions and it shall work without any troubles.
Regards,
Dimitar
Under this tab on the portal page it says krb5principlename - and in here we add the user’s details to logon via SSO.
In the OLD SPNego wizard - Users can log on from multiple domains etc using windows XP.
However I have now updated to try and use the new SPNEGO for windows 7, but cannot get it to use this field.
I have tried most settings etc, but to no avail,
Any chance you point me in the right direction top get this working?
I have already implemented the old SPNEGO in our NW7.1 SP3 Portal system.
The UME is in a separate ABAP system ECC 6.0 (Enhancement Package 4/ NW 7.1).
For Windows 7 users we have potential issue in the SPNEGO SSO.
I have followed the steps provided in the SAP note #1457499 and deployed the files in the SPNego_AddOn_700.zip and followed all the steps in the pdf, but on the User Mapping tab, I don´t know exactly what Mapping Mode/Source do I should use.
Using 'principal only' and 'logon id' i have the error: "User authentication failed" in the Portal logon screen.
Can anyone help me?
Thanks.
What user mapping/resolution have you used with the old SPNEGO?
Regards,
Dimitar
Thanks for your reply.
With the old SPnego I used Prefix-based.
KPN Prefix: uniquename
KPN Suffix: dn
Another info: all users have the same Id in the AD and UME (SAP ABAP).
Regards.
Arnaldo Calçada.
If you have a single domain configuration then I would recommend to use mapping mode "principal only" with source "logon id". This means that the SPNEGO login module will take only the principal (user id) from the received Kerberos Principal Name (KPN) - e.g. "john" from "john@COMPANY.COM", and search afterwards in UME for user with such logon id.
Regards,
Dimitar
since we have updated to the new spnego . We have trouble with UME Users from location without spnego. When we change the password to a inital password for a special UME User.
And the users try to login with the new inital password the logon screen shown again. It look like the password is wrong but it is 100% right .
The spengo Settings are :
Mapping Mode : principa only
Source : logon id
Very strange
Regards
When we implemented old spnego we started getting windows pop-up for username/password on hitting portal URL. We are getting that in New SPNego too (following note 1457499) - probably that pop-up still coming from old one as we didn't uninstall or undo anything to take out old one before applying new. We get to the portal logon screen regardless we provide user login info or cancell that pop-up. Diagtool shows that the SPNEGOLoginModule was triggered but failed to authenticate the user as follow;
Login Module
1. com.sap.security.core.server.jaas.EvaluateTicketLoginModule SUFFICIENT ok false true
#1 ume.configuration.active = true
2. com.sap.security.spnego.SPNEGOLoginModule OPTIONAL ok exception true Trigger SPNEGO authentication.
3. com.sap.security.core.server.jaas.CreateTicketLoginModule SUFFICIENT ok false true
#1 ume.configuration.active = true
4. com.sap.engine.services.security.server.jaas.BasicPasswordLoginModule REQUISITE ok false false
5. com.sap.security.core.server.jaas.CreateTicketLoginModule REQUISITE ok false true
#1 ume.configuration.active = true
and the list of exceptions in the diagtool is;
getLoggedInUser
[EXCEPTION]
com.sap.engine.services.security.exceptions.BaseLoginException: Cannot authenticate the user.
at com.sap.engine.services.security.login.ModulesProcessAction.run(ModulesProcessAction.java:180)
at java.security.AccessController.doPrivileged(AccessController.java:246)
at com.sap.engine.services.security.login.FastLoginContext.login(FastLoginContext.java:181)
at com.sap.engine.system.SystemLoginModule.login(SystemLoginModule.java:90)
.
.
.
.
.
at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104)
at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)
Caused by: javax.security.auth.login.LoginException: Trigger SPNEGO authentication.
Unfortunately not getting good help from SAP. If you or anyone please show me a right direction if I am making any mistake or missing anything then it it will be greatly appreciated.
Thanks
Check that the portal host name is registered in the Local Intranet sites of the browser. SPNEGO authentication is working by default only if the host is in the Local Intranet. If this is already the case I would propose to open a support ticket with SAP, attach diagtool and HTTPWatch traces. Send me also the number so that I can check it.
Regards,
Dimitar
Sorry for late reply as I have been on vacation since then. I confirmed earlier that hostname is registered in a way that if portal is myportal.domain.com then in Local Intranet sites it is listed as *.domain.com. I attached all of those supported files to the ticket# 651930 / 2010.
Any help from your side would be greatly appreciated.
Thanks
As far as I could see from the description in the support ticket the step to assign an SPN to the service user is failing. This could be because you are executing the command with user that does not have permissions to do this. Please check this with your AD administrator. Without an SPN assigned to the service user the SPNEGO authentication won't work.
Regards,
Dimitar
Hi Dimitar,Navaid
I am trying to deactive Kerberos so that I could log in as ADMINISTRATOR or as few other test users. UME is integrated to LDAP. Including the GET paramter in the URL doesnt seem to help both in IE and FF.
Kindly help.
Thanks and regards,
Rosun
1. Are you using the new SPNEGO add-on?
2. Which application are you accessing - Portal, User Admin, NWA, other?
Regards,
Dimitar
Thanks for the reply.
Yes, I am using Spnego add-on.
I am using Portal.
Regards,
Rosun
Hi Rosun,Dimitar
Hi Dimitar,Rosun
And I was trying to deactivate it using http://
Try this one - https:///irj/portal?spnego=disabled.
Hi Dimitar,Rosun
Then open a support ticket.
Regards,
Dimitar
I am able to deactivate Kerberos in IE by unchecking 'Enable Integrated Windows Authentication'. But the problem here is even the default login by ID and password also gets deactivated. This remains the same until I explicitly go to VA and remove SPNEGOLoginModule and rearrange the login modules.
Any inputs at this stage?
Regards,
Rosun
As already proposed please open a support ticket with SAP so that the colleagues could investigate the problem. If you want you can reply with the ticket number here so that I could forward it to them.
Regards,
Dimitar
I happen to run diagtool today. The trace says:
com.sap.engine.services.security.exceptions.BaseLoginException: Call logout before login.
I have lodged an OSS message for the same.
Regards,
Rosun
It was a problem with my login modules. I had only one CreateTicketLoginModule in my stack. SAP advised me to add another one at the end. I am able to login with alternative ID's too now.
Thanks a lot!
Rosun
We needed to upgrade the portal to the newest SP (in this case SP23 for NW 7.0), but JSPM throws an error while deploying the LM-Tools I get Error: Aborted: software component 'LM-TOOLS'/'sap.com'/'MAIN_APL70P23_D'/'1000.7.00.23.0.20101122115451'.
On further investigation, I see that it it fails while trying to upgrade sap.com/tc~sec~auth~spnego~wizard, I get java.rmi.RemoteException: Cannot deploy application sap.com/tc~sec~auth~spnego~wizard, Reason: Clusterwide exception.
Any of you have experienced similar problem? any ideas?
Undeploy the "sap.com~spnego.cfg.wd.ear" application from the add-on solution and then continue with the upgrade. Then you should face no more problems related to the SPNego wizard.
Best regards,
Dimitar Dimkin
Can you please clarify something for me, as we have had the same issue when applying NW 7.01 SP08.
After undeploying sap.com~spnego.cfg.wd.ear and then deploying the NW 7.01 SP08, we appear to have losr the spnego2 config wizard. We now get a "404 not found" error.
In addition, according to Note 1457499, the new SPNego solution is included in NW 7.01 SP08. If we install a new NW system out of the box and patch it tp NW 7.01 SP08, do we need to deploy the SPNego Add-On as per Note 1457499. The reason I ask is that we also undeployed spnego.lm and spnego.cfg before applying the Support Pack, but there does not appear to be any spnego.lm or spnego.cfg in NW 7.01 SP08. Has spnego been delivered differently in the Support Pack vs the Add-On?
I have configured SPNEGO as mentioned in the SNote attached PDF on a trial Netweaver 7.01 SPS3 installation (JRE 1.4.2.26) with ABAP datasource without much luck (ABAP datasource is in sync with ADS accounts).
Using Diagtool I have found that SPNegoLoginModule receives NTLM token in the header. All the requirements are confgured in IE v7 to avoid NTLM issue and correct Hotfix has been applied to the OS (confirmed that via regedit). Kerbtray reveals that I do have a valid kerberos ticket with RC4-HMAC encryption.
I do notice an additional logon MS window pop-up (with 'remember my password' checkbox). I have entered both correct and incorrect passwords and don't receive any feedback however on both occassions I am thrown onto portal logon screen which only accepts ABAP passwords. When I enter ADS credentials on this screen nothing happens and no feedbacks received still.
Any help would be appreciated.
Thanks
Vipul
Use Wireshark to see why the client fails to obtain a Kerberos token from the domain controller. Before running the rool either logof/logon or purge the cached tickets with kerbtray tool.
In most of the cases a browser popup for credentials appears because the system is not added to the local Intranet sites. Check also these settings of your browser.
Regards,
Dimitar
Kerberos is working for 1st domain ex. D1.COM:
domain: D1.COM
service account: D1\s1d1
userPrincipalName: host/sapweb.d1.com@D1.COM
servicePrincipalName: HTTP/sapweb.d1.com
ktab -a host/sapweb.d1.com@D1.com -k ktd1.keytab
ktab -a HTTP/sapweb.d1.com@D1.com -k ktd1.keytab
To add the second realm, how do I set up service account and keytab file?
Is this correct:
domain: D2.COM
service account: D2\s1d2
userPrincipalName: host/sapweb.d1.com@D2.COM
servicePrincipalName: HTTP/sapweb.d1.com
ktab -a host/sapweb.d1.com@D2.com -k ktd2.keytab
ktab -a HTTP/sapweb.d1.com@D2.com -k ktd2.keytab
After I run spnego2 Kerberos is working for D1.COM users, but for D2.COM users I get the error:
Could not validate SPNEGO token. Reason: Checksum error.
Do I need to run keytab logged in to D2.COM domain?
Any other comments regarding the setup?
Thanks!
I would propose to check the blog on how to create and configure service user in Active Directory. How to create a keytab file is described in the PDF attached to note 1457499. The number of domains/realms does not affect this procedure.
I strongly recommend not to use "ktpass" at the domain controller because of the many issues with it. It seems that you have used it because of the "strange" userPrincipalName-s. If necessary delete the existing ones and create new ones.
In your case the keytab files should contain keys for s1d1@D1.COM and s1d2@D2.COM.
Regards,
Dimitar
We configured userprincipalname as logon id.
Userprincipalname in our ADS is identical to the emailadress, for example user.n@mycompany.de
Now using new SPNego login module, no mapping method works. It comes with principal=user_n (samaccountname) and realm=DE.MYCOMPANY-NET.DE.
Any help?
Try using mode="principal@REALM" and source="user attribute", where the value of the attribute would be "userprincipalname". This means that the whole string that arrives, "user.n@mycompany.de", will be searched for in the "userprincipalname" attribute.
Best regards,
Dimitar
I tried to map to userprincipalname.
But our microsoft staff defined upn as the user.n@mycompany.de.
So there is no user found, searching by user_n@DE.MYCOMPANY-NET.DE.
SSO works by using mapping method principal only and logon alias. But this is not correct, cause it could happen, that we have the same logon alias in different domains.
I thought about the option principal AND realm. But it is not possible to choose different ADS Datasource attributes, for example sammaccountname and cn.
Best regards
Helge
Well, it all depends on what unique attributes you have and how they relate to the KPN used by Kerberos - as you say, user_n@DE.MYCOMPANY-NET.DE. If you separate the string, the value of principal will be "user_n" and the value of REALM - "DE.MYCOMPANY-NET.DE". If the "samaccountname" and the "cn" attributes have the correct values assigned to them and if they are mapped to UME attributes, then you can use this mode, it should work. If not, you have to find an attribute which is unique.
Best regards,
Dimitar
Hi Helge,Dimitar
the section
is missing in our datasource file. Could I just insert it?
Best Regards
Helge
Hi Helge, <physicalAttribute name="null"/> <physicalAttribute name="null"/> <physicalAttribute name="null"/><br/> </attribute><br/> </nameSpace> <br/> </principal><br/><br/>Regards,<br/><br/>Dimitar
I changed the xml-file as you told.
But SPNego fails again. This is what the diagtool says:
15:05:29:297 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~p.security.spnego.cfg.SPNEGOUserMapping User mapping SPNEGOUserMapping: mode = principal_and_REALM, source = ads converted to user mapping filter [[principal],[realm]]
15:05:29:298 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~m.sap.security.spnego.SPNEGOLoginModule User mapping filter to be used for resolving local user: [principal],[realm]
15:05:29:298 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~m.sap.security.spnego.SPNEGOLoginModule KPN extracted from encrypted ticket: stuehrman_h@DE.UHLMANN-NET.DE
15:05:29:303 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~urity.spnego.util.SPNEGOUserMappingUtil User mapping filter [[principal],[realm]] will be used to map KPN [stuehrman_h@DE.UHLMANN-NET.DE] to a local user.
15:05:29:304 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~urity.spnego.util.SPNEGOUserMappingUtil SPNEGOUserMapping case: [principal],[realm]
15:05:29:305 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~urity.spnego.util.SPNEGOUserMappingUtil Searching for user by account attributes: [[namespace: com.sap.security.core.authentication, name: principal, value: stuehrman_h], [namespace: com.sap.security.core.authentication, name: realm, value: DE.UHLMANN-NET.DE]]
15:05:29:331 Warning Guest SAPEngine_Application_Thread[impl:3]_37 ~urity.spnego.util.SPNEGOUserMappingUtil User not found by account attributes: [[namespace: com.sap.security.core.authentication, name: principal, value: stuehrman_h], [namespace: com.sap.security.core.authentication, name: realm, value: DE.UHLMANN-NET.DE]]
15:05:29:332 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~es.security.authentication.logincontext Login module com.sap.security.spnego.SPNEGOLoginModule from authentication stack ticket does not authenticate the caller.
Could you please open a support ticket with SAP and send me the number? Please attach the used datasource file so that I could check it. Meanwhile I'll write a small JSP page which shows the "principal" and "realm" account attributes so that you can check if they are at all retrieved from AD and and if yes what their values are. Unfortunately the standard User Admin application cannot show account attributes and cannot be used in this case.
Regards,
Dimitar
Hi Dimitar,Helge
the section
is missing in our datasource file. Could I just insert it?
Best Regards
Helge
I read most of the blogs and everyone talks about SPNEGO set up with portals UME being LDAP. Our portal has database as the UME and I followed the steps specified and it doesn't work (In the logs I find that NTLM token is found in the header and unable to authenticate). So my question is will the SSO work for CE 7.2 with Database UME?
The SPNEGO works with any UME persistency. It is just a matter to select the right mapping mode - for example if the user ids in the AD and in UME database are matching then select mapping mode "principal only" with source "logon id".
However the error that you get with the NTLM token is not related to how users are mapped because the server do not even receives a valid SPNEGO token. You have to check the configuration in the AD and in your browser:
- do you use the correct hostname to access the CE system
- is SPN registered in AD with this hostname
- is the SPN unique in AD, e.g. assigned to a single user
- do you use HTTP proxy
Also you may check what is happening on the wire and why the browser fails to obtain Kerberos ticket from the domain controller:
- logoff/logon or alternatively purge Kerberos tickets using Kerbtray
- start Wireshark
- repeat the test to logon to the CE system
- stop Wireshark
- filter the collected data on TCP or UDP port 88 and check what KRB5 messages were exchanged with the domain controller
Regards,
Dimitar
We had 2 service accounts registered for the same SPN, once we removed one service account, it worked just fine. New SPNego is really simple and easy to set up.
I was trying to use Logon Alias to do the mapping between AD user account and portal user account, but the Logon Alias says "Logon Alias is mapped to Logon ID". Is there anyway that I can use a different value in this Logon Alias? Please let me know.
Thanks
Sasi
Good blog. My client is using NetWeaver CE 7.1 (with SAP Sourcing on top). From the documentation it suggests that this is not supported, but other comments suggest it will work. Does this work on CE 7.1?
Many Thanks
Paul
Paul
This blog really helps..
Changing with both Authenticationa and authorization to Email, SPNEGO worked for me.
Thanks for great blog.
And I hope you will give me some advice why this is not working for me.
I am trying to configure SAP Portal to login without login screen. I made all steps according to note 1488409 - New SPNego Implementation.
Java SupPack level is 24.
But after all steps portal login screen didn't change, it still asking name/pass.
How and where can I look, why SPNego configuration is not working?
ABAP part has BASIS SupPack 22 level - can this be a reason for problems?
Thanks,
Ilgvars
Unfortunately without traces I can't say anything. You can deploy the Web diagtool from Note 1045019 on the AS Java, start it with the locations described in Example 1 and collect the traces while reproducing the problem. If you are not able to figure out what is wrong by looking at them, the best option is to open a new OSS message in component BC-JAS-SEC, describe how you configured the engine and attach the generated ZIP file.
Best regards,
Dimitar
I have reached a situation when portal logon screen says "User authentication failed", before entering username and password.
I would be very grateful if you would look at the following errors, may be you have some ideas what is wrong.
Mapping mode is Principal only/Logon alias
file ./j2ee/cluster/server0/log/defaultTrace.5.trc contains:
*------------------------------------------
#1.#00096BEEC10E007400000003001250240004AC0DE4C60D66#1315075579579#com.sap.security.core.server.jaas.spnego.krb5.KrbApReq#sap.com/irj#com.sap.security.core.server.jaas.spnego.krb5.KrbApReq#J2EE_GUEST#0##n/a##033c6908d65d11e0b61c000008be0ba6#SAPEngine_Application_Thread[impl:3]_31##0#0#Error##Plain###Clock skew too great. Client time: 1315075949000#
#1.#00096BEEC10E007400000004001250240004AC0DE4C60F71#1315075579579#com.sap.security.core.server.jaas.SPNegoLoginModule#sap.com/irj#com.sap.security.core.server.jaas.SPNegoLoginModule#J2EE_GUEST#0##n/a##033c6908d65d11e0b61c000008be0ba6#SAPEngine_Application_Thread[impl:3]_31##0#0#Error##Java###Could not validate SPNEGO token.
[EXCEPTION]
{0}#1#java.lang.Exception: Clock skew too great. Client time: 1315075949000
at com.sap.security.core.server.jaas.spnego.krb5.KrbApReq.throwValidationException(KrbApReq.java:112)
at com.sap.security.core.server.jaas.spnego.krb5.KrbApReq.validate(KrbApReq.java:105)
at com.sap.security.core.server.jaas.SPNegoLoginModule.parseAndValidateSPNEGOToken(SPNegoLoginModule.java:294)
at com.sap.security.core.server.jaas.SPNegoLoginModule.processAuthorizationHeader(SPNegoLoginModule.java:439)
at com.sap.security.core.server.jaas.SPNegoLoginModule.login(SPNegoLoginModule.java:140)
at com.sap.engine.services.security.login.LoginModuleLoggingWrapperImpl.login(LoginModuleLoggingWrapperImpl.java:194)
*------------------------------------------
file ./j2ee/cluster/server0/log/system/server.3.log contains:
*------------------------------------------
#1.#00096BEEC10E006100000009001250240004AC0E7EBA2383#1315078162490#/System/Security/Authentication#sap.com/irj#com.sap.engine.services.security.authentication.logincontext#J2EE_GUEST#0##n/a##06c6bb7dd66311e0972c000008be0ba6#SAPEngine_Application_Thread[impl:3]_38##0#0#Info#1#com.sap.engine.services.security.authentication.logincontext#Plain###LOGIN.FAILED
User: N/A
Authentication Stack: ticket
Login Module Flag Initialize Login Commit Abort Details
1. com.sap.security.core.server.jaas.EvaluateTicketLoginModule SUFFICIENT ok false true
2. com.sap.security.core.server.jaas.SPNegoLoginModule OPTIONAL ok exception true Trigger SPNEGO authentication.
3. com.sap.security.core.server.jaas.CreateTicketLoginModule SUFFICIENT ok false true
4. com.sap.engine.services.security.server.jaas.BasicPasswordLoginModule REQUIRED ok false false
5. com.sap.security.core.server.jaas.CreateTicketLoginModule REQUIRED ok false true
6. com.sap.engine.services.security.server.jaas.ClientCertLoginModule SUFFICIENT ok false false #
#1.#00096BEEC10E00650000000F001250240004AC0E7EBAA3AC#1315078162523#/System/Security/Authentication#sap.com/irj#com.sap.engine.services.security.authentication.logincontext#J2EE_GUEST#0##n/a##06cb6e35d66311e0c2e0000008be0ba6#SAPEngine_Application_Thread[impl:3]_8##0#0#Info#1#com.sap.engine.services.security.authentication.logincontext#Plain###LOGIN.FAILED
User: N/A
Authentication Stack: ticket
Login Module Flag Initialize Login Commit Abort Details
1. com.sap.security.core.server.jaas.EvaluateTicketLoginModule SUFFICIENT ok false true
2. com.sap.security.core.server.jaas.SPNegoLoginModule OPTIONAL ok exception true Could not validate SPNEGO token. Reason: Clock skew too great. Client time: 1315078532000
3. com.sap.security.core.server.jaas.CreateTicketLoginModule SUFFICIENT ok false true
4. com.sap.engine.services.security.server.jaas.BasicPasswordLoginModule REQUIRED ok false false
5. com.sap.security.core.server.jaas.CreateTicketLoginModule REQUIRED ok false true
6. com.sap.engine.services.security.server.jaas.ClientCertLoginModule SUFFICIENT ok false false #
#1.#00096BEEC10E006500000012001250240004AC0E7EBAC4AB#1315078162531#/System/Security/Authentication#sap.com/irj#com.sap.engine.services.security.authentication.logincontext#J2EE_GUEST#0##n/a##06cb6e35d66311e0c2e0000008be0ba6#SAPEngine_Application_Thread[impl:3]_8##0#0#Info#1#com.sap.engine.services.security.authentication.logincontext#Plain###LOGIN.FAILED
User: N/A
Authentication Stack: ticket
Login Module Flag Initialize Login Commit Abort Details
1. com.sap.security.core.server.jaas.EvaluateTicketLoginModule SUFFICIENT ok false true
2. com.sap.security.core.server.jaas.SPNegoLoginModule OPTIONAL ok exception true Could not validate SPNEGO token. Reason: Clock skew too great. Client time: 1315078532000
3. com.sap.security.core.server.jaas.CreateTicketLoginModule SUFFICIENT ok false true
4. com.sap.engine.services.security.server.jaas.BasicPasswordLoginModule REQUIRED ok false false
5. com.sap.security.core.server.jaas.CreateTicketLoginModule REQUIRED ok false true
6. com.sap.engine.services.security.server.jaas.ClientCertLoginModule SUFFICIENT ok false false #
*------------------------------------------
Next week I will open OSS message, but I am not sure SAP will help because they will say it is not error.
Thanks in advance,
Ilgvars
The clock on your client machine and the clock on the AS Java system are not synchornized. The time difference is greater than 5 minutes. If the clocks seems to be in sync then especially check for different time zones, day light saving settings etc.
Regards,
Dimitar
I can not express how much I am grateful for this advice. Indeed, time difference was 7 min. After time correcting automatic login works fine. Strange that SSO for SAP ABAP instance worked without problems with this difference.
Thank you very much once more. Last thing for me is test current configuration on Windows 7 workstations.
Thanks,
Ilgvars
I looked for this file krb5.conf but in this new version doesn’t used it.
Best Regards
This is my first time configuring SPNego and I would like to confirm with you the correct procedure to use. We are using EP (7.01 SPs 08) which uses an ABAP BI (7.01 SPs 08) system as its UME data source.
If I’m not wrong I should follow the steps described in “SPNego Configuration Guide” (included in “Note 1488409 - New SPNego Implementation”). Also, as per your blogs, this one (“New SPNego login module - just around the corner”) is the one I should use as reference.
My question maybe a silly one is……the steps described in docs “Configuring SPNego with ABAP data source” and “Configuring SPNego with ABAP data source –part 2” are not longer needed for this new Spnego version right? Specially those involving the config tool? Following only this blog is ok?
The other question …Does this procedure described for the New Spnego also work on my scenario (UME in ABAP database)?
Thanks for your help and for all these helpful blogs.
Regards