Tag Archives: Azure AD Application Proxy

Publish the Service Manager Self Service Portal with Azure AD Application Proxy

1 Reply

The Scenario

Updated blog post: 10th November 2015. With todays release of Update Rollup 8 for Service Manager 2012 R2 (https://www.microsoft.com/en-us/download/details.aspx?id=49556) and the new HTML5 based Self Service Portal, I have made some changes to this blog post where the scenario is updated. Please read on for how to publish this portal externally via Azure AD App Proxy:

Recently in a SCSM LyncUp call news came of a coming Self Service Portal that the Service Manager Team are working on. This portal will no longer have a requirement for SharePoint and Silverlight, and will be built on HTML5. Stefan Johner has a good write-up on the features here: http://jhnr.ch/2015/08/22/service-manager-lync-up-summary-august-2015-new-portal-sneak-preview/.

For a while ago I had a blog article on how to publish the Cireson Self Service Portal via the Azure AD Application Proxy (https://systemcenterpoint.wordpress.com/2015/03/26/publish-the-cireson-self-service-portal-with-azure-ad-application-proxy/), and in this blog article I will describe how to publish the new SCSM Self Service Portal. This will give me some interesting possibilities for pre-authentication and controlling user access.

There are two authentication scenarios for publishing this Self Service Portal with Azure AD App Proxy:

  1. Publish without pre-authentication (pass through). This scenario is best used when the Self Service Portal is running Forms Authentication, so that the user can choose which identity they want to log in with. As the new SCSM Self Service Portal doesn’t support Forms Authentication, this is not really an option here.
  2. Publish with pre-authentication. This scenario will use Azure AD authentication, and is best used when the Self Service Portal is running Windows Authentication so that we can have single sign-on with the Azure AD identity.

It is the second scenario with pre-authentication I will configure here.

I went through these steps:

Verify Windows Authentication for Service Manager Self Service Portal

The Service Manager Self Service Portal installs per default with Windows Integrated Authentication. From my environment, I can verify the following configuration settings:

  • Windows Authentication is enabled for the Web Site Application
  • On Advanced settings for the Web Site Application, Kernel Mode Authentication Enabled and Extended Protection to Off. For Providers Negotiate are listed on top.

It is a good idea at this point to verify that Windows Integrated Authentication is working correctly by browsing internally to http[s]://scsmportalservername:[port]/selfserviceportal. Your current logged on user (if permissions are correct) should be logged in automatically.

Create the Application in Azure AD

In this next step, I will create the Proxy Application in Azure AD where the Self Service Portal will be published. To be able to create Proxy Applications I will need to have either an Enterprise Mobility Suite license plan, or Azure AD Basic/Premium license plan. From the Azure Management Portal and Active Directory, under Applications, I add a new Application and select to “Publish an application that will be accessible from outside your network”:

I will then give a name for my application, specify the internal URL and pre-authentication method. I name my application “SCSM Self Service Portal”, use “http://portalserverfqdn:%5Bport%5D” as internal URL and choose Azure Active Directory as Pre-Authentication method.

After the Proxy Application is added, there are some additional configurations to be done. If I have not already, Application Proxy for the directory have to be enabled. I have created other Proxy Applications before this, so I have already done that.

I also need to download the Application Proxy connector, install and register this on a Server that is member of my own Active Directory. The Server that I choose can be either on an On-Premise network, or in an Azure Network. As long as the Server running the Proxy connector can reach the internal URL, I can choose which Server that best fits my needs.

Update: Regarding AADP Connector, you can now greate connector groups and configure the application to use the group of connector(s) you choose:

AADPConnectorGroup

Since I choose to use pre-authentication, I can also assign individual users or groups to the Application. This enables me to control which users who will see the application under their My Apps and who will be able access the application’s external URL directly.

I now need to make additional configurations to the application, and go to the Configure menu. From here I can configure the name, external URL, pre-authentication method and internal URL, if I need to change something.

I choose to change the External URL so that I use my custom domain, and note the warning about creating a CNAME record in external DNS. After that I hit Save so that I can configure the Certificate.

AADPCustomDomain

Since I have already uploaded a certificate (see previous blog post https://systemcenterpoint.wordpress.com/2015/06/10/using-a-custom-domain-name-for-an-application-published-with-with-azure-ad-application-proxy/), I can just verify that it is correct.

AADPCert

Next I need to configure to use Internal Authentication Method “Windows Integrated Authentication”. I also need to configure the Service Principal Name (SPN). Here I specify HTTP/portalserverfqdn, in my example this is HTTP/az-scsm-ms01.skill.local.

Update: You can now choose which Identity to delegate, in this case UPN is fine.

AADPIntegratedWinAuth

From the bottom part of the configuration settings I can configure Acces Rules, which at this time is in Preview. This is cool, because I can for example require for this Application that users will be required to use multi-factor authentication. I have not enabled that here though.

Another feature that is in Preview, is to allow Self-Service Access to the published application. I have configured this here, so that users can request access to the application from the Access Panel (https://myapps.microsoft.com).

After I have configured this and uploaded a logo, I am finished at this step, and now need to configure some more settings in my local Active Directory.

Configure Kerberos Constrained Delegation for the Proxy Connector Server

I now need to configure so that the Server running the Proxy Connector can impersonate users pre-authenticating with Azure AD and use Windows Integrated Authentication to the Self Service Portal Server.

I find the Computer Account in Active Directory for the Connector Server, and on the Delegation tab click on “Trust this computer for delegation to specified services only”, and to “Use any authentication protocol”. Then I add the computer name for the portal server and specify the http service as shown below (I already have an existing delegation set up):

This was the last step in my configuration, and I am almost ready to test.

If you, like me, have an environment consisting on both On-Premise and Azure Servers in a Hybrid Datacenter, please allow room for AD replication of these SPN’s and more.

Testing the published application!

Now I am ready to test the published proxy application.

Remember from earlier that I have assigned the application either to a group of all or some users or directly to some pilot users for example.

I will now log on with my Azure AD user (which of course is synchronized from local Active Directory), and I will use the URL https://myapps.microsoft.com.

After logging on, I can see the applications I have access to. Some of these are SaaS applications I have configured, some are applications we have developed ourselves, and I can see the published Self Service Portal:

(Don’t mind the Norwegian captions and texts, you get the idea;)

I then click on the SCSM Self Service Portal, and can confirm that I am able to access the Self Service Portal. See the external URL I specified and that indeed I’m logged in with my Active Directory user with SSO.

AADPSCSMPortal

Another cool thing is that I can use the App menu in Office 365 and add the Self Service Portal to the App chooser for easy access:

I can now also access the Self Service Application from the “My Apps” App on my Mobile Devices.

How to add Azure AD Application Proxy Connector Log to Operations Management Suite

Leave a reply

If you have published Proxy Applications with Azure AD App Proxy, you will also have installed one or more Application Proxy Connectors in your environment.

When you install the Application Proxy Connector, you will also get an event log for the Connectors Information, Warning or Error events.

I wanted to bring these events to my Operations Management Suite (OMS) environment, so this blog post shows how to do that.

First, let us look at the event log in question. Here I have some events, I also see that I have some warning and error events, showing that I have an issue with connecting to a backend server published with Azure AD App Proxy:

Before I can add this event log to OMS, I need to determine the name of the event log. I select Properties for the log:

The name of the log is Microsoft-AadApplicationProxy-Connector/Admin.

Now I can log into Operations Management Suite to configure the log source. I go to Settings and select the Logs section. I then add the name of the Application Proxy Connector log, and select which type of events that I want to collect. In my case I select Error and Warning.

When saving that, OMS will soon start collection event log entries from the Connector Proxy log, assuming of course that the server in question have an agent installed, either directly or via Operations Manager Management Group:

Let us see how it looks when data from the event log are appearing in OMS.

I start by doing a Log Search. I can either specify the query directly, like this: Type=Event EventLog=”Microsoft-AadApplicationProxy-Connector/Admin”, or I can select from all events and filter my way to the event log I want to.

This is how I specified the query:

I can see that I have some errors and warnings, let us drill into one of them. I do this by clicking [+] show more. I can now see the same error with backend as I had in the local event log:

So, my objective for getting the Connector Proxy event log data to OMS has been fulfilled, and I can start grouping, filtering and searching the log data.

As a last step, let us add a Dashboard view for this data.

First, I select to Save my Search:

Then I go to My Dashboard, and select Customize:

I find my Saved Search and add it to the Dashboard:

If I want to I can customize the Tile Visualization:

When I finish customizing, I now have a Dashboard Tile for Azure AD App Proxy Events, and by clicking it, I am going directly to the Log Search:

Hope this has been helpful, happy log searching in OMS!

Service Manager Self Service Portal – Password Reset with Azure AD Premium

1 Reply

One challenge with using a Self Service Portal for Service Manager is that the user must have a valid Active Directory user name and password to be able to log on to the Self Service portal. So what do you do if have forgotten your password or the password has expired?

Previously in Service Manager, we have addressed this by having another user request a password reset on your behalf, that user being either a Service Desk analysts or a Super User allowed to create that password reset request.

The optimal solution would be to enable the user to reset their own password. This blog article will show how you can use Azure AD Premium to accomplish just that!

Some requirements

First of all, this solution will have some requirements:

  • You must have Azure AD with Directory Integration enabled for your on-premises Active Directory
  • You must have configured password write-back to on-premises Active Directory

  • You must configure a user password reset policy in Azure AD, and users must at least have one authentication method defined:
  • You must have either configured federated (SSO with ADFS) users or users with password synchronization in the directory integration set up
  • Each user, and any administrator setting this up, needs to have an Azure AD Premium license. Azure AD Premium is either licensed directly or part of the Enterprise Mobility Suite (EMS)

Some recommendations

In addition to the requirements above, I have some recommendations as well:

How this works

With all these requirements in place, this is how it works when a user tries to access the Self Service Portal and wants to reset the password.

In my environment, I am using the Self Service Portal from Cireson, but this should work for the built-in Service Manager Portal as well.

  1. First, I go to my application URL, https://selfservice.skill.no. Since I have published this with Azure AD App Proxy, I must sign in with my hybrid Azure AD identity. I am presented with my customized Azure AD sign in page:
  2. Since I have forgotten my password or maybe my password has expired, I select the link for “Can’t access your account” under the Sign in button. This will bring me to the reset password page where I can specify my user identity and write the captcha code:
  3. Next I select one of my defined authentication methods, in this example I will receive a text message to my mobile phone:
  4. I receive the SMS verification code and type it in:
  5. Next after successfully verifying my SMS code, I can specify my new password:
  6. And my password has been reset:
  7. Since my user are a federated user I will now be redirected back to the ADFS on-premises and my customized sign-in page there:

  8. After logging in, I’m redirected directly to the published Self Service Portal:

Conclusion

By using the powers of Azure AD Premium and directory integration with my local Active Directory, I can as an end-user reset my passwords, and directly access my published Self Service Portal for Service Manager in this case.

PS! For those that are not in Azure AD yet, Cireson will soon deliver their own password reset solution in the Identity Management Stream. I’ll come back to that later.

Publish the Cireson Self Service Portal with Azure AD Application Proxy

6 Replies

The Scenario

Update: This blog post is the first part in a series. See:
Part 2 – Using a Custom Domain Name for an Application Published with with Azure AD Application Proxy

I have been looking at different usable scenarios for publishing internal sites via the Azure AD Application Proxy, and decided to have a go at publishing the Cireson Self Service Portal. This will give me some interesting possibilities for pre-authentication and controlling user access.

I have been considering two scenarios for publishing the Self Service Portal:

  1. Publish without pre-authentication (pass through). This scenario is best used when the Self Service Portal is running Forms Authentication, so that the user can choose which identity they want to log in with.
  2. Publish with pre-authentication. This scenario will used Azure AD authentication, and is best used when the Self Service Portal is running Windows Authentication so that we can have single sign-on with the Azure AD identity.

It is the second scenario with pre-authentication I will configure here.

I went through these steps:

Configure Windows Authentication for Cireson Self Service Portal

The Cireson Self Service Portal installs per default with Forms Based Authentication. I need to configure Windows Integrated Authentication for the portal, and this is well documented in the Knowledge Article Cireson customers and partners can access at https://support.cireson.com/KnowledgeBase/View/45. From my environment, I can summarize the following configuration settings:

  • The Self Service Portal (v3.6 with hotfix) are running on the same server as the Service Manager Management Server (recommended and officially supported by Cireson)
  • The Portal/Management Server is configured with Kerberos Delegation in Active Directory with “Trust this computer for delegation to any service (Kerberos only)”
  • The Service Manager Service Account is configured with Service Principal Names (SPN) with:
    • SETSPN –s MSOMSDKSVC/NameOfYourServerHere SCSMServiceAccountHere
    • SETSPN –s MSOMSDKSVC/FQDNOfYourServerHere SCSMServiceAccountHere
  • Service Manager Service Account is added to the IIS_IUSRS local group on the Portal Server
  • The Cireson Portal Web Site are configured with Windows Authentication (Kernel Mode Authentication Enabled, Extended Protection to Off). For Providers Negotiate are listed on top.

It is a good idea at this point to verify that Windows Integrated Authentication is working correctly by browsing internally to http://portalservername. Your current logged on user (if permissions are correct) should be logged in automatically.

Create the Application in Azure AD

In this next step, I will create the Proxy Application in Azure AD where the Self Service Portal will be published. To be able to create Proxy Applications I will need to have either an Enterprise Mobility Suite license plan, or Azure AD Premium license plan. From the Azure Management Portal and Active Directory, under Applications, I add a new Application and select to “Publish an application that will be accessible from outside your network”:

I will then give a name for my application, specify the internal URL and pre-authentication method. I name my application “Self Service Portal”, use “http://portalserverfqdn” as internal URL and choose Azure Active Directory as Pre-Authentication method.

After the Proxy Application is added, there are some additional configurations to be done. If I have not already, Application Proxy for the directory have to be enabled. I have created other Proxy Applications before this, so I have already done that.

I also need to download the Application Proxy connector, install and register this on a Server that is member of my own Active Directory. The Server that I choose can be either on an On-Premise network, or in an Azure Network. As long as the Server running the Proxy connector can reach the internal URL, I can choose which Server that best fits my needs.

Since I choose to use pre-authentication, I can also assign individual users or groups to the Application. This enables me to control which users who will see the application under their My Apps and who will be able access the application’s external URL directly.

I now need to make additional configurations to the application, and go to the Configure menu. From here I can configure the name, external URL, pre-authentication method and internal URL, if I need to change something.

What I need to configure here is to use Internal Authentication Method to “Windows Integrated Authentication”. I also need to configure the Service Principal Name (SPN). Here I specify HTTP/portalserverfqdn, in my example this is HTTP/az-scsm-ms01.skill.local.

From the bottom part of the configuration settings I can configure Acces Rules, which at this time is in Preview. This is cool, because I can for example require for this Application that users will be required to use multi-factor authentication. I have not enabled that here though.

After I have configured this, I am finished at this step, and now need to configure some more settings in my local Active Directory.

Configure Kerberos Constrained Delegation for the Proxy Connector Server

I now need to configure so that the Server running the Proxy Connector can impersonate users pre-authenticating with Azure AD and use Windows Integrated Authentication to the Self Service Portal Server.

I find the Computer Account in Active Directory for the Connector Server, and on the Delegation tab click on “Trust this computer for delegation to specified services only”, and to “Use any authentication protocol”. Then I add the computer name for the portal server and specify the http service as shown below:

This was the last step in my configuration, and I am almost ready to test.

If you, like me, have an environment consisting on both On-Premise and Azure Servers in a Hybrid Datacenter, please allow room for AD replication of these SPN’s and more.

Testing the published application!

Now I am ready to test the published proxy application.

Remember from earlier that I have assigned the application either to a group of all or some users or directly to some pilot users for example.

I will now log on with my Azure AD user (which of course is synchronized from local Active Directory), and I will use the URL https://myapps.microsoft.com.

After logging on, I can see the applications I have access to. Some of these are SaaS applications I have configured, some are applications we have developed ourselves, and I can see the published Self Service Portal:

(Don’t mind the Norwegian captions and texts, you get the idea;)

I then click on the Self Service Portal, and can confirm that I am able to access the Self Service Portal. See the special proxy URL and that indeed I’m logged in with my Active Directory user with SSO.

Another cool thing is that I can use the App menu in Office 365 and add the Self Service Portal to the App chooser for easy access:

I can now also access the Self Service Application from the “My Apps” App on my Mobile Devices.