IIS Express Configuration

Using appcmd to manage Visual Studio IIS Express Configuration:

"C:\Program Files (x86)\IIS Express\appcmd.exe" list site /apphostconfig:"<solution folder>\.vs\config\applicationhost.config"

"C:\Program Files (x86)\IIS Express\appcmd.exe" list config "WcfService1/" /apphostconfig:"<solution folder>\.vs\config\applicationhost.config"

"C:\Program Files (x86)\IIS Express\appcmd.exe" set config "WcfService1" /apphostconfig:"<solution folder>\.vs\config\applicationhost.config" -section:system.webServer/security/authentication/iisClientCertificateMappingAuthentication /+"manyToOneMappings.[name='Contoso Employees',enabled='True',permissionMode='Allow']" /commit:[site,apphost]

For the last example above, it may be necessary to unlock the section in the applicationhost.config file, depending on where you save the changes:

 <section name="iisClientCertificateMappingAuthentication" overrideModeDefault="Allow" />

or

"C:\Program Files (x86)\IIS Express\appcmd.exe" unlock config /apphostconfig:"<solution folder>\.vs\config\applicationhost.config" -section:system.webServer/security/authentication/iisClientCertificateMappingAuthentication

IIS Quick reference: https://blogs.msdn.microsoft.com/mikezh/2012/04/23/iis-appcmd-quick-reference/

BIG-IP Migration

In order to test upgrades to BIG-IP systems it would be useful to transfer the configuration to a virtual instance.  However, moving the configuration from a physical platform to a virtual platform seems to be consistently problematic.

I have identified a process which permits some (most/all) of the LTM services to be migrated and tested.

The certificate private keys, monitor passwords, and possibly other sensitive resources are protected with the BIG-IP key.  In order to be able to use resources from a configuration file the keys on the source and target system must match.

The virtual appliance I am using runs on Hyper-V.  Other virtualisation environments may require different changes, especially with the network.

Preparation

Prior to applying the configuration the target virtual instance should be prepared, to make it as similar to the source system:

  • Install the same release and hotfix as the source system.
  • Ensure the target system has as at least as many network adaptors as are in use on the source system (don’t forget the management port).
  • Export the master key from the source system:
    /usr/local/bin/f5mku -K
  • Import the master key to the target system:
    /usr/local/bin/f5mku -r aaaaaaaaaaaaaaaaaaaaaa==
  • Ensure the target system has limited access/no routing to production addresses.  While many things will work fine there are risks associated with high availability and replicated configurations, where the restored test system may try and partner with a production system.  In addition any outbound monitoring, logging or reporting connections could result in contaminating production systems.

Steps

  1. Save and download an archive on the source system
  2. Use gzip to expand the .ucs file to a .im file
  3. Use tar to restore the contents of the .im file
    tar -xvf configsync-2.0-1-Linux-2.6.32358.23.2.6.5.8664.im
  4. Edit the config/bigip_base.conf, making appropriate changes. See below.
  5. Use tar to create a new .im file (with an identical name), containing the original contents and the modified bigip_base.conf. I need to use sudo to read authorized keys file:
    sudo tar -cf configsync-2.0-1-Linux-2.6.32358.23.2.6.5.8664.im *
  6. Use gzip to create a new .ucs file
  7. Upload the .ucs file as an archive to the target system
  8. Restore the configuration file onto the target system using a shell:
    tmsh load sys ucs /var/local/ucs/SOURCE-MOD.ucs no-platform-check no-license
  9. Remove any partner systems, change device certificates to make the new system untrusted.
  10. Change self IP addresses and routes (this could also be done through changing the configuration file but you should consider making any changes from the previous step in the config as well).
  11. Change the addresses of virtual servers.

Changed settings

I use a static IP address for the management interface, most of the changes required relate to this. The minimal set of changes to the config in my environment are:

  • Change the management IP address ‘management-ip’ in ‘cm device’ and ‘sys management-ip’
  • Change the gateway for the management-route.
  • Disable dhcp in the ‘sys global-settings’ section (mgmt-dhcp disabled)
  • Add ‘media-fixed 10000T-FD’ to net interface.  For me this was only required on 1.1, not all enabled interfaces, I don’t understand why.

Warning

I have only managed to get LTM working.  The GTM configuration seems to be loaded and visible, but the named daemon constantly restarts.  I can’t get the restored system to respond to DNS requests.

Hyper-V firmware

Changing the Hyper-V firmware boot settings needs to be done with PowerShell. To prevent the build up of entries if a virtual machine is re-built the following command will remove UEFI file and network entries:

Get-VMFirmware -VMName "VMNAME" | % {Set-VMFirmware $_ -BootOrder ($_.BootOrder | ? {($_.BootType -Ne 'Network') -And ($_.BootType -Ne 'File')})}

Creating USB drive for Windows UEFI install

diskpart
list disk
select disk &lt;usb&gt;
clean
create partition primary
select partition 1
format fs=fat32 quick
active
assign
exit
robocopy f:\ g:\ /E /XF install.wim 
dism /Split-Image /ImageFile:f:\sources\install.wim /SWMFile:g:\sources\install.swm /FileSize:3800

See https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/split-a-windows-image–wim–file-to-span-across-multiple-dvds

Exchange issues

Problems with renewing my exchange certificate. I was getting the following error:

[PS] C:\windows\system32>Get-ExchangeCertificate
The Exchange Certificate operation has failed with an exception. The error message is: Unknown error (0xe0434f4d)
+ CategoryInfo : InvalidOperation: (:) [Get-ExchangeCertificate], LocalizedException
+ FullyQualifiedErrorId : B5063A5B,Microsoft.Exchange.Management.SystemConfigurationTasks.GetExchangeCertificate

After searching the internet there was a suggestion to start the IIS Admin service.  The service was, indeed, disabled.  Starting the service resolved the issue.

BIG IP CRYPTO Example

The big ip CRYPTO command provides an opportunity to provide secure communication between applications and the BIG IP device.

This is a simple example of using CRYPTO to communicate with OpenSSL.

Add an iRule to the big ip virtual server:

when HTTP_RESPONSE {
    set key "abed1ddc04fbb05856bca4a0ca60f21e"
    set iv "d78d86d9084eb9239694c9a733904037"
    set data "The quick brown fox"
    set enc_data [CRYPTO::encrypt -alg aes-128-cbc -keyhex $key -ivhex $iv $data]
    HTTP::header insert aes_encrypted "[b64encode $enc_data]"
}

The encrypted data can be retrieved with any utility, I use curl:

curl -D - http://site/
HTTP/1.1 200 OK
Content-Type: text/html
Date: Thu, 29 Jun 2017 13:58:01 GMT
Content-Length: 1293
aes_encrypted: cfsVbrUjPXg4ieEI3R1WsVliS5VRDJVINhMJW55whJc=

The encrypted header can be decoded with OpenSSL:

echo "cfsVbrUjPXg4ieEI3R1WsVliS5VRDJVINhMJW55whJc=" | openssl enc -d -A -a -iv d78d86d9084eb9239694c9a733904037 -K abed1ddc04fbb05856bca4a0ca60f21e -aes-128-cbc -nosalt
The quick brown fox

GL.iNnet GL-AR150 Wifi Pineapple

I’ve deployed the Wifi pineapple firmware on a GL-AR150, and wanted to use the second ethernet port for connecting to the Internet.

The normal configuration is to connect the controlling PC to the WAN port on the GL-AR150, this is eth0 within Wifi Pineapple. The web interface on the wifi pineapple does not appear to allow configuration of the other interface. Logging into the GL-AR150 using ssh allows configuration of eth1. I use ssh to set the IP address on eth1, which reports an error, but seems to work.

root@Pineapple:~# ifconfig eth1 192.168.1.252 255.255.255.0
ifconfig: SIOCSIFADDR: Invalid argument
root@Pineapple:~#

The default route can now be added to eth0 using the web gui.

Bridged networks can be displayed using the command:

root@Pineapple:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.e4956e4061d2       no              eth0
                                                        wlan0
root@Pineapple:~#