RESTful on Tomcat AD SSO Throws This server does not allow NTLM

[NTruhan]

Hello,

In a new 4.2 SP5 Patch 3 install, I have RESTful deployed into Tomcat, not WACS. I enabled AD SSO in the environment and have it configured properly for the standard launchpad (/BOE/BI) This works fine. I took the settings for global.properties and replicated into biprs.properties for RESTful with the idm settings. When I configure the idm.allowNTLM=false which is how global.properties is configured, I get the following message when I navigate to http://URL/biprws

Message This server does not allow NTLM, but the client attempted NTLM anyway.

In addition, when I go to /BOE/BILaunchpad I get the logon page (so SSO doesn't work) and after I enter credentials, I get an Error: Logon failed for RESTful Web Services. contact system administrator.

So... I enabled the allowNTLM. idm.allowNTLM=true. Doing this throws an error in Tomcat:

javax.servlet.ServletException: KerberosFilter: Use of parameter 'idm.allowNTLM' is restricted. Filter will not load.

When I go to the /biprws/v1/logon/adsso test after enabling, I get:

<message>A java.lang.Exception occurred; original exception message VSJ authentication was not performed for this request</message>

However, going to just /biprws renders the json download and going to the /BOE/BLaunchpad works now and logs into the new Fiori Launchpad, but no AD SSO.

Has anyone been able to get AD SSO to work properly with the new Fiori Launchpad and RESTful both hosted in Tomcat, not using WACS.

Thank you.

[BasicTek]

Which KBA did you use to setup AD SSO on BI the old one KBA 1631734 or the new one KBA 2629070

When you copied the configuration did you do this for the custom folder or also the default (as there is an issue noted below with the custom). Yes this does work, tested in house.

-Tim

[NTruhan]

Well, I haven't looked at the KBA's for AD SSO in forever as I had my own documentation for it which evolved over versions and worked for the standard Launchpad SSO. It started similar to the old KB and now looks similar to the new one.

The main differences from the new KB and what I did are:

- I include forwardable=true in the krb5.ini file

- When testing AD before SSO, I use the -Dcom.wedgetail.idm.sso.password in Tomcat and not idm.password. This is removed of course once a keytab is created.
- I have the -mapuser in the ktpass for a BICMS/seviceaccount entry which is a SPN setup for the Kerberos then updating idm.princ to use the new one once mapped.
- I am also only using the RC4-HMAC-NT crypto and not ALL since the service account is also used in a 4.1 environment and it does not have the AES encryption enabled on the account.
- I still have the siteminder.enabled=false in the global.properties

- I also didn't seem to have copied the vintela.enabled = true into the biprws.properties file. I used the one from default as a template and it didn't have it there.

Here is what the AD part of the biprws.properties looks like:

sso.enabled=true
siteminder.enabled=false
vintela.enabled=true
idm.allowNTLM=false
idm.allowUnsecured=true
idm.logger.props=error-log.properties
idm.realm=XXXXX
idm.princ=BICMS/boadmin
idm.keytab=C:/WINDOWS/boadmin.keytab

I am testing standard authentication against http://server/biprws/logon/long and get the 401 unauthorized: The request has not been applied because it lacks valid authentication credentials for the target resource. If I set the sso.enabled=false then I get standard authentication to work with 200 OK. Doing this also allows it to work fine with Lumira, so I am just leaving SSO off and calling it.

[BasicTek]

I thought I had this configured but apparently not, I'll test it again and let you know

it should not need the siteminder.enabled and probably doesn't need the vintela enabled, I tried to quickly configure this but it failed for me, there was a correction on patch 1 so I may need to test on your patch. I'll update when I find out

-Tim

[former_member230921 · Accepted solution]

1. New Fiorified BI Launchpad not depending on RESTful APIs for authentication. Because classic and new BI Launchpad share same session.
2. So no need to setup ADSSO for RESTFul APIs to make Fiorified BI Launchpad work.
3. Make sure first RESTFul APIs working with normal authentication.
4. Make Sure classic BI Launchpad works with ADSSO (http://server/BOE/BI), if yes open new BI Launchpad in next ab of same browser (http://server/BOE/BILaunchpad)
5. still facing the issue , then check browser network trace and check REST URL in CMC->Applications->RESTFul Webservices

[NTruhan · Accepted solution]

I have 2 installs for testing this. Both are identical in authentication setup, including users, except for one install I configured the idm.AllowNTLM to true and the other to false.

Classic Launchpad works fine with AD SSO in both installs. the Cmc also works with manual sign-on with Windows AD on both just as reference so AD works in both environments.

I then used the Advanced REST Client to send a post request to /biprws/logon/long with an XML set of credentials to both.

The one that has the value set to true, came back as 200 OK and provided a X-SAP-LogonToken.

The one that has the value set to false, came back with 401 Unauthorized. The request has not been applied because it lacks valid authentication credentials for the target resource. Which explains the Logon Failed error when trying to login via the Fiori Launchpad.

On the install where the value is true, opening Classic Launchpad, then opening Fiori in a new tab worked.

On the install where the value is false, opening Classic Launchpad,then opening Fiori resulted in the same Logon failed Error.

However, with all of this, I was doing some of the testing on a machine that was not part of the domain! There are a very small handful of users who would access it this way. The Classic Launchpad would prompt me in Internet Explorer for credentials then go in. RESTful would behave like represented above, and so did Fiori.

I requested VM in the domain and tested there. Of course Classic just went in, no IE credential prompt. On the machine with AllowNTLM false the Advanced REST client still gave 401 Unauthorized for a user, but accessing via a browser via /biprws just provided the json, no prompt and NO ERROR!. Similarly, the AllowNTLM true install also gave a 200 OK in the Advanced REST client and when accessed via browser also just provided json, no prompt.

So it seems that when you enable AD SSO with AllowNTLM false, standard Authentication stops working for RESTful. When it is set with AllowNTLM true, standard and SSO work. Not sure if others have seen this behavior. Perhaps it is a Patch 3 bug.

Since 99% of users will be on the domain, or using a VPN to get in Fiori should they want to use it.

[former_member230921 · Accepted solution]

Are you using REST APIs for anything else apart from Fiorified BI Launchpad?

If answer is No: No need to configure ADSSO for REST APIs. verify "FioriBI.properties" in BOE webapp.

[NTruhan · Accepted solution]

Just Client tools like Lumira, etc... which I configured the AD Parameters for so manual AD Authentication works there now, not concerned about it.

[former_member230921 · Accepted solution]

If old launchpad works then new one also must work with same auth. just compare FioriBI.properties and BILaunchpad.properties in /tomcat/webapps/BOE/config/custom and default .

[former_member230921]

If you are looking for "ADSSO auth for REST APIs",

Change the configuration file (biprws.properties) in default (<INSTALLDIR>\tomcat\webapps \biprws\WEB-INF\config\default\biprws.properties).

Not only in custom config, because there is a issue in custom config.

SAP Note:

https://launchpad.support.sap.com/#/notes/2633539

https://launchpad.support.sap.com/#/notes/2613391

For More info:

https://blogs.sap.com/2018/03/16/sso-configuration-for-bi-rest-apis-on-tomcat/

https://blogs.sap.com/2018/03/16/sso-configuration-for-bi-rest-apis-on-tomcat/#comment-419481

[former_member210191]

Hi Nathan.

I just upgraded our BI Platform to 4.2 SP05 Patch 300 and I am also getting the same error when working with RESTful authentication. URL http://<BOhost>:<RESTful_port>/biprws/v1/logon/adsso throws the following exception.

I followed all considerations in SAP Notes/KBA (these include modifying biprws.properties in default and custom folders and restarting Tomcat):

2613391 - AD SSO for RESTful on Tomcat Server

2614257 - How to Enable Kerberos SSO for Restful Web Services on Tomcat

2633539 - AD SSO configuration on Tomcat BI REST Service application fails to log on

But my SSO using RESTful Web services is not working yet from SAP Lumira Discovery client. Other SSO options (not RESTFul-based) are working OK.

Try to look at these notes. Maybe you get a solution there.

Best regards,

Nacho