This topic covers frequently asked questions (FAQs) about the enterprise federation of corporate domains with Omnissa Cloud Services.
Q: What is the difference between connector-based federation setup and connectorless (dynamic) federation setup?
A: In a connector-based federation setup, you download the Omnissa Access connector executable file and install it on a Windows machine with access to your enterprise directory. In a connectorless federation setup, this step is not required as there is no executable to install. In a connector-based federation setup, the users and groups are pre-provisioned while in a connectorless federation setup, the users and groups are provisioned dynamically (Just-in-Time).
Q: Can I initiate the federation setup from my identity provider?
A: No, customer IdP-initiated setup is currently not supported with Omnissa Cloud Services.
Q: Can I still access Cloud Services with my Omnissa ID (Omnissa Customer Connect) account after enterprise federation is set up for my corporate domain?
A: If your domain(s) are federated, you can access Omnissa Cloud Services using your corporate account, but you can continue to access https://customerconnect.omnissa.com with your Omnissa account.
Q: Do I still need to create an account with Omnissa if my corporate account is federated?
A: As a user of a federated account, you need to create a Customer Connect account only if you want to file a support ticket.
Q: Can I continue to use my Omnissa ID account to log into Omnissa Cloud Services portal after Federation is set up for my enterprise?
A: No. After enterprise federation is set up with your corporate identity provider, you must use your corporate credentials for all subsequent logins to Omnissa Cloud Services.
Q: Does linking my Omnissa ID account to my corporate account result in changes to my corporate account?
A: Your corporate account does not change as a result of linking it to your Customer Connect account. The linking creates an internal mapping that does not change any attribute of your corporate account.
Q: Can I enforce Multi-factor Authentication (MFA) for access to Omnissa Cloud Services after enterprise federation is set up?
A: It depends on your corporate setup. If the identity provider used by your enterprise is set up to perform MFA, then the answer is yes. You will be prompted for MFA for access to Omnissa Cloud Services at login.
Q: Is enterprise federation tied to a particular Organization or service in Omnissa Cloud Services?
A: No. Enterprise federation is domain wide. Any user with registered and verified domains can access any Omnissa Cloud Services Organization and the services for which that Organization is subscribed.
Also, if you subscribe for additional cloud services from Omnissa, you will continue to access the new services with your corporate credentials.
Q: Can I undo the enterprise federation after it was activated?
A: Yes. To undo the federation setup for your domains, file a support ticket in the Cloud Services Console. If Support reverts the enterprise federation setup, any entitlements, users, and groups that were added post federation setup can be lost.
Q: Why don't I see the services in my Organization after I log in with my corporate account?
A: Before enterprise federation was set up for your enterprise, you used your Customer Connect account to authenticate with Omnissa Cloud Services. After federation is activated, you use your corporate account to log in to Omnissa Cloud Services and authenticate directly against your corporate Identity Provider. To access the services you previously used by logging with your Customer Connect account, you must link your corporate account to your Omnissa ID. Only when the two accounts are linked, services become visible and accessible to you based on the Organization and service role access you have in the Organization.
Q: Why do I see two accounts under the Identity & Access tab after enterprise federation has been activated?
A: You initially accessed Omnissa Cloud Services using your Customer Connect account. Let's say you used joe@acme.com to create a Customer Connect account and log in to Omnissa Cloud Services using that account. Post federation, you access Omnissa Cloud Services using your federated account and linked your Omnissa Customer Connect ID account. The initial joe@acme.com is grayed out and marked with an Omnissa ID label to indicate the Customer Connect account you no longer use, yet it remains visible as a “shadow account”.
You cannot modify shadow accounts in terms of Organization or service role assignments. It is a best practice to keep these entries for at least a few months after the federation setup is activated just in case you decide to undo the enterprise federation setup.
Q: What kind of third party identity providers are supported?
A: Any SAML 2.0 complaint third-party identity provider is supported for enterprise federation with Omnissa Cloud Services.
Q: I don’t have a SAML 2.0 compliant third-party Identity Provider and want to authenticate directly against my corporate Active Directory (AD). Is this supported?
A: Yes. You can use the Omnissa Access on-premises connector’s built-in authentication methods to authenticate users directly against your corporate AD.
Q: Can I use a Windows virtual machine created using Omnissa technology to install the Omnissa Access on-premises connector?
A: Yes. You can use Omnissa technologies to create a Windows virtual machine that can be used to install the Omnissa Access Windows connector.
Q: Does the Omnissa Access connector have to be installed on-premises?
A: The Omnissa Access Windows connector is an on-premises component that is typically installed in an enterprise's intranet or green zone. However, customers can install the connector on a cloud, provided it can communicate with the enterprise Active Directory over LDAP/LDAPS protocol on ports 389, 636.
Q: My enterprise already has an Omnissa Access tenant configured as a part of other products purchased through Omnissa. Can I use the existing tenant instance instead of creating a new one for the self-service federation setup?
A: No, you cannot use any of the existing Omnissa Access tenants that you have. A new Omnissa Access tenant will be spun as part of the self-serivce federation setup. It will be used exclusively for Omnissa Cloud Services. There is no cost or license requirement to use the new Omnissa Access tenant for access to Omnissa Cloud Services.
The same applies to using an existing Omnissa Access connector. The federation setup requires a new one.
Q: My enterprise already has an on-premise Omnissa Access connector. Can I use the existing connector instead of creating a new one for the self-service federation setup?
A: No. The self-service federation setup requires your enterprise to install and configure a dedicated Omnissa Access connector that will be used only for federation with Omnissa Cloud Services.
The same applies to using an existing Omnissa Access tenant. The federation setup requires a new one.
Q: Do I have to open any firewall ports for the Omnissa Access connector to establish trust with the Omnissa Access service instance?
A: The Omnissa Access connector communicates over outbound HTTPS/443 channel to the Omnissa Access service instance that acts as identity broker. If the firewall blocks access to external domains, some Omnissa domains must be granted access.
Q: What data is synced by the Omnissa Access on-premises connector?
A: The Omnissa Access on-premises connector is used for user and group sync into the Omnissa Access service instance (identity broker) to the customer's identity provider. Only User and Group DNs configured during the self-service setup are synced, not your entire AD. Only a set of required attributes are synced: first name, last name, email, username and domain. If your enterprise uses User Principal Name (UPN) to authenticate users, this attribute must have a value for the sync as well.
Important: User passwords are never synced.
Q: In what regions is the Omnissa Access service instance (Identity Broker) hosted?
A: The Omnissa Access service instance is hosted on AWS in the US region.
Q: Can I have users from different domains that I own – like acme.com, ext.acme.com, company.com – authenticate against my Identity Provider?
A: Yes. If you can verify all the public domains that you own, then the users of these domains can authenticate to Omnissa Cloud Services with their corporate credentials. The users of all these domains first have to be synced into the Omnissa Access service instance (identity broker).
Q: How do I verify private domains during the self-service federation setup?
A: This option is not available in the current self-service federation workflow. To verify private domains, you must raise a support request and the support team will verify your private domains on your behalf.
Q: Can I add services to the Management Organization?
A: No. You cannot and should not add services to the Management Organization. You access the enterprise federation dashboard in the Management Organization with the sole purpose of performing operations that impact all services and Organizations for a given domain.
Q: Is there a break-glass account that I can use to access Omnissa Cloud Services if I cannot log in with my corporate credentials?
A: You can add a Customer Connect account to your Organization with a domain that is not federated. For example, if the acme.com domain is federated, then any Customer Connect account with a non-acme.com domain can be used to log in to Omnissa Cloud Services. The user with the Customer Connect account must be added as an Organization Owner or Organization Member user to the Organization.
Q: Are the attributes, synced from my corporate Active Directory, encrypted when persisted on Omnissa Access service instance and Omnissa Cloud Services on AWS?
A: No. The user attributes first name, last name, email, username, domain and UPN are not encrypted when persisted by Omnissa Cloud Services on AWS.
Q: What would be the impact on users accessing Cloud Services Console if the connector server is down? Can I configure the connector in HA mode?
A: If your enterprise is using third party Identity Provider authentication, and not the connector based authentication methods, then all user authentication is happening directly against your Identity Provider. In this case, if the connector is down, the user login will not be impacted for those users who are already synced. Since the connector is only used for user and group sync, connector in HA mode may not be needed.
Was this page helpful?