Applying the Microsoft Teams domain change iFix
Microsoft is migrating Teams and other Microsoft 365 applications from teams.microsoft.com to the unified cloud.microsoft domain. This change affects HCL Connections integrations that embed content inside the Microsoft Teams interface such as tab apps and messaging extensions. If you do not apply the fixes described here, Connections content might fail to render in Teams when accessed from the teams.cloud.microsoft domain.
For more information about the Microsoft domain migration, see Action required: ensure your Microsoft Teams apps are ready for upcoming domain changes.
This iFix addresses the following:
- Install or upgrade Component Pack to the latest build
- Update Content Security Policy headers to include the
.cloud.microsoftdomain - Verify email permission in Microsoft Entra ID app registration
- Verify Microsoft TLS CA certificate in WebSphere truststore
Before you begin
Ensure that the Microsoft Teams integration is configured for your HCL Connections environment. For more information, see Integrating Connections and Microsoft Teams for the full setup procedure.
Install or upgrade Component Pack to the latest build
The Teams add-in includes a fix that adds support for the cloud.microsoft domain. This fix is included in the latest Component Pack build. For a new installation, no further action is required. For existing deployments, you must upgrade the Component Pack to use the updated Teams add-in.
For instructions, see Installing or upgrading Component Pack for Connections.
Update CSP headers to include the cloud.microsoft domain
The Content-Security-Policy frame-ancestors directive on IBM HTTP Server controls which domains can embed Connections content in an iframe. The new *.cloud.microsoft domain must be added so that Connections content loads correctly when Teams uses the new domain.
-
Open the
httpd.conffile on your IBM HTTP Server. -
Locate the existing
Content-Security-Policyheader for the Microsoft Teams integration. It looks similar to the following:Header always set Content-Security-Policy "frame-ancestors 'self' teams.microsoft.com *.teams.microsoft.com *.skype.com" -
Add
*.cloud.microsoftto theframe-ancestorsdirective:Header always set Content-Security-Policy "frame-ancestors 'self' teams.microsoft.com *.teams.microsoft.com *.skype.com *.cloud.microsoft" -
Restart IBM HTTP Server for the changes to take effect.
Note
If you use the Microsoft Outlook add-in and have combined the CSP headers, ensure that the combined directive includes all required domains for both Teams and Outlook.
Verify email delegated permission in Microsoft Entra ID
The OIDC Relying Party TAI on WebSphere employs userIdentifier=email to map JWT claims to LDAP users. If you do not grant the email delegated permission in the Microsoft Entra ID app registration, the JWT issued by Microsoft does not include the email claim. This missing claim might cause authentication to fail with a 401 invalid_token error. Ensure that your app registration includes this permission.
-
Sign in to the Azure portal with an administrator account that has sufficient rights to manage applications.
Note
For information about the permissions required by the administrator, see Microsoft Entra built-in roles in the Microsoft documentation.
-
Select or find App Registrations and then click on the Azure app for HCL Connections Teams integration.
-
Navigate to Manage > API Permissions.
-
Verify that the following Microsoft Graph delegated permissions are present:
emailoffline_accessopenidprofile
If the
emailpermission is missing, click Add a permission > Microsoft Graph > Delegated permissions. Select the email checkbox, and then click Add permissions. -
Click Grant admin consent for your tenant name.
Important
Administrator consent is required. If you do not grant consent, Microsoft Entra ID does not include the
emailclaim in the JWT, even if the permission is listed. In this case, users might receive401 invalid_tokenerrors when they access Connections from Teams. -
Navigate to Manage > Token configuration.
-
Verify that the
emailoptional claim is configured for the Access token. If it is missing, click Add optional claim, select Access token, choose email from the list, and click Add.
Verify Microsoft TLS CA certificate in WebSphere truststore
The OIDC Relying Party TAI fetches JWKS signing keys from login.microsoftonline.com to verify JWT signatures. If the WebSphere CellDefaultTrustStore does not include the Microsoft TLS CA certificate (for example, Microsoft Azure RSA TLS Issuing CA 03), WebSphere cannot establish a secure connection to retrieve the signing keys and can result in the following error:
CWTAI2047E: No key was found to verify the signature.
To verify or import the certificate:
-
Log in to the WebSphere administrative console.
-
Navigate to Security > SSL certificate and key management.
-
Click Manage endpoint security configurations.
-
In the Outbound section, select the appropriate configuration and click Key stores and certificates.
-
Select CellDefaultTrustStore and click Signer certificates.
-
Click Retrieve from port.
-
Enter the following values:
Field Value Host login.microsoftonline.comPort 443Alias MicrosoftAzureTLS -
Click Retrieve signer information and verify that the certificate chain includes the expected Microsoft TLS CA certificate (for example, Microsoft Azure RSA TLS Issuing CA 03).
-
Click OK and save the changes.
-
Synchronize all nodes.
-
Restart the WebSphere server.
Note
Microsoft might rotate its TLS certificates periodically. If you encounter CWTAI2047E errors in the future, repeat the previous steps to import the updated certificate. For information about this error, see Azure TLS certificate changes in the Microsoft documentation.
Parent topic: Integrating Connections and Microsoft Teams