Cheng's Random Thoughts on System Management : Security

SCVMM 2008 R2 downloadable docs are available now!

Cheng Wei — Thu, 01 Oct 2009 03:24:00 GMT

Greetings, folks!

I'm pleased to let you all know that our documentation team has just published the doanloadable version of SCVMM 2008 R2 documents at here: http://go.microsoft.com/fwlink/?LinkId=162764

Available documents for download are:

· Deployment Guide

· Guide to Operations Manager Integration

· Security Guide

· Operations Guide

· Scripting Guide

· Cmdlet Reference

· Building PRO-Enabled Management Packs

Go check them out today, download them onto your favorite device, print them out or just read them wherever / however you want.

Feedback on these? Please send it to: scvmfdbk@microsoft.com.

Cheers!

Cheng

VMM Security content is posted on Technet.

Cheng Wei — Fri, 06 Mar 2009 04:59:00 GMT

Greeting folks!

Hot off press – Our content team has worked hard to produce a set of documents around how to secure your VMM 2008 environment, which includes interesting topics:

· Basics of VMM security

· Hardening VMM components (from VMM Server to the VM hosts, from your DB server to your library server)

· Security around PRO (OpsMgr integration)

· We even offer you the security guidance on how to configure a more secure VMware environment by using VMM

This set of documents offer both security guidelines as well as some best practices in tightening up the security in your VMM environment. Some of the documents extend their ways into explaining how VMM works “under the hood”, so that the readers understand what and why they should decide to implement. I hope you’ll find it as useful, refreshing and informative as I did.

It’s available for download here:

http://technet.microsoft.com/en-us/library/cc764247.aspx

Enjoy your reading!

Cheng

When should I consider running my VMM Service by using a domain account?

Cheng Wei — Fri, 20 Feb 2009 05:19:00 GMT

Greetings folks!

Hope you all had a good Valentine weekend last week!

If you noticed, during your VMM Server installation, there is an option of allowing you to select a different account to run VMM Server service (VMMService) from the default computer account.

“When should I consider using this non-default option?”, you may ask.

You may have other reasons / policies to run VMMService by using a domain account. However, based on some of our recent CSS reports, choosing your own domain account to run VMMService should be a preferred option for customers who are running a more restrictive AD environment. Here is why:

· With default install option, VMMService is run under the VMM Server local system / computer account.

· When adding trusted domain-joined VM hosts (whose domain has two-way trusts with the domain VMM Server is in), VMM Server adds its computer account (the account it uses to run VMMService) into the local administrator group of the target VM hosts, as part of the Add-VMHost process.

· In a more restrictive AD environment, we find it common for customers to have a “Restricted Groups” group policy that disallows machine accounts to be part of the local administrators group. Hence, when the GP is in effect, the machine account will be removed by this GP.

· And when this happens, the affected VM Hosts will show up in VMM console as “Needs Attention” (and the agent status will be “Not Responding”), since the VMM Server will no longer be able to authenticate with the hosts. Here is error message that you will see from the failed host refresher job (BTW, we’ll be updating this error message in our vNext):

Error (2927)

A Hardware Management error has occurred trying to contact server servername.domainname.com.

(Unknown error (0x80338104))

Recommended Action

Check that WinRM is installed and running on server servername.domainname.com. For more information use the command "winrm helpmsg hresult".

When users get into this situation, there are a few options they can do to fix this issue:

1. Check with your IT security group and see if it’s possible to disable the “Restricted Groups” group policy in your Active Directory environment; or

2. Check with your IT security group and see if it’s possible to modify the group policy to allow the VMM machine account in the Local Administrators group; or

3. Check to see if it’s possible to move the VMM Server machine account to its own organizational unit (OU) and block the group policy from being applied to that OU; or

4. If making changes to your group policy (or negotiating with your IT security group J) is next-to-impossible, the only option left is to reinstall the VMM server and choose the option to run the VMM service by using a domain account with admin privilege on your VMM Server computer (in this case, you will need to remove and re-add all your VM hosts, or choose to reinstall your VMM Server without retaining data).

Hence, I highly recommend users to evaluate your IT security (AD) policies before deploying your VMM server into production environment, as those factors do directly affect how VMM performs operations within that environment. And, if you do have a more restrictive AD environment, I suggest you to use a domain account to run VMM Server service. Also, if you have a disjoint namespace environment, it's also recommended to use a domain account to run your VMM Server service.

Before I close on this subject, there is one restriction that I think folks should be aware when using a domain account to run your VMM Server service:

· Users cannot use the same domain user account to add or remove hosts.

o Say, you configured VMM Server to use account “foo\bar” to run VMM Server service.

o And it also happens to be part of the local admin group for a host “MyNewHost” that you want to add to VMM.

o When we go through AddHost wizard (or through our cmdlet), you will be asked about a credential with admin privilege for us to install agent.

o At this point, it’s disallowed to use the same user account “foo\bar” to add the host. And yes, we actually block you from doing such operation.

o The same is true for host removal, it’s disallowed to use the same account “foo\bar” to remove the host.

· Why do we not allow this?

o During host addition, we add the service account to the local admin group on the host. When removing the host, we need to remove the account from the local admin group.

§ If we remove the account first, we won't be able to talk to the agent.

§ If we remove the agent first, we leave the account behind.

§ Thus, users need to use a different account for host removal.

o During host addition, we add the service account to the local admin group on the host.

§ In case of failure during the agent install process as part of the AddHost task, we need to be able to roll back and successfully remove the agent.

§ To do that, we need the same requirement.

· So, the proper process is that if you use “foo\bar” to run your VMM Server service, you will need to use a different account with admin privilege to add or remove your host.

Hope this helps and thanks for reading!

Thanks,

Cheng

Hyper-V Security Guide – beta now available

Cheng Wei — Fri, 13 Feb 2009 22:15:00 GMT

The Hyper-V Security Guide can help you elevate the security of virtualized Windows Server environments to meet your business-critical needs. This accelerator provides IT professionals like you with recommendations to address your key security concerns around server virtualization. The guide provides authoritative guidance that relates to the following strategies for securing virtualized environments:

· Hardening Hyper-V. The guide provides prescriptive guidance for hardening the Hyper-V server role, including several best practices for installing and configuring Hyper-V with a focus on security. These best practices include measures for reducing the attack surface of Hyper-V as well as recommendations for properly configuring secure virtual networks and storage devices on a Hyper-V host server.

· Delegating Virtual machine management . The ability to safely and securely delegate administrative access to virtual machine resources within an organization is essential. The guide highlights several available methods to administer different aspects of a virtual machine infrastructure and ways to control administrative access to different servers and at different levels.

· Protecting virtual machines. The guide also provides prescriptive guidance for securing virtual machine resources, including best practices and detailed steps for protecting virtual machines by using a combination of file system permissions, encryption, and auditing.

The Beta release is available now for your review through March 4, 2009. After joining the Beta review program [live ID required], bookmark this link to the program site to get the latest information about project details.

Thanks for reading!

Cheng

SCVMM and Network Ports We Use for Communication

Cheng Wei — Mon, 30 Jun 2008 23:29:00 GMT

More than often, deploying SCVMM server and managing VM hosts require coordination with your network admins. One of the frequently asked questions is "What ports should I ask my network guy to open for me in order to allow SCVMM server to talk to the hosts?". For a tightly controlled enterprise data center, this question will come up for sure. By default, everything is blocked. Ports are only open (or exempted) per request and with good justifications.

Other times when a host failed to be added or the host agent goes into a "Not Responding" state, if you cannot afford to turn off the firewall, you might be scratching your head to try figuring out what port needs to be open and what needs not.

So, to make our SCVMM admin's job easier, here is the list of TCP/IP ports SCVMM needs to talk to various system components:

VMM Server exceptions needed:

80 (HTTP, WS-MAN)
443 (HTTPS, BITS)
8100 (WCF Connections to PowerShell or Admin Console)

SQL Server

1433 (Remote SQL instance connection)
1434 (SQL browser service) - only needed for initial setup

Host / Library

80 (HTTP, WS-MAN)
443 (HTTPS, BITS)
3389 (RDP)
2179 (VMConnect on Hyper-V hosts for single-class console view)
5900 (VMRC on Virtual Server hosts)

VMware VirtualCenter server

443 (HTTPS for calling VI Web Services APIs)

VMware ESX hosts

443 (HTTPS for calling VI Web Services APIs)
22 (SSH for SFTP files to/from ESX hosts) - this is only used for ESX host version 3.0 and 3.5 (not needed for 3.5i)

Hope this helps.

Thanks for reading,

Cheng