vCenter Server Virtual Appliance and Native Active Directory, back to the basics...
I had a rather interesting issue w/ my vCenter Server Appliance (vCSA). I had it natively joined to my Active Directory domain so I could use it as a native identity source in SSO. I was running into a rather curious issue where I would add a user to the SSO Administrators group, everything would appear to happen correctly, but the table showing group membership would be blank.
Searching for users in any domain would work fine. Just not the membership table (Group Members).
Line to capture LDAP port packets from within vCenter appliance (389 for LDAP, 636 for LDAPS):
tcpdump port 389 -v -w /tmp/pktcapturefile.log
or
tcpdump port 636 -v -w /tmp/pktcapturefile.log
LDAPS packet capture is somewhat not useful because the packets are encrypted. The best you can really tell is whether packets are communicating to whom.
Come to found out, after working w/ VMware, looking @ a packet trace, it so happened that the user search dialog was querying a domain controller that had DNS PTR records.
On the other hand, the table showing group memberships would query a domain controller that did not have a PTR record. After a little investigation, it appeared that we had several domain controllers (part of the parent domain) had PTR records, but because there was a reverse lookup domain space in the child domain that matched the IP address pattern, the reverse lookup would fail.
Seems like a workaround was put into place, but never cleaned up after the fact causing this wonderful conundrum. Regardless, this was a wonderful reminder to always check the most basic of things first, then move onto the more complicated stuff. The unfortunate aspect of this was the fact I had Windows vCenter servers running 5.5 and not having this issue. Just luck of the draw I suppose...
Searching for users in any domain would work fine. Just not the membership table (Group Members).
Line to capture LDAP port packets from within vCenter appliance (389 for LDAP, 636 for LDAPS):
tcpdump port 389 -v -w /tmp/pktcapturefile.log
or
tcpdump port 636 -v -w /tmp/pktcapturefile.log
LDAPS packet capture is somewhat not useful because the packets are encrypted. The best you can really tell is whether packets are communicating to whom.
Come to found out, after working w/ VMware, looking @ a packet trace, it so happened that the user search dialog was querying a domain controller that had DNS PTR records.
On the other hand, the table showing group memberships would query a domain controller that did not have a PTR record. After a little investigation, it appeared that we had several domain controllers (part of the parent domain) had PTR records, but because there was a reverse lookup domain space in the child domain that matched the IP address pattern, the reverse lookup would fail.
Seems like a workaround was put into place, but never cleaned up after the fact causing this wonderful conundrum. Regardless, this was a wonderful reminder to always check the most basic of things first, then move onto the more complicated stuff. The unfortunate aspect of this was the fact I had Windows vCenter servers running 5.5 and not having this issue. Just luck of the draw I suppose...
Comments