I have done this post before, but it was back in the day when we called VCD for vCloud, miss the name a bit but not the flash GUI. In the future Cloud Director will not support local users in organizations. Therefore, if the customer needs to have access to their organization it needs to be with an IDP identity provider for SAML or OAuth.
Many customers today have Microsoft 365 already and therefore also AzureAD which is a convenient choice for SAML integration For the non-AzureAD IDP admin, you should also be able to use this guide since it’s only claims and metadata.
This guide will focus on access assigned based on group membership, but you can also use roles. The main difference between roles and groups would be that roles can be more granular than group memberships. For example, you can have a role that gives access to expand a disk or delete a VM, the roles translate better than groups.
Microsoft have changed the name of AzureAD to Entra, this post will refer to both AzureAD but this also means Entra
Process
- Create Enterprise app in desired resource AzureAD
- Add entity ID and claims
- Import AzureAD enterprise app federation metadata to Cloud Director
- Assign allowed users/groups to roles in Cloud Director
Claims
Cloud Director is very picky about claims, VMware documentation gives a list of how the claims should look.
- email address = “EmailAddress”
- user name = “UserName”
- full name = “FullName”
- user’s groups = “Groups”
- user’s roles = “Roles”
If you want the claim names with the full namespace, then you can map it in the Cloud Director SAML attribute mapper. Attribute mapper
AzureAD(Entra) setup
Enterprise Application creation
The basic setup of Entra is shown in this short story below. We will end up with an Enterprise App that is ready to setup.
Enterprise app configuration
SAML Claims
Set up the claims according to the screenshot below. If you make claim names as in the screenshot then it will match Cloud Director so the SSO should work out of the box.
The only special setup is for the group claim where you should do the following
- Choose “Groups assigned to the application”. If you have many groups in Entra SAML setup is only returning some of them. And if the group Cloud Director is looking for is not returned, then you are not logged in.
- Source attribute of “Group ID”. Haven’t gotten it
- Under Advanced options, choose “Customize the name of the group claim” and set it to “Groups” This will make sure Cloud Director knows that its groups.
If you are using a differnt IDP wher you cant alter the claim names, then you the attribut mapper in Cloud Diretor to translate the claimnames over to something that Cloud Director understands.
Cloud Director configuration
Go to tenant context and navigate to “Administration” > “SAML”. You might be hit with a prompt that the certificate is expired.
Fill out the wanted entity ID. I usually just use the URL for the tenant vcd. The important thing is just that the entity ID matches between Entra Enterprise App and Cloud Director.
Download the federation metadata XML from the AzureAD Enterprise application.
Upload the metadata to Cloud Director SAML configuration, enable the SAML identity provider, and press save.
We are now ready to upload the metadata from Cloud Director.
Now upload the metadata to the Enterprise Application
After the upload the Entity ID and reply URL will be filled out.
Cloud Director SAML groups
For the Cloud Director to know what role the login user should have we need to tell it what group ID is associated with what role. We do that by fetching the ID of the group in AzureAD.
Copy the ID and go over to Cloud Director under “Administrator” > “Groups” > “Import Groups”
Paste in the ID and select the role followed by save. Using the Group ID helps if someone decides to change the name of the groups in Entra. For easier to see what group is behind the ID I tend to insert the group name(s) into the description after it has first been created.
Troubleshooting
There can be multiple places where problems can happen. Most of the time I start to look into a saml response, if that contains the groups that I expect then you will need to go on and look in the VCD logs.
SAML response
In your favorite browser, find developer mode and have it capture the traffic. Then log on to VCD have the error occur and then stop the capture again.
<samlp:Response Destination="https://vcd.ramsgaard.dk/login/org/system/saml/SSO/alias/vcd" ID="_684262e1-e528-422f-8bf7-dd6d78f3ab49" InResponseTo="af3h19802aa811a5824j5b18aidee2" IssueInstant="2023-09-18T11:52:08.837Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/c5c123a4-e828-43bd-84d6-05cbfe1efae5/</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<Assertion ID="_e96104c4-681e-4624-111e-a6e9a2bf6900" IssueInstant="2023-09-18T11:52:08.833Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">We want to see a success for the SAML authentication. If we got that then it can be due to the claims being sent with it.
<Attribute Name="name">
<AttributeValue>user@domain.tld</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/UserName">
<AttributeValue>user@domain.tld</AttributeValue>
</Attribute>
<Attribute Name="Groups">
<AttributeValue>93547461-c174-4cab-961f-6f21c43051bd</AttributeValue>
<AttributeValue>3c86569c-9e03-43f8-87fa-30b566ebb829</AttributeValue>
</Attribute>
</AttributeStatement>In the snip above you can see that I got two group IDs back in the claim, check if these are the group IDs VCD is looking for. If not, then you need to investigate if the user is a member of the correct groups.
Conclusion
Since VCD local users are deprecated and will be removed in the future we need to convert over to use an IDP instead. AzureAD is a nice way to implement MFA and has a single identity for accessing corporate resources.
