Setup Remoting on non domain joined machines

Not so unique situation here. Have a jump box (Client) in the DMZ with a VPN client installed from which I want administer machines on a domain and some standalone servers using PSRemoting

The first stumbling block I came across was the Public Connection my VPN tunnel was stuck on. Command below was the easiest way to set to Private

Get-NetAdapter -Name “Ethernet 2” | Get-NetConnectionProfile

The server you intend on connecting to needs to have a certificate installed, it can be from your own internal CA which is what I did. The powershell way:

PS Cert:\LocalMachine\My> $enrollresult = ( Get-Certificate -Template Machine -Url ldap:///cn=CAName -DnsName CAServer.FQDN -CertStoreLocation Cert:\LocalMachine\My )

To enable PSRemoting you need to run

Enable-PSRemoting

You can append the -Force option, it does bypass you answering all the questions you are going to probably say yes to anyway. Personally I only used it when automating the setup.

to test you can use the Test-WSMan cmdlet

Test-WSMan -ComputerName Server01.FQDN # Without SSL 
Test-WSMan -ComputerName Server01.FQDN -UseSSL # With SSL 

At this point you have PSRemoting working over an HTTP connection, as the above test will show, using the default port (5985). To enable SSL you run

winrm quickconfig -transport:https
New-NetFirewallRule -DisplayName “PSRemoting” -Direction Inbound -LocalPort 5986 -Protocol TCP -Action Allow

The New-NetFirewallRule seems to be needed on my DMZ machines that are not Domain Joined. May or may not be an anomaly, needs more testing. The firewall rule seems to be needed in all cases. I am not changing the rule to allow clear text from locations other than the Local IP Subnet, and may actually block that at a later stage. You can of course do this via GPO for domain joined machines.

On the client end you will need to add the non Domain Joined servers to the Allowed hosts

winrm s winrm/config/client ‘@{TrustedHosts=”ServerFQDN“}’

I had to do it for a bunch of servers so I did it with a quick bit of PS, you can add as many servers into $computers as you need, I ended up with 83.

$computers = “Server01.FQDN“,”Server02.FQDN“,”Server03.FQDN“,”Server04.FQDN
foreach ( $computer in $computers ) { winrm s winrm/config/client ‘@{TrustedHosts=”$computer”}’ }

If your client is domain joined you won’t need this, but I am on a different domain to the servers.

From here you should be able to connect using

New-PSSession -ComputerName Server01.FQDN -Credential (Get-Credential) -UseSSL

As I am unable to connect to the CA I have to add -SessionOption (New-PSSessionOption -SkipRevocationCheck ) to skip CRL validation.

I put together a nasty little function to simplify connections and to stop ending up with mutiple sessions on a server

Updates
2016-07-21

Added powershell method for certificate enrollment
Changed firewall requirement

Your Powershell $profile

Something us Windows admins neglect is our Powershell $profile. In the *nix world .bashrc (or whatever shell you use) is something that a user / admin tinkers with a fair amount.

I have been tinkering with my $profile for awhile now, adding and removing things. I am a long way from being finished but I think that is probably normal. I am embedding a github copy of my profile below

 

Quickly convert from VMDK to VHD

You will need two tools for this, a decent unzipping tool like 7Zip if you have the OVA and Microsoft Virtual Machine Converter

If you downloaded an OVA file decompress this with 7Zip

7z.exe e D:\temp\ucspe.ova -oD:\Temp\UCSPE

After this you should have at least three files

filename.mf
filename.ovf
filename.vmdk

Some OVA’s will contain multiple VMDK’s.

One you have these files open and admin powershell prompt

Import-Module ‘C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1’

ConvertTo-MvmcVirtualHardDisk -Verbose -SourceLiteralPath D:\temp\UCSPE_2.5.2a\UCSPE_2.5.2a-disk1.vmdk -DestinationLiteralPath D:\Path\To\HyperV\ -VhdType Dyna
micHardDisk -VhdFormat Vhdx

Once you have the disks create the VM as you normally would in HyperV and attach the converted disk, code snippet I use is below

$vmGeneration = “1” #Gen 2 for UEFI
$vmName = “Test”
$vmMemory = “2GB”
$vmDiskPath = D:\HyperV\Disks\UCSPE\UCSPE_2.5.2a-disk1.vhdx”
$switchName = “Ethernet”
New-VM -Name $vmName -VHDPath $vmDiskPath -MemoryStartupBytes $vmMemory -SwitchName $switchName -Generation $vmGeneration
Add-VMNetworkAdapter -VMName $vmName -SwitchName $switchName
Add-VMNetworkAdapter -VMName $vmName -SwitchName $switchName

LetsEncrypt working with OpenVPN data-share

I have a fairly specific use case, and this is too help those that may need to automate renewals if you have

  • OpenVPN on tcp/443, with port-share enabled
  • NGINX as your webserver

First to configure port-share on OpenVPN add the following to your server.conf

port 443
port-share 127.0.0.1 8443

On your NGINX CONF your port config should look like

listen 8443;

Basically you are now using built-in detection of OpenVPN to detect SSLVPN or HTTPS traffic coming in on port 443/tcp, and if it detects HTTPS traffic forwards it on to your NGINX daemon on port tcp/8443

To get you certificates to renew when you are using NGINX is a bit of a pain, especially if you are using port-share but it is doable with a small amount of downtime. I use a script by Acetylator from the LetsEncrypt community forums. How-to: completely automating certificate renewals on Debian

At the top I added

service openvpn stop

and at the bottom

service openvpn stop

There is probably a more elegant way to do this, but I am not a *nix guy .

For the script to work correctly you need a copy of cli.ini in your /etc/letsencrypt folder. Mine looks like below:

# This is an example of the kind of things you can do in a configuration file.
# All flags used by the client can be configured here. Run Let’s Encrypt with
# “–help” to learn more about the available options.
# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096
# Uncomment and update to register with the specified e-mail address
email = email@domain.tld
# Uncomment and update to generate certificates for the specified
# domains.
domains = www.domain.tld domain.tld
# Uncomment to use a text interface instead of ncurses
text = True
# Uncomment to use the standalone authenticator on port 443
# authenticator = standalone
# standalone-supported-challenges = tls-sni-01
# Uncomment to use the webroot authenticator. Replace webroot-path with the
# path to the public_html / webroot folder being served by your web server.
# authenticator = webroot
# webroot-path = /usr/share/nginx/html

I have a cron job that runs once a week calling this script and so far with 1 renewal that has happened it all worked as expected, such a rare occurrence.

Diagnosing a vlan issue on Cisco UCS pre 2.2

New VLAN not attaching to vnic

Added a new vlan to a service profile template and even though it shows in the UCSM UI there was no traffic traversing the vlan.

First you need to know what the vnic id is:

ssh admin@fc01.fqdn

Work out which service profile you are looking at and set your scope to it’s adapter

fc01-A# show service-profile assoc|grep SRV
SOperations/HyperVisors/HyperV01
SOperations/HyperVisors/HyperV02
fc01-A# scope org SOperations/HyperVisors/
fc01-A /org # scope service-profile HyperV01

Get the MAC addresses for your vethernet adapters

fc01-A /org/service-profile # show vnic

vNIC:
Name       Fabric ID Dynamic MAC Addr
———- ——— —————-
eth0       A B       00:25:B5:04:02:6F
eth1       B A       00:25:B5:04:01:4F
fc01-A /org/service-profile # exit
fc01-A /org # exit

Connect to NXOS

fc01-A# connect nxos

Get the Veth adapter id, grep for your vlan id while doing a show vlan

fc01-A(nxos)# show vlan |grep 1196
1196 VLAN1196                         active    Po1, Veth1484, Veth1490
fc01-A(nxos)# show vlan |grep 1197
1196 VLAN1197                         active    Po1, Veth1484
fc01-A(nxos)# show interface vethernet 1484 |grep server
Description: server 1/2, VNIC eth0
fc01-A(nxos)# show interface vethernet 1490 |grep server
Description: server 3/2, VNIC eth0

This will allow you to confirm using show  assoc that the both your servers have the vlan id

fc01-A# show server assoc |grep 1/2
1/2     Associated   HyperV01
fc01-A# show server assoc |grep 3/2
3/2     Associated   HyperV02

 

As you can see the seconds vlan id (1197) was missing from HyperV02. This is a known bug and luckily these hypervisors are clustered so we can re-ack them. Rebooting will not fix the problem, so you will need to re-acknowledge them in the UCSM server’s interface.

image

image

Download Windows PowerShell 4.0 and Other Quick Reference Guides from Official Microsoft Download Center

Some useful cheat sheets thanks to Microsoft

Quickly learn tips, shortcuts, and common operations in Windows Powershell 4.0, Windows PowerShell Desired State Configuration, Windows PowerShell Workflow, Windows PowerShell ISE, Windows PowerShell Web Access, Server Manager for Windows Server 2012 R2, WinRM, WMI, and WS-Man

via Download Windows PowerShell 4.0 and Other Quick Reference Guides from Official Microsoft Download Center.

Getting ADFS 3.0 with WAP to actually work in my environment

Setting this up has been “fun”. For whatever reason we have been having all sorts of weird errors. Hope something here helps someone else out there.

Basically the design is as such: ADFS Design Connecting to the ADFS servers from the internal networking worked as expected using the https://sts.contoso/adfs/ls/idpinitiatedsignon URL.

First we where getting certificate issues when accessing https://sts.contoso/adfs/ls/idpinitiatedsignon from a machine with a hacked together hosts files pointing to either of the two proxies. On this TechNet Post I noticed a mention by someone asking if the certificates on the WAP and ADFS server where verified and that the certificate paths where okay. We found that the path was not complete we and exported the certificate again from a working source and imported again. That problem cleared.

While we had been waiting for the F5’s to be configured we setup the proxies with DNS pointing to only one of the ADFS servers (ADFS-01), and everything was working. Once the F5’s where done DNS was changed to the F5 IP which is when we started having the proxy connections break. After inspecting the logs we noticed that we where getting trust failures with the self-signed certificates that get created when you join the WAP to the ADFS servers. Reconfiguring the proxies did not help. After approaching the F5 admin we realised that the F5’s are configured by default to MiM the SSL connections. Once the internal F5 cluster was reconfigured to pass the certificate on that problem disappeared.

Currently working at getting the access from inet.0 to the proxies configured via our external F5’s, will update post with information there. This seems to be an issue with SNI and the F5’s. I found two possible fixes, F5 Dev Central has a write up on ADFS SNI and F5’s. Another possible is to run
netsh http add sslcert ipport=IPAddress:443 certhash=certificatethumbprint certstorename=MY sslctlstorename=AdfsTrustedDevices appid={5d89a20c-beab-4389-9447-324788eb944a}
on each of the proxies. We have tested this and it worked, but it is not exactly elegant. One of the good examples of documentation being important.

Something I have noticed that is really annoying and is going to be a maintenance nightmare is the fact that the proxy trust certificates expire after 20 days but now there are 30 odd device certificates in the ADFSTrustedDevices store. Apparently there is a hot fix on the way.

Useful Tips:

  • How to reconfigure the ADFS WAP
    Change the registry key at HKLMSoftwareMicrosoftADFSproxyConfigurationStatus from 2 to 1, and then run ramgmtui.exe, clicking on Web Application Proxy
  • Use
    https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml and
    https://sts.contoso.com/adfs/ls/idpinitiatedsignon
    to test ADFS
  • To test if your SSL Certificate is binding correctly netsh http show sslcert
    Hostname:port : adfs.contoso.com:443
    Certificate Hash : bdaa3368d535b0612055ee8b0494423829f585cf
    Application ID : {5d89a20c-beab-4389-9447-324788eb944a} <- this is the ADFS SSL Owner GUID so we know this mapping was created by ADFS
    Certificate Store Name : MY
    Verify Client Certificate Revocation : Enabled
    Verify Revocation Using Cached Client Certificate Only : Disabled
    Usage Check : Enabled
    Revocation Freshness Time : 0
    URL Retrieval Timeout : 0
    Ctl Identifier : (null)
    Ctl Store Name : AdfsTrustedDevices <- this is the important part to watch out for
    DS Mapper Usage : Disabled
    Negotiate Client Certificate : Disabled

 


References:


Shout out to Gavin van Niekerk from Microsoft SA

Tips for being a less annoyed Windows admin

Some things I have picked up to make being a Windows Admin less annoying

A few ways to open a command prompt as Administrator:

  1. Press the Meta Key, type cmd then press CTRL+SHIFT+ENTER together
  2. Under HKEY_CURRENT_USERSoftwareMicrosoftCommand Processor in your registry create a String (REG_SZ) Autorun with a value of cd /d “%userprofile%”
  3. You can also copy cmd.exe under System32 and rename it as cmda.exe and change the Privilege Level as per screenie, ugly but it works.
    image

All of the above assume you have not (unable to??) changed UAC to it’s lowest level. Personally I couldn’t be bothered and run with my UAC on it’s highest level on everything but my gaming PC which is one level below that.