OTKA as IDP failing

[anothervsphereu]

Has anyone successfully configured OKTA as an IDP in vCenter 8u2?  After walking through the documentation, it fails with the following error

Could not create indirect identity provider: Failed to create identity provider with IDP name Okta for tenant customer

We have deleted everything on the OKTA side 3 times and recreated it...it fails consistently with that error.

Does anyone know where the logs for this are stored on the VCSA?

 

[mschmitt-nasuni]

Were you able to figure this out? I'm in the same situation with the same error. 

I think it's because the vCenter doesn't trust the certificate that the Okta endpoint is using, but I can't import the DigiCert Root CA to get it to trust the Okta endpoint.

[anothervsphereu]

Yes, we figured it out. Our issue was the following:

The vmware documentation says the OpenID Address should be this: https://example.okta.com/oauth2/default/.well-known/openid-configuration

In our case, it needed to be this https://example.okta.com/.well-known/openid-configuration

We had to open a case with OKTA support to figure that out.  Once we had that, the configuration completed successfully.   We are still having some goofy issues with the SCIM app and how it provisions users, still working through those.

[mschmitt-nasuni]

THANK YOU! That new URL got me over the hump and I was able to get the integration working after a bit more troubleshooting. (had to get a trusted certificate on the vcenter and expose it to Okta's servers as well). 

I've got the user/group provisioning working in my environment as well. I had to strip out special characters from the display name field, but those were the only errors I was seeing during SCIM push.

Thanks again for the tip- I'm off and running now. Appreciate it!

[anothervsphereu]

Glad i could help.  Out of curiosity, how did you expose your vCenter to OTKA?  We tried doing a NAT and that didnt work. Ultimately, we used Azure Application Proxy.

[mschmitt-nasuni]

We did a NAT (with a security policy). I didn't want to expose the vcenter to the entire web, so I only allowed traffic from Okta's US pool of IPs.

Palo Alto has some really useful hosted dynamic lists that I used to target just Okta's US pool:

https://docs.paloaltonetworks.com/resources/edl-hosting-service

[Casey]

Sadly, this can be tricky and probablly will require reading some logs. You can do it yourself or submit a ticket to have an Agent help out. The logs you want to scan through at least are going to be: 

/var/log/vmware/sso/*
/var/log/vmware/sso/sts.log - This log file contains information related to the Security Token Service (STS) and might provide insights into the issues with the IDP configuration.
/var/log/vmware/sso/vmware-identity-sts.log - This log file can also contain relevant information about the identity provider configuration.
/var/log/vmware/sso/idm.log - The Identity Manager log file may contain relevant information about the IDP configuration and errors.

/var/log/vmware/vmdird/*
/var/log/vmware/vmdird/vmdird.log - This log file records directory service-related events, which might be useful if the issue is related to the directory services used by SSO.

/var/log/vmware/lookupsvc/* - These logs can help you understand if there are issues with the lookup service used by the vCenter Server for identity management.

You can use commands such as: 
tail -f sts.log - To view the most recent entries. 
cat sts.log -or- less sts.log - To view the log files

Look for any error messages or warnings that could provide more details about why the IDP creation is failing. Feel free to post them here, or if your company doesn't want their public info, you can scrub the logs or create a support ticket. 

------------------------------
Love for Virtual Infrastructure!

VCP-DCV 8.x | VCP-DCV 6.x | CompTIA A+, Net+, Sec+, Proj+ | MCSE | MCSA | MCITP |
------------------------------