Service Principals and Azure AD

There are a few scenarios with Azure AD that folks commonly run in to.

I have not blogged about the relationships of an Azure Tenant and Azure AD.  So let me briefly mention the relationship between these two.
(I will be repeating this all in future posts, as this relationship is important to grok)

An Azure Tenant is the Account that you or your company has in Azure.  It is divided into Subscriptions. 
Each Subscription is where you 'consume' in Azure; and it also serves as an isolation boundary (as in, resources in different services can only talk to each other through public entry points - they cannot directly touch each other).
Below that you have Resource Groups, which are management containers (not isolation).
And then you have the actual resources that you get billed for consuming.

All of this together is an Azure Tenant - or phrased another way, you are a Tenant of Azure and this is your playground and thus billing entity.
I will keep using the phrase Azure Tenant in this way.
(I run across MSFT folks that use the word Subscription when referring to the Tenant, and it is just plain incorrect and thus confusing as to the ramifications)

Azure AD is an entirely separate thing.  It is this huge multi-tenant cloud based identity provider, with a number of cool features and touch points.
An Azure Tenant must have an associated Azure AD, but an Azure AD has no dependency on an Azure Tenant (or an Office365 tenant - which is yet another entity).

A single company can have multiple Azure AD's (which is highly likely), they could also have multiple Azure Tenants (which is not very likely, but possible).

A single Azure Tenant can only be associated with one Azure AD.  Nuance here; the tenant has one Azure AD, but people from other Azure ADs can be granted access.  But the invited accounts are foreign accounts.

I bring all of this up since it is this multi-pronged association that usually gets folks into a pickle.

The "Service Principal" is a term that has been within the IT world for a long time.  It describes the user account that a particular application or service runs under.  If that application needs to access resources on the network, the Service Principal user account for that particular service is used.

This has worked well for decades in the enterprise with Active Directory.  And now we need to take this to the cloud.  And it works a bit differently with Azure Active Directory.

Within Azure Active Directory the service principal is called an "App Registration".  And just like with the enterprise, you would have a unique app registration for each application.

This is different than a user account that you simply grant access to Azure resources.  While it really appears to be the same thing, it actually isn't.

Now, as we put things together a number of questions arise.  Which Azure AD should my app registration reside in?  Is there any limitation on the user account?  What resources does the app registration need to access?

Most likely you are using the app registration to interact with your Azure tenant resources.  For example, the app registration is used to provision new machines, or to power machines on and off.  Essentially to perform lifecycle events on your Azure resources.

This means that the app registration must be "native" to the Azure Tenant Azure AD - regardless of what Azure AD your user accounts reside in.  You cannot simply use a random user account.

If you manually create your app registration, you need to be a user administrator in your Azure AD.  And then you can grant the permissions to the Subscription or Resource Groups and you are golden.

https://itproctology.blogspot.com/2017/04/manually-creating-service-principal-for.html

If you are using some other app to create the app registration programmatically things immediately get unique.  All of a sudden your user account matters.

And to programmatically create an app registration, your user account needs to be native to the 

Azure AD.

This is a special kind of native.  The Azure AD account that you use must be an "onMicrosoft" account within that Azure AD.  You cannot use a user account that is synchronized with your on-premises Active Directory.  It does not even matter if your user is a domain admin.

Each Azure AD begins life as an "onMicrosoft" entity.  If you look at the properties of the Azure AD, you will see the information about its original creation, such as brianeh.onmicrosoft.com.  And this remains even if you add a vanity domain, such as ITProctology.com to the Azure AD.

I mention all of this because you might be in a position where you need to create a special Azure AD account, so that your app can create its own app registration (Citrix Cloud does this, RDMI does this).

In your Azure AD, create a new cloud user, using name@domain.onmicrosoft.com  This will create a cloud user that is native only to the Azure AD, and this user will have the full permissions to the API that it needs to create an app registration.

In your app you need to then use the credentials of this new user account so that it can access the API and self create its app registration.

A lot of explanation just to get you to the answer, but the why is often as important as the what.

The gotchas of Azure AD Domain Services in ARM

Not too awful long ago Azure Active Directory Domain Services moved over to the ARM portal from the Azure Classic portal.

Yea! the world said.  And there was much rejoicing.

Now, the real world impacts of this.

There are a few scenarios with Azure AD that folks commonly run in to.

I have not blogged about the relationships of an Azure Tenant and Azure AD.  So let me briefly mention the relationship between these two.
(I will be repeating this all in future posts, as this relationship is important to grok)

An Azure Tenant is the Account that you or your company has in Azure.  It is divided into Subscriptions. 
Each Subscription is where you 'consume' in Azure; and it also serves as an isolation boundary (as in, resources in different services can only talk to each other through public entry points - they cannot directly touch each other).
Below that you have Resource Groups, which are management containers (not isolation).
And then you have the actual resources that you get billed for consuming.

All of this together is an Azure Tenant - your phrased another way, you are a Tenant of Azure and this is your playground and thus billing entity.
I will keep using the phrase Azure Tenant in this way.
(I run across MSFT folks that use the word Subscription when referring to the Tenant, and it is just plain incorrect and thus confusing as to the ramifications)

Azure AD is an entirely separate thing.  It is this huge multi-tenant cloud based identity provider, with a number of cool features and touch points.
An Azure Tenant must have an associated Azure AD, but an Azure AD has no dependency on an Azure Tenant (or an Office365 tenant - which is yet another entity).

A single company can have multiple Azure AD's (which is highly likely), they could also have multiple Azure Tenants (which is not very likely, but possible).

A single Azure Tenant can only be associated with one Azure AD.  Nuance here; the tenant has one Azure AD, but people from other Azure ADs can be granted access.  But the invited accounts are foreign accounts.

Now.  Some background into the processes that get us into the strange places that folks end up in.

When an Azure Tenant is created an Azure AD is created for it.
So you end up with some Azure AD such as you@tenantName.onmicrosoft.com

This is fine.  It gets you up and running and then you add your admins which might be your.admin@yourcomapny.com  and they get invited.  Everything in the Azure Portal works.  Now, lets get into the cases that won't work in this scenario.

This actually puts you in a very common scenario, the scenario where the Azure AD associated with your Azure Tenant is not the same Azure AD where your corporate user accounts reside.

Now, if you only want to use Azure AD RBAC to add your IT folks to the Azure Tenant for administrative purposes, this is fine.  And thus, a more common scenario than most folks want to realize.

Now, lets get to Azure AD Domain Services in ARM.  There is a security boundary here.  The Azure Tenant.  Therefore, when you enable AAD DS in ARM you are restricted to the Azure AD that is associated with the Azure Tenant.

Oh, your Azure Tenant Azure AD is not the one with your users?  Oh my!  How do we resolve this?
(trust me, the sarcasm is real here, I can't tell you how many times I have spoken to folks about this and it takes a while for all the dots to connect before they realize the dilemma).

There are three ways to resolve this:

1. 're-parent' the Azure Tenant.  What does this mean?  It means that you make some other Azure AD the primary Azure AD for your Azure Tenant.  There is an option in the Azure Portal "Move to another Directory".  The impacts:  If you had any RBAC set up, you will break it, and therefore need to set it up all over again.
2. Use a vNet.  When logged on to the Azure AD where the users are, create a new Azure Tenant and subscription.  Turn on AAD DS there.  Then set up a gateway between the vNet in this subscription where your AAD DS and user accounts are, and a vNet in a subscription of the Azure Tenant where your workloads are that require the domain services provided by AAD DS.
3. Don't use AAD DS.  Stand up a Windows Server Domain Service VM (more than one for a proper deployment) and use Azure AD Connect to sync the users with the AD domain.

In the end, this is about your user accounts, the reasons why you wanted AAD DS in the first place (you need NTLM or Kerberos for any reason).

Yes, AAD DS is convenient, but the security models that forced it into this particular assumption is not always in line with reality.

Isolating Citrix Cloud in your Azure Tenant

I have recently been studying issues that customers are having when trying to stand up a proof-of-concept environment for Citrix Cloud in Azure.

Most of these customers are standing up the full XenApp and XenDesktop Service.  However, our Citrix Cloud Services all have the same basic needs for any customer:

1. Azure Subscription (for workers and infrastructure)
2. App Registration (this is an Azure Tenant service account for our cloud based control plane to perform worker lifecycle events within a subscription)
3. Virtual Network (the machines need IP addresses)
4. Active Directory (there is a much larger discussion here, but either a read / write Domain Controller VM  or the Azure Active Directory Domain Service will work)
5. The DNS setting for the Virtual Network must be your Active Directory 
6. Cloud Connector machines (the connection between the machines in the subscription and the control plane)
7. Some type of 'golden' image that is provisioned into the worker machines your end customers get their work done on.

Growing this conversation from the bottom up;

Each customer of Azure has at least one Azure Tenant.

This is your account in Azure.  It is the highest level of connection between Azure and you the customer.

Within your Azure Tenant you have Subscriptions.

Subscriptions are billing boundaries and service boundaries (services within subscription cannot 'talk' to each other without extra work, as if they are in different buildings).

Isolating Citrix Cloud in your tenant;

Can you isolate Citrix Cloud to its own Subscription in your Azure Tenant?  Yes!  And that is actually the topology that I am going to describe here.  How to isolate Citrix Cloud from your corporate infrastructure.

Common project slow down points that I have heard are:  modifications to existing virtual networks and protecting Active Directory.  

Focusing on the Virtual Network issue first;

You CAN create a virtual network dedicated to your Citrix Cloud deployment. 

The important things to remember are:

• You need a route to your Active Directory
• You must update the DNS settings of the Citrix Cloud virtual network to be the AD

The DNS setting is the most common place where customers trip up.  The DNS setting must be set. The Azure default results in the machines not being able to resolve the Active Directory.

The three models as pictures;

It is often that pictures tell a story faster and easier, I wanted to provide those to get you started thinking about your individual topology as well.

If your Active Directory is on the same Virtual Network you are most likely golden.

If your Active Directory machine(s) is on a different Virtual Network in the same subscription, you can use peering between the two virtual networks.

If your Active Directory machine(s) is on a different Virtual Network in a different subscription, you must use a gateway between the two virtual networks.

Virtual Network permissions for Citrix Cloud

In a previous post I covered how to manually create a Service Principal (App registration) for XenDesktop Essentials.  (this also applies to the XenApp and XenDesktop Service)

If you recall, this is the identity that Citrix Cloud will be using when it performs machine lifecycle actions in your Azure Subscription.

Things with permissions can get a bit strange in Azure pretty quickly.  One such area is Virtual Networks.

First of all, a Virtual Network exists within a Subscription.  It can belong to any Resource Group for management, but can be used by any machines or services within the subscription.

Now, in the world of assumptions, this is all fine and easy if you grant the Service Principal account the Contributor role AND the resource group that your virtual network belongs to is within a resource group under that same subscription.  You can take advantage of the inheritance.

This is not always the case.  In fact, it might not be the case for you at all.  You might be putting very tight controls on that Virtual Network to ensure it never gets messed up.

The minimum permissions that the Service Principal needs to your Virtual Network is the VM Contributor Role.  This level of access is necessary for the automated provisioning and lifecycle of desktop or session workers.

If you have a need to grant access to your Virtual Network or want to constrain access to your virtual network, here is how.

Remove the inheritance at the Virtual Network Resource Group from the subscription if it is enabled.
Explicitly grant the App Registration the VM Contributor role on the Virtual Network where worker machines will be attached when provisioned.

You can find more about the permissions in this article that I authored:  Manually granting Citrix Cloud Access to your Azure Subscription

Azure Resource Manager Templates for Citrix Cloud workloads

At Citrix we recognize that different customers need different tools to accomplish their goals.  In the end, it is all about selecting the right tools for your environment and business processes to get you moving forward in an efficient way.

It has been brought to our attention that getting started in Azure with Citrix Cloud is not necessarily as straightforward as it needs to be, especially when customers go it alone (without the aid of a sales engineer or an integrator).

You will be seeing different tools, recommendations, updated documentation, and product enhancements to help get you (the customer) moving forward with your demonstration project, that Proof-of-Concept project, and moving into full production.

One of those tools was recently mentioned on this blog: Citrix Cloud XenDesktop Resource Location ARM Template

Without modification of the template this Azure Resource Manager template is focused on getting you up an going with that very first Demo environment.
It provides everything from an Active Directory Domain to NetScaler VPX.  And the glue in between to make it all work.

Additionally, there are other Azure Resource Manager templates that are componentized to support you in building out the infrastructure in your own way or integrating with your current Azure environment for any of the Citrix Cloud offerings.

These are being built to bring success to your Proof-of-Concept and production deployments. You can find the PoC and Production template repository here: https://github.com/citrix/CitrixCloud-ARMTemplates

This is a community repository and we would love to see your additions and suggestions.

I would also like to hear your stories and questions about using Azure to deploy your Citrix Cloud service, whether it be XenApp Essentials, XenDesktop Essentials, or XenApp and XenDesktop Service. 

Lets make it better together.

Deploying XenDesktop using the SCVMM Service Template

The latest release of XenDesktop is now available as a Service Template for System Center Virtual Machine Manager.

I am assuming that my blog readers are already familiar with the concept of Service Templates, introduced with SCVMM 2012. 

The “Service” is where the applications and OS are separate entities, they are layered across each other and deployed as a composed entity with intact references and dependencies.  The Template is the representation of these dependencies and relationships.  The Template is ‘deployed’ into a ‘Service’.  The Service is the running machines.

For most of the past year we have been focused on simplifying the deployment of the XenDesktop infrastructure.  After all, there are enough decisions to make without having to spend one or two days installing operating systems, applications, and configuring them.  This is where the XenDesktop VMM Service Template comes in.

The whole idea is to take the monotonous tasks of deploying VMs, installing XenDesktop, configuring those infrastructure machines and reducing them to a few questions and time.  Freeing you up to do more important things.  Ant the end you can have a distributed installation of XenDesktop – the license server, Director, StoreFront, and Controller.  All connected and ready to deliver applications or desktops.

Why not give it a go?

If you just want to see what this is all about, take a look here:  http://www.citrix.com/tv/#videos/9611

If you head over to the XenDesktop download page, you will find a “Betas and TechPreviews” section.  In there you can download the XenDesktop Service Template zip package.  (The Service Template is the TechPreview not the version of XenDesktop).

http://www.citrix.com/downloads/xendesktop/betas-and-tech-previews/system-center-service-template-tech-preview.html

By the way – there are four templates.  One template to install a scaled out XenDesktop, another for an evaluation installation of XenDesktop.  You will also find Provisioning Server templates that can also support scaling out or an evaluation installation.

After downloading the package, unzip it to a convenient location, then open up the SCVMM Console, Select the Library view, and click on the Import button in the ribbon. 

You can always stop here and read the administration guide, it is short and has all the pretty screen shots that this post is missing).

Browse to the XML file in the package you just unzipped. 

Then map your generalized Server 2012 (or Server 2012 R2) VHD / VHDX to the package by selecting the pencil (a red X appears when it is mapped – don’t ask me why a red X)

Just like the generalized virtual disk, if you want SCVMM integration enabled, then place the SCVMM installation ISO in your VMM Library and select that pencil icon to create the mapping.

The Custom Resource should be uploaded from the package and contains the Citrix parts.

There is a really short import video here if you don’t want to read all of that.

After you import, you can deploy the XenDesktop infrastructure by simply right clicking the template and selecting Configure Deployment.  Answer a few pertinent questions, select Refresh Preview for SCVMM to place the machines, and select Deploy Service.  The name you give your Service will also become the name of your XenDesktop Site.

Now, go to lunch.  When you return, connect to the console of the Controller VM, open Studio, and begin publishing desktops.

You can watch a shortened version of the deployment process.

The requirements are not different than any version of XenDesktop.  There needs to be; a domain to join with DNS, a SQL Server, a VM Network from which the machines can reach those resources, a RunAs account for the (first) XenDesktop administrator, and a user account for XenDesktop to integrate with SCVMM.

As time passes you may decide that you need additional StoreFront Servers or Desktop Controller servers.  To do that, select your Service in the VMs and Services view, right click, and Scale Out.  Select the tier and go.  Additional Controller capacity is created for you and added to the Site, StoreFront requires some additional configuration so you can tailor the load balancing to your environment.

If you need to see that one, I have a video for that as well.

If you need support, you can get that in the XenDesktop forums, we will be there to help and respond to questions.

Please, give us feedback and let us know what you think.

Secure Gateway SSL handshake from client failed with IE9

I recently ran into an issue with Internet Explorer 9 (IE9) and Citrix Secure Gateway.

Using two Windows 7 machines (one with IE9 one with IE8) it was quick to realize that this was an IE9 specific issue.

What I discovered was that I could logon, I would get my list of applications, but when I launched my application from the WebInterface the application never launched.

Interestingly, the download of the launch.ica file was never completed by IE9 either.

If I look at the logs on the Secure Gateway server I see the error message: “SSL handshake from client failed.”  But that does not intuitively fall into place with the download of the launch.ica file not completing.

I have further learned that this is most likely due to new security sandboxing that exists in IE9.

The workaround to all of this is to place the URL of your Citrix Secure Gateway server into the Trusted Sites security zone within IE9.

After doing this, it all works as before.

I hope this helps overcome some issues and moves you on to IE9 (I will admit, I am still not used to typing search strings into the same box that I have been typing URLs into for years).

Importing the XenApp EVA is really this easy.

I’m going to import the XenApp 6 Evaluation Virtual Appliance into Citrix XenServer 5.6 using a new feature of XenServer 5.6 and XenCenter 5.6 called the Disk Image Import Wizard.

You can also watch this in action here: http://www.citrix.com/tv/#videos/2368

I will assume that you have already downloaded and installed XenServer 5.6 and XenCenter 5.6.

First, go to the download website for the Citrix XenApp EVA. http://www.Citrix.com/tryxenapp

A login with a MyCitrix user account is required. Be sure to download two items: the Getting Started Guide and the Evaluation Virtual Appliance package for XenApp 6.

After downloading the Evaluation Virtual Appliance, execute the CitrixXA6EVA.exe to expand the self extracting archive into a folder that contains a VHD and licensing documents.

Now, open (and read) the getting started guide. The import wizard requires some important information regarding the configuration of the virtual machine. On page four, the guide states that the EVA requires at least 2GB of RAM and the VHD requires at least 30GB of storage space. So make sure that your XenServer has a Storage Repository with at least 30GB of available space.

Open XenCenter and connect to a XenServer 5.6 host (using version 5.6 is required). In the left hand tree view select the host and then right click for the context menu and choose the Disk Image Import.

In the import wizard browse to and select the VHD and choose next.

Enter the information for the virtual machine. The VM needs a name, the number of virtual processors to assign and an amount of memory.

Note: I am unselecting the Run Operating System Fixups option because I know that this VM contains Server 2008 R2 and that it was built for Hyper-V. Server 2008 R2 can handle hardware changes pretty well (single to multiple processors, critical boot devices, etc.). XenServer also presents a critical boot device controller similar to the Hyper-V IDE specific boot device.

Then begin the import.

Once the import completes, select done.

At this time: power on the virtual machine and login at the logon screen. The domain and user account and password are in the Getting Started Guide.

If the screen of the VM flickers, Windows Server 2008 R2 is busy setting up some of the new hardware devices that it is detecting. You should still be able to login and complete the setup of the Evaluation Virtual Appliance environment.

If you would like to optimize the virtual machine for XenServer, install the XenServer tools within the virtual machine.

There is no “smoke and mirrors” involved here, it is literally this easy using the Disk Image Import wizard.