Purpose
Note: This is a not a comprehensive guide. For more information, see the vSphere 5.1 documentation. The documentation contains definitive information. If there is a discrepancy between the documentation and this article, assume that the documentation is correct.
Resolution
vSphere 5.1 introduces a new independent Single Sign On service as part of the vCenter Management Infrastructure.
Authentication by vCenter Single Sign On makes the VMware cloud infrastructure platform more secure by allowing the various vSphere software components to communicate with each other through a secure token exchange mechanism, instead of requiring each component to authenticate a user separately with a directory service like Active Directory.
This impacts the way the management software is installed, deployed, configured, and used.
Authentication by vCenter Single Sign On makes the VMware cloud infrastructure platform more secure by allowing the various vSphere software components to communicate with each other through a secure token exchange mechanism, instead of requiring each component to authenticate a user separately with a directory service like Active Directory.
This impacts the way the management software is installed, deployed, configured, and used.
Behavior during the installation or upgrade
If you are performing a fresh installation of vCenter Server 5.1 or upgrading from an earlier version, ensure that you are aware of these changes:
| Behavior | vCenter Server 5.0 or earlier | vCenter Server 5.1 |
| Installer | Setup.exe | Auto launcher that guides through the installation |
| Installation steps | Single installer installs vCenter Server and silently installs the Inventory service. | Three separate installers are available on the auto launcher. These components need to be installed the order: Single Sign On (SSO) Inventory Service (IS) vCenter Server (VC) Each of these can be installed in a different host or virtual machine. SSO can be installed in multiple modes:
|
| Upgrade from vCenter Server 4.x or 5.0 | The local operating system user or Active Directory users registered with vCenter Server can continue to work with the new vCenter Server. | The upgrade process installs SSO first and then upgrades vCenter Server. AD use case In case of AD, if SSO is running in a virtual machine or host that is in the same domain as AD, SSO auto discovers the AD domain and joins it automatically during the SSO install process. Otherwise, the user must log in to the vSphere Web Client and add the AD domain to SSO. Local OS users If you are installing SSO and vCenter Server in the same host or virtual machine, the existing local operating system users are picked by SSO. Upon upgrade, one can log in to vCenter Server with the registered local operating system user ID. If SSO and vCenter Server are installed in different hosts or virtual machines, the former local operating system users (used for logging in to vCenter Server) are not be available to SSO. Therefore, new local users must be created in the host or virtual machine where SSO is being installed. In vCenter Server 5.1, local operating system users refer to the local users in the SSO machine. |
Notes:
- For small vSphere deployments, vCenter Server 5.1 provides a vCenter Server Simple Install option that installs vCenter Single Sign On, Inventory Service, and vCenter Server on the same host or virtual machine.
- Alternatively, to customize the location and setup of each component, you can install the components separately by selecting the individual installation options in this order: vCenter Single Sign On, Inventory Service, and vCenter Server. Each component can be installed in a different host or virtual machine.
- For the first installation of vCenter Server with vCenter Single Sign On, you must install all three components, Single Sign On Server, Inventory Service, and vCenter Server, in the vSphere environment. In subsequent installations of vCenter Server in your environment, you do not need to install Single Sign On. One Single Sign On server can serve your entire vSphere environment.
- After you install vCenter Single Sign On once, you can connect all new vCenter Server instances to the same authentication server. However, you must install a Inventory Service instance for each vCenter Server instance.
- In vCenter Server 5.0 or earlier upgrades, both the local operating system users and Active Directory users that are registered with vCenter Server before the upgrade continue to work with the upgraded vCenter Server. This behavior changes in vCenter Server 5.1.
- In vCenter Server 5.1, if vCenter Single Sign On is running on a virtual machine or physical machine that is joined to an Active Directory domain, Single Sign On automatically discovers the existing Active Directory domain and adds it as an identity source during the Single Sign On installation process. If Single Sign On is not running on a virtual machine or physical machine that is in the same domain as Active Directory, you must use the vSphere Web Client to log in to vCenter Server and add the Active Directory domain to Single Sign On.
- If you install vCenter Single Sign On and vCenter Server on the same physical machine or virtual machine, Single Sign On recognizes existing local operating system users. After the upgrade, you can log in to vCenter Server with a registered local operating system user ID.
- If you install vCenter Single Sign On and vCenter Server on different hosts or virtual machines, the former local operating system users who managed login access to vCenter Server are not available to Single Sign On.
- When you install vCenter Single Sign On in multisite mode or clustered high availability mode, all pre-upgrade permissions for local operating system users are lost. In vCenter Server 5.1, the term local operating system users refers to those local users in the Single Sign On host machine instead of the vCenter Server host machine or virtual machine.
- After the upgrade, if no super administrator remains (the administrative user or group for the root folder), you must provide a valid user or group to be used as super administrator during installation. This situation can occur due to changes in user stores from pre-5.1 to 5.1 versions of vSphere.
For more information on installing vCenter Server Sign On, see the vSphere Installation and Setup guide.
Behavior after upgrading or installing vCenter Server and its services
| Behavior | vCenter Server 5.0 or earlier | vCenter Server 5.1 |
| Adding an AD domain | vCenter Server automatically adds those AD domains to which the host or virtual machine running vCenter Server is a part of. | SSO automatically discovers those AD domains to which the host or virtual machine running SSO is a part of. It adds those auto discovered AD domains to SSO. |
| Adding multiple AD domains | vCenter Server can also be configured for a different AD domain. However, at a given time only one AD domain can be configured with vCenter Server. | Using SSO, multiple AD domains can be added simultaneously. |
| Adding OpenLDAP | This was NOT possible in vCenter Server | SSO can add multiple OpenLDAP domains. vCenter Server can be configured for use by users from these OpenLDAP repositories. You can also do without AD if you choose to. |
Notes:
- vCenter Server 5.0 or earlier versions add Active Directory domains that the vCenter Server host or virtual machine is part of. In vCenter Server 5.1, vCenter Single Sign On discovers those Active Directory domains that the vCenter Single Sign On host or virtual machine is part of.
- vCenter Single Sign On adds those discovered Active Directory domains. Unlike earlier vCenter Server versions, which permit only one Active Directory domain at a time to be configured for vCenter Server, in vCenter Server 5.1 with Single Sign On, you can add multiple Active Directory domains.
- vCenter Single Sign On can also add multiple OpenLDAP domains, and you can configure vCenter Server to be available to users who are registered with these OpenLDAP repositories, enabling you to manage vCenter Server access without Active Directory.
For more information on adding domains to vCenter Server 5.1, see the vSphere Security Guide.
Behavior or the user repository
| Behavior | vCenter Server 5.0 or earlier | vCenter Server 5.1 |
| User Repository |
|
|
Notes:
- vCenter Server 5.0 and earlier versions support Active Directory and local operating system users as user repositories. vCenter Server 5.1 supports these types of user repositories as identity sources:
- Active Directory
- OpenLDAP
- Local operating system
Local operating system users are local to the operating system where the Single Sign On server is running, such as Windows. Only one local operating system identity source is allowed. The local operating system identity source exists only in basic Single Sign On server deployment. - System
A fourth type of user repository is Single Sign On system users (System-Domain). Exactly one system identity source is always associated with an installation of Single Sign On. These users are contained in a database that is internal to the Single Sign On server. System users are not the same as local operating system users.
- You can attach multiple identity sources from each type to a Single Sign On server.
For information about configuring identity store support, see the vSphere Installation and Setup and vSphere Security Guides.
Behavior when authenticating to the vCenter Server environment
| Behavior | vCenter Server 5.0 or earlier | vCenter Server 5.1 |
| Authenticating to SSO Service | This did not exist. | Because the vCenter Server service now has an independent SSO service, users must be created to manage this service. These users may not be the same as the users administering vCenter Server. The default SSO administrator user id isadmin@System-Domain. SSO admin users can be created using the SSO Users and Groups navigation link. There are three permissions that can be associated with these users:
|
| Authenticating to vCenter Server | Users connect to vCenter Server and vCenter Server authenticates the user by validating the user against an AD domain or local operating system. | Users do not authenticate to vCenter Server any more. |
Notes:
- In vCenter Server 5.0 and earlier versions, when users connect to vCenter Server, they were authenticated when vCenter Server validated their credentials against an Active Directory domain or the list of local operating system users. In vCenter Server 5.1, users authenticate through vCenter Single Sign On.
- The default Single Sign On administrator is admin@System-Domain with the password you specified at installation. You use these credentials to log in to the Single Sign On administration tool in the vSphere Web Client. You can then assign Single Sign On administrator privileges to users who are allowed to manage the Single Sign On server. These users might be different from the users that administer vCenter Server.
- In the vCenter Server Appliance, local operating system administrators, such as root, also have vCenter Single Sign On administrator privileges.
- Logging in to the vSphere Web Client with Windows session credentials is supported only for Active Directory users of the domain to which the Single Sign On system belongs.
- ESXi 5.1 is not integrated with vCenter Single Sign On and you cannot create ESXi users with the vSphere Web Client. You must create and manage ESXi users with the vSphere Client. vCenter Server is not aware of users that are local to ESXi. In addition, ESXi is not aware of vCenter Server users. However, you can configure Single Sign On to use an Active Directory domain as an identity source, and configure ESXi to point to the same Active Directory domain to obtain user and group information. This action allows the same set of users to be available to the host and to vCenter Server.
For more information on using vCenter Single Sign On to Manage Users and Groups, see the vSphere Security guide.
Behavior when using the vSphere GUI
| Behavior | vCenter Server 5.0 and prior | vCenter Server 5.1 |
| vSphere Client | User logs in to each vCenter Server separately. All linked vCenter Server instances are visible in the left pane. vCenter Servers that are not linked are not visible unless the user connects to it explicitly. | Same behavior. None of the new capabilities of the vSphere 5.1 Web client is available on the vSphere Client GUI. |
| vSphere Web Client | User logs in to each vCenter Server, just as in the vSphere Client GUI. All Linked vCenter instances can be seen by connecting to any of the vCenter Servers connected in linked mode. | User authenticates to SSO and gets connected to the vSphere Web Client. User gets to view all the vCenter Server instances for which he has permissions. When a user connects to vCenter, he does not have to authenticate any more. The actions that a user can perform on objects depends on his vCenter Server permissions on those objects. For vCenter Server 5.0 or earlier versions, the user must explicitly register the vCenter Server with the vSphere Web Client using the Register vCenter Server link. |
Notes:
- Before you can connect to a vCenter Server 5.0 system with vSphere Web Client 5.1, you must register it with the vSphere Web Client.
- You can register multiple vCenter Server systems with a single vSphere Web Client.
- Register a given vCenter Server system with only one vSphere Web Client instance, rather than using multiple vSphere Web Client instances to manage that vCenter Server system.
- To register a vCenter Server system with the vSphere Web Client installed as part of a vCenter Server Appliance, you must use the admin-app command-line script, rather than the Web-based administration tool.
For more information, see the Using the vSphere Web Client Administration Tool section of the vCenter Server and Host Management Guide.
Behavior when using the vSphere API
| Behavior | vCenter Server 5.0 or earlier | vCenter Server 5.1 |
| vSphere API | User logs in to each vCenter Server using userid/password or SSPI | User has to authenticate to SSO using userID and password or SSPI. Upon successful authentication, user gets a SAML token. User passes the token to vCenter Server. |
For more information on using the vSphere API, see the vSphere Management SDK Guide.
Behavior of SSO Instance
| Behavior | vCenter Server 5.0 or earlier | vCenter Server 5.1 |
| SSO to vCenter Server ratio | Not Applicable | A single SSO instance can support multiple vCenter Server and Inventory Service(IS) instances. During the very first installation, all three components (SSO, IS, VC) must be installed. During subsequent installations SSO need not be installed. IS and vCenter Server can be pointed to an existing SSO service. The installer provides a way to specify that information. |
For more information on the SSO instances, see the vSphere Installation and Setup Guide.
SSO Deployment modes
| Behavior | vCenter Server 5.0 or earlier | vCenter Server 5.1 |
| Basic | Not Applicable |
|
| Cluster | Not Applicable |
|
| Multisite | Not Applicable |
|
Notes:
- vCenter Server instances in linked mode can be connected to different physical Single Sign On servers, but must be connected to a single logical Single Sign On server. A single logical Single Sign On server can take any of these forms:
- A single physical Single Sign On server
- Two nodes of a cluster
Note: This is the same as a single physical Single Sign On server because the nodes use the same Single Sign On database. - Two nodes in multisite mode.
For information about SSO Deployment modes, see the vSphere Installation and Setup and vSphere Security Guides.
Source of this Info:-
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2032135
No comments:
Post a Comment