I have upgrade VCSA to 6.5 Update 1 (from 6.5)
After this I can't login using AD credentials. administrator@vsphare.local is still working
Logs say:
Invalid credentials
exception 'com.vmware.identity.idm.IDMLoginException: Native platform error [code: 851968]
Network packects at port 389 are going. And i can add permissions at objects: vcenter sees users from AD.
"Identify Source" for domain is configured with "use machine account".
When i try to using SPN, I need type SPN as STS/domain.local, but i have error: SPN can't be found
Now i have configured AD as LDAP service, but it is not good way.
Does anyone know something about this problem ?
Can you check if the vCSA has joined the Domain from CLI.
/opt/likewise/bin/domainjoin-cli query
and if it is already joined the domain, then try the below steps in order to correct the behavior
In disjoint domain namespace the domain users might fail to authenticate after you update to vSphere 6.5 Update 1
After you update a Platform Services Controller Appliance to vSphere 6.5 Update 1, in the disjoint domain namespace the users might fail to authenticate.
1. Log in to the Platform Services Controller Appliance as root and activate the bash shell.
2. Leave the domain by running the /opt/likewise/bin/domainjoin-cli leave
command.
3. Reboot the appliance.
4. Delete the computer account on the Active Directory.
5. Log in to the appliance again and enable the bash shell.
6. Join to the domain by running the following command /opt/likewise/bin/domainjoin-cli join domain-name domain_admin_user
for example: /opt/likewise/bin/domainjoin-cli join vmware.com administrator
7. Reboot the appliance.
Release notes link: VMware vCenter Server 6.5 Update 1 Release Notes
Make sure you have configured nameservers in /etc/resolv.conf of VCSA.
Checked. It is ok.
and krb5.conf too.
VCSA FQDN is resolving successfully ?
Check if it works for you Creating an SPN for use with VCSA 6 – cloud, virtualization and sddc blog
I have created SPN. Checked that it exists.
But I can't use it.
I input SPN, username and password, but i received in gui: "No principal name found".
In logs:
vmware-sts-idmd.log: probeAdConnectivity failed for user@domain
ssoAdminServer.log: ERROR com.vmware.identity.admin.server.ims.impl.DomainManagementImpl] Invalid crendential? principalName: [user@domain], details: [probeAdConnectivity failed for user@domain]
The specified principal (user@domain) is invalid.
com.vmware.vim.sso.admin.exception.InvalidPrincipalException: The specified principal (user@domain) is invalid.
But with the same user and password i can configure AD as LDAP.
Any ideas ?
Can you check if the vCSA has joined the Domain from CLI.
/opt/likewise/bin/domainjoin-cli query
and if it is already joined the domain, then try the below steps in order to correct the behavior
In disjoint domain namespace the domain users might fail to authenticate after you update to vSphere 6.5 Update 1
After you update a Platform Services Controller Appliance to vSphere 6.5 Update 1, in the disjoint domain namespace the users might fail to authenticate.
1. Log in to the Platform Services Controller Appliance as root and activate the bash shell.
2. Leave the domain by running the /opt/likewise/bin/domainjoin-cli leave
command.
3. Reboot the appliance.
4. Delete the computer account on the Active Directory.
5. Log in to the appliance again and enable the bash shell.
6. Join to the domain by running the following command /opt/likewise/bin/domainjoin-cli join domain-name domain_admin_user
for example: /opt/likewise/bin/domainjoin-cli join vmware.com administrator
7. Reboot the appliance.
Release notes link: VMware vCenter Server 6.5 Update 1 Release Notes
Thank You.
After correct /etc/hostname by hand ("/opt/likewise/bin/domainjoin-cli sethostname" got error) and join by hand, I got oportunity to add Windows authentication mechanism.
It is the same for me.
After a reboot I noticed that the hostname has been set back to "localhost.localdom".
I used the command
/opt/likewise/bin/domainjoin-cli join domain-name domain_admin_user
to change it back and didn't reboot after that.
Immediately after changing the name the AD authentication worked again.
This has to be a bug not yet resolved ... pretty bad that you have to search for hours for something that hasn't been a problem in the past.
The reason could also be the domain functional level, see compatibility matrix below