With the new 1801 Web Console, more and more companies are likely to depend on it in foreseeable future, especially when SCOM has been given more focus lately. The post will cover the aspect of utilizing Azure Web Application Proxy to access SCOM webconsole through internet, and provide single-sign on feature if your environment allows it. As AAD is widely adopted as authentication mechanism, it makes more sense for enterprises to consolidate their sign-on efforts to Azure AD, given all the capabilities it provides.
- Azure-AD-enabled enviornment. You don’t need to have it synced via ADConnect, you just need to make sure you have a tenat that can be used. At least AAD Basic plan is required.
- SCOM Installation (well, it is a prerequisite in the end 🙂 )
- Some knowledge on Kerberos Constrained Delegation
- Some understanding of Federation/SSO features
- Global Administrator rights on Azure tenant
Disclaimer here: I will follow what worked for me, to get SSO to work. Your environment will most likely be in a different configuration, so please do not treat this post as a guide, but much rather as an insipration
1. Enable Azure AD Web Application proxy
Login to Azure AD portal, and navigate to Azure Active Directory blade. Click on “Application proxy” and following blade should start up:
Discard the existing Connector here, it’s a leftover from my lab setup. You need to Enable application proxy for your tenant first. Once you enable it, you can register AAD Proxy on your server. For production environments, I would suggest considering creating a dedicated servers, which will work in a “cluster” so to say, that is at least one gateway in a group must be active.
Click on the link “Download Connector”, and install it onto your desired Web Application gateway. During installation it will ask you to sign in, you need to use your privileged credentials to register AAD Web Application proxy. Also, please bear in mind the server needs to be able to connect remotely to Azure Datacenter.
Once you have installed gateway, it’s time to configure it. Assign the proxy to a group that works for you. Remember one application proxy can be used for many applications – in my example here “SCOM” is valid, but you might want to name your proxy after network boundary you are accessing on-premises (LAN, DMZ etc.)
Now it’s time to register an on-premises application for authentication. I have gone to “Enterprise applications -> Categories -> Add an application -> Add your own on-premises application” and filled in the details as follows:
You might notice that I chose the internal URL to be only a FQDN of SCOM web console server. I will explain why that, instead of http://w16d-scom/OperationsManager later in this post.
Now that we have this part completed, we might need to create additional security group for SCOM Web Console Access. I do encourage to use groups instead of direct user assignments for obvious reasons – it does help a lot with access management.
You need to assign the user or group an access to the enterprise application that has been created. You can do so by following to “Enterprise Applications -> SCOM Web Console -> Add Assignment -> User or Group:
Now we are reaching the tricky part. How will SCOM server know that the person who authenticated is really that person? Since SCOM Web Console uses Integrated Windows Authentication, Kerberos Constrained Delegation can help here. See more details here
To get IWA to work with our SCOM Web Console, we need to modify KCD settings in Active Directory. In AD Users And Computers snap-in, naviage to computer object of the Web Application proxy and choose Delegation tab. In my example I’m running Web App Proxy on the same server as SCOM web console, so it’s actually the same server. In this specific case it is not even be required (authenticating server and authentication target is the same), but I did it for clarity purpose. Also, this part needs revision for your specific environment as the identity needs to be matched to local AD, and one that has enough permissions to access SCOM Web Console. In my setup, my local AD is oblivious to Azure AD, meaning there is completely no trust between these domains. What I did to overcome this issue is to create a user “firstname.lastname@example.org” on my local AD, so that User Principal Name could be matched properly from AAD. I also registered HTTP SPN to my SCOM Web Console, so it was being used:
SetSPN -S http/w16d-scom w16d-scom
SetSPN -S http/w16d-scom.ad.alexpawlak.pl w16d-scom
Configure the SSO settings of Web Application Proxy as follows, once you have the username ready. Play around these settings and see what works for you in the end 🙂
Furthermore, the app is made available on Office365 application dashboard:
Now that we have Azure AD part covered, there is one extra thing you need to do to trick SCOM to load up properly. As we have set the web application proxy to FQDN of the web server, we are now getting generic IIS greeting screen. To overcome this issue, log on to web server of SCOM, go to HTTP Redirect:
And configure this feature like that:
This way any request that goes to your FQDN will be redirected to OperationsManager Application.
At least for me at this step it was enough to get this to work.
Let me know if you are using Azure Web Application Proxy and with what extent – as far as I know in my current company it’s not used at all, and it could well help us provide secured remote access to resources we might need to reach – all with credentials protected by AAD features:
Thanks for reading !