Invalid user (ssmcadmin) or password error when logging into SSMC TUI (3.8.0.0)

[Paolo_c]

After building SSMC 3.8.0 appliance and configuring network i am trying to login to the SSMC GUI https:\\10.xx.xx.xx:8443 under the ssmcadmin user/pass (which I used for initial configuration) but receiving the error message attached/below "Invalid user (ssmcadmin) or password" . According to the documentation , from SSMC version 3.6 ssmcadmin login also functions as the Administrator account for adding and remove your 3PAR arrays to SSMC so should be able to use this account without defining a separate Administrator login ? Also when i initially connect to SSMC 3.8 via the web-browser (http://<ssmc-IP>:8443 ...) I was not prompted to define name and password of the "Administrator login" so wondering why it wont allow me to login under the existing ssmcadmin account (Incidentially I have checked that the user/password i am entering is correct as still able to login to web/remote console under ssmcadmin from the SSMC VM. 

[Cali]

Hi Paolo,

the ssmcadmin User is the Administrator Console User of SSMC. This User is only used if you enable the Checkbox "Administrator Console" by Login. It has nothing to do with any Storage Login (3paradm) and is only used for and Inside this VM.

You can define the Password during the SSMC VM Setup, if you do this, the Password must be set by using the Rules (see down), or leave the Password Filed empty and it is asked by the First Login.

>>>>>>>>>>>>>>>>>>>>>

SSMC appliance does not perform password validation when deployed through VMware vCenter. If you specify a
password, such a password must be compliant to the password policy requirements. If you are unsure but intend
to be compliant, then leave the password field blank in the vCenter GUI. So the password defaults to ssmcadmin
and you will be asked to reset the password as per password policy, the next time your login to the console.
• The password must contain at least one uppercase letter, one lowercase letter, one digit, one special character,
and the length of the password must be minimum of eight characters. The special characters are the
nonalphanumeric characters. For example, ~, `,! , @, #, $, %, ^, &, *, (,), _, +, -, =, [, {,], }, \, |,; , :, ', ", <, >, /, and,? .

<<<<<<<<<<<<<<<<<<<<<<<<

Cali

[Paolo_c]

Thanks.  However when i originally logged into the SSMC appliance, I changed the ssmcadmin password to meet the standards required below, so my question is why is the same username/password not being accepted when i attempt to login to the tui https:\\10.xx.xx.xx:8443 (with the "Administrator Console" checkbox enabled) ?? I have already spoken to our Server/network and they cant see any connectivity issues/restrictions + the error message "Invalid user (ssmcadmin) or password". suggests the problem is local to the appliance ? I really need to get beyond this error as currently preventing me from importing 3par connections and enablling certificates etc and seem to be going around in circles with this issue. 

• The password must contain at least one uppercase letter, one lowercase letter, one digit, one special character,
  and the length of the password must be minimum of eight characters. The special characters are the
  nonalphanumeric characters. For example, ~, `,! , @, #, $, %, ^, &, *, (,), _, +, -, =, [, {,], }, \, |,; , :, ', ", <, >, /, and,? .

[Paolo_c]

Just thought I would offer the following update. I changed the ssmcadmin password this morning and tested logging to localhost on web console okay. I then connected to the TUI , and attempted to log to Administrator Console (with checkbox enabled), but after a few seconds received the same invalid user (ssmcadmin) or password error. Im not sure if the following is related to this issue but if i try and launch the remote console from the SSMC VM appliance i get a connection error could not negotiate ssl (see attachment) error displayed but assuming thats related to not being able to logon to Administrator Remote Console and enable/manage certificates ? 

[Cali]

Please check, if ESX Hypervisor and ESX compatibility setting that appears in the Compatible with drop-down menu is 6.0 or higher.

Change the Default Virtual Machine Compatibility Setting (vmware.com)

Also, see this Note in the Administrator Guide:
IMPORTANT:
The self-signed certificates are accepted in Internet Explorer but not in Google Chrome browser.

If this is both OK, I'm out.

Cali

[Paolo_c]

The self-signed certificates are accepted in Internet Explorer but not in Google Chrome browse

Thank you for the feedback. With regards to your 2nd point above , are you referring to the CA trusted certificates (attached) as seeing these certficate errors reported, whether trying to login under Edge, Google Chrome and IE ? If i try installing these tickets the issue persists. 

[Paolo_c]

Please check, if ESX Hypervisor and ESX compatibility setting that appears in the Compatible with drop-down menu is 6.0 or higher.

Change the Default Virtual Machine Compatibility Setting (vmware.com)

With regards to checking compatability above. Although the VM is self managed it sits inside an ESXi environemnt which is managed by a third party so have asked them to check the config and to see whether its related to the SSL/username issue. 

[Paolo_c]

The 3rd party supporting the vCloud were unable to provide me with an answer to the question you originally raised below ...

"Please check, if ESX Hypervisor and ESX compatibility setting that appears in the Compatile with drop-down menu is 6.0 or higher."

but instead responded with the following...

1. Try connecting to some other VMs using VMRC, windows and linux. We believe that if conditions are met it should work.
2. Verify the TLS settings on client as well as on target server side, TLS 1.2 is default, TLS 1.0 and 1.1 should not be enabled but different versions of software and network policies give a room to play with settings.
3. Please let me know in advance when you can test the connection again, we will check on firewall side for eventual blocked traffic – older VMRC versions work with port tcp902, newer version (11 and above) it’s tcp443. If you are not available, could you share the password for ssmcadmin with either me or one of the Intel members in cc and we can test it ourselves.
4. And we would also suggest to check the SSL certificate settings on target server to make sure they are valid and working.

Im not sure how many of their questions above are relevant to this particular issue but with regards to item 4 above. In order to verify the SSL settings on the VM appliance i ran the following curl command from another VM . The output appears to suggest an issue with the SSL certs on the SSMC vm applicance ? 

$ curl -v https://10.xx.xx.xx:8443
* About to connect() to 10.xx.xx.xx port 8443 (#0)
* Trying 10.xx.xx.xx...
* Connected to 10.xx.xx.xx (10.xx.xx.xx) port 8443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* Server certificate:
* subject: CN=ssmc
* start date: Apr 06 09:27:50 2022 GMT
* expire date: Apr 03 09:27:50 2032 GMT
* common name: ssmc
* issuer: CN=ssmc
* NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)
* Peer's certificate issuer has been marked as not trusted by the user.
* Closing connection 0
curl: (60) Peer's certificate issuer has been marked as not trusted by the user.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

[Paolo_c]

The 3rd party have confirmed this morning that they could not identify anything traffic associated with connection to TUI https:\\10.xx.xx.xx:88443 being blocked on their firewall, so based on test carried out yesterday (Peer's certificate issuer has been marked as not trusted by the user), below, to check the SSL settings on Target Server, issue does appear to be related to the SSL certs on target Server. If so then would be grateful on any advice on how to resolve them (which presumably would involve copying CA root certificates (associated with certificate error shown in failed connection to TUI window - see screenshot attached )  to the SSMC Server ? 

$ curl -v https://10.xx.xx.xx:8443
* About to connect() to 10.xx.xx.xx port 8443 (#0)
* Trying 10.xx.xx.xx...
* Connected to 10.xx.xx.xx (10.xx.xx.xx) port 8443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* Server certificate:
* subject: CN=ssmc
* start date: Apr 06 09:27:50 2022 GMT
* expire date: Apr 03 09:27:50 2032 GMT
* common name: ssmc
* issuer: CN=ssmc
* NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)
* Peer's certificate issuer has been marked as not trusted by the user.
* Closing connection 0
curl: (60) Peer's certificate issuer has been marked as not trusted by the user.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

[Paolo_c · Accepted solution]

I am now faced with an additional issue , which i suspect,  could well be related to the original problem i continue to experience in trying to login to the GUI under Administrator Console. SInce building the appliance and changing the default SSMCADMIN password I've remained logged into the appliance via the VMware web console. However after logging out of the web console last week I'm now unable to log back in (even though the password remains unchanged).

When i try entering the username characters appear upper/lowercase/upper/lowercase etc  (as per screenshot). I am eventually able to the enter ssmcadmin in lowercase but note that when entering the password some of the characters entered in lowercase appear uppercase (and vice versa). Although the username and password i enter via the Browser GUI does display the correct case in the browser connection window, I'm wondering whether the case entered is being translated correctly on the appliance which would explain why im now unable to login via web console or Gui (i was never able to login via putty due to access denied error) so now faced with having to rebuild appliance in order to faciliate any form of access via ssmcadmin username !

[Paolo_c]

Turns out the issue was due to VMware console/browser issue. 

After rebuilding the appliance for the 3rd time last week i asked a colleague to change the ssmcadmin default password and then to try logging out and back into the appliance (which they were able to do). However when i attempted to login from my laptop i got the same invalid password error again as before (which I could see was because caps lock was still not functioning correctly for me) .  I also tried connecting to VMware console from a 2nd laptop (via citrix) with the same result !. However , because my colleague had managed to change the password correctly (without any upcase/lowercase) issues I was able to access the console via putty (which up until then id been unable to do). I was also able to login to the gui https://10.xxx.xxx.xx:8443 , connect to the 3PAR's, accept certificates and can now access all the new features under the original 3par username/password that i setup under the old (now disabled) 3.3.1 SSMC console