Publishing MIM Portal with Azure App Proxy

Ever wanted to offer a single sign experience to users who are not on domain joined clients? well now you can if they have an Azure account! The Azure Application Proxy is pretty cool actually and allows you to do a load of tricky things like pre-authentication, use shared accounts as if they were individual accounts, publish local app safely onto the tinterweb. The following walkthrough will show you how to publish the MIM portal through Azure Application Proxy (AAP). The same technique also works for the password registration portal. It’s very similar to the Web Application Proxy by Microsoft but its a lot simpler to setup and maintain and it doesn’t need ADFS (Yay!)

Overview

Get Started!

First lets get MIM using Kerberos only, now there are loads of guides out there but I will just summarize quickly.
Imagine your environment is:
MIM Portal URL: portal.mim.ninja (use an A record its just easier trust me)
MIM Service Account: MIMServ
SharePoint App Pool account: MIMSP
Domain: MIMNINJA

so SPN’s
On the MIMSP account add the SPNassuming tyou entered the correct portal address during installation check the web.config detailed below to check they HAVE to match:
http/portal.mim.ninja so do via ADUC or setspn -x http/portal.mim.ninja mimninja\MIMSP

On the MIMServ account:
FIMService/portal.mim.ninja or setspn -x FIMService/portal.mim.ninja mimninja\MIMServ

On the MIMSP account Set delegation to Kerberos only and select the MIMServ account and the select the SPN we just registered.
On the MIMServ account Set delegation to Kerberos only and select the MIMServ account and the select the SPN we just registered (it delegates to itself).

in the web.config file for your mim portal located at C:\inetpub\wwwroot\wss\VirtualDirectories\XX\web.config (xx being the port normally 80) change the line:

  <resourceManagementClient resourceManagementServiceBaseAddress="http://portal.mim.ninja:5725" timeoutInMilliseconds="60000"/> 

to

 <resourceManagementClient resourceManagementServiceBaseAddress="http://portal.mim.ninja:5725" timeoutInMilliseconds="60000" requireKerberos="true"/>

This forces connections to the portal service to be Kerberos only.

In the file:
C:\Program Files\Microsoft Forefront Identity Manager\2010\Service\Microsoft.ResourceManagement.Service.exe.config

Make sure the following values match your portal address:

 <resourceManagementClient resourceManagementServiceBaseAddress="portal.mim.ninja" />
<resourceManagementService externalHostName="portal.mim.ninja" />

Now I’m not 100% sure whether the following change is absolutely required anymore, but what I do know is that it doesn’t break it so may be best to update it also:
Remove line 10 in C:\Windows\System32\inetsrv\config\applicationHost.config this stops fall-back to NTLM authentication:

    <location path="MIM Portal">
        <system.webServer>
            <handlers accessPolicy="Read, Execute, Script" />
            <security>
                <authentication>
                    <windowsAuthentication enabled="true" useKernelMode="false" useAppPoolCredentials="true">
                        <providers>
                            <clear />
                            <add value="Negotiate" />
                            <add value="NTLM" />
                        </providers>
                    </windowsAuthentication>
                    <anonymousAuthentication enabled="false" />
                    <digestAuthentication enabled="false" />
                    <basicAuthentication enabled="false" />
                </authentication>
            </security>
            <urlCompression doStaticCompression="true" doDynamicCompression="true" />
            <httpErrors existingResponse="PassThrough" />
            <httpProtocol>
                <customHeaders>
                    <clear />
                    <add name="X-Powered-By" value="ASP.NET" />
                    <add name="MicrosoftSharePointTeamServices" value="16.0.0.4327" />
                </customHeaders>
            </httpProtocol>
        </system.webServer>
    </location>

Now run iisreset and net stop/start fimservice and try and access your portal it should load ok if you get the generic fim service error then you would have got one of the steps wrong above, if it works ok you can run klist at a command prompt and you should see a Kerberos ticket for your portal url in our case portal.mim.ninja. You cannot go any further until KCD is working in the MIM portal.

Great so everything working using Kerberos? well lets go ahead and start to setup AAP…You will need:

A Microsoft Azure AD basic or premium subscription and an Azure AD directory for which you are a global administrator.
A server running Windows Server 2012 R2 or 2016, on which you can install the Application Proxy Connector. The server needs to be able to connect to the Application Proxy services in the cloud, and the on-premises applications that you are publishing.
For single sign-on to your published applications using Kerberos Constrained Delegation, this machine should be domain-joined in the same AD domain as the applications that you are publishing. For information, see KCD for single sign-on with Application Proxy.
Follow this guide to get started, I can’t be bothered pasting all the menial stuff! Come back here when you’re finished ūüėČ

This last point is key for us we have just done it!
Follow the guide here until you get to the publish application part below:

This how would be filled in for us, pick whatever url you like if its a custom domain it needs to be added to Azure to work and DNS updated accordingly but you are probably best getting it working first then changing the url later.

SSO
Now follow the guide again here and when you get to the configuring the Kerberos delegation on the AAP connector machine you would put in something like

Make sure that use any authentication protocol is checked rather than Kerberos only.
Keep following the guide then make sure SSO config looks like below for our example:

The delegated login identity will probably be the onsite UPN, obviously you users need an Onsite AD and an Azure AD accounts.

You can have your internal and external URL’s the same, you point your dns to the cname record it gives you on the config page the use your HOSTS file on the connector server to point to your internal portal.

That should be it you can configure conditional access and users and groups if you like or give access to the whole of Azure AD obviously only people with access to the portal will be able to access. Give it a go and experiment. Let me know any feedback!

Keep it Ninja!

FIM/MIM times out or SSL connection error behind Azure Load Balancer

Recently I had been setting up a load balanced MIM Portal solution in the Azure cloud and the setup seemed to work ok, after a while I got reports it was working for some people. It turned out if you were connected via WIFI it worked fine but if you connected via LAN it didn’t…….How bizarre! All the networks, gateways and site to site VPN’s were setup correctly and indeed if you tried to access any of the portal servers directly it worked only access via the Load Balancer was problematic.

The solution ended up being the setting “Large Send Offload” and I will explain why…

I collected the traces both on the Azure Server and my client pc. Initially I saw the 3-way handshake was successful, which means the port is opened and packet is reaching the backend VM. I then noticed that to complete SSL handshake, my client PC sends Client Hello, but never receives Server Hello.
then the Azure Server logs were checked, I noticed that the Server Sends Server hello but with a payload larger than 1350 MTU……but why is that a problem?

Below is the architecture

Azure Server –> Load balancer –> Azure gateway–> Source client PC

When the Azure Sever sends payload greater than 1350 , the Azure gateway sends the Destination Unreachable message to the Load balancer. Stating that it should decrease the Payload and send it again. The Destination Unreachable message is sent to Load balancer, but the load balancer never sends to the Backend VM, because it never knows the packet is for the particular target VM. It always thinks that the packet is for itself. Due to which the target backend VM never reduces the payload and subsequently doesn’t re-send it to the gateway.

Finally the Solution!

‚ÄĘ Go to the Network adaptor
‚ÄĘ Go to properties
‚ÄĘ Click on configure

‚ÄĘ Go to Advanced option and Disable the below 2 options

Disable the “Large Send Offload”
Check the status of “Jumbo frames” also but this usually disabled by default anyway

After disabling those settings everything started working apparently this mechanism is by design, can only be resolved by disabling the above 2 features. Apparently Microsoft are working on making the Azure Load Balancers accept and forward large packets.

Logging for the FIM/MIM Web Services connector and config tool

There is so much information out there about setting up logging and none of it I could get to work, so to that end here is the definitive list of how to get logging working. Please note the difference between logging the Web Services Configuration tool and the Web Services connector itself….

To enable ETW logging for connector, please follow the below steps:

Case 1: When “Run this Management agent in a separate process” checkbox is checked.

Add the below section after the </configSections> tag in dllhost.exe.config file.
File Path: C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\dllhost.exe.config

&lt;system.diagnostics&gt;


    &lt;sources&gt;


        &lt;source name="ConnectorsLog" switchValue="Verbose"&gt;


            &lt;listeners&gt;


                &lt;add initializeData="ConnectorsLog" type="System.Diagnostics.EventLogTraceListener, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ConnectorsLogListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack" /&gt;


            &lt;/listeners&gt;


        &lt;/source&gt;


    &lt;/sources&gt;


&lt;/system.diagnostics&gt;



Case 2: When “Run this Management agent in a separate process” checkbox is not checked.

Add the below section inside the <system.diagnostics>/<sources> section in miiserver.exe.config file.
File Path: C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miiserver.exe.config

Note: There are two <system.diagnostics> sections in miiserver.exe.config file. Please make sure to add the below section under <system.diagnostics> section which appears first.


<source name="ConnectorsLog" switchValue="Verbose">


    <listeners>


        <add initializeData="ConnectorsLog" type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ConnectorsLogListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack" />


    </listeners>


</source>


To enable ETW logging for WS Config tool, please follow the below steps(new method):

Log level is resolved from the tool’s config file WSConfigTool.exe.config which is located under C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\UIShell\Web Service Configuration:

Initially after installing the tool the below section is commented out so user needs to uncomment this section as shown below:

 


<!--Uncomment system.diagnostics section to enable the event viewer logging for the WS Config tool, other listeners can also be added like TextWriterTraceListener, XmlWriterTraceListener etc.-->


<system.diagnostics>


  <sources>


    <source name="WSConfigToolLog" switchValue="Verbose">


      <listeners>


        <add initializeData="WSConfigToolLog" type="System.Diagnostics.EventLogTraceListener, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="WSConfigToolLogListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack, ProcessId, ThreadId" />


      </listeners>


    </source>


  </sources>


</system.diagnostics>

 

If you don’t see the section above in the WsConfgTool.exe.config file it means you are working with an older version of WS Connector so in this case please follow the steps below:

Web Service Configuration Tool Logging(old method)

By default, Web Service Configuration Tool logging is disabled. In order to turn ON logging, one should perform following operation:

1.     Open file FIM_INSTALL_DIR\Synchronization Service\ UIShell\Web Service Configuration\ WSConfigTool.exe.config

2.¬†¬†¬†¬† Goto the “LoggingLevel” section and change the value to 2 or 3.

Logging level section:

<setting name=”LoggingLevel” serializeAs=”String”>

<value>0</value>

</setting>

3.     The different logging values represent the following:

a.¬†¬†¬†¬† Value 2 ‚Äď High logging ‚Äď High important events (e.g. Exceptions) are logged.

b.¬†¬†¬† Value 3 ‚Äď Verbose logging ‚Äď All the activities performed are logged.

c.     Any other value than the above represents logging disabled.

4.     Save the changes.

Log file is written to folder:  C:\ProgramData\WebServiceConfigTool

Log file name: WebServiceConfigTool.log

After you have enabled the connector logging, please follow these steps :

  1. Clear the Application log.
  2. Creating a new connector  Copy all the logs in a separate file  Clear the logs.

 

If you get the error “The configuration section cannot contain a CDATA or text element” then try removing all the spaces in the xml pasted and re-insert them. White spaces from the web turn out to be not so white sometimes……