Linux encrypted volume

When upgrading the Linux kernel I encountered an issue where the new kernel was not correctly identifying and decrypting my volume. Fortunatley I was able to access the system using an older kernel.

It seems that a critical package had been removed, as redundant.

apt install cryptsetup-initramfs

Add CRYPTSETUP=Y to /etc/cryptsetup-initramfs/conf-hook

update-initramfs -u -k <problematic kernel>

Logitech K400 Plus

The default scroll direction setting for my Logitech K400 Plus track pad does not match the track pad on my device. The scroll direction setting can be changed through a registry key.

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\HID\VID_046D&PID_C52B&MI_01&Col01\7&1604964&0&0000\Device Parameters
FlipFlopHScroll => 1
FlipFlopWheel => 1

The exact registry key may vary, I’m not able to check on multiple systems. There is only a single key with the FlipFlop values.

Unplugging and re-inserting the USB dongle was sufficient for the settings to take effect.

TFS Process Template Upgrade

When I first started using TFS processes, using on-premises TFS 2010, I selected the MSF for Agile Software Development v5.0 template.

After the upgrade of TFS to 2017, the process template was not working as expected. When attempting to upgrade the process templates in the web portal, the system performed upgrade checks against the Agile template, and failed with the following errors:

[Warning] TF400609: Cannot add the action 'Microsoft.VSTS.Actions.StartWork' to the work item type 'Task' because the state 'New' does not exist.

[Warning] TF400609: Cannot add the action 'Microsoft.VSTS.Actions.StopWork' to the work item type 'Task' because the state 'New' does not exist.

[Warning] TF400609: Cannot add the action 'Microsoft.VSTS.Actions.StartWork' to the work item type 'Bug' because the state 'New' does not exist.

[Warning] TF400609: Cannot add the action 'Microsoft.VSTS.Actions.StopWork' to the work item type 'Bug' because the state 'New' does not exist.

[Warning] VS402404: Bugs On TaskBoard: Bug does not have the Microsoft.VSTS.Common.Activity field defined. Some charts will not include these work item types.

[Warning] VS402404: Bugs On TaskBoard: Bug does not have the Microsoft.VSTS.Scheduling.RemainingWork field defined. Some charts will not include these work item types.

[Warning] TF400607: Category 'Microsoft.HiddenCategory' will be overwritten.

[Error] TF400654: Unable to configure Planning Tools. The following element contains an error: RequirementBacklog/Columns. TF400529: This element defines the columns that appear on the backlog. You must set all values to fields that exist in at least one of the work item types belonging to the category. The following fields do not exist in any of the work item types: Microsoft.VSTS.Common.ValueArea.

[Error] TF400654: Unable to configure Planning Tools. The following element contains an error: BugWorkItems/BugWorkItems. TF400506: This element defines the states for work items that represent Bugs or Defects. Each state must exist in at least one of the work item types that are defined in: BugWorkItems. The following states do not exist in any of the work item types: New.

The Microsoft documentation outlines what is necessary to perform the manual steps prior to the upgrade: https://docs.microsoft.com/en-us/azure/devops/reference/add-features-manually?view=azure-devops-2019

Other pages show how to download the relevant items that need to be updated.

The target process template is downloaded using Visual Studio, Team->Team Project Collection Settings->Process Template Manager… This will show the template manager with installed templates. Since my project was closest to Agile I downloaded the Agile template.

Since the upgrade check flagged errors for the Task and Bug work item types, I tried to upgrade these using the Visual Studio TFS 2017 tools, but encountered an error:

c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer>witadmin importwitd /collection:https://<tfsserver>/<collection> /p:<project> /f:"C:\Agile\Agile\WorkItem Tracking\TypeDefinitions\Task.xml"
Error while copying content to a stream.

I never managed to identify the cause of the error, instead, with the help of Google, I identified a work around. When running the commands with Fiddler (https://www.telerik.com/download/fiddler), they succeed. This may indicate an issue with tls/certificates.

c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer>witadmin importwitd /collection:https://<tfsserver>/<collection> /p:<project> /f:"C:\Agile\Agile\WorkItem Tracking\TypeDefinitions\Task.xml"
The work item type import has completed.

c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer>witadmin importwitd /collection:https://<tfsserver>/<collection> /p:<project> /f:"C:\Agile\Agile\WorkItem Tracking\TypeDefinitions\Bug.xml"
The work item type import has completed.

After performing these, the upgrade validation was still flagging the error about the RequirementBacklog. Searching through the new Agile process template, I located a dependency on User Story:

<RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="User Story" workItemCountLimit="1000">

I imported the item definition for User Story:

c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer>witadmin importwitd /collection:https://<tfsserver>/<collection> /p:<project> /f:"C:\Agile\Agile\WorkItem Tracking\TypeDefinitions\UserStory.xml"
The work item type import has completed.

After this, the upgrade process was successful.

Git, TFS and Visual Studio

We use our own certificate authority for internal systems, with the CA certificate being self signed and distributed to all systems through Active directory Enterprise Trust. We host TFS internally, and sign the TFS certificate with our internal CA. However, Git has its own list of trusted certificate authorities. In order to use Git with our on premises TFS we need Git to trust the organisations certificate authority, our CA certificate must be added to the Git trusted certificate authorities list.

When using Git from the command line, you can identify the location of the list of certificate authorities with the command:

c:>git config http.sslCAInfo
C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt

The organisations CA certificate (in PEM/Base64 format) needs to be appended to the file, or you can take a copy of the file and change the Git configuration to reference your copy.

However, when using Git within Visual Studio, a different instance of Git is used, with a different certificate trust file. The location of the file will depend on the installation of Visual Studio, for example:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\ssl\certs\ca-bundle.crt

If you can locate Git in the Team Explorer, git config http.sslCAInfo will give a path relative to the installation of mingw32. In the case of uncertainty, you can use a utility such as the Sysinternals ProcMon to locate which certificate bundle is being used.

.gitignore

git rm --cached .eslintcache

Kerberos delegation

Resource based delegation property:

Get-ADUser <account> -properties msDs-AllowedToActOnBehalfOfOtherIdentity | select -ExpandProperty msDs-AllowedToActOnBehalfOfOtherIdentity | fl *

To set up target resource:

$creds = Get-Credential
$user1 = Get-ADUser -Identity <samaccountname1> -Credential $creds -Server <remote-DC-FQDN>
$user2 = Get-ADUser -Identity <samaccountname2> -Credential $creds -Server <remote-DC-FQDN> 
Set-ADUser <target-samaccountname> -PrincipalsAllowedToDelegateToAccount $user1,$user2

Office 2019 installation

Configuration tool available at https://config.office.com/

 setup /configure configuration.xml
<Configuration>
  <Add OfficeClientEdition="64" Channel="PerpetualVL2019" AllowCdnFallback="TRUE" ForceUpgrade="TRUE">
    <Product ID="ProPlus2019Volume">
      <Language ID="en-us" />
      <ExcludeApp ID="Groove" />
    </Product>
    <Product ID="VisioPro2019Volume">
      <Language ID="en-us" />
      <ExcludeApp ID="Groove" />
    </Product>
    <Product ID="ProjectPro2019Volume">
      <Language ID="en-us" />
      <ExcludeApp ID="Groove" />
    </Product>
  </Add>
  <Property Name="SharedComputerLicensing" Value="0" />
  <Property Name="PinIconsToTaskbar" Value="FALSE" />
  <Property Name="SCLCacheOverride" Value="0" />
  <Updates Enabled="TRUE" />
  <Display Level="Full" AcceptEULA="TRUE" />
</Configuration>

Certificate bundle

When requesting a certificate from a CA they will typically send a bundle of intermediate certificates. Frequently, this bundle includes the root certificate. Web server certificate bundles don’t need to include the root certificate, so it is necessary to remove the root certificate from the bundle.

You can check the certificates in the bundle, to make editing easier, using a single line command, that works on Windows and Linux:

openssl crl2pkcs7 -nocrl -certfile cert-bundle.cer | openssl pkcs7 -print_certs -text -noout

ADFS

Cookie persistence

Set-AdfsWebConfig -HRDCookieEnabled:$false

Diagnostic Claims

When analysing federation trust issues, it is sometimes useful to be able to pass all claims from the Identity Provider to the Service Provider. In general this is unsafe.

One option is to flag the original claims in a way that means they are not accepted by the Service Provider. In ADFS this can be done with the following claim rule:

@RuleName = "Diagnostics"
c:[]
=> issue(Type = "XX-" + c.Type + "-XX", Value = c.Value);

This rule nests the original claim type between “XX-” and “-XX”

Federation Metadata

Federation metadata url:

https://server/federationmetadata/2007-06/federationmetadata.xml

Home Realm Discovery

Prevent caching of home realm:

Set-AdfsWebConfig -HRDCookieEnabled:$false

Claim rule language

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-the-claim-rule-language

https://social.technet.microsoft.com/wiki/contents/articles/4792.understanding-claim-rule-language-in-ad-fs-2-0-higher.aspx