Tom Fojta's Bloghttps://fojta.wordpress.com
About virtualization, cloud computing and beyondThu, 15 Mar 2018 10:36:26 +0000enhourly1http://wordpress.com/https://s2.wp.com/i/buttonw-com.pngTom Fojta's Bloghttps://fojta.wordpress.com
What’s New in vCloud Director 9.1https://fojta.wordpress.com/2018/03/09/whats-new-in-vcloud-director-9-1/
https://fojta.wordpress.com/2018/03/09/whats-new-in-vcloud-director-9-1/#commentsFri, 09 Mar 2018 10:20:58 +0000http://fojta.wordpress.com/?p=2021Continue reading What’s New in vCloud Director 9.1→]]>vCloud Director version 9.1 has been released. It has been just 6 months since the previous release (9.0) so VMware is delivering on its promise of multiple yearly releases in 6 months cadence.

In this whitepaper you can find high level overview of some of the new features. Let me summarize them and also provide additional ones here below.

H5 UI Enhancements

In iterative process the HTML 5 UI is slowly replacing legacy Flex UI. The tenant portion now includes vApp, Catalog and Networking management functionality, OVF/ISO download/uploads without the need for Client Integration Plugin (hooray!) and support for standalone VMware Remote Console.

Associated organizations from multiple or single (new in 9.1) vCloud Director instances now have aggregated view of all Org VDCs with seamless UI redirections between instances.

SDK for UI Extensibility has been released which means the service provider can extend the UI with additional sections to provide access to new services. The SDK includes very simple example of a static page extension (e.g. terms of service, links to other services or price lists) and upcoming vCAT-SP whitepaper will show how to do more complex ones.

The H5 UI is now also used in provider context but only for new features related to vRealize Orchestrator extensibility configuration.

Both legacy UIs (provider and tenants) are still available until the full feature parity is achieved.

vRealize Orchestrator Integration

Updated vRealize Orchestrator plugin has been released. This means both providers and tenants can automate and orchestrate repeating tasks in vCloud Director.

What is completely new is the ability to integrate any vRealize Orchestrator workflows into vCloud Director UI and essential provide XaaS (anything as a service). Similar to vRealize Automation XaaS.

External Tools

Not specifically tied with vCloud Director 9.1 but fully supported now are:

vcd-cli Linux command line tool to easily trigger or script common vCloud Director tasks (both for provider and tenant).

Container Service Extension Ability to extend vCloud Director to be target for deployment of Kubernetes clusters for tenants and simple management through CLI.

Removed support for old vCloud API versions (1.5, 5.1): make sure you update your scripts or applications to use at least version 5.5 APIs (e.g. Usage Meter).

vCloud Director no longer registers itself as an extension to resource vCenter Servers (upgraded instances will not delete the extension registration).

]]>https://fojta.wordpress.com/2018/03/09/whats-new-in-vcloud-director-9-1/feed/11fojtaWhat’s New in vCloud Availability 2.0.1https://fojta.wordpress.com/2018/02/26/whats-new-in-vcloud-availability-2-0-1/
https://fojta.wordpress.com/2018/02/26/whats-new-in-vcloud-availability-2-0-1/#respondMon, 26 Feb 2018 01:49:34 +0000http://fojta.wordpress.com/?p=2013Continue reading What’s New in vCloud Availability 2.0.1→]]>Minor patch of vCloud Availability 2.0.1 was released last week. Besides many bug fixes, improved documentation and support for Cassandra version 3.x I want to highlight two undocumented features and add upgrade comment.

Provider vSphere Web Client Plugin

This is a return from 1.0 version of an experimental feature, where the provider can monitor state of vSphere Replication Manager Server, vSphere Replication Servers and all incoming and outgoing replications from inside the vSphere Web Client plugin in the particular (provider side) vCenter Server. This is especially useful for quick troubleshooting.

vRMS StatusvRS StatusReplication Status

Complex vSphere SSO Domain Support

Although it is not recommended to have multiple vCloud Director / vCloud Availability instances sharing the same vSphere SSO domain, it is now possible to accommodate such scenario. The reason why it is not recommended is, that it creates unnecessary dependency between the instances, limits upgradability and scale of each instance.

Upon startup vSphere Replication Cloud Service (vRCS) is querying SSO Lookup Service for Cassandra nodes and resource vCenter Servers. In order to limit the scope of such query to only those that belong to the particular vCloud Availability instance, create text file /opt/vmware/hms/conf/sites on all vRCS nodes with SSO site names that should be queried (one line per site).

Upgrade Options

You can upgrade to vCloud Availability 2.0.1 both from version 1.0.x and 2.0, however you need to use different upgrade ISO images for upgrading of the replication components (vRMS, vRCS and vRS). The installer and UI appliances are redeployed fresh as they are all stateless.

]]>https://fojta.wordpress.com/2018/02/26/whats-new-in-vcloud-availability-2-0-1/feed/0fojtavRealize Orchestrator Client with 4K Screenhttps://fojta.wordpress.com/2018/02/20/vrealize-orchestrator-client-with-4k-screen/
https://fojta.wordpress.com/2018/02/20/vrealize-orchestrator-client-with-4k-screen/#respondTue, 20 Feb 2018 10:26:53 +0000http://fojta.wordpress.com/?p=2006Continue reading vRealize Orchestrator Client with 4K Screen→]]>This is a quick tip for those that want to run vRealize Orchestrator client on 4K screen in Windows 10 and cannot see anything because the font is so tiny and does not scale. The full credit goes to @joerglew who published in on our internal Socialcast but I have not seen it on public internet.

Edit the file in notepad and add line <property name=”sun.java2d.dpiaware” value=”false”/> into the resources section of the xml.

That’s it. Enjoy nice large font on your 4K screen.

]]>https://fojta.wordpress.com/2018/02/20/vrealize-orchestrator-client-with-4k-screen/feed/0fojtaLayer 2 VPN to the Cloud – Part IIhttps://fojta.wordpress.com/2018/02/16/layer-2-vpn-to-the-cloud-part-ii/
https://fojta.wordpress.com/2018/02/16/layer-2-vpn-to-the-cloud-part-ii/#commentsFri, 16 Feb 2018 18:00:35 +0000http://fojta.wordpress.com/?p=1992Continue reading Layer 2 VPN to the Cloud – Part II→]]>Almost 3 years ago I have published an article how to set up layer 2 VPN between on-prem vSphere environment and vCloud Director Org VDC.

As both vCloud Director and NSX evolved quite a bit since to simplify the whole set up, here comes the part II.

Let me first summarize the use case:

The tenant has an application that resides on 3 different VLAN based networks running in its own (vSphere) datacenter. The networks are routed with existing physical router. The tenant wants to extend 2 of these networks to cloud for cloud bursting or DR purposes, but not the 3rd one (for example because there runs a physical database server).

This means the full setup can be done by the tenant in self-service fashion

Here are the steps:

The tenant will deploy freely available NSX Standalone Edge in its datacenter connected to trunk port with 2 VLANs mapped (10 and 11). Additional network configuration is necessary (forged transmits and promiscuous mode or sink port creation – see the link)

In the cloud Org VDC tenant deploys two routed Org VDC networks with identical subnets and gateways as networks A and B. These networks must be connected to the Org VDC Edge GW via subinterface (there can be up to 200 such networks on single Edge). The Org VDC Edge must have advanced networking enabled.

Tenant enables and configures L2VPN server on its Org VDC Edge GW. Note that this is a premium feature that the service provider must enable in Organization first (see this blog post).

Before the L2VPN tunnel is established the following must be taken into account:

The Org VDC Edge GW IP addresses are identical with the on-prem existing physical router. Therefore Egress Optimization Gateway addresses must be entered in the Peer Site configuration. That will prevent the Org VDC Edge GW from sending ARP replies over the tunnel.

The same must be performed on the Standalone NSX Edge via CLI (see egress-optimize command here).

The non-stretched network (subnet C) must be configured on the Org VDC Edge GW so it knows that the subnet is reachable through the tunnel and not via its upstream interface(s). This option however is not in vCloud UI, instead vCloud networking API must be used.Alternatively the provider could configure non-stretched network directly in the NSX UI:

Finally, the tunnel can be established by configuring L2VPN server details on the on-prem Standalone NSX Edge L2VPN client (endpoint IP, port, credentials, encryption) and providing VLAN to tunnel mappings.

Note to find the Org VDC network subinterface tunnel mapping vCloud API must be used again:

]]>https://fojta.wordpress.com/2018/02/16/layer-2-vpn-to-the-cloud-part-ii/feed/1fojtavCloud Director vApp Runtime Lease Expiration Actionhttps://fojta.wordpress.com/2018/01/23/vcloud-director-vapp-runtime-lease-expiration-action/
https://fojta.wordpress.com/2018/01/23/vcloud-director-vapp-runtime-lease-expiration-action/#respondTue, 23 Jan 2018 14:01:53 +0000http://fojta.wordpress.com/?p=1975Continue reading vCloud Director vApp Runtime Lease Expiration Action→]]>In vCloud Director it is possible to configure vApp leases. The maximums are set by system admin at Organization level (in Policies), which can be lowered by Org Admin (at org level) and set by vApp owner at the vApp level. A vApp has runtime lease (for how long it will be in running state) and storage lease (for how long it will consume storage once it is not running).

vApp leases are very useful in test & dev or lab environments to make sure abandoned, unused VMs are not running and taking resources.

When vApp lease is coming to an end, its owner gets a reminder via email (how many days before expiration can be configured in User Preferences) and can optionally reset vApp lease to avoid its stopping or deletion.

By default expired running vApp is put into suspended state which means its memory content is saved to datastores. This ensures fully consistent state upon consequent power on of the vApp. This however make not be always needed especially in dev/lab situations – the memory content could take lots of storage space and for example saving 16 GB RAM VM to datastore could also create IO performance impact. As of vCloud Director 8.20 the Organization Administrator can instead change the default runtime expiry action to power off. The setting is done at Org level and must be done via API by setting the element <PowerOffOnRuntimeLeaseExpiration> of OrgLeaseSettingsType to true. The API version must be at least 25.0.

Only customers that use vSphere Replication for DR or migrations to the cloud endpoints (e.g. vCloud Availability for vCloud Director) with ESXi 6.5U1 hosts are affected (ESXi 6.5 and older works fine). Also host-to-host replication is not affected.

The root cause is that ESXi 6.5U1 hosts are unable to retrieve from vSphere Replication Appliance vr2c-firewall.vib that is responsible for opening outgoing communication ports for replication traffic on the ESXi host firewall.

This results in inability to perform any to-the-cloud replications. To see the issue look into the host Firewall configuration in the Security Profile section. If you do not see Replication-to-Cloud Traffic section you are affected.

The picture below which traffic it is related to (red rectangle on the left):

If you would look into esxupdate.log on the host you will see error: [Errno 14] curl#56 – “Content-Length: in 200 response”.

This was a conscious decision as already for some time the licensing is handled externally by vCloud Usage Meter and the metering in vCloud Director caused vCloud database bloat.

If for some reason you still need to have these metrics available in UI, vCloud API or vROps Management Pack you can enable license metering with this command on a cell. No need for reboot, just wait few minutes for the next data collection.

]]>https://fojta.wordpress.com/2017/12/01/missing-licensing-metrics-in-vcloud-director-9-0/feed/0fojtaHow to Configure Additional VM Metrics in vCloud Directorhttps://fojta.wordpress.com/2017/11/24/how-to-configure-additional-vm-metrics-in-vcloud-director/
https://fojta.wordpress.com/2017/11/24/how-to-configure-additional-vm-metrics-in-vcloud-director/#respondFri, 24 Nov 2017 20:15:22 +0000http://fojta.wordpress.com/?p=1948Continue reading How to Configure Additional VM Metrics in vCloud Director→]]>vCloud Director already for some time (since version 5.6) provides to tenants basic set of VM metrics. Until vCloud Director 9.0 they had to be retrieved with vCloud API, however now the users can easily access the metrics from the new HTML5 UI.

The metrics in the file must not overlap with the already existing default metrics. Additional options about frequency, interval averages, etc. can be provided as well. See docs for the details.

On a vCloud Director cell with the cell-management-tool we will import the new metrics:$VCLOUD_HOME/bin/cell-management-tool configure-metrics –metrics-config /tmp/metrics.groovy

Still on the cell we need to update Cassandra schema, again with the cell-management-tool (provide the correct nodes addresses, DB authentication details, port and metrics time to live in days):$VCLOUD_HOME/bin/cell-management-tool cassandra –configure –cluster-nodes 172.16.0.41 –username cassandra –password cassandra –port 9042 –ttl 31 –update-schema

Restart all cells

That is all. After while we can monitor the new metrics with the UI or API.

The metric definition is stored in vCloud Director table metric_configuration.

In vSphere Replication when you are configuring replication of powered-off VM you will get the following message:

The virtual machine is not powered on. Replication will start when the virtual machine is powered on.

The replication is actually configured and its placeholder VM is created in the recovery location (cloud) but the VM will stay in Not Active state.

Why is this? Immediate start of replication locks VM disks which means such VM would not be able to power-on until the initial sync is finished. But what if you want to replicate powered-off VMs for example templates that are never meant to run?

You can in fact force start the replication by right clicking the VM and selecting Sync Now, which asks confirmation question if we really want to do so as the VM will not be able the be powered on until the operation completes.

Is there a use case for this? As I mentioned this could be used for catalog sync as replication is much faster and efficient that OVF export / import.

]]>https://fojta.wordpress.com/2017/11/22/vcloud-availability-replication-of-powered-off-vm/feed/0fojtaHow To Disable Local System Administrator Accounts in vCloud Directorhttps://fojta.wordpress.com/2017/11/19/how-to-disable-local-system-administrator-accounts-in-vcloud-director/
https://fojta.wordpress.com/2017/11/19/how-to-disable-local-system-administrator-accounts-in-vcloud-director/#respondSun, 19 Nov 2017 19:59:02 +0000http://fojta.wordpress.com/?p=1931Continue reading How To Disable Local System Administrator Accounts in vCloud Director→]]>For some time there has been a hidden security feature in vCloud Director that allows disabling local system administrator accounts. During vCloud Director installation a default local system administrator account is created. The user credentials are stored encrypted in the vCloud Director database but there is no way to enforce complex password policies other than Account Lockout Policy.

It is possible to configure external identity sources such us generic LDAP for basic authentication and SAML2 IdP (such as vCenter SSO). The authentication and thus also the password policies are than managed externally. However, when you try to delete or disable all local system administrator accounts you will get the following error:

Cannot delete or deactivate the last system administrator.

This is a built in protection against completely locking yourself out when the external identity sources are not available.

Some customers can have the need to enforce strict security rules on all vCloud Director system administrator logins. There is a non-documented way to disable all local system administrator accounts with a single command. The system administrator can run the following cell-management-tool command to enable config property local.sysadmin.disabled.

Immediately after the property is enabled, authentication with local accounts will stop working. It means authentication for all local system administrator accounts that exist in vCloud Director (not just the default account created during installation) will be rejected. Organization local accounts will not be affected.

In case access to external IdPs is lost, the system admin can again disable the property to regain access to vCloud Director:

]]>https://fojta.wordpress.com/2017/10/03/vcloud-director-9-customize-tenant-ui/feed/10fojtavCloud Director 9: SAML2 Federation for System Administratorshttps://fojta.wordpress.com/2017/10/03/vcloud-director-9-saml2-federation-for-system-administrators/
https://fojta.wordpress.com/2017/10/03/vcloud-director-9-saml2-federation-for-system-administrators/#commentsTue, 03 Oct 2017 10:37:32 +0000http://fojta.wordpress.com/?p=1907Continue reading vCloud Director 9: SAML2 Federation for System Administrators→]]>In the past in vCloud Director 8.20 (and older versions) system admins (the provider context) could use local, LDAP and vSphere SSO accounts. vCloud Director 9.0 now replaces vSphere SSO accounts with more generic SAML2 accounts which means you can have the same IdP mechanism in the tenant and system context.

This change however breaks the previous vSphere SSO federation which was as simple as entering the vSphere Lookup Service URL and enabling the vSphere Single Sign-On with a check box (which in vCloud Director 9.0 is no longer there).

Here is the procedure how to enable vSphere Single Sign-On in vCloud Director 9.0.

Login to vCloud Director as system admin and from administration>System Settings/Federation download the metadata document (spring_saml_metadata.xml) from the link provided (../cloud/org/System/saml/metadata/alias/vcd). Make sure the certificate (below) is valid.

Login to vSphere Web Client as SSO admin and go to Administration/Single Sign-On/Configuration/SAML Service Providers

Import the metadata from step #1

Download the vsphere.local.xml metadata from the link below.

Go back to VCD, check use SAML Identity Provider and upload metadata from #4.

Note that Import Users/Group source now changes from vSphere SSO to SAML.

vCloud Director 8.20vCloud Director 9.0
]]>https://fojta.wordpress.com/2017/10/03/vcloud-director-9-saml2-federation-for-system-administrators/feed/4fojtavCloud Director 9: NSX Distributed Logical Routerhttps://fojta.wordpress.com/2017/10/02/vcloud-director-9-nsx-distributed-logical-router/
https://fojta.wordpress.com/2017/10/02/vcloud-director-9-nsx-distributed-logical-router/#commentsMon, 02 Oct 2017 10:04:57 +0000http://fojta.wordpress.com/?p=1889Continue reading vCloud Director 9: NSX Distributed Logical Router→]]>vCloud Director version 9 introduces support for the last major missing NSX feature – the distributed logical router (DLR). DLR provides optimized router which in distributed fashion performs routing between different logical switches in the hypervisor. The routing always happens in the hypervisor running the source VM which means that the traffic goes between maximum two ESXi hosts (source and destination) and no tromboning through third host running router VM is necessary. Read here for technical deep dive into how this works. This not only provides much better performance than traditional Edge GW routing, but also scales up to 1000 routed logical networks (as opposed to 10 on Edge GW or up to 209 if trunk port is enabled).

Generally, DLR should be used for routing only between VXLAN based logical switches, although NSX supports VLANs networks with certain caveats as well. Additionally dynamic routing protocols are supported as well and managed by Control VM of the DLR.

Now let’s look how vCloud Director implements DLR. The main focus was making DLR very simple to use and seamlessly integrate with the existing networking Org VDC concepts.

DLR is enabled on Org VDC Edge Gateway which must be already converted to advanced networking. You cannot use DLR without Org VDC Edge Gateway! There must be one free interface on the Edge (you will see later on why).

Once DLR is enabled, a logical DLR instance is created in NSX in headless mode without DLR Control VM (the instance is named in NSX vse-dlr-<GW name) (<UUID>)). vCloud Director can get away without Control VM as dynamic routing is not necessary – see later below.

DLR has default gateway set to the Org VDC Edge GW interface (10.255.255.249)

New Org VDC networks now can be created in the Org VDC with the choice to attach them to the Edge Gateway (as regular or subinterface in a trunk) or to attach them to the DLR instance.For each distributed Org VDC network a static route will be created on the Org VDC Edge Gateway to point to the DLR uplink interface. This means there is no need for dynamic routing protocols on the DLR instance.

Static Routes on NSX Edge GW

In the diagram below is the networking topology of such setup.

In the example you can see three Org VDC networks. One (blue) traditional (10.10.10.0/24) attached directly to the Org VDC Edge GW and two (purple and orange) distributed (192.168.0.0/24 and 192.168.1.0/24) connected through the DLR instance. The P2P connection between Org VDC Edge GW and DLR instance is green.

DHCP relay agents are automatically configured on DLR instance for each distributed Org VDC network and point to DHCP Relay Server – the Org VDC Edge GW interface (10.255.255.249). To enable DHCP service for particular distributed Org VDC network, the DHCP Pool with proper IP Range just needs to be manually created on the Org VDC Edge Gateway. If Auto Configure DNS is enabled, DHCP will provide IP address of the Org VDC Edge P2P interface to the DLR instance.

Some networking features (such as L2 VPN) are not supported on the distributed Org VDC networks.

VLAN based Org VDC networks cannot be distributed. The Org VDC must use VXLAN network pool.

IPv6 is not supported by DLR

vApp routed networks cannot be distributed

The tenant can override the automatic DHCP and static route configurations done by vCloud Director for distributed networks on the Org VDC Edge GW. The tenant cannot modify the P2P connection between the Edge and DLR instance.

Disabling DLR on Org VDC Edge Gateways is possible but all distributed networks must be removed before.

Both enabling and disabling DLR on Org VDC Edge Gateway are by default system administrator only operations. It is possible to grant these rights to a tenant with the granular RBAC introduced in vCloud Director 8.20.

DLR feature is in the base NSX license in the VMware Cloud Provider Program.

Edit 02/10/2017: Engineering (Abhinav Mishra) provided a way how to change P2P subnet between the Edge and DLR. Add the following property value with CMT:

VXLAN Network Pool is recommended to be used as it scales the best. Until version 9, vCloud Director would create new VXLAN Network Pool automatically for each Provider VDC backed by NSX Transport Zone (again created automatically) scoped to cluster that belong to the particular Provider VDC. This would create multiple VXLAN network pools and potentially confusion which to use for a particular Org VDC.

In vCloud Director 9 we have the option to create our own VXLAN network pool backed by a NSX Transport Zone manually created and scoped to clusters we want to (and using any control plane mode).

During creation of Provider VDC we then have a choice to create a new VXLAN Network Pool (the legacy behavior) or use an existing one.

Advantages of the new feature are:

No more clutter of large amount of VXLAN network pools (if there are many Provider VDCs)

Simpler way to use hybrid or unicast control plane modes (vCloud Director would always default to multicast before)

Control over scope of VXLAN networks – especially useful for sharing Org VDC networks between Org VDCs from different Provider VDCs.

Adhering to best practice of scoping transport zone to whole vDS (more here)

]]>https://fojta.wordpress.com/2017/09/29/vcloud-director-9-create-vxlan-network-pool/feed/5fojtavCloud Director 9: What’s Newhttps://fojta.wordpress.com/2017/09/29/vcloud-director-9-whats-new/
https://fojta.wordpress.com/2017/09/29/vcloud-director-9-whats-new/#commentsFri, 29 Sep 2017 13:54:33 +0000http://fojta.wordpress.com/?p=1883Continue reading vCloud Director 9: What’s New→]]>VMware just released new version of vCloud Director – and it is a major release with version number 9.0.

Note that announced migration tool called vCloud Director Extender has not yet been released.

]]>https://fojta.wordpress.com/2017/09/29/vcloud-director-9-whats-new/feed/7fojtavCloud Architecture Toolkit for Service Provider Updatehttps://fojta.wordpress.com/2017/09/14/vcloud-architecture-toolkit-for-service-provider-update/
https://fojta.wordpress.com/2017/09/14/vcloud-architecture-toolkit-for-service-provider-update/#commentsThu, 14 Sep 2017 15:43:21 +0000http://fojta.wordpress.com/?p=1874Continue reading vCloud Architecture Toolkit for Service Provider Update→]]>The vCloud Architecture Toolkit for Service Provider website has been updated with new set of documents. All documents were re-branded with the new VMware Cloud Provider Program logos that replace the old vCloud Air Network brand.

]]>https://fojta.wordpress.com/2017/09/14/vcloud-architecture-toolkit-for-service-provider-update/feed/2fojtavRealize Operations Management Pack for NSX-V and Log Insight Integrationhttps://fojta.wordpress.com/2017/08/17/vrealize-operations-management-pack-for-nsx-v-and-log-insight-integration/
https://fojta.wordpress.com/2017/08/17/vrealize-operations-management-pack-for-nsx-v-and-log-insight-integration/#commentsThu, 17 Aug 2017 16:07:51 +0000http://fojta.wordpress.com/?p=1869Continue reading vRealize Operations Management Pack for NSX-V and Log Insight Integration→]]>Quick post about an issue I discovered in my lab during upgrade to NSX 6.3.3. This particular NSX version has a silent new feature that verifies if syslog configuration on Edges is correct. If the syslog entry is incorrect (it is not an IP address or FQDN with at least one dot character or does not have TCP/UDP protocol specified) it will not let you save it. This however also means that older Edges (with version 6.3.2 or older) that have incorrect syslog setting will fail to be upgraded as the incorrect config will not be accepted.

So how does it relate to the title of the article? If you have vROps in your environment with NSX-V management pack and you have enabled Log Insight integration, the Management Pack will configure syslog on all NSX components. Unfortunately in my case it configures them incorrectly with only hostname and no protocol. This reconfiguration happens roughly every hour. This might be especially annoying in vCloud Director environment where all the Edges are initially deployed with syslog setting specified by VCD, but then are changed within an hour by vROps to something different.

Anyway, the remediation is simple. Disable the Log Insight integration of the vROps NSX Management Pack as shown on the picture below.

]]>https://fojta.wordpress.com/2017/08/17/vrealize-operations-management-pack-for-nsx-v-and-log-insight-integration/feed/1fojtaSSO for vCloud Availability Portal UIhttps://fojta.wordpress.com/2017/06/23/sso-for-vcloud-availability-portal-ui/
https://fojta.wordpress.com/2017/06/23/sso-for-vcloud-availability-portal-ui/#respondFri, 23 Jun 2017 13:16:53 +0000http://fojta.wordpress.com/?p=1860Continue reading SSO for vCloud Availability Portal UI→]]>This is a quick followup on my yesterday’s blog post that discussed how to customize vCloud Director UI with additional links. vCloud Availability has separate Portal UI where the users can monitor status of their replications and optionally trigger failover operations. Wouldn’t it be nice if the link from vCloud Director UI would automatically sign in the user into the vCloud Availability Portal UI?

Quick chat with the engineers showed that indeed it is possible by leveraging the {vcdSession} variable that provides the vCloud Director session token. The URL provided in the link then must look like this:

vCloud Director 8.20 provides very simple way to extend the right column of the Home screen with additional sections and static links. It is really simple extensibility and should be used as interim solution until the new HTML 5 UI will fully replace the existing UI and which will be more extensible.

In the screenshot below you can see that the right section has been extended with vCloud Availability, Backup and Other sections.

The configuration of these links is very simple and is done from cell-management-tool on any vCloud cell.

It is also possible to pass vCloud session ID as parameter in the URL by including {vcdSession} string.

The CMT manage-config command creates/modifies database entry in the config table tenant-customOrgLinks with the provided value in the quotes. Re-running it will replace the previous entry. The change is immediate, no need to run this on other cells or restart vcd services.

One last note, the right column on the home screen is not visible to all user roles. The role needs to have General > Administrator Control right.

]]>https://fojta.wordpress.com/2017/06/22/how-to-customize-vcloud-director-ui/feed/10fojtaDefer to Identity Provider Role in vCloud Directorhttps://fojta.wordpress.com/2017/06/05/defer-to-identity-provider-role-in-vcloud-director/
https://fojta.wordpress.com/2017/06/05/defer-to-identity-provider-role-in-vcloud-director/#respondMon, 05 Jun 2017 15:47:11 +0000http://fojta.wordpress.com/?p=1842Continue reading Defer to Identity Provider Role in vCloud Director→]]>Besides traditional roles (Org Administrator, vApp Author, …) there is already for some time (as of vCloud Director 8.0) the possibility to assign to vCloud Director organization users a role called ‘Defer to Identity Provider’.

I am going to show how this role can be used to manage assignments of organization roles centrally from within the Identity Provider (IdP) and not from vCloud Director at the Organization level. Central management might be beneficial in cases where there are many Organizations (and vCloud Director instances) associated with single IdP and one user might have access to multiple Organizations. With the traditional approach the user (or his group) would have to be imported into each Organization where he/she should have access and assigned a role.

By deferring to identity provider we rely on the IdP to provide the user’s role just in time when the user is logging in. The feature works both with SAML and OAuth identity providers. In my example I am going to be using the SAML IdP provided by Active Director Federation Services federated with vCloud Director as described in my older blog post.

The set up:

Active Directory is used to manage all the users (with exception of local user for onboarding or troubleshooting purposes). The AD can be owned by the Service Provider or the tenant, it depends on the use case.

AD FS has been deployed and integrated with vCloud Director Organizations. Note that each Organization must be federated with AD FS specifically. And the federation must be refreshed every year by regeneration of new certificate. In SP use case some level of automation is essential. For details refer to the blog article linked above.

AD users who should have access to vCloud Director organization will be part of AD group <Tenant_X>.

Role association will be achieved by assigning the AD users to specific AD groups: Organization Administrator, vApp Author, …

For each role we will need to add new Transform Claim Rule in AD FS.

On the existing relaying party trust click Edit Claim Rules

Click Add Rule

Select Send Group Membership as a Claim template

Name the rule (e.g. vApp Author)

Browse to the User’s group that represents the role membership (vApp Author group)

In Outgoing claim type select Role.

In Outgoing claim value type the vCloud Director role name (vApp Author).

In vCloud Director Organization we need to do following:

As already mentioned each Org needs to be federated with AD FS

In Members > Groups import the <Tenant X> group from Source: SAML with Role: Defer to Identity Provider.

Now the users can start logging in with their AD accounts and they will be automatically imported as users with Defer to IdP role. If needed, you can still directly import SAML users and specifically give them role which will take precedence over the IdP role.