Configuring
Vers Versio ion n 4.5.0 4.5.0
Reference: C-CSTBOC-450 5 September 2016
Copyright Copyright © 2001-2016, CyberSafe Limited. Al l Ri gh ts Reser ved .
CyberSafe®, the CyberSafe logo, TrustBroker ®, and the TrustBroker ® logo are registered trademarks of CyberSafe Limited. All other product names, logos, or company names are used for identification purposes only, and may be trademarks or service marks of their respective owners. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of CyberSafe Limited. The information contained herein may be changed without prior notice. If associated software has been purchased with this publication, then the purchaser’s rights regarding this publication shall be in accordance with the terms of the associated software license.
Copyright Copyright © 2001-2016, CyberSafe Limited. Al l Ri gh ts Reser ved .
CyberSafe®, the CyberSafe logo, TrustBroker ®, and the TrustBroker ® logo are registered trademarks of CyberSafe Limited. All other product names, logos, or company names are used for identification purposes only, and may be trademarks or service marks of their respective owners. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of CyberSafe Limited. The information contained herein may be changed without prior notice. If associated software has been purchased with this publication, then the purchaser’s rights regarding this publication shall be in accordance with the terms of the associated software license.
Configuration Guide
Table Ta ble of Contents Copyr Cop yrig ig ht ...................... ................................. ...................... ....................... ....................... ...................... ....................... ....................... ...................... .............. ... 2 Table Tabl e of Conten Con tents ts ...................... ................................. ...................... ....................... ....................... ...................... ....................... ....................... ............. 3 Ab ou t Thi s Gui de ..................... ........ .......................... .......................... ......................... ......................... .......................... .......................... ................. .... 5 Purpose ............................................................. .................................................................................................................................. .................................................................................... ...............5 Audience ............................................................ ................................................................................................................................. ................................................................................... ..............5 Conventions ................................................................... ........................................................................................................................................ ....................................................................... ..5 How to use this guide ................................................................ ........................................................................................................................... ...........................................................6
Contac Con tacti ti ng Cyber Safe ........................ .................................... ....................... ...................... ....................... ....................... ...................... .............. ... 7 Technical Support & Feedback ............................................................... ............................................................................................................. ..............................................7 Contact Details ................................................................................................. ...................................................................................................................................... ..................................... 7
How it Works Wor ks ........................ .................................... ....................... ...................... ...................... ....................... ....................... ...................... .................. ....... 8 Stage 1 – User Authentication ....................................................................................... .............................................................................................................. .......................9 Method: HTTP Negotiate ..................................................................................................................9 Method: HTTP Basic (Active Directory Password) .........................................................................10 Method: Active Directory Director y Password ................................................................................................11 ................................................................................................11 Method: SAP Password ..................................................................................................................1 ..................................................................................................................12 2 Method: RSA SecurID Secur ID Passcode ..................................................................... ....................................................................................................13 ...............................13 ® Method: TrustBroker One Credential authentication API ..............................................................13 Stage 2 – Identity Mapping / Determine the SAP User ID & Client ....................................................15 For Kerberos authentication aut hentication m ethods .............................................................. .............................................................................................15 ...............................15 For SAP Password authentication m ethod ............................................................................... .....................................................................................16 ......16 For RSA SecurID Passcode authentication method, and other authentication methods where an external authentication server is used, but not when Kerberos authentication methods are used 17 Stage 3 – PBSA ............................................................. .................................................................................................................................. .....................................................................18 18 Stage 4 – Create an authentication auth entication context and SAP SSO2 cookie ..................................................18 The authentication context cont ext cookie: .................................................................................................18 .................................................................................................18 To change the type of authentication aut hentication context cookie cook ie used: ............................................................18 To change the authentication context cookie c ookie lifetime: ............................................................... ....................................................................19 .....19 Other cookie related configuration conf iguration parameters: param eters: ............................................................ ..............................................................................20 ..................20 Stage 5 – Check for existing logons ............................................................................... ...................................................................................................21 ....................21 Stage 6 – Logoff............................................................. Logoff .................................................................................................................................. .....................................................................21 21 There are many man y ways to process a logoff for an ICF service .........................................................22 How to configure the logoff page for NWBC ................................................................ ...................................................................................23 ...................23 How to configure the logoff logof f page for ICF services, s ervices, using SICF transaction ...................................24 ...................................24 Typical logoff logof f scenarios........................................................... scenarios...................................................................................................................26 ........................................................26
Table of Contents
Page 3
Configuration Guide
Configuration Instructions ..................................................................................... 27 Configuration for SAP BPC 10.x EPM Add-in ....................................................................................27 If you are upgrading from a TrustBroker One Credential version prior to 4.5.0..............................27 Create Key Table Entry (If using HTTP Negotiate) ............................................................................27 Determine the correct principal name .............................................................................................27 Creating a key table entry ...............................................................................................................29 Configure Identity Mapping (Using the USRACL Table) ....................................................................31 Configure ICF Services to use TrustBroker ® One Credential for User Authentication .......................32 For SAP Business Planning and Consolidation (BPC) version 10.x or later ..................................33 For SAP Fiori Launchpad ................................................................................................................33 Configure which Authentication Methods are Allowed .......................................................................33 How to change the configuration ....................................................................................................33 Example 1 – Allow HTTP Negotiate for all ICF Services except NWBC ........................................34 Example 2 – Allow HTTP Negotiate for all Integrated ITS Services ...............................................35 Example 3 – Active Directory Password for EPM Add-in ...............................................................35
Testin g and Troublesh ooti ng ................................................................................. 36 Without HTTP Negotiate .....................................................................................................................36 With HTTP Negotiate ..........................................................................................................................37
Backgro und Infor matio n ......................................................................................... 39 CyberSafe ...........................................................................................................................................39 Kerberos .............................................................................................................................................39 TrustBroker ® .......................................................................................................................................39
Table of Contents
Page 4
Configuration Guide
Ab out Thi s Guide Purpose This guide contains instructions for configuring and testing version 4.5.0 of the TrustBroker ® One Credential product. Before you make any changes you must install the product by following the instructions in: Reference
Document Title
I-CSTBOC-450
Install ing Trus tBr oker One Credenti al
Au dience This guide is for the use of IT Professionals, who are responsible for the installation and maintenance of the TrustBroker ® One Credential product.
Conventions Before you start reading this guide, it is important to understand the typographical conventions used: Style / Icon
Represents
Bold
Menus, menu options, tabs, radio buttons, check boxes, command buttons, commands, and product names.
Italic
Buttons on the screen and Keys on the keyboard.
Hyperlink
A link or an external reference. A note, providing additional information about a certain section/topic.
An important message, not to be ignored.
Example command or parameter syntax.
Output t ext
Fi l e Name
About This Guide
Textual computer output. File names and locations.
Page 5
Configuration Guide
How to use this guide First, you should read the How It Works section to gain a better understanding of the product and how it authenticates users. This will help when you make any configuration related decisions. Next, you should review the Configuration Instructions section and make any configuration changes that are required. Finally, the instructions in the Testing and Troubleshooting section should be followed so you can be sure that the product is working as it should.
About This Guide
Page 6
Configuration Guide
Contactin g CyberSafe This section provides information about whom to contact in CyberSafe, in case you have any need for assistance, or any questions, comments or feedback.
Techni cal Support & Feedback If you experience any technical problems or have questions regarding the TrustBroker ® products, or have feedback to give us on this documentation, use one of the methods described on the CyberSafe Website at https://CyberSafe.com/Support. If you have a technical problem, it is particularly important that you provide us with useful information when you make initial contact. For example, if an error occurs, please provide details of the error message, explain what you did to get the error, and provide any logs or traces which you think might be useful for us to understand the problem and help you.
Contact Details If you need to talk to somebody from CyberSafe using the telephone, or need to send us information via post, you can use the contact details provided below: Ad dr ess
Oth er Co nt act Detai ls:
CyberSafe Limited Abbey House 450 Bath Road Longford Middlesex UB7 0EB United Kingdom
Telephone:
United Kingdom: +44 203 510 6333 United States: +1 929 333 4499 Fax :
+44 207 681 2299 Web :
https://CyberSafe.com
Contacting CyberSafe
Page 7
Configuration Guide
How it Works The TrustBroker ® One Credential product is used to authenticate users when they logon to applications that authenticate users using HTTP or HTTPS (e.g. a Web browser) and when the applications are running on the SAP NetWeaver AS for ABAP platform. This user authentication involves the following stages: 1.
First, the user is authenticated using one of the available TrustBroker ® One Credent ial initial authentication methods. It is possible to configure multiple initial authentication methods, so if one method is not possible, another can be used instead. The aim is to allow users to authenticate using a single credential (e.g. their Ac ti ve Di rec to ry password), so they have fewer credentials to remember. Also, the users shouldn’t need a password for their SAP User ID anymore.
2. After the user has completed the initial authenticated, their authenticated identit y (e.g. their Ac ti ve Directory Kerberos principal name) is used to determine their SAP User ID. If their identity maps
onto more than one SAP User ID in the same Client (or in different Clients), then the user will be asked which User / Client they want. The desired SAP User ID and/or Client can also be added to the URL so that they won’t be asked. If the SAP Password initial authentication method is used in Stage 1, then no identity mapping is required as the SAP User ID and Client are determined during the authentication. 3.
If the Policy Based Secondary Authentic ation (PBSA) feature is enabled, the policy is checked to determine if the user needs to be authenticated again (secondary authentication). For example, if they are assigned a certain role in the SAP system they might be required to enter their Acti ve Directory password again, or enter an RSA SecurID Passcode, whilst other users who logon to the same system might be allowed to logon without needing any secondary authentication (e.g. Single Sign-On).
4.
Using the SAP User ID and Client determined in Stage 2, a TrustBroker authentication context cookie and an SAP SSO2 logon ticket cookie are created. These cookies are stored in the browser as domain session cookies, so that the user doesn’t need to authenticate again, unless they logoff or close all instances of their Web browser (in which case the cookies will be destroyed). The authentication context cookie can be configured as a persistent cookie so that it doesn’t get destroyed when the browser is closed. When a persistent cookie is used the user can logon, restart their browser and they won’t need to authenticate again if they access the same SAP system. The lifetime of this cookie can also be configured so it expires after any number of hours, e.g. 2 days, 1 week, 1 month, …
5.
If configured, the TrustBr oker One Credential product will check for existing sessions and ask the user if they want to cancel existing sessions or continue with the logon. The existing sessions are sometimes found if the user doesn’t logoff the application – instead they might just close their browser, which will mean the session will still be active in the SAP system.
6.
When the user has finished with the application, they can logoff, and the SAP SSO2 logon ticket cookie created in Stage 4 will be deleted. The TrustBroker authentication context cookie will also be deleted unless it is configured to persist after a logoff.
These stages are described in more details on the following pages:
How it Works
Page 8
Configuration Guide
Stage 1 – User Aut hentic ation The TrustBroker ® One Credential product includes support for many initial authentication methods. These authentication methods are described below, so you can decide which methods you want to use.
Method: HTTP Negotiate Protocol
An implementation of the HTTP Negotiate protocol (https://tools.ietf.org/rfc/rfc4559.txt). This allows Integrated Windows Authentication (IWA) to be used when users logon to SAP applications using a Web browser or authenticate using HTTP or HTTPS. The Kerberos protocol is used by the client (e.g. Web browser), and it requests a Kerberos service ticket from Ac ti ve Di rec to ry during the authentication process. SAP and other vendors often call this method of authenticationSPNEGO. Whilst SPNEGO is an IETF standard, it is not the name for a user authentication method, but is actually the name of the IETF standard used to negotiate which GSS-API cryptographic mechanism to use when more than one is supported. The HTTP Negoti ate authentication method implemented in the TrustBroker ® One Credential product is used when the browser sends an SPNEGO token inside the Authorization header. This token contains a GSS-API token which contains a Kerberos service ticket.
Usage
When using this method, the user can logon to a workstation using an Ac ti ve Di rect or y domain account, then use a Web browser or an application that uses HTTP authentication to logon to an ICF Service (e.g. applications such as SAP Fiori Launchpad, Web GUI, CRM WebClient UI, SAP Business Client, or Business Planning & Consolidation). The user’s Kerberos credentials, issued during the workstation logon, will be used to authenticate them to the ICF Service, which means that no passwords will be transmitted over the network and the user won’t be asked to enter any credentials during the logon. When using a Web browser, it is possible to disable this authentication method for a particular logon and use a different initial authentication method that is configured instead. This is useful when Single Sign-On is normally used to logon, but a user might want to logon to an application using Acti ve Directory credentials that are different to those used to logon to the workstation, or to use a different authentication method entirely such as using an RSA SecurID Passcode. They can do this by adding the query string parameter Negot i at e=Fal se to the URL used to access the application. If the user is not logged onto a workstation with a domain account the TrustBro ker One Credential product will automatically disable the HTTP Negotiate authentication method for this logon and allow the user to use another authentication method such as using an Ac ti ve Di rec to ry Password. Prerequisites
The support for IWA via the Negotiate protocol is included in Internet Explorer , Firefox , Google Chrome and Safari Web browsers. The server where SAP NetWeaver AS for ABAP and TrustBroker ® One Credential are installed does not communicate with Ac ti ve Di rec to ry domain controllers during a logon to the system. The use of SSL (https://) is optional, since passwords are NOT being transmitted over the network from the user to the TrustBr oker One Credential product. If however you want to protect application data in transit after the user has logged onto the application, then you should consider using SSL.
How it Works
Page 9
Configuration Guide
Endpoint Device Support
A Windows ® workstation can be used, if the user is logged onto a domain account. A Mac ® running OS X® can be used, since Apple have included the necessary functionality in OS X to allow authentication against Ac ti ve Di rec to ry and the Kerberos libraries included with OS X can be used by Web browsers such as Safari ®, Google Chrome® and Firefox ®. A Unix ® or Linux workstation can be used, if the workstation has been configured to authenticate the user using Kerberos (e.g. via a suitable PAM module) when they logon. The HTTP Negotiate protocol can also be used for mobile device user authentication, with the help of Kerberos constrained delegation and protocol transition features that are included in many commercial ‘gateway’ products, including those from Juniper, CISCO, Citrix and Microsoft.
Method : HTTP Basic (Active Director y Passw ord ) Protocol
An implementation of the HTTP Basic authentication protocol (https://tools.ietf.org/rfc/rfc2617.txt). This is not generally considered to be the most secure protocol, but can be useful when users logon to SAP applications and a more secure protocol is not available to authenticate the user using their Ac ti ve Directory user name and password. When the Ac ti ve Di rec to ry user name and password are passed to the TrustBroker ® One Credential product on the server, the Kerberos protocol is used to authenticate the user. Usage
Some examples (not an exclusive list) of where this protocol can be used: 1. A user authenticates using Microsoft TMG gateway authentication, and then needs to logon to SAP Fiori applications using their mobile device without re-authenticating. The TMG gateway remembers the user’s Acti ve Di rec to ry credentials and can use them to logon to the SAP system
without asking the user to re-enter them. 2.
When using the SAP BPC 10 EPM Add-in f or Micro soft Office, it is possible to use this authentication method so that the user will be able to enter their Ac ti ve Di rec to ry credentials each time they connect to BPC 10. Some users prefer this (Multiple Sign-On) instead of using Single Sign-On. For Single Sign-On, the HTTP Negoti ate authentication method should be used with BPC 10.
The user name can be in any of the following formats: 1.
user – When a user just enters their account name, the default realm configured in TrustBroker ®
on the server is used to determine which realm to send the authentication request. 2.
user@REALM – When a user enters an account name in this format, the TrustBroker One Credential product knows which realm to send the authentication request to so the default realm
is not used. 3.
user@upn – When a user enters an account name with a UPN suffix, the authentication request
is sent to the default realm. 4.
user@upn@REALM – When a user enters a UPN and a realm, the TrustBro ker One Credential
product knows to which realm to send the authentication request, so the default realm is not used. 5.
DOMAIN\user – When the NetBIOS domain name is used, the TrustBr oker One Credential
product will convert this to user@DOMAIN and send the authentication request to the default realm.
How it Works
Page 10
Configuration Guide
Regardless of the user name format entered by the user, the Activ e Dir ect or y domain controller to which the authentication request is sent might respond with a realm referral, in which case TrustBroker ® will send the authentication request again to the referred realm. For example, a user called Fred might enter
[email protected] but Fred’s account is in the emea.kerby.com domain, so the kerby.com Acti ve Di rec to ry domain will refer the request to the emea.kerby.com domain. The user’s authenticated principal name will then be
[email protected] . Prerequisites
A product that requires HTTP Basic authentication, and is not able to use a more secur e authentication protocol when a user has a valid Ac ti ve Direct ory user name and password. The server where TrustBroker ® One Credential is installed needs to be able to communicate with the Acti ve Di rec to ry domain controllers when authenticating the users. This requires UDP and/or TCP port 88 to be open in any firewall that might be present between the SAP server and the domain controllers. The use of SSL (https://) is strongly recommended, since passwords are being transmitted over the network from the user to the TrustBroker ® One Credential product. Endpoint Device Support
The device support depends on the application that is requiring this protocol to be used.
Method: Active Directory Password Protocol
The Kerberos protocol is used to authenticate the user after they have entered their Acti ve Di rec to ry user name and password. The authentication is performed on the server where TrustBroker ® One Credential is installed. Usage
The user is shown the TrustBroker ® One Credential Sign-On screen in their browser, and can enter a valid Ac ti ve Di rec to ry account name and password. The user name can be in the following formats: 1.
user – When a user just enters their account name, the default realm configured in TrustBroker ®
on the server is used to determine to which realm to send the authentication request. 2.
user@REALM – When a user enters an account name in this format, the TrustBroker One Credential product knows to which realm to send the authentication request, so the default realm
is not used. 3.
user@upn – When a user enters an account name with a UPN suffix, the authentication request
is sent to the default realm. 4.
user@upn@REALM – When a user enters a UPN and a realm, the TrustBro ker One Credential
product knows to which realm to send the authentication request, so the default realm is not used. 5.
DOMAIN\user – When the NetBIOS domain name is used, the TrustBr oker One Credential
product will convert this to user@DOMAIN and send the authentication request to the default realm. Regardless of the user name format entered by the user, the Activ e Dir ect or y domain controller to which the authentication request is sent might respond with a realm referral, in which case
How it Works
Page 11
Configuration Guide
TrustBroker ® will send the authentication request again to the referred realm. For example, a user called Fred might enter
[email protected] but Fred’s account is in the emea.kerby.com domain, so the kerby.com Acti ve Di rec to ry domain will refer the request to the emea.kerby.com domain. The user’s authenticated principal name will then be
[email protected] . Prerequisites
This method is supported when using any Web browser (If using Internet Explorer, version 7 or later is supported, but 9 or above gives best results), as long as it is supported by the SAP application that the user is logging on to. The authentication of the user does not depend on any specific protocol to be supported in the Web browser, and doesn’t require any additional software to be installed on the user’s workstation. The server where TrustBroker ® One Credential is installed needs to be able to communicate with the Acti ve Di rec to ry domain controllers when authenticating the users. This requires UDP and/or TCP port 88 to be open in any firewall that might be present between the SAP server and the domain controllers. The use of SSL (https://) is strongly recommended, since passwords are being transmitted over the network from the user to the TrustBroker ® One Credential product. Endpoint Device Support
Any end-point device is supported, including mobile devices that have a Web browser.
Method : SAP Passwor d Protocol
There is no authentication protocol being used, since the SAP password which is provided by the user is checked against the password stored in the SAP database for the given SAP User and Client. The user authentication is performed on the server where TrustBroker ® One Credential is installed. Usage
The user is shown the TrustBroker ® One Credential Sign-On screen in their browser, and can enter a valid SAP User ID, Client and Password. This method is mostly used when the user cannot enter their Activ e Dir ect or y credentials, maybe if they need to logon using special User ID’s such as DDIC or SAP* which probably don’t exist in Ac ti ve Directory . Prerequisites
This method is supported with any Web browser (If using Internet Explorer, version 7 or later is supported, but 9 or above gives best results), as long as it is supported by the SAP application that the user is logging onto. The authentication of the user does not depend on any specific protocol to be supported in the Web browser, and doesn’t require any additional software to be installed on the user’s Workstation. The use of SSL (https://) is strongly recommended, since passwords are being transmitted over the network from the user to the TrustBroker ® One Credential product. Endpoint Device Support
Any end-point device is supported, including mobile devices that have a Web browser.
How it Works
Page 12
Configuration Guide
Method: RSA SecurID Passcode Protocol
The RSA Authentication Manager product needs to be available on the network and the TrustBroker ® One Credential product will communicate with this server to validate the RSA SecurID passcode entered by the user. The protocol used for this communication is proprietary to RSA, and is secured using a node secret. Usage
The user is shown the TrustBroker ® One Credential Sign-On screen in their browser, and can enter a valid RSA User ID and RSA SecurID passcode. The on-demand authentication (ODA) feature of RSA Authentication Manger is also supported, where the user can enter their ODA passcode and then receive a passcode via Email or SMS Text Message. This passcode can be entered into the TrustBroker Sign-On screen. Prerequisites
This method is supported when using any Web browser (If using Internet Explorer, version 7 or later is supported, but 9 or above gives best results), as long as it is supported by the SAP application that the user is logging on to. The authentication of the user does not depend on any specific protocol to be supported in the Web browser, and doesn’t require any additional software to be installed on the user’s workstation. The server where TrustBroker ® One Credential is installed needs to be able to communicate with the RSA Authentic ation Manager when authenticating the users. This requires UDP and/or TCP port 5500 to be open in any firewall that might be present between the SAP server and the RSA Au th ent ic ati on Manag er server(s). The use of SSL (https://) is strongly recommended, since RSA User IDs and passcodes are being transmitted over the network from the user to the TrustBroker ® One Credential product. Endpoint Device Support
Any end-point device is supported, including mobile devices that have a Web browser.
Method: TrustBroker ® One Credential authenti cation API Protocol
The TrustBroker ® One Credential product can be invoked from Javascript code, from .NET code or from any ABAP application which needs to authenticate the user. The actual authentication is performed using either HTTP Negotiate or HTTP Basic (as described earlier in this document). Usage
For example, a user can be authenticated to a .Net application running on a Window s Server , using IWA built into Internet Information Service (IIS). Then their delegated credentials can be used to authenticate them to the SAP system in order for the .Net application to be able to invoke Web services or run RFC function modules using the users’ credentials. It is also possible for an ABAP developer to call a Class included in the product to authenticate users who logon to their application.
How it Works
Page 13
Configuration Guide
Prerequisites
The prerequisites are dependent on which initial authentication method is used, and are described in the section describing the HTTP Negotiate or HTTP Basic authentication method, found earlier in this document. Endpoint Device Support
Any end-point device is supported, including mobile devices that have a Web browser.
How it Works
Page 14
Configuration Guide
Stage 2 – Identit y Mapping / Determi ne the SAP User ID & Client When a user logs onto a SAP system, the SAP User ID and SAP Client need to be determined after the user has authenticated. The method used to determine the SAP User ID and SAP Client is referred to as the identity mapping method. The identity mapping method differs according to the authentication method used, as explained below:
For Kerberos authentication methods If initial authentication method is HTTP Negotiate, HTTP Basic (Active Directory Password), or Active Directory Password (e.g. authentication methods which use the Kerberos protocol and use an Ac ti ve Directory infrastructure) then the identity mapping works as described below: The initial authentication method will have already been used to determine the Kerberos principal name of the user. This principal name is then converted to an SNC name, using one of the following methods: 1.
The default method involves adding a p: prefix, e.g. a user with principal name
[email protected] will have an SNC name p:
[email protected] To enable this method the following configuration parameter can be added to the /cstb/oc_conf table, but if it is not defined it will work the same way as this method is the default. identity_mapping /snc_name_form at = 1
2.
If the SNC library used by the system is the SAP NTLM library then SNC names in the USRACL table will be in p:
\ format. If the users principal name is [email protected], they will have an SNC name of p:EMEA\Fred To enable this method the following configuration parameters need to be added to the /cstb/oc_conf table: identity_mapping /snc_name_form at = 2 identity_mapping/netbios_domains = EMEA.KERBY.COM:EMEA,ASIA.KERBY.COM:ASIA
The identity_mapping/netbios_domains configuration parameter must have a value containing a comma separated list of one or more :. In the above example, the Kerberos Realm called EMEA.KERBY.COM has a Netbios Domain of EMEA and the Realm ASIA.KERBY.COM has a Netbios Domain of ASIA. When the SNC name of the user has been determined, the TrustBro ker One Credential product will perform a cross client search in the USRACL table to find one or more SAP User IDs that have the SNC name. The USRACL table is the same table used for identity mapping when SNC authentication is used on the AS A BAP system, and can be maintained using transaction SU01. The SNC name is case sensitive, so the SNC name specified for a user must be in the same case as their principal name as defined in Ac ti ve Di rec to ry . The principal name of a user is determined from their saMAccountName and the domain name (in upper case). If the user’s SNC name maps onto more than one SAP User ID in the same Client (or in different Clients) then the user will be asked which User / Client they want. The selection screen might look similar to this:
How it Works
Page 15
Configuration Guide
If there is no entry in the USRACL table for the SNC name of the authenticated user, an error might be shown, as illustrated in this screenshot:
It is also possible to specify the desired SAP User ID and/or SAP Client in the URL using query string parameters sap- user =and s ap- c l i ent =. For example, the URL http://sapn1a.kerby.com:8000/nwbc?sap-client=100&sap-user=SSMITH will authenticate the user, then log them into NWBC in Client 100 with SAP User ID = SSMITH, but only if this User ID and Client are mapped onto the users SNC name. If it is not mapped, an error will be shown and the user will be expected to select a different User ID / Client, or authenticate using different Ac ti ve Di rec to ry credentials.
For SAP Password authentication method Since the SAP User ID and Password are entered by the user on the TrustBroker Sign-On screen, there is no need for any identity mapping when this authentication method is used. It is also possible to specify the desired User / Client in the URL using query string parameters sapuser =and s ap- c l i ent =. For example, the URL http://sapn1a.kerby.com:8000/nwbc?sapclient=100&sap-user=SSMITH will use Client 100 with SAP User ID = SSMITH.
How it Works
Page 16
Configuration Guide
For RSA Secur ID Passco de authent icati on method, and other authenti cation methods wh ere an external authentication server is used, but not when Kerberos authentication methods are used If the initial authentication method involves the use of an external authentication server (e.g. when using RSA SecurID Passcode, the RSA Authenticatio n Manager product is used), but not when using the Kerberos authentication methods as described earlier in this document, where Activ e Directory domain controllers are used as the external authentication server, then you can change the identity mapping method. When using v ersion 4.5.0 of the TrustBr oker ® One Credential product :
With TrustBroker ® One Credential version 4.5.0, when RSA SecurID Passcode user authentication is used, there is only one identity mapping method available, where the SAP User ID is always assumed to be the same as the RSA SecurID User ID. When using version 4.5.0.SR1 or later of th e TrustBro ker ® One Credential pro duct :
It is possible to configure a different identity mapping method for each authentication method that uses an external authentication server, or the same identity mapping method for all authentication methods. You need to add one or more of the following parameters to the /cstb/oc_conf table: 1.
identity_mapping/method/ =
This configuration parameter is used to set the identity mapping method for a specific authentication method. For example, identity_mapping/method/rsa_securid_passcode = 1 (default) | 2 2.
identity_mapping/method =
This configuration parameter is used to set the identity mapping method for all authentication methods, and will be more useful in later versions of the product when there are more authentication methods available that use an external authentication server. If the authentication method specific (1) and non-specific (2) parameters are both configured, the authentication method specific parameter is used to determine the identity mapping method. If the identity mapping method is set to 1 (the default if not configured): The Active Directory User name is used to determine the SAP User ID using the existing mapping information found in the USRACL table, and it is assumed that the Active Directory User name is the same as the identity in the external authentication server (e.g. for RSA SecurID Passcode, the identity in the RSA Authentication Manager ). For RSA SecurID Passcode, it works as follows: 1.
The user enters their RSA SecurID User ID and Passcode on the Sign-On screen.
2.
The RSA SecurID User ID is used to construct an SNC name, e.g. p:@ or if the NTLM is used/configured, p:\
3.
If only one SAP User ID is found with the SNC name, this SAP User ID will be used.
4.
If more than one SAP User ID is found, a list will be shown to the user so they can select which one to use. This might happen if the user has a SAP User ID in more than one SAP Client.
How it Works
Page 17
Configuration Guide
If the identity mapping method is set to 2: The SAP User ID is assumed to be the same as the identity in the external authentication server (e.g. for RSA SecurID Passcode, the identity in the RSA Authentic ation Manager ).
Stage 3 – PBSA To use the Policy Based Secondary Au thentication (PBSA) feature, the instructions in the following document need to be followed to enable PBSA and configure a policy: Reference
Document Title
EC-PBSA-CSTBOC-450
Enabling and Configuring Policy Based Secondary Authentication (PBSA) for TrustBr oker One Credential
When PBSA is enabled, the SAP User ID and Client will be used to check the policy and determine if the user needs to be authenticated again (secondary authentication).
Stage 4 – Create an auth entication c ont ext and SAP SSO2 coo kie Once the SAP User ID and SAP Client has been determined, as described in Stage 2 (or if you are using the SAP Password method when the correct password is provided), and any secondary authentication has been performed successfully (using PBSA as described in Stage 3), next the TrustBroker ® One Credential product will create a TrustBroker authentication context cookie and an SAP SSO2 logon ticket cookie (a.k.a. the MYSAPSSO2 cookie).
The authentication con text cook ie: The authentication context cookie (and the SAP SSO2 logon ticket cookie) are both stored in the browser as domain session cookies, so that the user doesn’t have to authenticate again, unless they logoff or close all instances of their Web browser (in which case the cookies will be destroyed). The authentication context cookie can be configured as a persistent cookie instead of a session cookie so that it doesn’t get destroyed when the browser is closed. When a persistent cookie is used the user can logon, restart their browser and they won’t need to authenticate again if they access the same SAP system, or another SAP system on the same domain (see cookie domain configuration later in this section).
To change the type of authentication context cooki e used: You need to edit the entry for the application in the /cstb/oc_svcpath table. The value in the Auth ent ic ati on Con tex t column will change the type of cookie used, and/or allow it to be changed using the PersistentAuthContext=True|False URL query string parameter. The available values are summarised below: Session cookie
This is the default value if nothing is selected. The authentication context cookie will be a session cookie so that it persists until the browser is restarted. Persistent cookie
How it Works
Page 18
Configuration Guide
The authentication context cookie will be a persistent cookie so that it persists even after the browser or device is restarted. Session cooki e. Can be changed to Persistent co okie
The authentication context cookie will be a session cookie unless the URL used to logon to the application includes the URL query string parameter, PersistentAuthContext=True Persist ent cooki e. Can be changed to Session coo kie
The authentication context cookie will be a persistent cookie unless the URL used to logon to the application includes the URL query string parameter, PersistentAuthContext=False
To change the authentication cont ext cookie li fetime: In the /cstb/oc_conf table: 1.
auth_context/use_existing = 1 | 0 (default)
If this configuration parameter is set to 1: When the user accesses an SAP system, the ICF service will check the MYSAPSSO2 cookie and use that to authenticate the user if it is valid and hasn’t expired. If it is invalid or has expired, the authentication context cookie will be checked by TrustBroker ® One Credential login.do controller, and if this cookie is valid and hasn’t expired it will be used to authenticate the user. If the authentication context cookie is not valid or has expired, then the user will be required to reauthenticate using one of the authentication methods configured in the TrustBroker ® One Credential product. If set to 0 (the default if not configured): When the user accesses an SAP system, the ICF service will check the MYSAPSSO2 cookie and use that to authenticate the user if it is valid and hasn’t expired. If it is invalid or has expired, then the user will be required to re-authenticate using one of the authentication methods configured in the TrustBroker ® One Credential product. There is also a URL query string parameter, UseExistingAuthContext=True|False which can be used to override the value of the auth_context/use_existing configuration parameter for a particular logon request. This is useful in cases where you want most applications to use the authentication context cookie, but for a certain user logon session you might want the authentication context cookie to be ignored, or vice-versa. 2.
auth_context/lifetime = :
This is used to change the lifetime of the authentication context cookie. The number of minutes is optional, so you can specify hours only, e.g. auth_context/lifetime = 20 If you are using version 4.5.0.SR1 or later of the TrustBroker ® One Credential product, and this parameter is not configured, the default is the same as the lifetime of the MYSAPSSO2 cookie (configured using SAP profile parameter login/ticket_expiration_time , or 8 hours if not configured). If you are using version 4.5.0 of the TrustBroker ® One Credential product, and this parameter is not configured, the default is always 8 hours, not based on the login/ticket_expiration_time SAP profile parameter. This parameter is only used if the authentication context cookie is used to authenticate the user, e.g. if auth_context/use_existing = 1 or the URL query string parameter, UseExistingAuthContext=True
How it Works
Page 19
Configuration Guide
A lifetime which is less than the lifetime of the MYSAPSSO2 cookie will have no effect because the MYSAPSSO2 cookie is always checked by SAP NetWeaver, before the TrustBroker ® One Credential product gets a chance to validate the authentication context cookie. If the MYSAPSSO2 cookie lifetime is less than the HTTP session timeout value (configured using the SAP profile parameter http/security_session_timeout ) then the user will be required to authenticate again only after the HTTP session timeout has occurred.
Other cookie r elated confi guration parameters: In the /cstb/oc_conf table you can also configure the following: 1.
login/cookies/httponly = 1 (default) | 0
This configuration parameter is used when /cstb/oc/login.do is used to authenticate the user. If this configuration parameter is set to 1 (the default if not configured): When the authentication context cookie and SAP SSO2 logon ticket cookie are created, the HTTPOnly flag is set on these cookies to stop malicious code performing session hijacking. If this configuration parameter is set to 0: When the authentication context cookie and SAP SSO2 logon ticket cookie are created, the HTTPOnly flag is not set on these cookies. 2.
login/cookies/secure = 1 (default) | 0
This configuration parameter is used when /cstb/oc/login.do is used to authenticate the user, and when HTTPS is used to access the application. If this configuration parameter is set to 1 (the default if not configured): When the authentication context cookie and SAP SSO2 logon ticket cookie are created, the Secure flag is set on these cookies to stop malicious code performing session hijacking. If this configuration parameter is set to 0: When the authentication context cookie and SAP SSO2 logon ticket cookie are created, the Secure flag is not set on these cookies. 3.
auth/cookies/httponly = 1 (default) | 0
This configuration parameter is used when /cstb/oc/auth.do is used to authenticate the user. If this configuration parameter is set to 1 (the default if not configured): When the authentication context cookie and SAP SSO2 logon ticket cookie are created, the HTTPOnly flag is set on these cookies to stop malicious code performing session hijacking. If this configuration parameter is set to 0: When the authentication context cookie and SAP SSO2 logon ticket cookie are created, the HTTPOnly flag is not set on these cookies. 4.
auth/cookies/secure = 1 (default) | 0
This configuration parameter is used when /cstb/oc/auth.do is used to authenticate the user, and when HTTPS is used to access the application. If this configuration parameter is set to 1 (the default if not configured): When the authentication context cookie and SAP SSO2 logon ticket cookie are created, the Secure flag is set on these cookies to stop malicious code performing session hijacking.
How it Works
Page 20
Configuration Guide
If this configuration parameter is set to 0: When the authentication context cookie and SAP SSO2 logon ticket cookie are created, the Secure flag is not set on these cookies. 5.
cookies/domain_level =
When a cookie is created the DNS domain of the cookie is normally set as explained in the following example: If the URL used to access the application is http(s)://host.country.company.com then the cookie domain will be .country.company.com . The web browser will then send the cookie to any host in the country.company.com DNS domain, e.g. another-host.country.company.com . Sometimes it is useful to use a different cookie domain, so the domain level can be configured as explained below: If = 0 then the cookie domain when accessing the application at http(s)://host.country.company.com will be .host.country.company.com . Effectively the full URL is used, including the hostname. If = 2 then the cookie domain when accessing the application at http(s)://host.country.company.com will be .company.com . If = 3 then the cookie domain when accessing the application at http(s)://host.country.company.com will be .country.company.com .
Stage 5 – Check fo r exist ing l ogon s The /cstb/oc_svcpath table has a column titled Check for Existing Logons. When set to Local or System-Wide the TrustBroker ® One Credential product will check if the same user has an existing logon session on the system and, if so, ask them if they want to cancel the session before the logon to the application is completed. If there are any existing logon sessions, a screen like the one below will appear:
Stage 6 – Logof f When a user logs off an application, there are various options available to configure the logoff. These are explained below.
How it Works
Page 21
Configuration Guide
There are many ways to p roc ess a logoff for an ICF service Default ICF service logof f
By default, if no further configuration is made, when a user logs off an ICF service, the SAP system will close the logon session in the SAP system, then display a message saying that the user has been logged off successfully. The user is then told to close the browser, which will delete all session cookies, including the MYSAPSSO2 cookie. For example, when a user logs off the HTML version of NWBC (SAP Business Client ) they will see the following:
The SAP ICF logo ff page
Instead of being required to close the browser to remove cookies, the SAP ICF logoff page (/sap/public/bc/icf/logoff ) is provided, and it performs the following steps: 1.
It deletes all of the SAP session cookies, including the MYSAPSSO2 cookie.
2.
If invoked without passing redirectURL= as a parameter, it displays a page in the browser like the example shown below.
3.
If invoked using /sap/publi c/bc/icf/logoff? redirectURL= then it will redirect to a custom logoff page.
Applications such as SAP Fiori Launchpad will close the session, then redirect to this SAP ICF logoff page (/sap/public/bc/icf/logoff ) without any configuration being required. ICF services such as NWBC require special configuration, as explained later in this document. Other ICF services, e.g. Web GUI need to be configured to use this logoff page, so when the user logs off, their browser will be redirected to the SAP ICF logoff page. You need to configure this logoff page by using SICF to locate the ICF node, then entering the URL into the Redirect to URL field in the Error Pages Logoff Page configuration. You will find examples in the How to configure the logoff page for ICF services, using SICF transaction section of this document. The TrustBrok er One Credential logo ff page
The SAP ICF logoff page works well, but doesn’t have any knowledge of the TrustBroker ® One Credential authentication context cookie, so a TrustBroker ® One Credential logoff page (/cstb/oc/logoff.do ) is available for use instead of the SAP ICF logoff page. The TrustBroker ® One Credential logoff page performs the following steps:
How it Works
Page 22
Configuration Guide
1.
It deletes all of the SAP session cookies, including the MYSAPSSO2 cookie.
2.
It deletes the authentication context cookie, unless URL query string parameter KeepAuthContext=True is passed as a parameter.
3.
If invoked without passing RedirectPath= as a parameter, it displays a page in the browser like the example shown below:
4.
If invoked using /cstb/oc/logoff .do?RedirectPath= then it will redirect to a custom logoff page. If this custom logoff page is on the same SAP system, it should be referenced using a URI (e.g. a URL starting with a /). If you want to redirect to a page using a URL which starts with http(s):// (e.g. Intranet home page) then you need to allow this by adding the following configuration parameter to the /cstb/oc_conf table: logof f/redirect_path/allow_URL = 1
How to c onfigur e the logoff page for NWBC When using NWBC the logoff page URL needs to be configured using an entry in an NWBC specific configuration table called NWBC_CFG. 1.
First, run the SE16 transaction, and enter the Table Name as NWBC_CFG.
2.
Then choose Menu Table Create Entries (F5). You will see a screen like the one below where you can enter the value of LOGOFF_URL as your logoff page URL.
3.
When completed, save the table changes and test.
How it Works
Page 23
Configuration Guide
More details can be found on the following SAP Help page: http://help.sap.com/saphelp_nw70ehp3/helpdata/en/4c/5bdbee97817511e10000000a42189b/fram eset.htm
How to con fig ure the logoff page for ICF servic es, using SICF transaction When using ICF services such as the SAP Fiori Launchpad, the following steps are required to change the logoff page URL. 1.
Using transaction SICF, find the ICF logoff service as highlighted below:
2.
Edit the service, and specify the required logoff page URL into the Redirect to URL field as shown below:
When you enter the Redirect to URL, you might need to pass parameters like RedirectPath= and/or KeepAuthContext=True. These will depend on how you want the logoff page to be used, as explained later in this document. 3.
When you have changed the Redirect to URL you can save the changes and test to see if the logoff works as you expect it to.
How it Works
Page 24
Configuration Guide
When using ICF services such as Web GUI, the following steps are required to change the logoff page URL. 1.
Using transaction SICF, find the ICF service as shown below:
2.
Edit the service, and specify the required logoff page URL into the Redirect to URL field as shown below:
When you enter the Redirect to URL, you might need to pass parameters like RedirectPath= and/or KeepAuthContext=True. These will depend on how you want the logoff page to be used, as explained later in this document. 3.
When you have changed the Redirect to URL you can save the changes and test to see if the logoff works as you expect it to.
How it Works
Page 25
Configuration Guide
Typical logoff sc enarios The configuration options are summarised below: 1.
When the user logs off, if you want to show a friendly TrustBroker ® One Credential logoff page: 1.1. If the authentication context cookie is being used to authenticate the user and you don’t want
to remove it when the user logs off (you might want to wait for it to expire) then you need to specify the logoff page URL as /cstb/oc/logoff.do?KeepAuthContext=True 1.2. If the authentication context cookie is not being used to authenticate the user, then you need to specify the logoff page URL as /cstb/oc/logoff.do 2.
When the user logs off, if you want to show your own logoff page: 2.1. If the authentication context cookie is being used to authenticate the user and you don’t want
to remove it when the user logs off (you might want to wait for it to expire) then you need to specify the logoff page URL as /cstb/oc/logoff.do? KeepAuthContext=True&RedirectPath= Note: If the logoff page is on a different server (your RedirectPath needs to start http:// or https://) then you will need to set logof f/redirect_path/allow_URL = 1 in the /cstb/oc_conf
table, as described above. 2.2. If the authentication context cookie is not being used to authenticate the user, then you need to specify the logoff page URL as /cstb/oc/logoff .do?RedirectPath= 3.
When the user logs off, if you want to show them the application Sign-On screen: 3.1. If the authentication context cookie is being used to authenticate the user and you don’t want
to remove it when the user logs off (you might want to wait for it to expire) then you need to specify the logoff page URL as /cstb/oc/logoff.do? KeepAuthContext=True&RedirectPath=?sap-client=100?Negotiate=False . The Negotiate=False is added on to the URL so that the TrustBroker ® One Credential Sign-On screen will be shown instead of
HTTP Negotiate (if enabled) logging the user in again. Note: The application Sign-On screen might not appear if the authentication context cookie hasn’t expired, and is valid. The user will be logged back into the application when they logoff, which might not be what you want. 3.2. If the authentication context cookie is not being used to authenticate the user, then you need to specify the logoff page URL as /cstb/oc/logoff .do?RedirectPath=?sap-client=100&Negoti ate=False . 3.3. If you are using the SAP Fiori Client on a mobile device, we suggest that you test the logoff
when using the app. If the Sign-On screen is not shown when the user logs off and instead the user is logged back into the SAP Fiori Launchpad, you might need to specify the logoff page URL as /cstb/oc/logof f.do?RedirectPath=/cstb/oc/login.do? RedirectPath=?sap-client=100&Negotiate=False
Note: make sure that sap-client is first parameter after the URL/URI and not after Negotiate=False
How it Works
Page 26
Configuration Guide
Configuration Instructions To configure the TrustBroker ® One Credential product, you need to refer to the instructions in this section. You should review the instructions, and decide if you need to make any changes or not, depending on how you plan to use the product.
Configu ration for SAP BPC 10.x EPM Add-in Make sure you are using the latest version of the EPM Add-in, to take advantage of bug fixes. In older versions of the Add-in, the HTTP redirect wasn’t handled correctly, so it was not possible to redirect to login.do when the Add-in code accesses /sap/bpc/session . The Configuration Guide for version 4.4.0 of the TrustBroker ® One Credential product included instructions to “work around” these limitations by configuring the icm/HTTP/mod parameter. The HTTP redirect limitations are not present anymore, so there is no need to have this SAP profile parameter.
If you are upgrading f rom a TrustB rok er One Credential versio n pri or to 4.5.0 If you are using the latest EPM Add-in, you can remove the icm/HTTP/mod parameter from your SAP system profile using transaction RZ10. The entry you need to remove is shown below: On a Unix or Linux Server:
icm/HTTP/mod_0 = PREFIX=/sap/bpc/session,FILE=/krb5/scripts/oc/http-request-mod-bpc-session
On a Windows Server:
icm/HTTP/mod_0 = PREFIX=/sap/bpc/session,FILE=C:\Program Files\CyberSafe\scripts\oc\http-request-mod-bpc-session
When you have removed the entry, the SAP system needs to be restarted.
Create Key Table Entr y (If us ing HTTP Negotiate) If you are planning to use the TrustBroker ® One Credential product with the HTTP Negotiate authentication method (see a description of this authentication method in the How It Works section earlier in this guide) you will need to create a key table entry on the server where the CSTBoc package is installed by following the instructions given below. If you don’t plan to use the HTTP Negotiate authentication method, you can ignore the instructions given below.
Determine the correct principal name It is important to name the principal in the key table correctly. This requires a basic understanding of how the protocol works, and access to tools such as nslookup , as explained below: Protocol details
The HTTP Negoti ate protocol is implemented in the TrustBroker ® One Credent ial product, as is illustrated below:
TrustBroker ® One Credential Configuration Instructions
Page 27
Configuration Guide
The numbers in the diagram are explained here: 1.
The user logs onto their workstation using an Ac ti ve Di recto ry domain account.
2.
The logon results in a Kerberos TGT (initial ticket) being issued by Acti ve Directory and cached on the user’s workstation in a credentials cache. The user’s principal name is stored in this ticket.
3.
The user opens a Web browser and accesses the application on the SAP system using a URL such as http://sapn1a.kerby.com:8000/nwbc .
4.
The TrustBroker ® One Credential product responds with a HTTP 401 “Unauthorized” and sets the HTTP Header WWW-Authentication to Negotiate.
5.
The browser receives the HTTP header and the HTTP 401, and then requests a Kerberos service ticket from the Ac ti ve Directory domain. The requested service ticket principal name will be HTTP/sapn1a.kerby.com@ since this is constructed using the URL entered in 3. See Using nslookup below for more details on how this principal name is constructed.
6.
The Acti ve Di rec to ry Domain Controller responds with a service ticket, which is encrypted and contains the authenticated user’s principal name. This ticket is cached on the user’s workstation in the credentials cache for subsequent logons - to improve performance.
7.
The browser sends the service ticket in a Negotiate response to the TrustBroker ® One Credential product. This response is stored in the Authorization header.
8.
The TrustBroker ® One Credential product receives the Authorization header containing the service ticket (Note: This is why the changes made in Step 4 of these installation steps was required) and looks for an entry in the key table with the same principal name. If it cannot find one, then it reports a Wrong principal name in request error. If an entry is found, and the encryption type and key versions match, then the key is used to decrypt the service ticket. The decrypted service ticket contains the authenticated user’s principal name (see 6.) so the TrustBroker ® One Credential product is able to know the user’s principal name and use it for identity mapping, followed by creation of an SSO2 logon ticket.
TrustBroker ® One Credential Configuration Instructions
Page 28
Configuration Guide
Using nslookup
As you will see from the HTTP Negoti ate protocol (see explanation above), the principal name that needs to be used when creating a key table entry is based on the URL entered in the Web browser. So, for example, if the user enters http://sapn1a.kerby.com:8000/nwbc the principal name used for creating the key table entry should be HTTP/sapn1a.kerby.com@. However, depending on which browser is being used, which version of the browser is used, and how DNS is configured for the SAP system hostname, the browser might request a service ticket with a different name from the name you expect. So, we recommend you use nslookup to determine the correct principal name. If you use multiple hostnames to access the same SAP system using a Web browser, you need to perform this nslookup check with each of the hostnames and create a key table entry for each. Lookup the address or hostname entered in the browser URL to find out what name this resolves to. For best results, you should run this nslookup command on the same workstation that the Web browser is on. If this is not practical, you can run the command on the server, but the server might not be using the same DNS server that is used by the workstation. On Unix or Linux : sapn1a: n1aadm 52> nsl ookup | grep "Name: " Name: sapn1a: n1aadm 53>
On Windows : C: \ >nsl ookup | f i nd " Name: " Name: C: \ >
The principal name of the key table entry would be HTTP/@ where was determined by using nslookup as explained above. The is a realm ( Ac ti ve Di rec to ry domain in upper case) that trusts the realm which users use to authenticate.
Creatin g a key table entry You need to use ktutil to create a key table entry. If you haven’t already, we recommend that you start by referring to the following documentation where you will learn about the many different methods that can be used to create key table entries: Reference
Document Title
H-CSTB-AD-450
How TrustBr oker works with Active Directory
TrustBroker ® One Credential Configuration Instructions
Page 29
Configuration Guide
See example command below: On a Windows Server:
Open a Command Window, and then run the ktutil command, like this example: C: \ >kt ut i l - x HTTP/ sapn1a. ker by. com@EMEA. KERBY. COM
On a Unix or Linux Server:
Run the ktutil command, like this example: [ r oot@sapn1a ~] # / kr b5/ sbi n/ 64/ kt uti l - x HTTP/ sapn1a. kerby. com@EMEA. KERBY. COM
After the key table entry has been created successfully, you need to check the pe rmissions on the key table (/ krb5/ v5sr vtab) to be sure that the adm user has read access to this file. The easiest way to check the permissions is to run ktutil whilst logged onto the adm user. If you get a permission error, then you need to fix the file permissions. If you get a list of key table entries, then the permissions are correct. See example ktutil output below: sapn1a: n1aadm 52> / krb5/ sbi n/ 64/ ktuti l Key Tabl e: FI LE: / krb5/ v5srvt ab KVNO EType Ti mest amp ---- ----- ---------------------------2 17 Fr i 04 May 2012 17: 10: 25 BST 2 18 Fr i 04 May 2012 17: 10: 25 BST 2 23 Fr i 04 May 2012 17: 10: 25 BST sapn1a: n1aadm 53>
Pr i nci pal --------HTTP/ sapn1a. ker by. com@EMEA. KERBY. COM HTTP/ sapn1a. ker by. com@EMEA. KERBY. COM HTTP/ sapn1a. ker by. com@EMEA. KERBY. COM
You might get a Permission denied error, like this: sapn1a: n1aadm 54> / krb5/ sbi n/ 64/ ktuti l Key Tabl e: FI LE: / krb5/ v5srvt ab Err or occur r ed i n kt ut i l whi l e star t i ng key tabl e scan ( 0x0000000d 13 ) Permi ssi on deni ed sapn1a: n1aadm 55>
If you do, then you need to change the permissions on this file, so that it is readable by the adm user. This is often necessary when the key table was created whilst logged as root .
TrustBroker ® One Credential Configuration Instructions
Page 30
Configuration Guide
Configu re Identit y Mapping (Usin g t he USRACL Table) As described in the How it Works section of this document, once the user has been authenticated, their principal name is converted to an SNC Name by adding a p: prefix, then the USRACL table is checked to find which SAP User and SAP Client can be used. If more than one SAP User and SAP Client can be used, the user can select which they want to use. The maintenance of the USRACL table is normally performed using standard transactions such as SU01, using the SNC tab. This should be possible even when SNC is not active on the application server. The SNC tab in the SU01 transaction is shown below:
If you are also using SNC to authenticate users when they logon using SAP GUI (e.g. using the TrustBroker ® Secure Client products), you can maintain the mapping in the same place for both SAP GUI and Web browser logon. If you are not using SNC for user authentication, the TrustBroker ® One Credential product will still be able to use the entries maintained in the SNC tab for identity mapping.
TrustBroker ® One Credential Configuration Instructions
Page 31
Configuration Guide
Configu re ICF Services to use Trus tBr oker ® One Credential for User Au thent ication We recommend that you do not make any changes to applications unless you have completed the testing described in the Testing and Troubleshooting section of this guide. After testing is complete you can re-visit these instructions to configure applications to use TrustBroker ® One Credential for user authentication. To configure an application so that it uses TrustBroker ® One Credential for user authentication, you need to use the SICF transaction and edit the service, or a service node, and enter a Redirect to URL in the Error Pages tab. The Redirect to URL should contain the following URL: /cstb/oc/login.do?RedirectPath=<%=PATHTRANS%>?<%=FORMFIELD%>
The configuration for the HTML version of the NetWeaver B usiness Client (NWBC) application is shown as an example in the screen below:
When a user accesses the application URL, if they have not already authenticated then the TrustBroker ® One Credential product will authenticate them, then perform identity mapping (if required), and finally create an SSO2 logon ticket so that the application can recognize the user by their SAP User ID and client. When you upgrade a SAP system to a new version of NetWeaver or apply an enhancement pack, sometimes the Redirect to URL configuration will be reverted back to the SAP default. So, we recommend that you make a note of which ICF services you have edited so that if you later perform a SAP system upgrade you can re-configure the Redirect to URL.
TrustBroker ® One Credential Configuration Instructions
Page 32
Configuration Guide
For SAP Busi ness Planning and Conso lid ation (BPC) version 10.x or later If you are using SAP BPC 10.0, we recommend that the /sap/EPM_BPC/web service is configured with a Redirect to URL as described above. If you are using BPC 10.1 then you need to configure the /sap/bc/ui5_ui5/sap/bpcwebclient service. This will ensure that users can logon to the BPC Web Client and be authenticated using TrustBroker ® One Credential . If you are usi ng t he BPC 10.x EPM Add-in
The /sap/EPM_BPC/REST service needs to be configured with a Redirect to URL . As mentioned earlier in this guide, if you are using the latest EPM Add-in, then the icm/HTTP/mod parameter is not required anymore, so if you are upgrading from a version of the TrustBroker ® One Credential product older than 4.5.0, you can remove this parameter from the SAP system profile.
For SAP Fiori Launchpad You need to install the TrustBroker ® One Credential product on a SAP NetWeaver AS for ABAP Gateway system, then configure the SAP Fiori Launchpad to use TrustBroker ® One Credential for user authentication, as described below: 1.
Configure the Redirect to URL in the /sap/bc/ui5_ui5/ushell service.
2.
If your system has an ICF Path (you can check this using the SICF transaction) at /sap/bc/ui2/flp then you also need to configure the Redirect to URL in this service. This is because there is an External Alias defined which redirects to this service for the Fiori Cache Buster when you access the SAP Fiori Launchpad URL.
3.
If you want to configure the SAP Fiori Launchpad Administrator Tool, configure the Redirect to URL in the /sap/bc/ui5_ui5/sap/arsrvc _upb_admn service.
Configure which Authentication Methods are Allowed The default and initial configuration for the TrustBroker ® One Credential product is such that all users can use any of the available authentication methods when they logon to any application (e.g. an ICF service) that has been configured to use the TrustBroker ® One Credential product. If this meets your requirements, then you don’t need to make any changes and can ignore the instructions given below.
How to change the configuration You can configure the TrustBroker ® One Credential product so that only certain authentication methods will be allowed for a specific ICF service or hierarchy of ICF services. For this, you need to use the table maintenance transaction (SM30) to maintain the /CSTB/OC_SVCPATH table, as shown below:
TrustBroker ® One Credential Configuration Instructions
Page 33
Configuration Guide
By adding entries into the table, ICF services can authenticate users using different authenticaiton methods. Some examples are shown below:
Example 1 – All ow HTTP Negotiate f or all ICF Services except NWBC If you want to disallow the HTTP Negotiate authentication method when users logon to NetWeaver Business Client (NWBC), but allow users to authenticate using the HTTP Negotiate authentication method when they logon to all other ICF services, you can configure an entry like this:
The HTTP Negotiate authentication method is allowed by default for all ICF services, so a table entry is not required to allow this authentication method to be used by all other ICF services.
TrustBroker ® One Credential Configuration Instructions
Page 34
Configuration Guide
Example 2 – Allow HTTP Negotiate fo r all Integrated ITS Servic es If you want to allow only HTTP Negotiate for the entire hierarchy of integrated ITS services, you can configure an entry like this:
The ICF Service Path is set to /sap/bc/gui/sap/its which will make this configuration apply to any service under this path, e.g. /sap/bc/gui/sap/its/webgui. If there are no other table entries, the default will apply to other ICF services. So, any ICF service that is configured to use TrustBroker ® One Credential for user authentication (and is not an ITS service) will be allowed to use HTTP Negotiate, HTTP Basic, Active Directory Password or SAP Password authentication methods, but the hierarchy of ITS services will only be able to use HTTP Negotiate.
Example 3 – Active Director y Passw ord f or EPM Add-in If you are using the EPM Add-in for Microsoft Office with BPC 10, and you want users to enter their Ac ti ve Di rec to ry user name and password, you can configure the table like this:
The EPM Add-in authentication doesn’t use a Web browser. Instead, it uses the HTTP REST protocol during authentication, so the HTTP Basic with Active Directory Password authentication method needs to be enabled, instead of the Active Directory Password authentication method. The Active Directory Password authentication method is more suited to users who are using a web browser. When user’s logon using the EPM Add-in, they will be able to enter their Acti ve Di rec to ry user name and password. When users logon to other ICF services that are configured to use TrustBroker ® One Credential for authentication, they will be able to use Active Directory Password and SAP Password authentication methods, but not HTTP Negotiate.
TrustBroker ® One Credential Configuration Instructions
Page 35
Configuration Guide
Testing and Troubleshooting The External Alias /cstboc_test is created when the ABAP Add-On is installed, and used to access the ICF Service at /default_host/sap/bc/bsp/cstb/oc_test . This ICF Service is provided for testing the product before you change the Redirect to URL of any other ICF Services, as described in the Configure ICF Services to use TrustBroker One Credential for User Authentication in the Configuration Instructions section of this guide. To test the product, open a URL (http://:/cstboc_test) using your Web browser. e.g. http://sapn1a.kerby.com:8000/cstboc_test Then, depending on which authentication methods are configured, you can check if the product is working, as explained below:
Without HTTP Negotiate If you did not configure the HTTP Negotiate authentication method or if HTTP Negotiate is configured but is not possible (e.g. you are not logged onto a domain joined workstation/device), you should see a Sign-On screen similar to this:
On this screen you can enter Ac ti ve Di rec to ry credentials in the fields provided, click on the SAP Password logo and enter SAP Client, SAP User ID and a Password, or click on the RSA logo and enter RSA SecurID User ID and Passcode. Then, if identity mapping is required to determine the SAP Client and SAP User ID, you will be asked, like this:
TrustBroker ® One Credential Testing and Troubleshooting
Page 36
Configuration Guide
Finally you should see a screen similar to this:
With HTTP Negoti ate If you did configure the HTTP Negotiate authentication method, and are logged onto a domain user account on your workstation, and your Web browser is correctly configured, you should be authenticated and if your Active Directory User name is mapped onto more than one SAP User ID you might see a screen similar to:
TrustBroker ® One Credential Testing and Troubleshooting
Page 37
Configuration Guide
When you click on one of the SAP User ID’s on this screen, you will then be shown a screen like this:
If instead of a screen like described above, you see a Sign-On screen, then you need to: 1.
Check for an error message on the Sign-On screen which explains why the HTTP Negotiate authentication method didn’t work.
2.
Check that your Web browser has the host name of the SAP system configured in the Intranet zone (if using Internet Explorer or Microsoft Edge).
3.
Click on the CyberSafe company logo in the bottom left corner of the Sign-On screen to get additional information that might be useful to understand why the HTTP Negotiate authentication method didn’t work.
4.
Logon to the application server host and check the logs in the / kr b5/ l ogs folder, if using Unix or Linux , or in the Event Viewer if using a Windows Server .
TrustBroker ® One Credential Testing and Troubleshooting
Page 38
