Intro
Trying to log in to ESXi and vCenter 5.1, getting error 'Authorize Exception'. These are the troubleshooting steps taken to resolve.There was a specific cause tied to a scenario and there are solution steps taken to remedy.
Troubleshooting
Luckily there is a KB article that shows up when you search for the error text on a search engine. We'll start with that as a guide
VMware advises to check these 3 things
- SSO identity source not configured correctly
- vCenter Server disconnected from Active Directory
- DNS resolution
In order of difficulty, start from the bottom.
3. DNS resolution
To verify that the DNS is working, on the vCenter window server, do one or all of these- check the ipconfig/all from the command line and verify the DNS servers listed are correct
- open cmd, type nslookup, and try to resolve the hostname and FQDN of your vCenter server
2. vCenter Server AD connectivity
To verify, RDP to vCenter and open the user groups in Windows Server, then review the Administrators group.
If you are seeing the Security IDs instead of DOMAIN\USER, the AD connectivity is lost and you may have to rejoin the AD.
The KB article above has some more details before you just re-add blindly.
1. SSO identity source
Here's the guide on how to configure the SSO
To verify this configuration we are going to go backwards
- Navigate to vCenter web Client
- https://vcenter.corp.potato.com:9443/vsphere-client/
- login using the following
- username: admin@System-Domain
- password: set up during vCenter installation. If you used Simple install, the password may be blank (?)
- Go to Administration -> Sign-On and Discovery, Configuration
- under Identity Sources, click on the ldaps entry and then the little pencil icon to edit it.
- Verify your settings and check the Primary server URL first
- Note the button 'Choose Certificate' does not show up until you type something in any box
- You can test the connection but the fail message is non-descript here.
Check Certificate
There are different ways about this, but you want to verify the machine certificate of the 'Primary server URL'. This is needed for secure LDAP to work.
- RDP to the windows machine (dynamics.corp.potato.com). Start -> run -> mmc -> add remove snap-in -> Certificates -> Add -> Computer account -> Local -> finish
- Expand Certificates -> Personal -> Certificates
- find the matching cert and verify
- Valid from: check this date is correct!
- Issued to: dynamics.corp.potato.com
- Issued by: your AD cert authority
- Intent: "Proves your identity to a remote computer" AND "Ensures the identity of a remote computer"
- Certificate Template Name : "DomainController"
- Enhanced Key Usage: "Client Authentication (1.3.6.1.5.5.7.3.2)" AND "Server Authentication (1.3.6.1.5.5.7.3.1)"
Check LDAPS is working
- connect to any domain controller that works and go start -> run -> ldp
- Connection -> connect -> enter the FQDN of the 'primary server' (dynamics.corp.potato.com)
- use port 636 and check 'SSL'
- if it's failing you will get an error that you can look up, hopefully. In this case it was
0x0 = ldap_unbind(ld);
ld = ldap_sslinit("dynamics", 389, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 81 = ldap_connect(hLdap, NULL);
Server error: <empty>
Error <0x51>: Fail to connect to dynamics.
ld = ldap_sslinit("dynamics", 6389, 1);
Error 81 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 81 = ldap_connect(hLdap, NULL);
Server error: <empty>
Error <0x51>: Fail to connect to dynamics.
- If it's successful you will get something like this
ld = ldap_sslinit("dynamics", 636, 1);
Error 0 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 0 = ldap_connect(hLdap, NULL);
Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
Host supports SSL, SSL cipher strength = 128 bits
Established connection to dynamics.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
configurationNamingContext: CN=Configuration,DC=corp,DC=potato,DC=com;
[many lines]
.......
Cause
In this case, the following scenario happened:- A domain controller was removed from the forest.
- This DC by chance was also the Cert Authority.
- The replacement DC was not made a CA
- There was no CA on the domain, and all the existing machine issued certs were valid for a year
- After a year has passed since the [automatic] issuing of the certs, the LDAPS ceased to function since the certs were past their expiry date.
- The clue was that during the cert check of 'dynamics' the machine cert was showing as expired and LDP tool was failing to connect as well
Solution
Issue new cert to the 'Primary server' (dynamics)
- A Cert Authority was installed in the domain forest. 'New CA' was added since old private keys were lost
- CA automatically propagated on the domain and issued new machine certs to all the existing DCs and signed with the new CA as 'issued by'.
- Reboot of the 'dynamics' server was performed here.
- at this point verified LDAPS with LDP tool connecting to 'dynamics' successfully
Export the cert from 'Primary server' (dynamics)
- Connect to the 'Primary server' (dynamics)
- Start -> run -> mmc -> add remove snap-in -> Certificates -> Add -> Computer account -> Local -> finish
- Expand Certificates -> Personal -> Certificates
- Find the matching cert by the FQDN -> properties
- Details tab -> Copy to File -> Next -> No, do not export the private key -> Base-64 encoded X.509 (.CER)
- Save this file to a common location
Import the new cert to vCenter server
This next bit may not be the formal way to fix, but it worked since all the config in place was valid and only the cert was needed
- Navigate to vCenter web Client as instructed above
- https://vcenter.corp.potato.com:9443/vsphere-client/
- .... like above and refer to the picture....
- Add any text in either 'Primary' or 'Secondary server URL' and undo it. This will cause the button 'Choose Certificate' to appear, but keep all the existing values as they were.
- Click the 'Choose Certificate' and navigate to the .CER file you exported above
- The successful message is 'Certificate added' / 'The selected certificate has been successfully added to the vCenter Single Sign On keystore.'
- You can test the connection now as well,
- since we're logged in as admin@System-Domain change to 'Password'
- use any domain user/pw that is authorized
- 'The connection has been established successfully.'
- Click OK to save
Logging in to vCenter using the vSphere client worked at this point without any more reboots.
