Category: ADFS

Azure AD Connect and .NET Framework 4.7.2

Introduction

Last week a discussion erupted on Microsoft forums regarding Azure AD Connect due to it’s Monitoring Agent using all free resources of CPU on the servers. These issues were caused by a .NET Framework update and a lot of administrators spent time uninstalling and blocking these patches to resolve the CPU usage issues on their servers. On Saturday Microsoft released an update (KB4340558) which contains a collection of several patches where one of the earlier mentioned .NET Framework updates were included. For more information, see this link.

Microsoft has recently published an article regarding this issue. In addition, Microsoft also published a new version of the health agent where they state that the issue is resolved, it can be downloaded from here. The new health agent version is set to be included in the next version of Azure AD Connect, which will be published for Automatic Upgrade (Auto Upgrade). The following patches have been identified with issues causing Azure AD Connect’s monitoring agent using huge amounts of CPU:

Auto Upgrade

In version 1.1.105.0 of Azure AD Connect, Microsoft introduced Auto Upgrade. Although, not all updates are published for Automatic Upgrade. Whether a version is eligible for automatic download and installation will be announced on Microsofts version-history website for Azure AD Connect.

You can verify whether your Azure AD Connect installation have Auto Upgrade enabled by either using Powershell or viewing your configuration in It’s GUI.


Graphical User Interface of Azure AD Connect
PowerShell-command for determining whether Auto Upgrade is enabled or not.

This command will return either Enabled, Disabled or Suspended, where as the Suspended state only can be set by the system itself. Newer installations of Azure AD Connect enables Auto Upgrade by default, in case your installation applies to Microsoft’s recommendations. For more information, see this link.

Enabling Auto Upgrade

In case you have an installation of Azure AD Connect older than 1.1.105.0 (February 2016), Auto Upgrade will be disabled, if you’ve not enabled it manually. Enabling this function can be done with below PowerShell-command if so wanted.

If you have any questions, feel free to email me at robert.skyllberg@xenit.se



Using NetScaler as OpenID Connect SP with ADFS as IDP

How do you configure Citrix NetScaler OpenID Connect Service Provider with Microsoft ADFS as OpenID Connect Identity Provider? I’ve tried making it easy to understand and how you do it using CLI (NetScaler CLI and powershell).

Read this post for doing this with SAML.



Using NetScaler as SAML SP with ADFS as IDP

How do you configure Citrix NetScaler SAML Service Provider with Microsoft ADFS as SAML Identity Provider? I’ve tried making it easy to understand and how you do it using CLI (NetScaler CLI and powershell).

Before we begin, let us look at what we need to establish the federation:

  • NetScaler (with at least Enterprise license)
  • Active Directory domain and ADFS (read this post if you want to load balance and use NetScaler as ADFS Proxy)
  • Website (lb vserver) we want to protect with AAA (will be referred to as the service provider)
  • AAA vserver to bind SAML Service Provider policy

In my case, the following FQDNs are used:

  • LB vserver: webapp-test.domain.com / LB-WEBAPP-TEST
  • AAA vserver: sp.domain.com / AAA-SP-DOMAIN.COM (note: it will actually not be access by the web browser)
  • ADFS: adfs.domain.com

When installing ADFS two self signed certificates are issued for Token-signing and Token-decryption. When it comes to the NetScaler, we could always use whatever certificate for the signing and decryption – but I recommend using a certificate that isn’t used for web site communication. That’s why I create a self signed certificate that I use: (note: I do this on my computer, modify the variables to match your environment – and even though this certificate and key is self signed – keep them secure)

The certificate (not the key) needs to be copied to the ADFS server for when we create the Relying Party Trust, and we also need to copy the ADFS Token-signing certificate to the NetScaler (below called adfs.domain.com-signing).

Copy the newly created certificate and key to the NetScaler, as well as the ADFS Token-signing certificate:

Now we need to create the SAML Service Provider action and profile, as well as bind it to the AAA vserver:

(Note: As I stated before, this policy is bound to the AAA vserver but the expression is matching the hostname of the LB vserver – since the web browser actually never is redirected to the AAA vserver in this scenario)

As a last step, create (if it isn’t already) an authentication profile and bind it to the LB vserver:

Now configure ADFS (modify the variables to match your need):

 



Prepopulate username with NetScalers RfWebUI

We’ve been seeing an issue with AAA in front of ADFS where credentials entered at the service provider (Office 365 for example) doesn’t populate the username in the NetScaler login, which works with ADFS. This isn’t the biggest issue, but something that makes it annoying to use AAA instead of pure ADFS. We were able to do this just fine with the cookie NSC_NAME (or even query based) before when not using RfWebUI. Because RfWebUI is the latest and greatest as well as responsive, most want to use it.

I’ve been looking into how to solve this using RfWebUI and may not have found the best solution in the world, but it works reliably and is easy to implement. A big thanks to Sam Jacobs who helped me out with the javascript parts, I haven’t been working with it before so was crucial to tying the knot on the issue.

The first thing I had to figure out was how to extract the username that Office 365 sends to ADFS. We can see the username in the query to ADFS as follows:

Note: It is URL Encoded which means the @ will be presented as %40.

The thing is that when using AAA, a new redirect will be made directly inside NetScaler to the AAA vserver for authentication. I was thinking of either trying to add ”Set-Cookie: UserNameCookie=<email>” somewhere here but I was thinking that this may not work since rewrites doesn’t always work on internal redirects and I may have to add another redirect to an already long chain of redirects – which may cause issues for some browser. What I did find was a cookie named NSC_TASS that contains a long string of random letters, numbers and symbols. After trying some things I was able do decode it by first converting it from URL Encoded format and then from Base64. When doing this, I was able to see the original ADFS URL containing the query with the username. To do this, I had to run the following to get the email/username in the correct format for the NetScaler login:

In other words we do the following: Grab the value of NSC_TASS and decode the URL Encoding. After that, decode it using Base64. Then typecast it to a HTTP URL and grab the value of the query username, and decode the URL Encoding (converting %40 to @ in my case).

Now to the part where I had to get some help to actually insert the username into the form. The solutions works fine, but if you have a better way of doing it please share! We had to put a small loop and wait to make sure the input field is created before the username can be inserted. The result looks like this:

We’re waiting for the window to load, but for some reason that doesn’t mean that the input field ”login” exists (yet) and that’s where the setInterval-loop comes in. Without the loop, I did see it work most of the times on computers but rarely on phones. To make sure that this only happens when being redirected, we’ll be verifying that the cookie NSC_TASS exists and that the referrer length is greater or equal 1. After that we verifies that the element ”login” is created and inserts the username / email and changes focus to the password input.

Now it’s just a matter of using a rewirte to insert this:

If you are using the GUI, the rewrite part looks like this:

I hope this can help some people out there making their end users happier! If you find a way of doing this easier, please share!



Redirect users with mailboxes in Office 365 from Exchange using NetScaler

I wrote a blog post about smart links to Office 365, but there’s also a way to make sure users with their mailboxes in Office 365 automatically are redirected to their Outlook Web Access there (with SSO). They key lies in using a 307 redirect instead of 301 or 302, where the post is sent to ADFS – and the username and password field (luckily) are the same in Exchange (tried it with 2013). I haven’t tried this with Windows Integrated Authentication internally, but should work just fine – but maybe needs some tweaking.

First off, as always, create the pattern sets and expressions (if not already created for your Exchange load balancing):

Next step, create the rewrite to actually redirect the user from Exchange to ADFS:

Remember to replace example.com (it’s in a few different places) as well as the ADFS FQDN.

Now, create the rewrite policies and policy labels- and don’t forget to replace OFFICE365TENANT with your tenant name:

And as a last step, bind them to the vservers – in my case the load balancing vservers:

Leave a comment if you have any questions or if it doesn’t work – or if you have any better ways of doing this! I’ve tried it with Exchange 2013 and ADFS on 2012 R2.



Office 365 smart links with NetScaler and ADFS

A common issue in organizations moving to Office 365 is the different URLs the users have to remember. This can be made easier by for example smart links, where the users only have to remember something like ”office.example.com” or ”onedrive.example.com”.

This is something we can easily do with NetScaler and ADFS. See below for a few examples.

First, create a few pattern sets and expressions to reflect the different host headers:

In this case, they will do the following:

  • adminportal.example.com will point to portal.office.com but not use SSO in ADFS (internally), but rather allow the user to enter username and password.
  • portal.example.com will point to portal.office.com and use SSO in ADFS (internally)
  • onedrive.example.com will point to OFFICE365TEANANT-my.sharepoint.com
  • sharepoint.example.com will point to OFFICE365TENANT.sharepoint.com

Next step, create the responder actions. Different for internal and external usage:

In my case, I’ve added the ability to enter add a query string to onedrive, which forwards it to ADFS. For example, you’ll be able to go to https://onedrive.example.com/?username=simon and it will be entered in ADFS for you. Great to use in combination with other tools that already knows you username. Don’t forget to change adfs.example.com and OFFICE365TENANT to your own.

Now we’ll create the responder policies and policy labels:

 

And as a last step, bind these policy labels to vserver, in my example to content switching vservers:

Please leave a comment if something doesn’t work as expected or you have some enhancements that can make this work even better! I’ve tried it with ADFS on Windows Server 2012 R2.



Manually configuring Unified Gateway

I’m writing this post in English to make it easier for our non-Swedish readers.

I’m going to try and explain how to configure Unified Gateway, without the wizard! I’ll try to let the commands speak for themselves, but feel free to comment if you need me to add some additional information about what I’m doing or why. I’ll be configuring Unified Gateway enabling ICA Proxy, RDP Proxy and AAA protected applications – we would also be able to add SSL VPN using a specific group, but we’ll leave that for another time.

I’ve tried to remove parameters that don’t ”matter”, but if there’s something that doesn’t work, it’s most likely because of that – just comment and I’ll update.

My first step of configuring Unified Gateway is also the easiest part, creating a redirect to https (in my own special way) for traffic coming in on http.

Now we’re able to redirect everything hitting HTTP to HTTPS with a 301 (Moved Permanently), while still keeping the Host-header, URL and query. I’ve also added the HSTS header, just to be sure.

 

Next step is configuring some basic AAA settings, and I always try to limit what is allowed by default and then use groups from the AD to allow access to different resources.

The above authentication profile is using ugw.example.com which is my URL to the Unified Gateway, which will be added later.

 

Now, let’s create an AAA portected web application with form fill, and require users to be members of a specific group. In my case, I’ll use ADFS for the form fill application:

You will find some more information about what needs to be configured on ADFS 3.0 to get this working in another blog post I’ve written (in Swedish, but you’ll find the commands).

 

Now let’s create another web application (which is using either 401 / WIA authentication or perhaps ADFS / SAML).

 

Now we need to create the  NetScaler Gateway and some groups.

 

As last step, let’s add all these vServers into one content switch:

 

Now we’ve got one content switch with NetScaler Gateway (ICA Proxy & RDP Proxy) as well as AAA protected applications, and single sign-on between everything. Configured manually!

When it comes to publishing the same URL internally (if you don’t want to use NetScaler Gateway internally as well), you can move the creating of the bookmark from NetScaler Gateway to XenApp/XenDesktop (described here by Jason Samuel, possible with version 7.11) and use StoreFront on the Content Switch instead of NetScaler Gateway.

Good luck and feel free to leave a comment!



ADFS – Test av autentisering

Efter en installation och konfiguration av ADFS vill man säkerställa att autentisering fungerar, ett enkelt sätt att testa detta är att besöka:

https://fqdn.contoso.com/adfs/ls/idpinitiatedsignon

Sitter man internt, får man möjligheten att klicka på Sign In och därefter är man inloggad:
adfs-test-page-sign-out

 
Sitter man externt får man istället möjligheten att ange användarnamn och lösenord:
adfs-test-page-external-sign-in

 



ADFS Single Sign-on med Google Chrome

Många använder Google Chrome istället för Internet Explorer i arbetet. Har man en domänjoinad dator och fungerande Single Sign-on med Internet Explorer finns det ett enkelt sätt att aktivera det för Google Chrome i ADFS, det enda som behöver göras är att lägga till en ytterligare UserAgent i paramtern för Windows Integrated Authentication (WIA) på ADFS.

Enkelt gjort via powershell:

För att det ska fungera är det ett krav att ExtendedProtectionTokenCheck är satt till ”None”: