ADFS – Custom User Login experience outside of In-Network/Outside Network

There are a lot of different ways to tailor the login experience of Microsoft ADFS.  Out of the box when you create a trust, the log in experience for the application is if you are “in-network” (in other words not going through the proxy and using the Internet Explorer browser), you will be subject to the Windows Integrated login, where the application will use the credentials of the logged in user.  In the event that fails, the user will be prompted with the ugly Windows Login box.  Yes, we all know the one.  ADFS-WIA

When you are outside the network, you get the Microsoft ADFS forms based authentication page, all with your company logo and customized verbiage.

SCENARIO

You have in network users that have corporate issued laptops and desktops that belong to them, and in network users that share a single workstation under a shared department user account.  You want the users with the issued computers to get the integrated sign in experience, but at the same time want the users on the shared computers to identify themselves using the Forms Based Authentication.

Right there it is NOT possible to use the ADFS management global authentication policy options that determine forms-based versus windows-integrated sign on experiences.

ADFS-GEOAuth.png

What to do?

There are a lot of thoughts on the situation, and this is the one that I implemented in my organization that made the most sense.  Microsoft consulting at the time did not necessarily agree with this approach, and they preferred the global route, or by pointing workstations that need forms based to the external proxy.  I did not agree with that approach, so here is what I did.

  1. Leave the default global settings alone.  We don’t want to break anything that is working.
  2. Think of a name for a custom user agent.  In this example, lets use “CUSTOM”
  3. For Windows domain joined computers, create a Group Policy that sets the following registry key:
    1. HIVE:  HKEY_CURRENT_USER
      Key path Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform
    2. NAME:  CUSTOM
    3. TYPE: REG_SZ
    4. VALUE: IEAK
  4. You see in the above step that the name matches what our custom user string is.  NOTE:  DO NOT USE the Internet Explorer group policy option to change the user agent string.  You need to use the registry key, as the option will break or cause issues with versions of SharePoint.
  5. Apply the policy to the computers(or users) that you WANT to log in using integrated authentication.  In other words, exclude the shared computers, or the shared login accounts from this policy.
  6. If you do not have domain joined computers, or are using alternate browsers i.e. chrome, you will need to append the custom user agent string to those browsers.  For example, Chrome can be done via command line startup. chrome.exe –user-agent “CUSTOM”
  7. On the primary ADFS server, run the following powershell command: Set-AdfsProperties -WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,”MSIPC”,”Windows Rights Management Client”,”CUSTOM”)
  8. This command is telling ADFS that you want only browsers with the user agent CUSTOM using windows integrated authentication.  All others will use forms based.

Problem solved, without the need to invest in more servers or changing DNS settings. Users with the issued computers will get the integrated sign in experience, and at the same time users on the shared computers will be able to identify themselves using the Forms Based Authentication, and not the ugly Windows Integrated dialog box.


Default Settings:

To restore the default settings for Windows Integrated Authentication in ADFS, run the following command on the primary ADFS server:  Set-AdfsProperties -WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,”MSIE 6.0″,”MSIE 7.0″,”MSIE 8.0″,”MSIE 9.0″,”MSIE 10.0″,”Trident/7.0″,”MSIPC”,”Windows Rights Management Client”)

Concept of simple automated support bot using Microsoft Bot Framework and QnA Maker

concept_QnA

Abstract:

This concept is being developed using the cognitive services of Microsoft Azure to provide Question and Answer responses to a published end user help menu.

 

Implementation:

  1. Create a new QnA service @ https://qnamaker.ai/
  2. Publish the service
  3. Create a new AppService in Azure and tie it to the Service created in QnA maker
  4. Open up AppService and configure the web connector.
  5. Copy the embed code for the website
  6. Paste the embed code into a help website.

Use Case:

For automated responding to knowledge base questions.

Cost Considerations:

At time of writing, QnA maker is free for 10000 responses/month for a 20MB knowledge base.

Getting Started with Microsoft Flow – Building Blocks

Microsoft Flow; the workflow engine that anyone can use?  Triggers, actions, connectors; the shear amount of options can be intimidating at first.  So much so that regardless of the tutorials and templates, there is still thought of “What the heck do I do with this?”  Turns out you can do a lot, and you do not need to be a programmer to get the most out of Flow.

Continue reading Getting Started with Microsoft Flow – Building Blocks

Integrating the NetScaler Gateway with Microsoft Active Directory Federated Services

After combing through documentation from a few sources, I wanted to write down exactly how to properly integrate a Citrix NetScaler Gateway virtual server with any of the Microsoft identity and federation services (specifically AD FS and Azure AD).  Reason being, there is no definitive article on how to do it, and none .  After some blood, sweat, tears, and a few “Malformed SAML Assertion” errors,  I was able to have a working configuration for both AD FS.

For reference, this has been tested on NetScaler 11.x and 12.x, using AD FS 3.0 for Windows Server 2012 R2. This does not go in depth on how to configure a virtual server on a NetScaler device, nor any advanced options in AD FS.

Continue reading Integrating the NetScaler Gateway with Microsoft Active Directory Federated Services