Been trying to AD-join a newly deployed VCSA 8.02.0100 and not having much luck (see more here )
root@vcenter [ ~ ]# /opt/likewise/bin/domainjoin-cli join mydomain.com first.last
Joining to AD Domain: mydomain.com
With Computer DNS Name: vcenter.mydomain.com
first.last@MYDOMAIN.COM's password:
Error: ERROR_GEN_FAILURE [code 0x0000001f]
Stumbled upon a very weird issue that may explain it:
root@vcenter [ ~ ]# nslookup badname.mydomain.com
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find badname.mydomain.com: NXDOMAIN
... however pingng the same address (or any hostname for that matter, whether valid or not) gives me this:
root@vcenter [ ~ ]# ping badname.mydomain.com
PING badname.mydomain.com (208.91.***.***) 56(84) bytes of data.
^C64 bytes from 208.91.***.***: icmp_seq=1 ttl=238 time=84.4 ms
--- badname.mydomain.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 84.399/84.399/84.399/0.000 ms
Where is this IP coming from? I don't see this behavior on any of our devices, whether AD-joined or not.
Why does it even ping it if "server can't find" it in nslookup?
Our production VCSA 7.03 with identical DNS config - no such behavior.
Googling that IP:
208.91.***.*** was found in our database!
ISP Network Solutions LLC
Usage Type Data Center/Web Hosting/Transit
Domain Name networksolutions.com
Country Virgin Islands (British)
City Road Town, Virgin Islands, British
Nothing in our DNS setup points to that IP, far as I could tell...
Questions:
Thanks!
Set VCSA IP to static (same value as it was on DHCP) - and it worked - joined the domain.
The behavior is reproducible in our environment - i.e. if I deploy a fresh VCSA from scratch with a DHCP-provided IP and manually set DNS servers - it will be doing the same thing - at least in our environment.
Looks like a VMware bug, although there is a (small) chance it's something with our environment - although yet again, I've not seen this behavior in a gazillion of other scenarios, from freshly deployed ESXi 7 to Ubuntu 22.04 to non-VMware appliances (Dell OME), to a variety of Windows flavors - whether AD-joined or not.
Given I was able to successfully join the domain on a VCSA that was originally set up using an IP as the hostname
P.S. This may also mean VMware docs (Join or Leave an Active Directory Domain) could use a refresh:
The above snippet seems to indicate that a VCSA originally set up with an IP (as its hostname) cannot join a domain, period - which in my case wasn't true.
This is not a VMware issue. This issue may occur when port 445 is blocked on an external firewall or other device in the path from the vCenter to the Domain Controllers.
https://kb.vmware.com/s/article/77531
Set VCSA IP to static (same value as it was on DHCP) - and it worked - joined the domain.
The behavior is reproducible in our environment - i.e. if I deploy a fresh VCSA from scratch with a DHCP-provided IP and manually set DNS servers - it will be doing the same thing - at least in our environment.
Looks like a VMware bug, although there is a (small) chance it's something with our environment - although yet again, I've not seen this behavior in a gazillion of other scenarios, from freshly deployed ESXi 7 to Ubuntu 22.04 to non-VMware appliances (Dell OME), to a variety of Windows flavors - whether AD-joined or not.
Given I was able to successfully join the domain on a VCSA that was originally set up using an IP as the hostname
P.S. This may also mean VMware docs (Join or Leave an Active Directory Domain) could use a refresh:
The above snippet seems to indicate that a VCSA originally set up with an IP (as its hostname) cannot join a domain, period - which in my case wasn't true.
This is not a VMware issue. This issue may occur when port 445 is blocked on an external firewall or other device in the path from the vCenter to the Domain Controllers.https://kb.vmware.com/s/article/77531
Not the case. The article does not apply.
root@vcenter [ ~ ]# openssl s_client -connect dc01.mydomain.com:445
CONNECTED(00000003)
P.S. Whether or not it's a VMware issue, it only happens with a VCSA appliance. (Not with ESXis configured the same way, not with any other of hundreds of devices and appliances we have.)