Issue: When re-initializing the appliance after an update, if the custom certificate on the appliance contained a wildcard, it did not match the DNS name, so the certificate was replaced with a self-signed certificate. As a result, users were unable to register mobile devices against the appliance. (Bug 900139)

Fix: CloudAccess now matches wildcard certificates, so they are not replaced with self-signed certificates after an update.

Issue: If you want to change the preferred DNS server, you must select Use the following IP address in Step 1 on the initialization page, which assigns a static IP address to the appliance. (Bug 754137)

Workaround: After the initialization process completes, on the Admin page, change the IP address from static to DHCP.

Issue: If you implement custom branding in your CloudAccess or MobileAccess environment and then re-run the initialization process to modify the DNS server or make other changes to an existing cluster, branding is reset to the default settings. (Bug 852663)

Workaround: This is the intended behavior in CloudAccess and MobileAccess. Before you re-run the initialization process on an existing CloudAccess or MobileAccess cluster, ensure that you back up your customized branding files so that you can reuse them.

Issue: The appliance can be a heavy consumer of CPU, disk I/O, and network bandwidth. Performance can be adversely affected by other virtual machines with similar operational requirements deployed on the same VMware host server.

Workaround: As a best practice, ensure that you group or separate virtual machines on hosts and data stores to avoid resource conflicts for CPU, disk I/O, and network bandwidth. You can do this manually as you deploy virtual machines, or use affinity and anti-affinity rules if they are available in your VMware environment.

Issue: If you modify a non-public SSL certificate on the external filter server, the login service does not automatically re-read the trust store. User logins fail with a message that an external service is unavailable. However, the health status does not detect this failure and reports a healthy (green) status. This condition does not occur if you modify a certificate from a well-known certificate authority on the filter server. (Bug 895375)

Workaround: If you modify a non-public SSL certificate on a filter server, you must click Apply to restart the login services in the cluster, or reboot the appliance. A restart causes the login service to re-read the trust store and get the new certificate information. After the restart, users can log in again.

Issue: CloudAccess cannot currently set the TenantName attribute on events sent to Sentinel using the Sentinel Link collector. As a result, for events received from CloudAccess, reporting and identity tracking functionality does not work properly within Sentinel. (Bug 812159)

Workaround: No workaround is available at this time.

Issue: If Integrated Windows Authentication is enabled in CloudAccess, and a user is logged in to a domain where Kerberos is configured but Kerberos is not enabled in the browser, if the user enters invalid credentials at the login prompt or clicks Cancel, different browsers may display errors or may not behave as expected. (Bug 802257)

Workaround: To prevent this issue, ensure that Kerberos is enabled in the browser.

Issue: The initial import of a large number of users (for example, 20,000 or more) from the identity source can take several hours, and the administration console does not currently provide a warning to administrators before beginning the process. During the user import process, the health status in the console might report the following warnings on and off: Driver seems unresponsive | Provisioning | bis_AD_a4uLn | Driver seems unresponsive. (Bug 853863)

Workaround: If you have a large number of users in your environment, ensure that you allow several hours for the provisioning process to complete. After users are added, performance of other administration tasks in the console improves considerably.

Issue: When you re-activate users to Google Apps for Business in large batches, several users might be randomly suspended, even though their accounts have been created or activated properly by the connector for Google Apps for Business. (Bug 894890)

Workaround: Depending on the level of suspension, you can take the following actions to resolve the issue:

Issue: Account provisioning is not supported for the users in the SAML 2.0 Inbound unmanaged internal identity store. Because these users do not have a workforceID, they cannot be provisioned for or access the SaaS applications that depend on the workforceID attribute for authentication, such as Google Apps and Salesforce. (Bug 883446)

Workaround: To access the SaaS applications, the user must log in with the corporate identity that has a workforceID attribute.

Issue: User email address changes in Active Directory are not provisioned to Salesforce. (Bug 717153)

Workaround: No workaround is available at this time.

Issue: If you remove a user from a mapped group when there is an outstanding approval request, CloudAccess provisions the deleted user to the SaaS application when the administrator grants the approval. (Bug 752527)

Workaround: Verify that the user is a member of the group before you grant approval, or deny the request after removing the user from the group.

Issue: If you assign a user to a role in CloudAccess and then remove that user from the identity source, CloudAccess does not automatically remove the role assignment. So, if the user's context in the identity source is later restored, CloudAccess shows that user as having the same role that was previously assigned. (Bug 765609)

Workaround: To work around this issue, before you remove a user in the identity source, ensure that you have revoked all roles from that user on the Roles page in CloudAccess.

Issue: For eDirectory identity sources, CloudAccess uses the CN attribute to provision user accounts and to look up the user when the user tries to log in. eDirectory also provides the Other name field, which appends additional values to the underlying CN attribute. When CloudAccess queries the CN values, the order in which eDirectory returns the values is unpredictable, causing multiple issues. User objects that have values for "Other name" in eDirectory might be created in the identity vault with a CN that is set to one of the values in "Other name" rather than the original CN value. As a result, attempts to log in to the appliance or the service provider with the original user name might fail. (Bug 845116)

Workaround: NetIQ strongly discourages use of "Other name" in eDirectory. This issue does not occur in Active Directory because the lookup attribute (sAMAccountName) has a single value.

Issue: When you use the Relaxed User Matching option with an eDirectory identity source, renaming user objects in eDirectory could present unexpected results. If you enable relaxed user matching, CloudAccess tries to match an existing account in the appliance using the CN attribute. If you rename a user object in eDirectory, the CN attribute is effectively changed, so the user matching does not find the existing account, and a new account is created on the appliance. (Bug 848860)

Workaround: NetIQ recommends using relaxed user matching only when necessary to re-create users (with the same name) that have been previously deleted. If you do not enable relaxed user matching, renaming in eDirectory works as expected.

Issue: Users in a SAML 2.0 Inbound (SAML2 In) identity source must not be assigned as administrators because their passwords are not stored in the local identity store on the appliance. (Bug 895624)

Workaround: Assign administrator roles to users in other types of identity sources.

Issue: CloudAccess maps policies for Office 365 based on the authorization name, and not the underlying static ID. If you rename an authorization in Office 365, CloudAccess sees the action as a delete and create. Any existing policy mappings for the authorization are removed. (Bugs 811460, 815496)

Workaround: After changing the authorization name in Office 365, you must use the Policy page to re-map entitlements for the renamed authorization, and then use the Approval page to re-approve, if necessary.

Issue: The Policy Mapping page does not display the connectors for the SaaS applications.

Solution: There are two possible solutions:

Issue: CloudAccess does not reconcile pending approvals with changes to policy mappings. Users with pending approvals are granted the pending requests even if the mappings were removed after the requests were launched. (Bug 787938)

Workaround: If a policy mapping for a resource occurs by mistake, decline all the requests for that resource. If a policy mapping for a resource occurs correctly, but then the mapping is removed, simply decline all outstanding approval requests. You can often avoid this issue by ensuring that requests are approved or denied in a timely manner.

Issue: If you simultaneously use more than one browser or browser window to map authorizations, CloudAccess does not warn you if you inadvertently do the same mapping in two different browsers. Clicking Refresh displays two identical mappings on the Approvals page, but only one of them is a valid mapping. If you remove one of the mappings, CloudAccess might not actually deprovision the user until you remove the authorization that is mapped to the group. (Bug 815825)

Workaround: You can avoid this issue by using only one browser when you create policy mappings. To work around this issue, on the CloudAccess Policy page, manually remove all duplicate authorization mappings from the role, then map the desired authorizations back to the role.

Issue: If you use wildcards such as an asterisk (*) or question mark (?) in the Filter field on the Roles page, CloudAccess does not correctly filter results. (Bug 813540)

Workaround: Filters must be full regular expressions. If you want to use wildcards, they must be regular expression wildcards. If the filter does not start with '^' and '.*', then '.*' is added to the filter. If the filter does not end with '$' and '.*', then '.*' is added to the filter. Thus, a filter for "test" would end up as the regular expression ".*test.*"

Issue: When you approve or deny a large number of workflow requests in a single action, the amount of memory that the browser uses can cause the page to become unresponsive and the browser to close. (Bug 815971)

Workaround: Ensure that you select less than 300 requests in a single accept or deny action.

Issue: After you delete connectors, reports still contain information about the deleted connectors. (Bug 756690)

Workaround: No workaround is available at this time.

Issue: The numeric value in the mapping report appears after deleting and recreating mappings for connectors. (Bug 753321)

Workaround: No workaround is available at this time.

Issue: After you implement CloudAccess, you might have some issues with existing Google Apps for Business accounts. Any users who either do not exist in the identity source, or are not merged with the existing Google account, can no longer log in to the Google domain. For example, if user jsmith has an account in Google Apps for Business, and you implement CloudAccess with single sign-on, user jsmith cannot log in directly to the Google domain. Google Apps for Business does not allow both direct login and single sign-on to the domain.

Solution: Give users authorization to access the Google Apps for Business resource through CloudAccess.

Issue: Logging out of the landing page might not result in logging out of the SaaS accounts, depending on support and configuration for SAML Single Logout at the SaaS provider. Many SaaS providers do not support the SAML Single Logout service. The same issue exists with service provider-initiated logouts. (Bug 837076)

Workaround: Close the browser to allow the abandoned browser session to time out, so the session cannot be accessed again.

Issue: The Admin page in CloudAccess does not currently provide a means of viewing the critical content in an uploaded metadata file, such as when you configure the connector for Salesforce. (Bug 793495)

Workaround: No workaround is available at this time. Since metadata for connectors must be unique, ensure that the metadata file is correct before uploading it.

Issue: The Access Connector Toolkit does not currently provide a logout option, though the session does time out after 60 minutes of inactivity. (Bug 789303)

Workaround: Close the browser after you finish working in the Access Connector Toolkit.

Issue: If you change the display name of a user in Active Directory or eDirectory, the display name in Office 365 does not change accordingly. CloudAccess constructs the display name from the first and last name and does not synchronize the display name and full name from the identity source. (Bug 794602)

Workaround: Change the user's first and last name in the identity source instead of the display name.

Issue: If an authorization at the Office 365 account is renamed, any existing policy mappings in CloudAccess are lost, because CloudAccess uses the account name for policy mapping rather than the underlying static ID of the authorization. (Bug 811460)

Workaround: After changing the Office 365 authorization name, use Policy Mapping to re-map and Approvals to re-approve if necessary.

Issue: When you assign or unassign Office 365 subscriptions to users, if you select Office Web Apps, you must also select SharePoint Online. This is a Microsoft Office 365 dependency, and the Office 365 admin portal page displays an error if you attempt to assign or unassign subscriptions without also selecting SharePoint Online. The Policy page in CloudAccess does not actually prevent you from assigning Office Web Apps by itself, but nothing happens and the logs show Unable to assign this license. In addition, if you assign several subscriptions to a user, and you include Office Web Apps but do not include SharePoint Online, none of the other licenses in that operation are applied until you add SharePoint Online. This behavior occurs on the Office 365 admin portal page as well as in CloudAccess.

Workaround: When you assign or unassign Office Web Apps to a user, ensure that you also assign or unassign SharePoint Online.

Issue: If you configure a connector for Office 365 for a parent domain and then configure connectors for one or more child domains, users in the child domains do not see their assigned appmarks. Office 365 sends the same metadata for each domain, so the landing page shows only one of them. Users with policy mappings to the first connector installed can still see their appmarks. (Bug 847293)

Workaround: Microsoft does not support subdomains having different federated settings than their parent. To use a subdomain for Office 365, ensure that either you do not use Office 365 with the parent domain, or that both the parent domain and its subdomain have the identical federation settings.

Issue: If you provision a user to multiple Google Apps domains and select the Enable email proxy option in the administration console, the user cannot open the mailbox for any domain except the last domain to which the user was provisioned. This issue occurs because the dovecot mail proxy uses an attribute from the user object that is single-valued, so it is set with the name of the last Google domain to which the user was provisioned. (Bug 819157)

Workaround: No workaround is available at this time.

Issue: In Safari or Internet Explorer 9, if you attempt a service provider-initiated login from Salesforce, the Salesforce site does not send a SAML2 AuthnRequest XML document with the SAML Request. As a result, the landing page appears instead of the logged-in Salesforce page. The same behavior occurs with the connector for NetIQ Access Manager using Safari or Internet Explorer 9 or 10. (Bug 813313)

Workaround: This is application service provider behavior and cannot be addressed in the connector. This behavior does not occur in Internet Explorer 10.

Issue: If you have Kerberos enabled on your CloudAccess cluster, service provider-initiated login attempts to Salesforce might result in the browser staying at the landing page after authenticating to CloudAccess instead of redirecting to Salesforce. This issue occurs only if Kerberos is enabled on the CloudAccess cluster. It occurs regardless of whether users log in with Kerberos single sign-on or with another authentication (for example, when the workstation is not a member of the Active Directory domain). (Bug 817909)

Workaround: This issue occurs on workstations running Windows 7 and Internet Explorer 9, but does not occur with Firefox on Windows 7.

Issue: If you set the user session timeout for the cluster to 75 minutes or longer, the Box connector displays an error when users attempt to use single sign-on to Box. (Bug 814752)

Workaround: To ensure that single sign-on works for the Box connector, set the User session timeout value to 74 minutes or less. This is a cluster-level setting so it will affect behavior of user sessions not using Box as well.

Issue: Logins to the CloudAccess login page from the Safari browser on a mobile device no longer work after you enable the MobileAccess connector in the administration console. When you enable the MobileAccess connector, support for mobile devices requires that users install the MobileAccess app on their mobile devices. (Bug 838977)

Workaround: This is intended behavior.

Issue: Installing the MobileAccess app by clicking a link that points to the CloudAccess cluster DNS does not currently work correctly. If you click the link and then click OK to close the popup message, Safari displays a blank page and the smart app banner that is used to install the app from the App Store does not appear. This issue occurs in the Safari browser on iOS 7 devices, but does not occur on iOS 6 devices. (Bug 846705)

Workaround: No workaround is available at this time.

Issue: In a version 2.0 cluster, nodes with dual NICs can have only a single DNS name and SSL keypair. In a version 2.1 cluster, nodes with dual NICs must have two DNS names and matching keypairs: one for the public network and one for the administration network. However, you must not configure the additional DNS name and associated keypairs for the two NICs until after you update all nodes in the cluster to version 2.1. After an update, in the Cluster Configuration window for a node, the Public Interface section shows the cluster’s old DNS name and the Administration Interface section is blank.

Workaround: After you update all nodes in the cluster from version 2.0 to version 2.1, you must manually configure the cluster DNS names and keypairs.

Issue: After you update a cluster from version 2.0 to version 2.1 and configure the DNS names and keypairs for the public and administration networks, users might not be able to access applications for connectors that use SAML-based single sign-on if the connector does not provide automatic configuration. Changing the Public DNS name or keypair can affect your existing connectors that provide SAML single sign-on.

Workaround: You must manually re-configure the affected SaaS applications to use the new URL and SAML certificate for the new Public DNS name and its associated keypair.

Issue: After you update a cluster from version 2.0 to version 2.1 and configure dual NICS to use two different DNS names and certificates for the public and administration networks, users might see the following SSL Handshake error when they click an appmark for a connector for Simple Proxy:

Workaround: For each configured instance of the connector for Simple Proxy, you must open its Configuration page to allow it to detect the new settings for DNS names and certificates. After you update the connectors for Simple Proxy, users should no longer encounter the SSL Handshake error when they click the related appmarks.

Issue: After you update from version 2.0 to version 2.1, users might not see the appmarks for the existing configured application connectors, and they are unable to directly access protected resources. (Bug 899434)

Workaround: Reboot each node in the cluster.

Issue: After you update from version 2.0 to version 2.1, the appmarks for the existing configured application connectors cannot display the global URL and Public icon. The update does not automatically re-create appmarks for existing configured applications to get the new capabilities. (Bug 897349)

Workaround: At the top of the connector’s Appmarks configuration page, click Reset to re-create the appmarks with the new feature. Click Save, then click Apply on the Admin page. You can alternatively drag and drop a 2.1 version of the connector from the Applications palette to the Applications panel, remove the old 2.0 version of the connector, and then set policy mappings for the new instance of the application connector. Users must perform a refresh on their mobile devices before the re-created appmarks are displayed and the new capabilities are available.

Issue: CloudAccess and MobileAccess 2.0 did not support appmarks on the MobileAccess app for Android devices. After you update from 2.0 to 2.1, no appmarks for the existing applications appear on Android devices. (Bug 893055)

Workaround: After you update from 2.0 to 2.1, use the administration console to enable and create the Android appmarks for each of the connectors for existing applications, and then click Apply. Users must perform a refresh on their Android devices to get the newly created appmarks.