All posts by Morgan Simonsen

New preview version of Azure AD PowerShell available (Yes, it now supports ADAL!)

I guess the title says it all!

Here is the link to the Microsoft Connect site to download:

http://connect.microsoft.com/site1164/

Connect-MSOLService now brings up the familiar ADAL prompt with MFA and ADFS support etc. Make sure to read the release notes included, and you should probably uninstall the Microsoft Online Sign In assistant.

Here are the changes:

  • Dependency on the Microsoft Online Service sign in assistant removed.
  • Name of module updated Windows Azure -> Microsoft Azure
  • Connect-MsolService parameter -CurrentCredentials removed.
  • Connect-MsolService parameter -AccessToken added to enable AAD Connect, and other callers to use the PowerShell as a client library.
  • New device management cmdlets:
    • Get-MsolDevice
    • Enable-MsolDevice
    • Disable-MsolDevice
    • Remove-MsolDevice

Few apparent changes in the list of installed products though:

Before:

aad_ps_adal_before

After:

aad_ps_adal_after

Morgan

Office Modern Authentication (ADAL) and Autodiscover

The introduction of Active Directory Authentication Library (ADAL) support in Office 2013 and Office 265 ProPlus is great news. The Office suite of applications is now able to take advantage of advanced authentication options like federated SSO and MFA. Using ADAL with Office is referred to using Office with modern authentication. Modern authentication was recently made available to everyone and all you need to do to start using it is add three registry keys. You can find all the information you need here:

http://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/

I recently ran into a problem with using ADAL in Office, which I think is a bug. When you try to connect to a new mailbox in Outlook using Autodiscover, and who doesn’t, Outlook is unable to successfully connect to the mailbox. From my testing, this problem is present in version 15.0.4693.1002 of Office 2013/365 ProPlus (a.k.a. March 2015 Update), which is the first version to include ADAL support.

You can look at the change log for Office here: https://support2.microsoft.com/gp/office-2013-365-update

Check your Office version by going to FileAccount and looking at Product Information:

image

The problem manifests itself when using the Account Setup Wizard.You enter your name, email address and password. Outlook queries Autodiscover DNS records for your domain. When your settings have been discovered you are asked to authenticate against the service. This authentication does not used ADAL in my experience, but displays an old fashioned authentication prompt. However, because of the bug, you will never get this far. Instead the wizard will inform you that it cannot find your settings.

To fix this, simply update to the latest version of Office. The most recent update, at the time of this writing, is version 15.0.4711.1003 (a.k.a. April 2015 update).

None of the fixes in this update specifically addresses this problem, as described in this post, but there is some mention about not being able to add a new account if your are using ADAL in Office and the account uses basic authentication in this KB article:

https://support.microsoft.com/en-us/kb/2965218

  • When you enter incorrect credentials for an account that makes some mailbox connections use Active Directory Authentication Library (ADAL) authentication and some connections use basic authentication, you are not prompted to enter credentials again, and Outlook cannot connect to mailboxes by using basic authentication.
  • When you enable the Active Directory Authentication Library (ADAL)-based authentication for Outlook 2013, you may be unable to add Office 365 accounts that use basic authentication. If you have enabled the ADAL-based authentication for Outlook 2013 that has an Office 365 account configured and the account uses basic authentication, you cannot connect to the account.

Anyway; updating resolves the problem.

RunAs Radio Azure RMS Podcast

I just spent half an hour talking to RunAs Radio host Richard Campbell about Azure RMS. The show will go live on May 13th.

RunAs Radio is a weekly Internet Audio Talk Show for IT Professionals working with Microsoft products. The full range of IT topics is covered from a Microsoft-centric viewpoint.

I was not aware of RunAs Radio myself but they have a lot of great content, and are now on my list of podcasts I subscribe to, If you are are a technologist interested in Microsoft products I highly recommend you do the same!

http://www.runasradio.com/

Thanks to Richard and everyone else at RunAs Radio for having me on the show,

When configuring the Azure Load Balancer for Remote Desktop Gateway…

make sure you DO NOT enable Direct Server Return on your endpoint Load Balanced Set:

image

In November of 2014 support was added for Source IP Affinity (also known as session affinity or client IP affinity) in the Azure Load Balancer. Before that it was not compatible with Remote Desktop Gateway. You could sort of load balance your RDGWs but it required you to put every RDGW server in its own cloud service and the use Azure Traffic Manager to load balance. With this approach you could not put your RDGW servers in the same availability set, so you had no guarantee that your gateways would be distributed across fault and update domains. Boldly, or foolishly, depending on your point of view, I decided to try anyway to use the Azure Load Balancer for RDGW, even though I knew it was not supported. Of course it did not work, but when eventually support was added I ran into problems.

After client IP affinity support was added to the load balancer I reconfigured my endpoints of my RDGW VMs:

Set-AzureLoadBalancedEndpoint –ServiceName <cloud service name> -LBSetName “RDGW HTTPS” -Protocol tcp –LocalPort 443 -ProbeProtocolTCP -ProbePort 443 -LoadBalancerDistribution “sourceIP”

Set-AzureLoadBalancedEndpoint –ServiceName <cloud service name> -LBSetName “RDGW UDP” -Protocol UDP -LocalPort 3391 –ProbeProtocolTCP -ProbePort 443 -LoadBalancerDistribution “sourceIP”

The sourceIP value in the LoadBalancerDistribution parameter is the critical one and it can only be set through PowerShell.

But still no connections… I tried all sorts of things. Since this had never worked I didn’t know if it was failing because of a misconfiguration or something in the Load Balancer. The only difference in setup I could find was that  my load balanced endpoints had Direct Server Return enabled. This was something I had decided to try back when I first set it up. There was not much documentation back then about what Direct Server Return actually did. But now there is a description in the portal:

DIRECT SERVER RETURN

Direct server return configures a virtual machine’s endpoint for the floating IP capability required to configure a SQL AlwaysOn Availability Group. This setting is required when using the SQL Always On Availability Groups in SQL Server. This setting can’t be changed after you create the endpoint.

So, not for RDGW at all…

Unfortunately you cannot disable DSR without deleting and recreating your endpoints. After removing and adding them again I was able to connect through the load balancer.

Since traffic to a particular instance behind the load balancer now is determined by the source IP, all traffic from the same IP goes to the same instance, you might experience an uneven distribution of load. Clients behind a proxy or NAT router will all end up on the same instance.

More information:

BTW I wish the Remote Desktop PG would stop putting all their guides in Word docs, would be so much better on a web page…

The Case of the Missing Technical Preview build

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.

Add the Azure VM agent to existing Virtual Machines

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/

Customized claims in ADFS

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!

How to install the Azure Operational Insights agent on an Azure VM using PowerShell

Most of the Azure VM extensions have their own specialized PowerShell cmdlets to configure them, e.g. Set-AzureAccessExtension, Set-AzureVMBGInfoExtension, Set-AzureVMMicrosoftAntimalwareExtension etc. But you can also, to some extent, use the generic Set-AzureVMExtension. The example below show how to use it to install and configure the Operational Insights agent/extension in your Azure VM:

Get-AzureVM -ServiceName <cloud service name> -Name <VM name> | Set-AzureVMExtension –ExtensionName MicrosoftMonitoringAgent -PublicConfiguration ‘{“WorkspaceId”:”<OpsInsights Workspace ID”}’ -PrivateConfiguration ‘{“workspaceKey”:”<OpsInsights Primary Access Key>”}’ -Publisher Microsoft.EnterpriseCloud.Monitoring -Version 1.0 | Update-AzureVM

You can find your OpsInsights workspace ID in your Operational Insights portal.

  1. Select Servers and Usage
  2. Press Configure
  3. Your Workspace ID and access keys are displayed on the right. Use the primary key.
    For servers outside Azure you can onboard them directly following these instructions:

Connecting agents directly to Operational Insights

Happy monitoring!