VMware Cloud Community
TheVMinator
Expert
Expert
Jump to solution

Best practice for active directory/ dns / hostname configuration

Scenario:

DNS servers are not integrated with active directory and all vms/esx hosts in virtual environment have hostnames on the dns comain called inside.contoso.com - such as an esx server called "esx1.inside.contoso.com" and a vm called "linuxvm1.inside.contoso.com"

We set up an active directory domain to handle authentication for vcenter server. Should that active directory domain be a subdomain of the existing dns domain - such as

"addomain.inside.contoso.com"

what is best practice in this scenario?

Also, should the vcenter server be named as a member of the domain such as "vcenter1.addomain.inside.contoso.com"

or should it be named "vcenter1.inside.contoso.com"

Currently we have a scerario where active directory domain is not a subdomain - i.e. AD domain is nwtraders.local and dns domain is "inside.contoso.com" When the vcenter server is added to the ad domain, its host name is then "vcenter1.nwtraders.local". When vmware clients from computers outside the ad domain then connect to this vcenter server, problems result from this AD/DNS/hostname design, and some features of the vmware client don't work properly as a result, unless the vmware client is running on a computer joined to the nwtraders.local domain, which is not possible for all computers.

Any feedback or thoughts appreciated - thanks

Reply
0 Kudos
1 Solution

Accepted Solutions
amvmware
Expert
Expert
Jump to solution

You have an AD domain that is being used for your vcenter server only - that is pretty secure. MS do guides on hardening server roles such as domain controllers - you may wish to consider looking at these.

With regards to which DNS to use - there is no right or wrong answer, it is which option is the best fit for your organisation, considering any technical, business, geographical or political requirements.

View solution in original post

Reply
0 Kudos
10 Replies
amvmware
Expert
Expert
Jump to solution

You DNS naming convention is entirely up to you as an organisation - the AD DNS name does not have to be contiguous with an existing DNS name space. You could call you AD domain fred.local if you wanted - but ms best practise recommends you use a registered DNS namespace where possible.

You also need to check what none MS DNS versions will work with MS - what ever MS server OS version you are deploying.

The vcenter server needs to be part of an AD domain to take advantage of the AD accounts and the ESX hosts might as well be in the same DNS namespace as there is no point in not doing it.

So add the esx host names into the same AD DNS that vCenter server is in.

I would also caution that your DNS seems overly confusing and i would look to simplify it.

habibalby
Hot Shot
Hot Shot
Jump to solution

Hello,

What is the need to join the vCenter/ESX to the Domain/AD? In my opinion there is no need to integrate your ESX/vCenter to the Domain, becuase in a vSphere/Vi3 environment you must secure your ESX Service Console as well as the vCenter as much as you can becuase these are the components handling your core infrastructure. Putting the ESX/vCenter beside your Domain Infrastructure and it's open for everyone in your Internal Network, that lead to another risk, specially if your Internal LAN accessing the internet. So, if your Internal LAN get compromised, then your ESX/ServiceConsole might be compromised as well.

What I can recommend to you in here is, hide your ESX Service Console behind an firewall on a separate vLAN that's accessible only to your Admin. And put the vCenter beside that network. Configure the vCenter to be a DNS Server as well like ESX.LOCAL, register all your Hosts IP and Name in the vCenter DNS Console. Make sure your DNS resolution is working perfectly and you are done.

Maintain a proper firewall rules between your Internal/Production LAN and the ESX Network which is the one behind this firewall. So, doing this you will be staying secure and your ESX Console is secure too.

Have your AD/Domain infrastructure hosted in the VMWare Infrastructure but not subdomain/and another subdomain, like that your creating trouble for yourself when it comes to troubleshooting.

OOOh, forget to mention, also the vMotion network put it on separate network/vLAN that's not routable to another network and make it totally in different IP Schema.

Best Regards,

Hussain Al Sayed

Revisit your posts and award points for "correct" or "helpful".

Best Regards, Hussain Al Sayed Consider awarding points for "correct" or "helpful".
Reply
0 Kudos
amvmware
Expert
Expert
Jump to solution

I think you might be missing the point.

1. DNS is about name resolution and being able to find computers by their DNS name or IP address. Adding the ESX hosts as DNS entries in the AD DNS means the servers can be located based on their DNS names.

2. If you use AD intergrated DNS it is more secure than standard DNS that relies on primary and secondary DNS servers.

3. I would ask you the question - why would you not have a vCenter server as a member server in your AD - what benefits would you get from doing that?

Reply
0 Kudos
habibalby
Hot Shot
Hot Shot
Jump to solution

I think you might be missing the point.

2. If you use AD intergrated DNS it is more secure than standard DNS that relies on primary and secondary DNS servers.

What if your AD/DNS server/VM has got a problem? and your ESX hosts are pointing to that DNS Server. You Service Console security can be enhanced by putting it behind a firewall.

3. I would ask you the question - why would you not have a vCenter server as a member server in your AD - what benefits would you get from doing that?

I don't see any benefit having your vCenter a member of a Domain Infrastructure. Maybe only one feature of vCenter that require AD Infrastructure Authentication is the vCenter Guided Consolidation to analyze domain member servers.

If the Service Console itself is hidden behind a firewall, then the vCenter must always tied with the Service Console to avoid network latency. Hiding the Service Console behind a firewall and keeping the vCenter a member of the Domain, then unnicessary ports must be opened between the Service Console and vCenter.

So, in every deployment I make I have to hide the Service Console and put the vCenter beside it and configure the DNS service on the vCenter and point the Service Console to the vCenter for name resultion. I see it it's more secure that relying on you an AD/Domain DNS infrastructure even if it's set to Accept Secure Only.

Best Regards,

Hussain Al Sayed

Revisit your posts and award points for "correct" or "helpful".

Best Regards, Hussain Al Sayed Consider awarding points for "correct" or "helpful".
amvmware
Expert
Expert
Jump to solution

My responses are based on what cusiotmers normally deploy and how they configure their environments. You obviously have an issue with security in your environment that means it is more or a priority for your company than another - nothing wrong with that - but i do not have many customers that are looking to deploy vcenters behind hardware firewalls or insisting that they will not deploy it in their AD as a member server.

Reply
0 Kudos
habibalby
Hot Shot
Hot Shot
Jump to solution

It's only a best practice security deployment. I don't an issue with my secuity, but I always like to stay secure:)

Best Regards,

Hussain Al Sayed

Revisit your posts and award points for "correct" or "helpful".

Best Regards, Hussain Al Sayed Consider awarding points for "correct" or "helpful".
Reply
0 Kudos
TheVMinator
Expert
Expert
Jump to solution

Thanks for your input. To give some more background might be helpful. In this case, there is an extremely large enterprise dns structure already in place, the naming and structure of which I have no control or influence. In addition, there is no active directory structure in place except the domain that is used for the vcenter server - so we are not integrating into an existing forest or domain structure as active directory is not used for other things like managing desktops, etc. So in this case there is not a security issue related to someone whose desktop for example is on the domain getting admin credentials on the domain then compromising the virtual environment because this AD is only used for vcenter server and whatever else we want to join to it. (Currently ESX hosts are not using AD at all) The only control/influence we have is how to deploy and name the active directory domain that we will use for the purpose of authentication and user accounts for vmware. We have control over that naming convention but not the existing dns. Also we cannot use AD integrated DNS in this scenario.

Reply
0 Kudos
amvmware
Expert
Expert
Jump to solution

You have an AD domain that is being used for your vcenter server only - that is pretty secure. MS do guides on hardening server roles such as domain controllers - you may wish to consider looking at these.

With regards to which DNS to use - there is no right or wrong answer, it is which option is the best fit for your organisation, considering any technical, business, geographical or political requirements.

Reply
0 Kudos
TheVMinator
Expert
Expert
Jump to solution

Ok thanks for input

Reply
0 Kudos
SeagleEqualSeag
Contributor
Contributor
Jump to solution

Hi. I'm in a big company and we have policies to join all Windows servers into our domain, including vCenter. And some groups must be added into local admin group. I don't kike it because every server admin of the vCenter will have full access to our ESX. But I have no choice.

For non-Windows ones, ie. ESX or Linux, we have no domain policy for them. Adding their hostname into the domain just makes the name resolution.

So I don't think it's necessary to put vCenter and ESX into seprated domains. It gives no benifit. You never really "add" an ESX into Windows domain. As I said, it's just a name resolution...

Reply
0 Kudos