DefinIT

Installing .NET core, PowerShell and PowerCLI on macOS Sierra

powerclicore140x140So, this is something I’ve been waiting to write up for a while! PowerShell for macOS has been available for a while now, but what a lot of PowerCLI fans have been waiting for is to be able to use PowerCLI direct from their Mac.

Today, amidst all of the noise from VMWorld, PowerCLI Core dropped as a Fling! That means that although it’s not ready for production use yet, it is ready to start testing – and I’m way more excited than I should be!

At the moment it’s a limited subset of PowerCLI functionality (as PowerShell Core is a limited subset of PowerShell), but both PowerShell and PowerCLI are actively adding functionality at a really good rate – and VMware Flings have a pretty decent track record for being released as production (H5 client, Migrate2VCSA, VSAN HCL, Embedded Host Client – it goes on!) (more…)

Configuring a vRO/vCAC PowerShell host with Basic Authentication

vCenter Orchestrator (vCO)To add a Windows Server 2012 R2 PowerShell host using Basic Authentication only, follow these steps.

Ensure that the Windows Firewall service is running (it doesn’t matter if the firewall is enabled or disabled, it should always be running! That’s a general rule, not just for this).

On the PowerShell host open a command prompt (*NOT* PowerShell console) as administrator and run the quickconfig command – you can re-run it if it’s already been run – but make sure it has.

winrm quickconfig

Enable basic authentication:

winrm set winrm/config/service/auth @{Basic="true"}

image

(more…)

Configuring vCenter Orchestrator (vCO) with PowerShell over HTTPS with Kerberos Authentication

vCenter Orchestrator (vCO)As a PowerShell fan I find using the vCO PowerShell plugin makes my life a whole lot easier. What isn’t easy however, is  the configuration of vCO and a PowerShell jump host. Having done it a few times, this is my method for ensuring a secure working connection using HTTPS and Kerberos.

Configure the Orchestrator Appliance

Since we’re planning on using Kerberos authentication, we’d better ensure that the time is correct AND syncs to the same source as the domain.

image

In order to configure Kerberos on the Orchestrator appliance you need to SSH in to the box and log in using your root credentials.

Create a new krb5.conf file under /usr/java/jre-vmware/lib/security/ using the following command:

vi /usr/java/jre-vmware/lib/security/krb5.conf

Enter the following, substituting your domain details, and the local domain controller for “kdc =”. Case is important here, so use caps where I have:

[libdefaults] 
        default_realm = DEFINIT.LOCAL 
[realms] 
        DEFINIT.LOCAL = { 
                kdc = dc-01.definit.local 
                default_domain = definit.local 
        } 
[domain_realms] 
        .definit.local=DEFINIT.LOCAL 
        definit.local=DEFINIT.LOCAL 
[logging] 
        kdc = FILE:/var/log/krb5/krb5kdc.log 
        admin_server = FILE:/var/log/krb5/kadmind.log 
        default = SYSLOG:NOTICE:DAEMON

If the krb5.conf file did not exist, change the permissions to allow the system to read the file:

chmod 644 /usr/java/jre-vmware/lib/security/krb5.conf

Configure the PowerShell host

I’m configuring to use HTTPS with Kerberos authentication, so the first thing I need is a certificate with the Server Authentication (1.3.6.1.5.5.7.3.1) key usage. If you’re running a Microsoft PKI, the default Computer certificate template is perfect for this.

Open MMC and add the Certificates snap in for the Computer account, find your certificate and double-click to open. Select the Details tab and scroll to the bottom – copy the thumbprint value to use in the below command.

image

Enable WinRM with the following command:

winrm quickconfig

Increase the amount of memory allowed to be allocated to each executing PowerShell:

winrm set winrm/config/winrs @{MaxMemoryPerShellMB="2048"}

Create an HTTPS listener using the thumbprint and the following command:

winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="host_name";CertificateThumbprint="certificate_thumbprint"}

 

 

image

Finally, enable Kerberos authentication:

winrm set winrm/config/service/auth @{Kerberos="true"}

The PowerShell host is now listening on port HTTPS 5986 authenticated by Kerberos!

Test the WinRM connection

Using another computer on the same domain, run the following command to execute NSLookup on the PowerShell host:

winrs –r:https://mgmt-01.definit.local:5986 nslookup google.com

image

Adding a PowerShell host

The final step is to add a PowerShell host to Orchestrator. Open (or install first and then open) the Orchestrator client and connect to your vCO appliance. Make sure you’re connecting using your domain account (i.e. you need to pass your domain identity to the vCO appliance to use for authentication to the PowerShell host).

Specify a name for the PowerShell host (the hostname of the server is fine), the FQDN (best to use FQDN with Kerberos) and the port that we created the listener on – 5986 by default.

image

Select WinRM as the host type, HTTPS and do not accept all certificates, finally select Kerberos authentication.

image

Select “Session per user” to configure the remote host to use the workflow user’s identity. You can enter credentials for a shared session, but this could pose security risks if running as an elevated user.

image

Finish the wizard and wait until the workflow completes:

image

Now we have a PowerShell host added to vCO, we can run a PowerShell script against it over HTTPS and authenticated with Kerberos.

Running a Hello World PowerShell script in vCO

Firstly, lets create “Say-HelloWorld.ps1” script and save it in c:\SCRIPTS on the PowerShell host.

return “Hello World”

Next switch back to the Orchestrator client and select “Design” mode. Create a new folder to contain your workflows (mine is called “DefinIT”) and then create a new workflow (“Test-PowerShell-Hello-World”).

Select the “Workflow” tab and then expand “All Workflows” > Library > PowerShell, then drag the “Invoke an external script” onto the workflow editor:

image

Click on the “Setup” button:

image

Select the value radio button for the “host” binding and then click to select the PowerShell host from the inventory. Select value for the “externalScript” binding and enter the path to the hello world script we created earlier. Select script for the arguments, as we don’t have any. Leave the output binding as is.

image

Now we can run the workflow and select the “Logs” tab to see the output – you can see the “Hello World” that we returned is echoed in the logs.

image

Hopefully this has been a helpful kick-starter into using vCO PowerShell over HTTPS with Kerberos Authentication

vCenter 5.5 Certificate Toolkit for Distributed Environments

SSL PadlockIf you’ve had the dubious pleasure of generating and installing vCenter certificates, you’ll know that it’s not the greatest of fun. When VMware released the SSL Certificate Automation Tool, it helped hugely, especially when you use Derek Seaman’s excellent SSL toolkit. I know that there are hours and hours of work put into this script by Derek and I want to thank him for that – it’s a massive time saver. This modification is to fit a different set of circumstances – “standing on the shoulders of giants” – and should in no way be seen as me criticising or stealing Derek’s work.

This week, while using the SSL Certificate Automation Tool and Derek’s script, I encountered a couple of things I felt could be improved for a more complex environment.

  1. The script is not written to handle distributed setups – e.g. different vSphere components on different servers.
  2. The script will handle root and a single subordinate CA, but not a third level – this requires some manual fudging.
  3. The script still creates Java Keystore .jks files, .pfx and .p12 files and properties and ID files for the SSO – these are all no longer required for vSphere 5.5 with the SSL Certificate Automation tool.

Distributed Setups

I’ve modified the script to use an array of PSObjects for $WServices rather than listing the service names. This means I can provide an FQDN for each service as a property: these are used throughout the script to generate certificate requests for each service with the correct FQDN.

The function CreateCSR now uses the FQDN property of the $WServices array – and I have added a DNS lookup to add the IP address to the CSR automatically as an IP and DNS subjectAltName. Each generated CSR is specific to the FQDN provided at the start of the script.

Multiple Subordinate CAs

The environments I am working on have a fairly standard Microsoft Certificate Services PKI setup: at the top there’s a Root CA, under that there’s a Policy CA, and under that there are Issuing CAs.

I have modified the script to use an array variable $CAs, which contains a list of CA FQDNs. The function DownloadRoot cycles through those and attempts to download each CA’s certificate in turn. The certificates and saved as “CA64-x.cer”, where x is the number of the CA in order.

For example, the Root CA is first in the $CAs array, and is downloaded first. The file is saved as CA64-1.cer. The next CA in the list is my Policy CA, which is saved as CA64-2.cer. Finally, the Issuing CA is saved as CA64-3.cer.

The naming and ordering of the CAs and their certs is important because it’s important to get the chain correct in the .pem files used in the SSL Certificate Automation tool.

As with Derek’s original script, if you’re not able to access the CAs from the vCenter Server (or wherever you’re running the script) then you need to manually download the files and create the CA64-x.cer files and place them in the $Cert_Dir folder – they will be detected and used by the script.

Generating only required files

The only files required by the SSL Certificate Automation Tool are a .pem file containing the entire chain and a .key file containing the private key for the issued certificate.

To generate the .pem file, we need to copy the contents of the CA certificates from root to leaf, starting with the leaf certificate, then the issuing CA, any intermediate CA and finally the root CA. The image below shows the order the certificates need to be pasted into the file.

PEM Certificate Format

I’ve modified the CreatePEMFiles function to generate “RootChain.pem”, which is a concatenation of the root certificates in the correct order. It then cycles through the Services and copies the contents of the generated certificate file and “RootChain.pem” to create the .pem file required by the SSL Certificate Automation Tool.

I’ve removed the additional steps for the Java KeyStore (.jks) files, which were required for SSO 5.1 but aren’t actually needed for 5.5. Similarly, steps to create the .pfx and .p12 files are removed as they are no longer required.

Functionality I’ve removed

There are certain functions I’ve removed when it made no sense to keep them, for example generating certificates for the Linux appliance. This makes no sense as by definition they’ll be on the same server/FQDN.

The function VCFQDN has been removed since the FQDN of services is provided in the $WServices array.

The function DownloadSub has been removed since the DownloadRoot function has been modified to download all the CA certificates, including the Subordinate CAs.

The function WinVCCheck has been removed, this checked for the SSO install path and set up an alias to the keytool.exe installed there. These were used in functions that are no longer required.

The function CAHashes, which created the <hash>.0 files of the root certificates has been removed – again these are no longer required in 5.5.

The function CreateSSOFiles has also been removed, since the SSL Certificate Automation tool no longer requires these files to be manually generated.

Running the script

The script runs in the same way as Derek’s original – albeit with a few options removed. You need to edit the script before your first run to populate the details of your environment.

If you can’t access all the CA’s in your environment (e.g. offline root, or firewalled) then you will need to download your CA certificates as base64 encoded certs. Start at the top-most level – the root CA – and export it as CA64-1.cer. The next one should be CA64-2.cer and so on.

Other than that, the script runs as Derek’s. When it’s run, you will have a folder with the certificates in .pem format, and the matching private keys in a .key format. Copy the ssl-environment.bat in to replace the one in the folder for the SSL Certificate Automation Tool and run the tool to update your environment.

image

Download the script

The modified script is available to download here: http://vexpert.me/ToolkitDistributed

VCP5 – vSphere 5 Configuration Maximums Quiz in PowerShell

I’ve been learning my vSphere 5 config maximums before my upcoming VCP5 exam, so in a supreme effort of procrastination I thought I’d write a PowerShell quiz script: here it is!

Save the QuizMe.ps1 file into a folder and then place one or more text file in the same folder containing a comma delimited set of questions and answers. Then run QuizMe.ps1!

(more…)

Powershell – Generate Microsoft CA signed SSL certificates with vSphere 5.1

vmware logoThe process of requesting certificates for vSphere 5.1 is a fairly grim, manual process. It’s repetitive and easy to make a mistake on any step of the way. Since I’ve got to do this for quite a few VirtualCenter Servers, I thought I’d script the certificate generation if nothing else. I am following the excellent documentation provided in Implementing CA signed SSL certificates with vSphere 5.1 and more specifically in Creating certificate requests and certificates for vCenter Server 5.1 components.

The script assumes that:

  1. You have a working Certificate Authority
  2. You are in an Active Directory domain environment
  3. You have the relevant permissions to modify Certificate Templates, Request and Issue certificates.
  4. You have installed OpenSSL v1.0.1c or later.

You will need to modify the configuration section to suit your environment and the $WorkingDir folder should exist before you run the script. (more…)

SCOM 2007 R2: Daily Health Check Script v2

MSFT-System-Center-logoA couple of months ago I posted the first version of my SCOM 2007 R2 Daily Health Check Script – here is version 2. It’s more than a little motivated by some friendly competition with a Microsoft PFE for SCOM, hopefully you’ll agree it’s a big improvement on the last version.

Updated for this version

  • Formatting changed to make it more readable and more compatible
  • Added “Report generated on <server>” to the top of the report
  • Management Server states reported as one section
  • Default MP check moved to beneath the Management servers
  • Agents in pending states moved to be with the Agent health states
  • Clarified “Unresponsive Agents” and “Agents reporting errors”
  • Management server alerts streamlined
  • Added top 10 alerts for the last 7 days, and added top alerters for each

(more…)

PowerShell: Recursively taking ownership of files and folders and adding permissions without removing existing permissions

PowerShell LogoThis is every file server admin’s nightmare: hundreds of shares, thousands of folders, hundreds of thousands of files – and custom or not inherited rights on many of them. Terabytes of data that need auditing – e.g. to find customer data, or credit card information. How do you go about accessing all the data in all the trees? What about backups failing because someone removed the System account? Of course you can seize control of the folder by taking ownership and pushing down from a top level – but how do you preserve the existing Access Control Lists? (more…)

SCOM 2007 R2: Daily Health Check Script

An updated version of this script has been released: https://www.definit.co.uk/2012/05/scom-2007-r2-daily-health-check-script-v2/

MSFT-System-Center-logoI’ve been working with a Microsft SCOM PFE (Premier Field Engineer) for the last few months and part of the engagement is an environment health check for the SCOM setup. Based on this Microsoft recommend a series of health checks to for the environment that should be carried out every day. This is summarised as the following:

  1. Check the health of all Management Servers and Gateways
  2. Check the RMS is not in maintenance mode
  3. Review Outstanding Alerts
  4. Review Agent’s Health Status
  5. Review Backup Status
  6. Review any Management Group Alerts
  7. Review the Pending Management status
  8. Review Database Sizes (Operations, Data warehouse, ACS)
  9. Review Volume of Alerts
  10. Review Alert Latency
  11. Document any changes 

(more…)

Sponsors