Last week I posted a little movie on twitter. As promised, hereby the how-to.
First off SAML and Oauth look similar but aren’t the same:
And (more) suitable for different use cases:
This setup could (should) be used to integrate Intune / EM+S Conditional Access VPN to your on-premises environment. The following steps only cover the web integration part, if you want to setup the VPN part I suggest the following article / pdf: Integrating Microsoft Intune / Enterprise Mobility Suite with Netscaler (LDAP+OTP Scenario). It covers some details, in combination with this post, that should get the job done.
Let’s start: Setting up the Netscaler is globally described (1,2 and 3) the Azure & Oauth part is more detailed.
Step 1 – Give your NetScaler a basic configuration.
- IP (management)
Step 2 – start with the rest of your NetScaler config.
Login to your management IP address and set up the rest of the basics:
- Subnet IP (ip that is used to communicate to the ‘backend’).
- Hostname / DNS / Time Zone / NTP.
- And your license (advanced / premium) is feature wise needed for this walkthrough.
Extra: It is a good idea (understatement) to change the default password. Don’t forget to setup your DNS (Traffic Management, DNS, Name Servers), you’ll get error 43524 otherwise.
Step 3 – Determine what you want to set up.
I used the Unified Gateway wizard to quickly setup the Netscaler, just follow the wizard.
- Name of the Unified Gateway.
- IP that will be the ‘frontend’ aka VIP. You will need to NAT your public ip address towards this ip (port 443).
- Your FQDN.
- Certificate with a matching name of your public dns address. (Your public DNS address, a-record, forwards you to your public ip.)
- Create your AD Authentication connection and set Server Logon Name Attribute to UPN*.
- Portal theme is up to you.
- Don’t add any apps, click continue and click done.
*Your Active Directory setup is important, this will map the Oauth login to your Active Directory account. I used a demo tenant in Azure so I had to add the @onmicrosoft suffix.
Step 4 – Create an app in Azure.
- Go to your Azure Active Directory.
- You have 2 app registrations. (legacy and normal).
- Create a new (legacy) app by clicking New application registration.
- Give it a name and fill in the sign-on URL (your FQDN). Click Create.
- Go to Settings and change the Reply URL to : https://yourfqdn/oauth/login. The redirect url is the url where AAD redirects the user after the login.
- Go to Keys: Create a new Password, Set the expiration and click Save, the secret key is shown only at creation.
Be aware that the NetScaler can’t handle special characters, if you get the following error after this walkthrough -> Http/1.1 Internal Server Error 43524 – the client secret / app combi is wrong, or you got a key with special characters.
Examples of wrong keys:
Example of right key:
Step 5 – Next up is your ADC.
- Your newly created Universal Gateway needs to authenticate users. To do so we use a AAA virtual server. Go to Security, AAA- Application Traffic, Virtual Servers and click add. Give the AAA server a name and select a Non Addressable ip type.
- Click OK.
- Click on “No Server Certificate” to bind the certificate used to create your Universal Gateway. Click Continue
- Click on “No Authentication Policy”, In the next screen click Add next to Select Policy*.
- Give your new Oauth policy a name and select OAUTH from the Action Type*.
- Insert the expression true in the expression field.
- Did you notice that we skipped Action? This is next up!
- Click right next to Action on the Add button.
- Give the Oauth server a name.
- Select Intune at Oauth Implementation Type*.
- Fill in your Client ID* This is your Application id from your app created in step 4. In our case – 5105ccee-826c-4be9-8cde-e249cdf9057a. Make sure you don’t copy any spaces.
- Client Secret* This is your secret key you created – 3lhINygcTNepkVL3lz2JZcjE5D5WyWjw8ScjM4ILZvz=
- Your tenant id* You can find your tenant id in your app overview. Go to App Registrations (legacy) and notice the Endpoints button above your app. Your tenant id is the number after the https://login.microsofonline.com/ : in my case 27b3e525-15fb-4864-b568-b4dbcfce5991
- Oauth 2.0 Authorization endpoint (copy from your own endpoints) V1 – https://login.microsoftonline.com/your tenant id /oauth2/authorize
- Token endpoint (copy from your own endpoints) https://login.microsoftonline.com/your tentant id/oauth2/token
- Click more.
- Graph endpoint (see Endpoints) https://graph.windows.net/yourtenant id
- And the Cert endpoint https://login.microsoftonline.com/common/discovery/v2.0/keys
- User name field = upn
- Click create to finish the Action.
- Click Create to finish the Authentication Policy.
- Select the policy and bind it to the AAA Virtual Server.
- Click continue and done.
Step 6 – we need to create an Authentication profile that binds our Universal Gateway with our AAA Virtual Server.
- Go to Security, AAA-Application Traffic, Authentication Profile and create one.
Name – Give it a name (for example, to what AAA it redirects).
Authentication host – The name of the AAA Virtual Server.
Server type – Authentication Virtual Server.
Authentication Virtual server – Select the newly created AAA Virtual Server.
- Click create.
Final step – bind the Authentication Profile on your Universal Gateway.
Go to Citrix Gateway, Virtual Servers and open your Gateway Virtual Server. Click Authentication Profile on the right-hand side and add the form. Verify that your new profile is selected and click Done.
Test the result, but first a save & reboot of your NetScaler (don’t know why, but it restarts itself if you don’t reboot it).
Test it out! Azure asks your end users for permission, you can skip this for all users under your app settings, required permissions – Grant Permissions.
- If you are not successfully
redirected from the LB Vserver to the AAA OAuth login page, and you receive
“Internal Server Error 43549” verify the following:
- That the IdP Action “RedirectURL” is correct and using the correct protocol (HTTP vs HTTPS) in the URL, and is the Full URL as detailed, not just the FQDN.
- That the Client Secret matches and does NOT use any special characters. We know there are issues with some special characters here as of 12.0-57.24
It could also be that your Netscaler is missing an DNS server..