SecurID^®

  This section describes how to integrate SecurID Access with Microsoft Outlook Web Access using a HFED. Architecture Diagram Configure SecurID Access Cloud Authentication Service Perform these steps to configure SecurID Access Cloud Authentication Service(CAS) with Microsoft Outlook Web Access as a HFED. Before you begin Acquire an RSA SecurID Access super administrator account and an OWA end user account. Configure DNS canonical names (CNAMES) or aliases for the protected hostnames to the identity router. For example, exchange2013-exchange-pe-lab-net.sso3.pe-lab.com is a CNAME to exchange2013.exchange-pe-lab.net Note:   You can use a wildcard CNAME to add an HFED application-protected hostname without creating individual DNS entry. For example, *.sso3.pe-lab.com s a CNAME to portal.sso3.pe-lab.com. Ask your Microsoft Exchange administrator to verify that your Microsoft Exchange server version is 2013 and that it’s running on Window 2008 R2 or later. Verify that OWA has been configured to use an SSL certificate that was generated from a trusted Certificate Authority (CA). Self-signed certificates are not supported. Note:   The integration only supports SSL certificates that have been issued by a trusted CA. If your Microsoft Exchange 2013 server has been configured to use a self- signed SSL certificate for OWA client communication, your Microsoft Exchange administrator will need to replace the certificate. Consult Microsoft Exchange 2013 online documentation more information about configuring SSL for OWA and using a local Microsoft certificate authority, or a third party or commercial certificate authority to generate an SSL certificate: https://technet.microsoft.com/en-us/library/bb124558(v=exchg.150).aspx If your Microsoft Exchange 2013 server uses a local Microsoft CA, or an uncommon third- party or commercial CA for certificate signing, you must upload the CA’s root certificate to the IDR. For instructions and a list of CAs the IDR trusts out-of-the-box, see the RSA SecurID Access help documentation. Microsoft Exchange connections must use the TLS protocol (RSA highly recommends TLS 1.2) and at least one cipher that is supported by the IDR. Ask your Microsoft Exchange administrator to confirm that your Exchange server meets these requirements. For the current list of supported connection ciphers, see the RSA SecurID Access help documentation. Information about viewing, updating and prioritizing cryptographic protocols and cipher suites for Microsoft Exchange 2013 can be found on Microsoft TechNet . https://technet.microsoft.com. Confirm that you can log into your OWA end user account and access you folders, send/receive emails, view your calendar, etc. Procedure 1. Sign into the SecurID Access Cloud Administration Console and browse to Applications > Application Catalog, search for Microsoft Outlook Web Access (OWA) 2013 and click +Add to add the connector. 2. Enter a name for the application in the Name field on the Basic Information page and click the Next Step button. 3.When the Branded Settings page is displayed, the Logon Form URL field will contain a URL with two placeholders variables as illustrated below. Modify the URL value as follows: Replace the <OWA.HOST.SERVER> placeholder with your Microsoft Exchange Server’s fully qualified hostname. Replace the [:<PORT>] placeholder with the OWA listening port (preceded by a colon). If OWA is listening on port 443, simply remove [:<PORT>] from the URL. In this example, OWA is listening on 443, so the updated logon form URL would be https://exchange2013.exchange-pe-lab.net/owa/auth/logon.aspx 4. Scroll to the Web Servers table and click the pencil icon on the right hand side of the first row. 5. Enter the fully-qualified hostname of your proxy web server in the Proxy Hostname field. Do not include the internet protocol. Use a valid alias from the DNS database that points to the identity router hostname. For example: exchange2013-exchange-pe-lab-net.sso3.pe-lab.com 6. Enter the fully-qualified hostname of your Microsoft Exchange 2013 server in the Real Hostname field. Do not include the internet protocol. For example: exchange2013.exchange-pe-lab.net 7. If Microsoft Outlook Web Access 2013 is listening on https port 443, you can leave the Both (HTTP/HTTPS) radio button selected (default). If it is listening on a different https port, select the HTTPS radio button and enter the port number in the Port Number field. 8. Click the Save button. 9. Click the Next Step button. 10. On the User Access page, select the access policy the identity router will use to determine which users can access Microsoft Outlook Web Access 2013 from the portal. If you want to allow access to all users who are signed in to the portal, select the Allow All Authenticated Users radio button. Otherwise, select the Select Custom Policy radio button and select the policy you want to use from the dropdown list. 11. Click the Next Step button. 12. Select the Display in Portal checkbox on the Portal Display page. 13. The Portal URL field will contain a URL with the <OWA-HOST-SERVER> placeholder variable as illustrated below: Replace <OWA-HOST-SERVER> with the Microsoft Exchange server proxy host portion of your full proxy web server hostname (CNAME). In this example, the host alias is exchange2013-exchange-pe-lab.net and the proxy domain is sso3.pe-lab.com, so the updated portal URL would be: https://exchange2013-exchange-pe-lab-net.sso3.pe-lab.com/owa/ 14. f you want to allow users to change Oracle EBS credentials after configuring the connector, check Allow Users to Change Credentials checkbox 15. Click the Save and Finish button. 16. Click the Publish Changes button in the top left corner of the page.   Issue: The Microsoft Outlook Web Access (OWA) 2013 HTTP Federation Proxy catalog application has been correctly configured. However users cannot login to OWA from the application portal: The following message is seen: Unsuccessful logon   Cause: The connector is checking for English responses from the OWA application such as "Opening your mailbox." Responses in another language will cause the log on to fail.   Solution: Instead of using the OWA 2013 catalog item, create a generic HFED application from a template: 1. Login to the Administration Console and navigate to Applications > My Applications > Add an Application > Create From Template > Choose HTTP Federation Proxy 2. Input a Name for your application and click Next Step. 3. Select Connection Method as Manual and click Next Step. 4. In the Connection Profile section enter: Logon Form URL: https:<your-OWA-server>/owa/auth/logon.aspx Logon Form Action: https://<your-OWA-server>/owa/auth.owa Logon Form Identifier : logonForm HTTP Request Type : post Logon Form Fields and Input Value Types : 5. In Failure Detection, enter Indicator: VISIBLE_TEXT, Criteria: Does Not Contain, and Value: <string OWA returns for successful login>. For German, for example, this string is "the Postfach wird geoffnet" 6. Click Next Step. 7. In the Proxy Settings create two Web Servers, as follows: Proxy Hostname: help-outlook-com.<your-protected-domain-name>, Real Hostname: help outlook.com, Rewrite Rules: Substitute "s|help.outlook.com|help-outlook-com.%DOMAIN_NAME%|qin". Proxy Hostname: owa-hfed.<your-protected-domain-name>, Real Hostname: <your-OWA-server>, Rewrite Rules: Substitute "s|help.outlook.com|help-outlook-com.%DOMAIN_NAME%|qin". Custom Headers: Check Verify Certificates checkbox and click Next Step. 8. Set the User Access section as desired. 9. Set the Portal Display section as per below screenshot: 10. Click the Save and Finish button. 11. Click the Publish Changes button in the top left corner of the page.   Configure Microsoft Outlook Web Access There are no partner-side configuration changes needed to enable integration with RSA SecurID Access.   Next Step: Head back to the main page. ... View more

Certified:  April 15th, 2022   Solution Summary This section describes the ways in which Microsoft Outlook Web Access can integrate with RSA SecurID Access. Use this information to determine which use case and integration type your deployment will employ.   Integration Types HFED integrations use HFED technologies to direct users’ web browsers to Cloud Authentication Service for authentication. SSO Agents also provide Single Sign-On using the RSA Application Portal. Supported Features This section shows all of the supported features by integration type and by RSA SecurID Access component. Use this information to determine which integration type and which RSA SecurID Access component your deployment will use. The next section contains the steps to integrate RSA SecurID Access with Microsoft Outlook Web Access for each integration type.   Microsoft Outlook Web Access Integration with RSA Cloud Authentication Service Authentication Methods Authentication API RADIUS Relying Party HFED RSA SecurID - - - ✔ LDAP Password - - - ✔ Authenticate Approve - - - ✔ Authenticate Tokencode - - - ✔ Device Biometrics - - - ✔ SMS Tokencode - - - ✔ Voice Tokencode - - - ✔ FIDO Token n/a n/a - ✔ Identity Assurance - - - ✔   Microsoft Outlook Web Access Integration with RSA Authentication Manager Authentication Methods Authentication API RADIUS Authentication Agent RSA SecurID - - - On-Demand Authentication - - - Risk-Based Authentication n/a - -   ✔ Supported - Not supported n/t Not yet tested or documented, but may be possible. Configuration Summary The following links provide instructions on how to integrate Microsoft Outlook Web Access with RSA SecurID Access. This document is not intended to suggest optimum installations or configurations. It assumes the reader has both working knowledge of all products involved, and the ability to perform the tasks outlined in this section. Administrators should have access to the product documentation for all products in order to install the required components. All RSA SecurID Access and Microsoft Outlook Web Access components must be installed and working prior to the integration. Integration Configuration HFED Certification Details Date of testing: April 15th, 2022 RSA Cloud Authentication Service Microsoft Outlook Web Access 2013   Known Issues No known issues. ... View more

    We are using above mentioned request body and request headers and facing below error. Could you please help on this?   Error code = 2 Failure - Error processing RESTful web service response Cause: Error processing RESTful web service response: java.lang.IllegalStateException: Expected text/html; charset=utf-8 but received text/plain; charset=UTF-8       ... View more

We're planning an upgrade to 8.5 (and later on 8.6). My only option for getting the upgrades to the AM is the Windows shared folder option. I've been trying but I get constantly a permission denied error. I've tried from another server to access the shared folder and it works. I've tried putting username, domain\username and nothing on the Windows username, same result. I've checked permissions on the folder, my user has full control permission. The Windows server is a Windows server 2016. Any ideas? Thanks ... View more

For one of our requirement, we need the approval request to be assigned to two Approvers(L1 & L2) and the mail has to be sent to only one approver(L1). In the Approval node -> user data section, I have added the below attribute and setting the value of the L2 approver. But still the mail is getting sent to both the approvers. acm.To_avail.exclude[W-J1-L2_SUPR_ID] W-J1-L2_SUPR_ID – this attribute has L2 Approver acm.To_avail – AssignedTo(It has both L1 & L2 Approvers). Need mail to be sent to only L1 approver. NOTE: Since the reassign option is enable for the approval process, I did not mention the approver (L1 approver) in acm.To_avail.To Is there any other variable in which the we get this reassigned approver details other than "Assigned To" in Dynamic? ... View more