

Ask your Microsoft Exchange administrator to confirm that your Exchange server meets these requirements. 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.


For instructions and a list of CAs the IDR trusts out-of-the-box, see the RSA SecurID Access help documentation. 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. 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: (v=exchg.150).aspx 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. Note:The integration only supports SSL certificates that have been issued by a trusted CA. Self-signed certificates are not supported. Verify that OWA has been configured to use an SSL certificate that was generated from a trusted Certificate Authority (CA). For example, *. s a CNAME to .Īsk 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. Note:You can use a wildcard CNAME to add an HFED application-protected hostname without creating individual DNS entry. Perform these steps to configure SecurID Access Cloud Authentication Service(CAS) with Microsoft Outlook Web Access as a HFED.Īcquire an RSA SecurID Access super administrator account and an OWA end user account.Ĭonfigure DNS canonical names (CNAMES) or aliases for the protected hostnames to the identity router. This section describes how to integrate SecurID Access with Microsoft Outlook Web Access using a HFED.Ĭonfigure SecurID Access Cloud Authentication Service
