VMware Cloud Community
DroboDeveloper
Contributor
Contributor

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

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:

DroboDeveloper_1-1623073740181.png

 

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.

Labels (1)
Reply
0 Kudos
22 Replies
potato49
Contributor
Contributor

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.

Reply
0 Kudos
DroboDeveloper
Contributor
Contributor

Thank you so much, buddy. Very much appreciated.

Reply
0 Kudos
AlexHarb
Contributor
Contributor

I have the same issue in  7.0.2.00200

Reply
0 Kudos
potato49
Contributor
Contributor

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-
Contributor
Contributor

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?

Reply
0 Kudos
Lalegre
Virtuoso
Virtuoso

Hey @Oliver-,

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.

 

Reply
0 Kudos
Oliver-
Contributor
Contributor

 
Reply
0 Kudos
Oliver-
Contributor
Contributor

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

Reply
0 Kudos
Lalegre
Virtuoso
Virtuoso

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.

Reply
0 Kudos
Oliver-
Contributor
Contributor

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

QQ图片20210727164124.png

2. Generate dependent certificates through local ad CS certificate service

3. The certificate template is "subordinate certification authority"

Snipaste_2021-07-27_17-35-32.png

4. Code Base64

Snipaste_2021-07-27_17-35-58.png

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

Reply
0 Kudos
dgrove12
Contributor
Contributor

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.

Reply
0 Kudos
leejohnc
Contributor
Contributor

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

Tags (1)
Reply
0 Kudos
leejohnc
Contributor
Contributor

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

Reply
0 Kudos
lavoiealex
Contributor
Contributor

Hello @leejohnc !

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!

Reply
0 Kudos
Pixa
Contributor
Contributor

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.

Reply
0 Kudos
omifreak
Contributor
Contributor

Hello @leejohnc !

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 = FirLas00@mydomain.at,\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?

Reply
0 Kudos
leejohnc
Contributor
Contributor

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

 

image2021-11-9_13-28-49.png

image2021-11-9_13-29-21.png

image2021-11-9_13-29-46.png

 

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 

 

image2021-11-9_10-18-6.png

 

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

 

image2021-11-9_12-58-0.png

 

 

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

 

image2021-11-9_12-53-15.png

 

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

 

image2021-11-9_12-54-5.png

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

 

image2021-11-9_12-55-42.png

 

image2021-11-9_13-5-30.png

 

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

 

leejohnc_0-1652298558529.png

 

 

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

 

image2021-11-9_13-1-51.png

 

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.  

VMware_vSphere_OpenID_Connect_Config_for_AzureAD_-_Technology_Services_-_Confluence.png

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

Reply
0 Kudos
omifreak
Contributor
Contributor

Hi @leejohnc 

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.

 

Reply
0 Kudos
leejohnc
Contributor
Contributor

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-11...

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
Reply
0 Kudos