Monthly Archives: March 2015

Windows

The Case of the Missing Technical Preview build

1 Comment

I am trying out the Windows 10 Technical Preview, and have been running build 9926 for some time. Today (19032015) Microsoft released build 10041 and I installed it immediately, of course. Not surprisingly I had some problems which were so bad that I reverted back to the 9926 build. I later figured out that it might not have been the new build that was the problem, but something else. So I wanted to try installing 10041 again to test that theory. Problem was that 10041 was no longer being offered to me in Windows Update. Turns out Windows keeps track of the builds you have reverted from and hides those from Windows Update. Here is how to make them visible again.

In Registry Editor, navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsSelfHostApplicability.

This is where all the settings for the preview program are stored. Here is what that key looked like on my system:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsSelfHostApplicability
BranchName    REG_SZ    fbl_impressive
ThresholdRiskLevel    REG_SZ    low
ThresholdOptedin    REG_DWORD    0x1

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsSelfHostApplicabilityRecoveredFrom
10041    REG_DWORD    0x1

Notice the key RecoveredFrom and the value 10041 in it. Delete the RecoveredFrom key and do another check for updates in Windows Update. The build should now be listed.

Microsoft Azure

Add the Azure VM agent to existing Virtual Machines

Leave a comment

Here is a quick rundown of how to add the base VM agent to existing Azure VMs:

  1. Find all your VMs that currently do not have the agent installed:
    Get-AzureVM  | where { $_.GuestAgentStatus -eq $null }
    or this variation if you only want to get the VMs that are actually running:
    Get-AzureVM  | where { $_.GuestAgentStatus -eq $null -and $_.Status -eq “ReadyRole”}
  2. Install the agent bits on the VM
    Azure does not provide a way to inject the agent into an existing VM, AFAIK, but you can use any number of ways to push it out. You can download the agent here http://aka.ms/vmagentwin. I use the following command line to silently install the agent:
    msiexec.exe /package WindowsAzureVmAgent.2.3.1198.670.rd_art_stable.140328-0941.fre.msi /passive
    Pro Tip: Use Azure Files to store the files and scripts you use. That makes them readily accessible to you VMs, with the added benefit of not having to maintain a file server.
  3. Update your VMs to reflect that they are now running the agent:
    Get-AzureVM  | where { $_.GuestAgentStatus -eq $null } | ForEach { $_.VM.ProvisionGuestAgent = $true;Update-AzureVM -VM $_.VM -Name $_.Name -ServiceName $_.ServiceName}
  4. Check the status of the guest agent for all VMs:
    Get-AzureVM  | select -Property ServiceName,Name,@{Name=”GuestAgentStatus”; Expression={$_.GuestAgentStatus.Status}}
    Every VM with the agent installed should report a value for Ready in the GuestAgentStatus column.
  5. We can now add other extension agents; like BGInfo:
    Get-AzureVM | where { $_.ResourceExtensionStatusList.Count -eq 0} | Set-AzureVMBGInfoExtension -ReferenceName BGInfo -Version 1.* | Update-AzureVM
  6. Another example would be the Azure Operational Insights extension:
    Get-AzureVM  | where {$_.GuestAgentStatus.Status -eq “Ready” } | Set-AzureVMExtension –ExtensionName MicrosoftMonitoringAgent -PublicConfiguration ‘{“WorkspaceId”:”<OpsInsights Workspace ID”}’ -PrivateConfiguration ‘{“workspaceKey”:”<OpsInsights Primary Access Key>” -Publisher Microsoft.EnterpriseCloud.Monitoring -Version 1.0 | Update-AzureVM
    Find your workspace key and ID in the Azure portal. More info here: https://morgansimonsen.wordpress.com/2015/02/16/how-to-install-the-azure-operational-insights-agent-on-an-azure-vm-using-powershell/
Active Directory, ADFS

Customized claims in ADFS

1 Comment

Introduction

The claims pipeline in ADFS is an interesting piece of software. I recently had a chance to re-familiarize myself with it. A third party SaaS application used an organizations internal employee numbers together with their own customer number for that organization to uniquely identify users. This called for issuing a claim to the SaaS app relying party (a.k.a. service provider) that picked up an attribute from Active Directory containing the internal employee numbers, prepending the SaaS app’s customer number and issuing it as a Name ID claim. Furthermore it was a requirement that the Name ID claim was the only custom claim issued. Of course I wanted the most elegant and efficient solution I could come up with, so that meant the the number of claims rules had to be as low as possible.

To do this kind of thing you have to use custom claim rules. The template rules are not flexible enough, but it is a good idea to use them to create the base claims query language syntax for you. Here is what I ended up with:

Get the employeeID LDAP attribute from Active Directory

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”]
=> add(store = “Active Directory”, types = (“http://langskip.no/employeeID”), query = “;employeeID;{0}”, param = c.Value);

This claim rule queries the Active Directory store for the employeeID attribute. If it is present a claim is added to the incoming claims pipeline by using the operator ADD. I store the value of employeeID in a custom type (https://langskip.no/employeeID) which only exists as a temporary placeholder for the value of employeeID. You can use both URLs and URIs to create custom claim types, if you don’t want to go with one of the standard ones. No claim is issued by this rule. That happens in the next rule…

Transform employeeID

c:[Type == “http://langskip.no/employeeID”]
=> issue(Type = “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”, Value = “350-00” + c.Value);

Next we check for the existence of an incoming claim of type http://langskip.no/employeeID. If it is present we now issue a claim of type nameidentifier. If the statement evaluates to False; no claim is issued. Hopefully the relying party knows what to do in that case. We set the value of the Name ID claim to the SaaS app’s customer ID number plus the employeeID from Active Directory.

The result looks like this in a test app I used for testing:

Claim Type Claim Value
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier 350-00123456

Thoughts on improvements…

I really would have wanted to accomplish this with just one claim rule. If anyone of you reading this knows how to accomplish that; sound off in the comments.

Happy authenticating!