vSphere 6
2 SSO services installed on Windows Machines
Not load balanced.
PSC/VCSA 6 pointed at one of the above SSO servers.
I've tried repointing the VCSA at the other SSO server (replication is working fine) and restarting vcsa services
Could log back in as the above, but still not with the newly created user.
Answers on a postcard!
Ok so after digging in the vmware-sts-idmd.log on our SSO server I found the cause.
A brand new user was flagging as "User password expired".
Obviously complete rubbish. So a quick search then threw up this KB
Which identifies the root cause as an invalid value in the "expiration lifetime" setting.
So silly me for setting that right?
Nope, not guilty. The default of lots of 99999999s was set to whatever it was in vSphere SSO 5.5
Recently I upgraded to vSphere 6 (SSO, VC, ESXi)
Obviously the new limit of 1 or two less 99999s wasn't automatically applied.
Fortunately it doesn't lock out already created accounts or my administrator@vsphere.local account would have been useless.
Oh and it's a great fix. Fix the setting and then delete the account and re-create it!
Poor show.
Hi NealeC,
Hm, that's strange.
Normally i get this Issue if i not configure the User with an proper Role. minimum Read-only.
could you double check if Role is in Place for this User?. just as an Test use an easy Password also > i remember i had Issues with some Special Characters on vSphere6.
Best regards
Max
Hi Max,
Yes I've used the same password as the existing Administrator user that can log in ok
I tried a super simple password but it didn't meet the complexity.
I've also tried granting them User role or Administrator role
but neither let it in and it's not an access denied
nor logging me in but showing no resources/vcenters
it calls out the incorrect username/password
Ok so after digging in the vmware-sts-idmd.log on our SSO server I found the cause.
A brand new user was flagging as "User password expired".
Obviously complete rubbish. So a quick search then threw up this KB
Which identifies the root cause as an invalid value in the "expiration lifetime" setting.
So silly me for setting that right?
Nope, not guilty. The default of lots of 99999999s was set to whatever it was in vSphere SSO 5.5
Recently I upgraded to vSphere 6 (SSO, VC, ESXi)
Obviously the new limit of 1 or two less 99999s wasn't automatically applied.
Fortunately it doesn't lock out already created accounts or my administrator@vsphere.local account would have been useless.
Oh and it's a great fix. Fix the setting and then delete the account and re-create it!
Poor show.
Hi NealeC,
wow. bad Bug ;(. GZ for finding that out. Also funny since 6.0: if getting request from a customer to reset password. rofl. now there is a "Current Password" Field which highlighted as mandatory once trying to do reset. Had also to recreate user with new password. mass pain if permissions complicated. lucky requests very very rare.
personally i don't like the SSO Database overally. it's not really good implemented. i don't understand as they changed SSO from DB to inhouse Solution going away from External DB while ago.that is such painfully once during re/installations etc,.... > as the local SSO Database will getting deleted. So there was a Thread how to cover that on 5.x. but for 6.x is again differently for backup/restore. So therefore i switched away from SSO DB for new users. i use now local Authentication. Going to an Inhouse Solution was nice > but just where better to use the SQL etc,... instead of storing some Files somewhere where the dependency is not fully known.
Still missing a kind of "Export/Import" Function of Users/Groups > and i don't understand why Vmware not covering it. should be a simple Step which saves ages for Customers. that Data should be reliable available - but it isnt. Often simple Stuff not available - and complicated ones on mass.
Hope they switch back in Future to SQl or other Solution for storing DB.
Best regards
Max