Deploying a secondary PSC + VCSA appliances joinning existing SSO domain

[VincentGuy]

Hello everyone,

We are trying to deploy an external Platform Service Controller + VCenter on a secondary site joining an existing SSO domain.

However, on the existing domain the password policy has been set to not require a special character, the administrator account does not have one, and when we get to stage 2 of the deployment scenario, configuring the newly deployed PSC, we cannot proceed as the password policy is enforced with a special character.

We have tried the GUI and CLI install with same result.

We are trying to deploy a PSC + VCSA on v6.5.0 U1c

We have an existing PSC + VCSA on v6.5.0 U1c and SSO domain with an admin password that does not have a special character.

Has anyone encountered this issue? Is there a way to force the use of our existing password?

Thanks in advance for your input.

Vincent

[HassanAlKak88]

Hello,

Based on my experience, I didn't faced this case before.

But as workaround and if possible, i suggest to change temporary the policy to accept the complexity needed and once the PSC joined, you can re-change the policy.

Please consider marking this answer "CORRECT" or "Helpful" if you think your question have been answered correctly.

Cheers,

VCIX6-NV|VCP-NV|VCP-DC|

@KakHassan

linkedin.com/in/hassanalkak

[VincentGuy]

Hello Hassan and thanks for your input,

The problem encountered is with the VCSA deployment ISO.

When I input the administrator@vspheredomain.local's password the input field is surrounded in red and nothing happens if I click next. If I add a special character to the password I get a "invalid credentials" error.

So the problem, for me, is with the installer provided in that ISO which is enforcing the default password policy, do you know if and where I can change that policy?

I have tried to look through the ISO's files but did not come up with anything so far.

Regards,

Vincent

[HassanAlKak88]

kindly correct me, as I understand your issue happened at the stage 2 during the VCSA deployment. when trying to join the new PSC to existing PSC with sso domain has a custom password policy.

[VincentGuy]

That is correct.

[HassanAlKak88]

kindly share the error received if possible.

and please share your vCenter servers versions.

[VincentGuy]

The version is:

6.5.0.12000 Build Number 7119157

This is the error reported by the cli installer:

2019-01-18 13:57:11,167 - vCSACliInstallLogger - ERROR - The entered password for new.vcsa sso password does not meet the requirements. The password must be between 8 characters and 20 characters long. It must also contain at least one uppercase and lowercase letter, one number, and one character from '!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~' and all characters must be ASCII. Space is not allowed in password.

2019-01-18 13:57:11,167 - vCSACliInstallLogger - DEBUG -         Key 'password' is invalid.

The GUI installer simply surround the password input in red and does not permit to proceed (i.e. clicking next has no effect), I could not find anything relevant in the logs.

The password used is within the requirements except for the special character.

[HassanAlKak88]

And if you please to share the policy setting from the existing PSC:

Go to https://psc_hostname_or_IP  (In an embedded deployment, the Platform Services Controller host name or IP address is the same as the vCenter Server host name or IP address)

Navigate to Single Sign-On and click configuration, click the policies tab and select Password Policies. (take a screenshot here)

[VincentGuy]

The screenshot of the current password policy.

[HassanAlKak88]

Hello again,

if you please change the policy as the below (default):

and try the rejoin please,

Please consider marking this answer "CORRECT" or "Helpful" if you think your question have been answered correctly.

Cheers,

VCIX6-NV|VCP-NV|VCP-DC|

@KakHassan

linkedin.com/in/hassanalkak

[VincentGuy]

I am reluctant to make such a change to a production environment, won't that just invalidate my current sso administrator's password?

Would that be the equivalent to change that same password so that it meets the default (enforced) password policy? And what would be the consequences of changing that password (or changing the policy)?

As far as I can tell the installation process should just verify if the password is correct not if it meets the default policy, especially in the sense that I am joining an existing sso domain which has it's own policies which may deviate from the default. Maybe it should use the currently defined policy.

I prefer to research the impact such a change might have before trying this, ideally I would bypass such check and proceed with deployment.

Thanks for your help, I'll keep looking for alternative and post back with chosen solution.

[HassanAlKak88]

Hello,

FYI and if it is possible on your site,

I deployed two embedded vCenters on my LAB, and I changed the policy in first one as your policy, and then try to join the second vCenter to first one i got your error.

I changed the policy with password on first vcenter, the join process complete properly.

Please consider marking this answer "CORRECT" or "Helpful" if you think your question have been answered correctly.

Cheers,

VCIX6-NV|VCP-NV|VCP-DC|

@KakHassan

linkedin.com/in/hassanalkak

[farkasharry]

I would do the following:

1. Make your/an AD user to SSO admin, so you have access in case of trouble

2. Change the policy

3. Do the install

In case of further doubt, you should get a confirmation from VMware support or your TAM, that the policy change is only affecting new passwords (I assume so, as only the hash is stored so no further complexity checks available on a hashed string) are not affecting your current admin password, only when you are changing it.

[VincentGuy]

HassanAlKak88​: Thanks a lot for taking the time to try this in your lab, I will certainly consider this option.

farkasharry​: This is probably a good idea, as this will at least leave a valid access just in case.

I still don't get why the installer is enforcing the default password policy and not the one that we have defined on our sso domain.

Unfortunately I will not be able to do this rapidly, I will however report back once we have done this.

Regards,

Vincent

[VincentGuy · Accepted solution]

Hello,

just to finalize this, in the end the admin's account password was changed to something matching the default password policy and the install went through without a hitch.

This does not answer the original question but changing that password has apparently less consequences than I originally thought.

Regardless, thanks you both for your input.

Vincent

[HassanAlKak88]

It's good to hear it