This topic covers frequently asked questions (FAQs) about the enterprise federation of corporate domains with Omnissa Connect.
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 Connect.
Q: Can I still access Omnissa Connect 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 Connect using your corporate account, but you can continue to access https://customerconnect.omnissa.com with your Omnissa ID.
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 (Omnissa account) only if you want to file a support ticket.
Q: Can I continue to use my Omnissa ID account to log into Omnissa Connect 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 Connect.
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 Omnissa ID/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 Connect 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 Connect at login.
Q: Is enterprise federation tied to a particular organization or service in Omnissa Connect?
A: No. Enterprise federation is domain wide. Any user with registered and verified domains can access any Omnissa Connect organization and the services for which that organization is subscribed.
Also, if you subscribe for additional services from Omnissa, you will continue to access the new services with your corporate credentials.
Q: Can I switch from using non-federated accounts to federated accounts?
A: Yes. See the topic How do I move from using non-federated accounts to federated accounts? for details.
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 Omnissa Connect console. If Support reverts the enterprise federation setup, any entitlements, users, and groups that were added post federation setup can be lost.
Q: Can I change my third-party identity provider after I've set up enterprise federation?
A: No. You must file a support ticket to change the identity provider. Access How Do I Modify The Enterprise Federation Setup for details.
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 Omnissa ID/Customer Connect account to authenticate with Omnissa Connect. After federation is activated, you use your corporate account to log in to Omnissa Connect and authenticate directly against your corporate identity provider. To access the services you previously used by logging with your Omnissa ID/Customer Connect account, you must link your corporate account to your Omnissa ID. Only when the two accounts are linked, do 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 in Identity Management after enterprise federation has been activated?
A: You initially accessed Omnissa Connect using your Omnissa ID/Customer Connect account. Let's say you used joe@acme.com to create a Omnissa ID/Customer Connect account and log in to Omnissa Connect using that account. Post federation, you access Omnissa Connect using your federated account and linked your Omnissa ID/Customer Connect ID account. The initial joe@acme.com is grayed out and marked with an Omnissa ID label to identify 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: SAML 2.0 and OIDC compliant third-party identity providers are supported for enterprise federation with Omnissa Connect.
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-service federation setup. It will be used exclusively for Omnissa Connect. There is no cost or license requirement to use the new Omnissa Access tenant for access to Omnissa Connect.
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 Connect.
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 an 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 your 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 Connect 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 Connect if I cannot log in with my corporate credentials?
A: You can add a Omnissa ID/Customer Connect account to your organization with a domain that is not federated. For example, if the acme.com domain is federated, then any Omnissa ID/Customer Connect account with a non-acme.com domain can be used to log in to Omnissa Connect. The user with the Omnissa ID/Customer Connect account must be added as an Owner or a Member user to the organization.
Q: Are the attributes synced from my corporate Active Directory encrypted when persisted on the Omnissa Access service instance and Omnissa Connect on AWS?
A: No. The user attributes first name, last name, email, username, domain and UPN are not encrypted when persisted by Omnissa Connect on AWS.
Q: What would be the impact on users accessing the Omnissa Connect 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.
Questa pagina è stata utile?