Getting java.io.IOException: HTTP response code: 526 when configuring OIDC SSO in VCSA

[DroboDeveloper]

Hi Guys,

I am trying to configure SSO into VCSA using a third-party IDP provider that supports OIDC. On the last step of the VCSA "Change Identity Provider" wizard I am getting the following error:

 

I'm at a bit of a loss on how to debug this error. What I know so far:

1. The IDP has a cert signed by a publicly trusted Certificate Authority.
2. The OIDC settings are all configured correctly.
3. The LDAP settings are all configured correctly.
4. The VCSA is net-new. No other Identity Sources configured other than the default System Domain.
5. VCSA v7.0.2.00100

Any help to pull this over the finish line would be much appreciated.

[potato49]

I'm having this exact same issue after upgrading to VCSA v7.0.2.00100; I have a ticket open with VMware, I'll keep you posted if we come to a resolution on this.

[DroboDeveloper]

Thank you so much, buddy. Very much appreciated.

[Alexander Harb]

I have the same issue in  7.0.2.00200

[potato49]

I was finally able to get this resolved today. It ended up being a cert issue and I had to reissue a new publicly signed machine cert and cert chain.

 

This guide should work for you if you are using your own internal Microsoft CA: https://www.terataki.net/2020/04/14/add-custom-certificate-to-vcenter-7/

I, unfortunately was not able to use my Microsoft CA for this and had to request a cert from a public cert provider (we use SSL.com). In vSphere under Administration-> Certificate Management on the machine SSL cert actions-> Generate CSR (I had to provide this to the public cert authority for them to generate the cert). I've read that these certs ARE case sensitive for the hostname listed in your CSR, so be wary of that.

 

Once I got the cert I was able to go back into cert management in vSphere, select the machine SSL cert-> Actions Import and replace cert "Replace with external CA certificate where CSR is generated from vCenter Server (private key embedded)" I imported the machine SSL crt file for the machine SSL portion, but for the cert chain I had to open the certs sent to me in notepad and paste in the cert chain in order (For me it was 1st Trusted network CA 2nd Root Cert auth RSA 3rd SSL subCA) 

If you have any questions on this or are seeing any errors in this process, feel free to respond to this message and I'd be happy to help. This process was very painful for me working through it with VMware support so hopefully I can save you some of that time.

[Oliver-]

Hello, I still can't solve this problem after I operate according to your method. An error is reported when importing the certificate: invalid input: the subject fo the provided certificate does not contain the correct CN value

Do you have any other solutions?

[Lalegre]

Hey ,

Check the Subject and the Subject Alternative Name values of the certificate you are trying to use as this error is related to the values that are appearing there. If the Common Name does not comply with the FQDN that you are trying to connect then it will fail for sure.

 

[Oliver-]

Hello, but my "alternate name" is not filled in because it is an optional attribute. The public name is a secondary domain name customized by me according to the domain name. Does it have anything to do with this

[Oliver-]

[Lalegre]

I do not know if you wanted to attach that but the issue is what I told you related to the certificate it self. Check the contents of the certificate and see if the CN is populated properly.

[Oliver-]

Hello, I would like to ask whether the "computer SSL certificate" supports me to import self signed certificates. The public name is customized by me. The process of generating certificates is as follows

1. First, generate CRS files through vSphere client

 

2. Generate dependent certificates through local ad CS certificate service

3. The certificate template is "subordinate certification authority"

 

4. Code Base64

 

Finally, I want to confirm with you whether the computer accessing vSphere client (HTML5) needs to join the ad domain

[dgrove12]

I'm running into this issue.  Brand new vcsa 7.0.2.00200.  To me, it seems like it can't validate the cert associated with the ADFS OpenID URL, which for us is Entrust.  Strange that you needed to update the VC's local machine cert.  So basically, there's a requirement for the VC to be in hybrid certificate mode and not use the default machine cert that comes out of the box?  If that's the case, it'd be great to see that in the documentation.  I haven't tried those steps yet because I'm not sure I want to be in hybrid mode.  I opened a case.  We'll see what they say.

[Pixa]

We had the same issue. (7.0.2u2)

It worked after we entered root and subordinate from Digicert (which was asisgned to our ADFS) to Certificate Store.

[leejohnc]

Has anyone tried used AzureAD Federated SSO instead of ADFS and gotten that to work?

[leejohnc]

Nevermind, it was easy to setup with AzureAD Federated SSO.  We followed the same procedure as for ADFS, but with app registration in AzureAD.  We imported the digicert chain from login.microsoftonline.com in to the vmware cert store. Then we configured groups claims in AzureAD using the onprem security identifier.  Then of course then standard AD over LDAPS stuff for group authorization checks in vmware.

Works like a charm

[lavoiealex]

Hello  !

I am also trying to use AzureAD Federated SSO with our vCSA 7.0. Would it be possible for you to explain how to import the digicert from login.microsoftonline.com? I'm stuck there! Thanks for your help!

[omifreak]

Hello !

I would also like to change the vCenter login from ADFS to Azure AD. I imported the Microsoft DigCert certificates the the vCenter certificate store and replaced the ADFS part with a Azure AD app registration. The authentication works without errors when I directly authorize a Azure AD user in vCenter. But I'm struggeling to get the group membership into the SAML token.
I configured a group claim in the Azure app registration:

 

		"saml2Token": [
			{
				"name": "groups",
				"source": null,
				"essential": false,
				"additionalProperties": [
					"dns_domain_and_sam_account_name"
				]
			}
		]

 

But when I check the tokenservice.log in vCenter I see that the token is without group membership:

83,\n name = [e-mail],\n domain = mydomain.at,\n groupNames = [],\n groupIds = []\n}

The users are synchronized from Active Directory, should have the SAM account name and are in not to much groups. 

Does anyone have a tip on what I am doing wrong?

[leejohnc]

Microsoft is encouraging customers to use Azure Federation, with Azure PTA (Pass Through Authentication) or PHS (Password Hash Sync), in place of ADFS.  Many customers are using Microsoft ADConnect to sync on-prem AD with AzureAD.   Since the users and groups that are present in AD are also present in AzureAD (hybrid Identity), OIDC integration with VMware should be straight forward. 

 

Below is the process we used to accomplish it.  Please makes this an officially supported option.  It would also be helpful to add AzureAD groups for use in delegating access to vSphere as an option.  This would be forward thinking and help us get rid of the dependency on SSL certificates for LDAPS.  Please do also keep the option of using LDAPS for authorization, as this may still be helpful in some scenarios.

Configure vCenter Server Identity Provider Federation for (Azure)AD FS

 

Register an Enterprise Application in AzureAD.  Calling it something identifiable like VMware VSI Production

 

 

In AzureAD Click on app registration, and find the app registration created in the previous step

 

Record the Application Client ID and the Directory (tenant) ID.   You will need these for the “ADFS” config later 

 

 

Click on Endpoints.  Grab the Oauth V1 Endpoint and the oauth well-known open ID config.  These will be used in Step 6: Configure vCenter Server Identity Provider Federation for (Azure)AD FS

 

 

 

Add the URL for Oauth2 to the AzureAD integration:  https://<vmware vsphere portal fqdn>/ui/login/oauth2/authcode

 

 

Create a new secret and record it.  You’ll need this for the “ADFS” configuration of vSphere as the "Shared Secret" in Step 6 Configure vCenter Server Identity Provider Federation for (Azure)AD FS

 

Add the group claim using the AD Domain FQDN\group's samaccountname

 

 

 

Grant the integration the ability for authenticating users to read the AzureAD.

 

 

 

Per the VMWare Instructions for Configuring ADFS Configure vCenter Server Identity Provider Federation for (Azure)AD FS

• An AD FS root CA certificate added to the Trusted Root Certificates Store (also called the VMware Certificate Store).

Add the CA Root for login.microsoft.com

 

 

DigiCert CA

https://www.digicert.com/kb/digicert-root-certificates.htm

The remainder of the instructions are the same for AzureAD Federation Services, as they are for Microsoft AD FS (Step 6, and on).

 

Issues:

 

To Vmware:  PowerCLI appears to still be using the AD Auth Library.  To ensure the best security, MFA and Conditional Access, VMware should move to Modern Auth.  In lieu of Modern Auth (the preferred option), PowerCLI should not accept requests on TCP 443.  Rather advertise it on a separate port that can be firewalled.  A bastion host could then be used to gain access to this port.  

To VMWare Admins, make sure tcp 443 for vSphere is only accessible over VPN, preferably specific to vmware admins and vm guest admins, or to bastion hosts

[omifreak]

Hi  

thank you for this good documentation.
Two things are still unclear to me or surprise me:

The https://login.microsoftonline.com/13**********************/v2.0/.well-known/openid-configuration is not working for me. If I use this I get the error: ADSTS901002: The 'resource' request parameter is not supported. I need to change it to https://login.microsoftonline.com/13**********************/.well-known/openid-configuration to use the V1.0 endpoint.

What are you doing with the URL https://login.microsoftonline.com/13*********************/oauth2/authorize on the VMware site? I have only the possibility to add the open-id endpoint address.

 

[leejohnc]

Correct the oidc v1 endpoint url goes in vmware (below:  Step 6, part c, third bullet under c).  Also I am assuming that your hybrid AzureAD identities have the same UPN on-prem and in the cloud, or that if ADConnect is configured to use an alternate UPN, you can make the alternate UPN and On-prem UPN match.

 

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.authentication.doc/GUID-C5E998B2-1148-46DC-990E-A5DB71F93351.html

6.  Create an identity provider on vCenter Server.

a.Return to the Identity Provider tab in the vSphere Client.

b. Click the "Change identity provider" link.

The Configure Main Identity Provider wizard opens.

c. Select Microsoft ADFS and click Next.

Enter the information that you have gathered previously for the following text boxes:

• Client Identifier
• Shared Secret
• OpenID Address of the AD FS server

[omifreak]

Hi  

thank you for the confirmation. 
I was just confused because you marked the Azure OAuth 2.0 authorization endpoint (v1) URL as important in you description as well. 

[MRHOUSZ]

Did you encounter issues with how the group claim from Azure is named? When looking at the response from Azure, the claim for groups is named 'Groups'. When using ADFS, the documentation has you name the claim 'Group' without the 's'. I can get SSO working with ADFS but not with Azure and as far as I can tell the name of the groups claim is why its not working with Azure. The response from Azure AD has the groups but vCenter ignores them, resulting in an error of "Unable to login because you do not have permission on any vCenter Server systems connected to this client." You can also see the constructed JWT with empty groups by tailing the /var/log/vmware/sso/tokenservice.log when logging in. The groups are empty when configured to use Azure AD, and are properly parsed when using ADFS. 

[omifreak]

Hi , yes this is true. You need to change the name of the claim to group (without "s") in the Azure AD App registration. You can do this directly in the manifest of the application:

 

	"oauth2RequirePostResponse": false,
	"optionalClaims": {
		"idToken": [
			{
				"name": "group",
				"source": null,
				"essential": false,
				"additionalProperties": [
					"dns_domain_and_sam_account_name",
					"emit_as_roles"
				]
			}
		],
		"accessToken": [
			{
				"name": "group",
				"source": null,
				"essential": false,
				"additionalProperties": [
					"dns_domain_and_sam_account_name",
					"emit_as_roles"
				]
			}
		],
		"saml2Token": [
			{
				"name": "group",
				"source": null,
				"essential": false,
				"additionalProperties": [
					"dns_domain_and_sam_account_name",
					"emit_as_roles"
				]
			}
		]
	},