3rd of July, 2013 / / 51 Comments

==================
Updated: 10 September 2013

==================
Updated: 15 July 2013

  • I have heard from a member of the Web Application Proxy product group who said there is a bug in the Preview version that prevents Outlook Anywhere from working. They say it will be fixed in the RTM version
  • Lync 2013 and  Office Web Apps 2013 have been tested and work with some configuration changes. See http://blog.kloud.com.au/2013/07/15/publish-lync-2013-with-2012-r2-preview-web-application-proxy/ 
  • ActiveSync does not support SNI so a default binding needs to be set on the Web Application Proxy as per the post above to make it work
  • Clarification about ADFS being a hard requirement for the Web Application Proxy, even if only doing pass-through
  • Clarification about modifying published applications
  • Clarification about case sensitivity

==================

The announcement from Microsoft TechEd North America early in June that got me really interested was the Windows 2012 R2 Web Application Proxy which was described as:

Web Application Proxy – The Web Application Proxy is a new role service in the Windows Server Remote Access role. It provides the ability to publish access to corporate resources, and enforce multi-factor authentication as well as apply conditional access policies to verify both the user’s identity and the device they are using resources, and enforce multi-factor authentication as well as verify the device being used before access is granted.

The Web Application Proxy is a reverse proxy and ADFS (Active Directory Federation Services) Proxy that also provides functionality like Workplace Join for Windows 8.1 using the Device Registration Service (DRS). I have a particular interest in the reverse proxy side having done a lot of work with UAG lately which makes me miss TMG! As discussed in my previous blog Publish Lync 2013 Including Mobility and Office Web Apps with UAG 2010, with TMG disappearing the only Microsoft product (other than IIS with ARR) with reverse proxy functionality is Microsoft Forefront UAG (Unified Access Gateway).

UAG development seemed to have slowed down and the latest Service Pack added support for Exchange 2013 and SharePoint 2013 but not even Lync 2013 that came out at the same time. No word has been heard about any future development and with people like Erez Ben Ari (Ben Ari on TechNet) moving to the IIS team it seems like the writing is on the wall for Microsoft’s Forefront TMG and UAG products. UAG is a very powerful product but is hamstrung by its legacy roots in e-Gap and IAG and reliance on TMG underneath. TMG is not supported on Windows 2012 so if it was to move forward a total rewrite would have been needed.

In this blog I cover a bit about the Web Application Proxy and show how to configure ADFS, the Web Application Proxy and publish a claims-aware test application. I also did some testing with publishing Exchange 2013 to see how it worked.

TechEd Sessions and Documentation about Web Application Proxy

A session at TechEd North America titled Enable Work from Anywhere without Losing Sleep: Remote Access with the Web Application Proxy and VPN Solutions showed off some of the functionality (video and slides available at the link) and the same session at TechEd Europe last week WCA-B333 came out with a lot more information that I only saw after I started testing unfortunately. There is now a single TechNet page dedicated to the Web Application Proxy http://technet.microsoft.com/en-us/library/dn280944.aspx

Web Application Proxy Functionality

The Web Application Proxy (WAP) is a Role Service under the Remote Access role of Windows 2012 which also includes DirectAccess, VPN and routing services. It can provide simple reverse proxy functionality using ‘Pass-through’ where no preauthentication is performed, or provide Active Directory Federation Services (AD FS or ADFS) authentication by performing the ADFS proxy function. Note that even in Pass-through mode, WAP needs a Windows Server 2012 R2 Preview ADFS farm and must be setup as an ADFS Proxy. Without ADFS you can’t even complete the configuration wizard. Pass-through and ADFS federation to claims aware applications can be performed like previous AD FS proxies as a workgroup machine in the DMZ.

The reverse proxy functionality that seems like it could be a TMG/UAG replacement is the ability for the WAP to provide preauthentication for non-claims aware backend applications. It takes ADFS authentication and initiates a new session to the backend server providing Single Sign On (SSO) across multiple backend applications. This was possible with UAG by modifying applications to use the Claims to Windows Token Service (C2WTS) as described in Access OWA with ADFS, but the promise of this new functionality is that no modification is required on the backend service.

The catch in this scenario is that the WAP can only provide preauthentication and backend authentication to non-claims aware applications published with Integrated Windows Authentication (IWA) using Kerberos. No IWA with NTLM or basic authentication support. NTLM and basic are supported in Pass-through mode only. So this is not a full UAG/TMG replacement for applications such as Exchange that typically would have preauthentication performed by the reverse proxy. Slide 9 from the Europe WCA-B333 session mentioned above, shows the preauthentication support.

In my testing though, it wasn’t as simple as this as NTLM and Basic did not work for rich clients – even in pass-through mode (Update: for ActiveSync this is fixed by adding a default SSL binding as ActiveSync does not support SNI) . Slide 40 on the same presentation states that UAG will still be supported until 2015. Additionally it says that the Web Application Proxy is ‘part of a broader BYO Access platform alongside AD, AD FS, Intune’ and ‘We are not building all of UAG functionality into Windows Server’, so it looks like Web Application Proxy may not be a total replacement for UAG.

Exchange 2013 Testing

There is very little documentation right now for the Web Application Proxy so the following are my observations and assumptions based on testing Windows Server 2012 R2 Preview in Windows Azure. That meant I could only have a single network card (a restriction of Azure) and I don’t know if that would change any functionality (as it would for TMG and UAG).

ADFS and KCD Requirements

The first important thing to note is that any preauthentication or ADFS proxy functionality requires Windows Server 2012 R2 ADFS on the backend. So for anything other than Pass-through, ADFS is a hard dependency. It was mentioned that the recommendation now is to run ADFS on a domain controller and ADFS seems to be taking over as the primary authentication mechanism for all Windows applications. Additionally a schema upgrade will be required to support all of the device registration functionality.

The second important thing to know is that in order to do preauthentication to backend applications, the WAP must be domain joined as Kerberos Constrained Delegation (KCD) is required. In the past ADFS proxies were not domain joined and the WAP can act the same way as long as KCD is not needed.

Setup ADFS

Setup a Domain Controller and add the ADFS role. Add a ‘Non-Claims-Aware Relying Party Trust’ for the Exchange CAS or CAS Array as can be seen below.

For the Issuance Authorization Rules, either ‘Permit All Users’ or you can limit who can authenticate through ADFS (and the Web Application Proxy) using Active Directory attributes. In this example I have created an AD group that allows access through the WAP. In the Issuance Authorization Rules, specify ‘Permit or Deny Users Based on an Incoming Claim’, specify ‘Group SID’ and select the relevant group. This allow the full flexibility of ADFS claims rules which can include specifying IP subnets, whether people are coming through the ADFS Proxy and many more.

Setup Web Application Proxy

Join the computer to the domain and install the Remote Access Role, and the Web Application Proxy Role Service.

Import the ADFS public certificate and any other certificates required for publishing. As with Server 2012, 2012 R2 supports Server Name Indication (SNI) which was covered previously on the Kloud blog An Overview of Server Name Indication (SNI) and Creating an IIS SNI Web SSL Binding Using PowerShell in Windows Server 2012. This allows multiple certificates to be used on a single IP and port combination, which is a great improvement over TMG and UAG.

Start the Web Application Proxy configuration wizard and setup the server as an ADFS proxy.

Publish an ‘Active Directory Federation Services (AD FS)’ application

Specify the Relying Party from the list of enabled Relying Parties configured on the on-premise domain joined ADFS farm server.

Setup the external and internal URLs and SPN for the internal web server. The publishing can either be a specific path or the whole server, however unlike TMG there is no ordering of applications so if you publish a whole server you cannot add a sub path as a higher rule. In this case I have published Exchange OWA and ECP as separate applications.

Note the warning at the top about the external and internal URLs not matching. That help topic is not live so I do not know what problems can arise, but this is probably for applications like SharePoint 2013 with Host Name Site Collections that require the external and internal URLs to match. And this is where you see the benefit of a modern reverse proxy – it shows you the PowerShell commands to create the application. Also make sure to add the trailing ‘/’ on both the external and internal URLs or it will complain.

For the ECP application I can create it with PowerShell:

[sourcecode language=”powershell”]Add-WebApplicationProxyApplication -BackendServerAuthenticationSpn ‘http/marc-exchange1.marc.kloud.com.au’ -BackendServerUrl ‘https://marc-exchange1.marc.kloud.com.au/ecp/’ -ExternalCertificateThumbprint ‘F7F6B300FE4D569FD598E1C9722571CF9AD780DD’ -ExternalUrl ‘https://mail.marc.kloud.com.au/ecp/’ -Name ‘Exchange ECP’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘Exchange’
[/sourcecode]

The final task is to setup KCD to allow the WAP to impersonate the user and obtain a Kerberos ticket to access the Exchange CAS. This is done by editing the WAP computer object and allowing delegation to the Exchange CAS SPN, or CAS Array Alternate Service Account user or computer object. A PowerShell function for this is provided in my previous blog post Outlook Anywhere NTLM SSO with UAG 2010 KCD

Testing Web Clients

Browse to the OWA URL e.g. https://mail.marc.kloud.com.au/owa/ which redirects to

https://adfs.marc.kloud.com.au/adfs/ls?version=1.0&action=signin&realm=urn:AppProxy:com&appRealm=d2b07cee-c3e0-e211-af1e-00155d53e448&returnUrl=https://mail.marc.kloud.com.au/owa/?bO=1

Logging in with a domain user who is not a member of the ‘WAP Allowed’ group gives a friendly error:

While a user who is a member of the group gets OWA

Testing Rich Clients

In order to test Outlook Anywhere and ActiveSync rich clients, instead of creating separate applications for RPC, OAB, Autodiscover and Microsoft-Server-ActiveSync applications I published the whole server https://mail.marc.kloud.com.au/ as a test. This meant that Outlook couldn’t even get autodiscover as it doesn’t understand ADFS authentication. So back to separate applications and added autodiscover and RPC for Outlook Anywhere as Pass-through applications

This allowed a new Outlook profile autodiscover to work but Outlook just hangs on the ‘Logging on to the mail server’ for a few minutes and fails to connect.

I tried to change the Exchange internal and external URLs to be same to make sure the lack of body rewriting in WAP wasn’t causing the problem. I published the root of the server https://mail.marc.kloud.com.au/ and autodiscover https://autodiscover.marc.kloud.com.au/ in Pass-through mode but still could not get Outlook Anywhere or ActiveSync to work initially (Update: ActiveSync does not support SNI, so in order to make it work a default SSL binding must be added as mentioned in my post about Lync Publish Lync 2013 with 2012 R2 Preview Web Application Proxy). Possibly this is something in my configuration as according to the slide above, NTLM and Basic authentication should just work in Pass-through mode. If somebody else gets Outlook Anywhere to work, please let me know. (Update: according to a member of the Web Application Proxy product group there is a bug in the Preview version that prevents Outlook Anywhere from working. They say it will be fixed in the RTM version).

Testing Claims Aware Applications

Just to round out the testing, I used the WIF SDK 3.5 sample claims app ‘PassiveRedirectBasedClaimsAwareWebApp’ and configured it on a Windows 2012 R2 server using the process described in the ADFS and SSO lab setup guide. Create the Relying Party Trust as described in the documentation.

On the Web Application Proxy, add an ADFS preauthenticated application based on the ‘Claims App’ RP and configure the external and internal URLs

The end result is the published application:

WAP applications

Logging on from an external client shows the claims that the client has in the ADFS security token.

Opening other ADFS preauthenticated applications provides SSO as the client has a valid ADFS cookie and a valid Web Application Proxy cookie.

My Thoughts

This is a preview release that is probably 6 months out from final release, so many things may change before RTM. With very little documentation I am guessing my way through some of the scenarios and configuration, so don’t take this a final analysis of the product.

The Good

  • Single server for ADFS Proxy, Reverse Proxy, DirectAccess and VPN
  • Totally PowerShell enabled and integrated into Windows
  • Server Name Indication (SNI) support to provide a single ‘listener’ with multiple certificates
  • Not based on IIS
  • Stateless server with centralised ADFS configuration
  • Provides new solutions like Workplace Join to enable work from anywhere and long term persistent SSO for authenticated and authorised devices
  • Multi Factor Authentication (MFA) looks easy to define, but I couldn’t test it now

The Different

  • Windows 2012 R2 Preview ADFS farm is required to install Web Application Proxy
  • Cannot be an ADFS proxy for a previous ADFS version
  • Non-SNI compatible clients like Lync mobile and Exchange ActiveSync require additional configuration on the Web Application Proxy to support them
  • Case sensitive and requires trailing / for path based application publishing. https://mail.marc.kloud.com.au/owa/ does not equal https://mail.marc.kloud.com.au/OWA/ This isn’t an issue if you publish the root of the server. This is consistent with the web standards and Unix/Linux web servers that are case sensitive. It is a departure from IIS and TMG which do not care about case

The Bad aka ‘Hopefully will be added or fixed’

  • No Basic or NTLM preauthentication
  • Hard requirement on ADFS, even if only doing Pass-through
  • Pass-through not allowing Outlook Anywhere to work – may just be me!
  • No SSO for non-ADFS published applications. Pass-through applications each do their own authentication
  • No ability to edit published application on the WAP server in the GUI. This can be done from PowerShell only. See http://technet.microsoft.com/en-us/library/dn283404
  • No external HTTP to HTTPS redirect, or HTTP publishing
  • Descoped the full URL translation like IIS ARR can do in this release. Header translation only, not body translation
  • Exchange Outlook Anywhere is not supported with preauthentication. Planned to support in a future version
  • No built in outbound load balancing to the backend servers so it requires a load balancer. TMG and UAG can provide this currently even if it isn’t used much. This support would remove a barrier to entry for some smaller companies

I would also like to see the ability in the console and WAP PowerShell cmdlets to set a default SSL binding certificate for non-SNI supported browsers so it doesn’t have to be done via netsh.

Category:
ADFS, Communication and Collaboration, Exchange
Tags:
,

Join the conversation! 51 Comments

  1. Tyler H

    Great article. I’m looking at deploying IIS8/SNI/ARR for a reverse proxy but I love the preauth capability with WAP. Speaking of SNI, this seems like a great way to free up public IP addresses. Do you know if SNI is supported by Office 2010 and 2013 applications? Mostly considering Outlook and Lync. I’d like to publish ADFS, Exchange, and Lync (with three different certificates) all on a single public IP.

    • Marc Terblanche

      I can’t find any official statement on support for SNI in Outlook or Lync. However if you look at a Fiddler trace in the Inspectors / TextView / Extensions you will see that server_name is sent by Outlook and Lync. Wireshark can also show you this in the TLSv1 Client Hello. I am testing Lync at the moment and it looks good. As I mentioned above Outlook and ActiveSync weren’t working for me.

      • Marc Terblanche

        SNI is supported by the full clients, but not by the mobile clients. Lync mobile and Exchange ActiveSync require a default SSL binding be applied. See the other post on publishing Lync for the SNI fix.

  2. rzomerman

    hmmm so far.. direct publication works.. ADFS – > An Error has Occurred.. any idea where to find more logging?

    • Marc Terblanche

      You can start by trying to connect to the published site from the WAP server to check DNS and certificates are valid. If that works, look in the Event Logs Microsoft-Windows-WebApplicationProxy/Admin and ADFS/Admin. Also check ADFS log on the ADFS farm server.

      You can enable analytic and debug logging in Event Viewer to get ETW tracing.

      • Jason Bailey

        Hi Marc, I’m hitting this error on the RTM version and despite combing all logging I’m at a loss. My next option is to reinstall my whole test domain in US-EN as I’ve dealt with that several times before. I have some error messages but they have zero results on google. Any assistance appreciated. My email address is associated with the post, as I’m from Aus I appreciate it will be Saturday morning when you get this.

      • Marc Terblanche

        You didn’t mention which problem you saw. I was using en-AU but languages can cause problems. I would start with checking you can auth with ADFS directly using the /adfs/ls/idpinitiatedsignon.aspx page. Then check KCD is setup correctly. There is a way to do advanced ETL tracing but I haven’t seen how to do it.

      • Jason Bailey

        Hi Marc, apologies, ended up being a typo in a hosts file. Too much Johnnie Walker Black on a very long couple of days. Thanks for responding.

  3. Georgi

    Great article. After setting up the ADFS server and WAP server I am getting double prompts for OWA. I am prompted for ADFS creds and then prompted for Exchange creds. I have the Kerberos settings in place for WAP to delegate to exchange. Are there any other settings I should check?

    • Marc Terblanche

      Did you change the authentication on the OWA and ECP virtual directories from FBA to integrated? Are you getting a form or a popup?

      • Georgi

        I did not change the authentication. Thanks for that tip.

        Internally I am getting the windows auth popup window. That’s too be expected correct?

      • Marc Terblanche

        Yes, that is expected internally. Externally you should just get the ADFS logon page and get access to OWA.

  4. rayc25

    Thanks for sharing your experiences. I personally had issues with ADFS because there is a bug when the timezone is set above GMT.

  5. Reto

    Great article. Is this setup only supposed to work on a native W2012-R2-Environment? I’ve installed the W2012-R2-DC to an existing W2k8-R2-Lab-Environment (on-premise) and end up with event id511/364. And does the setup rely on publishing ADFS externally?

  6. Brian G

    I’m wondering if you can use this to allow client certificates with ActiveSync on Exchange 2013. Currently with 2010 we use TMG + KCD to do this, but it doesn’t work with Exchange 2013 ActiveSync. I was reading in the Exchange Blog that they removed KCD support for who knows what reason. Have you done any testing with that to see if it works? It’s really the only thing preventing me from moving forward with Exchange 2013 at this time.

    • Marc Terblanche

      You can’t do client certificate authentication with the 2012 R2 Preview but they did indicate it was coming in a future release. Whether that means 2012 R2 RTM, or in a later update isn’t clear. With ActiveSync now you can only do pass-through authentication.

      2013 must support KCD as that is how the WAP/ADFS pre-authentication works for OWA and ECP as they are not claims aware. This Exchange Team blog http://blogs.technet.com/b/exchange/archive/2012/11/21/publishing-exchange-server-2013-using-tmg.aspx mentions that KCD is not supported ‘at this time’, but I can’t find any other reference to it.

  7. Robert Pen

    Hi there,

    for some time I have been struggling to publish Apps by using the UAG service. I also looked at the new Windows 2012 features you describe in the article. My problem is: we want to create a SSO environment for the SharePoint Farm for users who enter from outside the firewall. Microsoft invented the nice and secure system of creating isolated app-domains to prevent crosssite scripting when a user uses an App in SharePoint. The result is, that when a user adds an app to the site, a new unique hostname will be generated, like: .appsmyorg.com. the sharepoint site (hostweb) itself has the hostname sitename.myorg.com. This introduces two problems when looking at the configuration of the UAG server:
    1. how can we publish all hundreds of apps with unique hostnames through UAG or Reverse Proxy in 2012? Because when we publish it , we are required to enter a hostname, but since we don’t know the hostnames of all apps added by our users, we have a problem with this. So what we need is some kind of publishing rule in UAG which accepts a wildcard hostname like *.appsmyorg.com and forwards those requests to the SharePoint farm (we can of-course use a wildcard certificate here to facilitate the SSL channel)
    2. if we can realize step 1, how can we apply sso with UAG or Windows 2012 reverse proxy so that users can use ONE ticket to access the *.appsmyorg.com and *.myorg.com domain. Of course we can use Kerberos impersonation, but that won’t work for all the apps, because we then have to enter all the SPN names of dynamically created apps to the service account of sharepoint web application in Active Directory. What is left then, is the possibility to use Claims Based Authentication in SharePoint and setup a trust with the UAG , windows 2012 proxy, and ADFS server. What do you think about this suggestion?

    I am curious about your reaction on this issue. seems to me that SharePoint moved a great step forward by using isolated app domains, but someone forgot about the consequences on firewalls. As far as I can see, you can’t publish a wildcard hostname to cover all the apps on sharepoint in an UAG application.

    kind regards,
    robert pen

    • Marc Terblanche

      You are right, UAG will only publish sites within the same domain as the trunk name and will not allow sites underneath that domain or a wildcard entry. You could add each application individually but it isn’t really scalable. Web Application Proxy will not let you publish a wildcard site name like *.appsmyorg.com. You could run a script to check when an application is created on SharePoint and create a publishing rule on WAP.

      I haven’t used the SharePoint isolated app domains, but it doesn’t fit well with reverse proxy that are designed to only allow site names that you specify.

      • Robert Pen

        Hi Marc,
        thanks a lot for your reply. I thought I was going mad but it really is true: there is no support for this in Microsoft products like UAG and reverse proxy 2012 -> people get exited on the new app framework of SharePoint but no one tells them that you can’t use uag or reverse proxy (recommended products to publish SharePoint 2013 in a safe way) to use this in a manageable and scalable way.
        The next thing I can think of is publishing the known hostnames by using UAG or reverse proxy of 2012, use adfs to arrange claims and when an app is clicked, the browser navigates to a Nat device publishing the ip of the sharepoint apps domain. then when user opens the app, claims based authentication is used and hopefully the user can use the same ticket just required when entering the SharePoint portal. In worst case, the user must login again on adfs.

  8. Thomas Fewn

    Great article, do you have any expierence with SSO between different subdomains?

    If we would do pre-authentication for x.domain.com and y.domain.com and the users signs in for the url x.domain.com and then wants to visit y.domain.com: Would he get the adfs login form again?

    Thanks,
    Thomas

    • Marc Terblanche

      I haven’t tried it with multiple preauthentication applications. Publishing x.domain.com and y.domain.com should will work as you will have an authentication SSO cookie for ADFS and that is essentially what happens when you authenticate to ADFS and access another application. I am not sure about publishing http://www.x.domain.com and http://www.y.domain.com as they are on different domains but I would expect it to work.

  9. Ian Morrish

    Another limitation, if you want to publish SharePoint 2013, Wildcard domain is required for SharePoint hosted apps.
    “Web Application Proxy does not support wildcard domain publishing. That is, you cannot configure an external URL using a wildcard; for example, https://*.contoso.com.”

    So you would have to publish every hosted app URL.

    • Marc Terblanche

      This was discussed in the comments above in September. It is setup to only accept traffic for FQDNs and paths that have been defined by the administrator and UAG is not supported for app domains for the same reason. In fact the SharePoint documentation I saw in a quick search does not seem to even mention reverse proxy or external publishing other than in SharePoint hybrid situations where it says TMG is the only supported reverse proxy and specifically says UAG is not supported. This was before WAP came out, but also after TMG disappeared as an option.

      As mentioned above, you could theoretically export app domains from SharePoint and create the new ones on WAP. It isn’t a very clean solution, but it should work.

  10. turbomcp

    Hi Mark
    I found your blog by mistake asi am searching how and does ADFS and WAP support smart card login pre-authentication(that im currently doing with TMG)(users login with smart card only to access owa)
    awesome stuff just awesome.
    one question:
    will it support the same scenario? what do I need to change? just change authentication to integrated?
    Many thanks
    and awesome job again, I cant say this enough:)

  11. Matt

    Excellent blog post Marc, thanks so much for everything you have put together around WAP! I have a question though. I have deployed this in my test environment with Exchange 2013 and everything seems to be working great, but I do have a question related to how the OWA Url is handled. So in my WAP, I created and published a rule just like you did in your blog post for OWA. External URL is https://webmail.domain.com/owa/. What if we want our end users to just access a simplified OWA url, like webmail.domain.com? Right now if an external user go to webmail.domain.com they get a 404 page not found, I assume because the WAP is listening for webmail.domain.com/owa, not webmail.domain.com? I can’t publish a rule just for webmail.domain.com because that type of rule conflicts with my other rules for Exchange.

    I’m using a KEMP VLM100 behind the WAP, so my internally connecting clients go right to the KEMP (not to the WAP) and dont have the simple url problem. So my issue is only an issue for users connecting externally that go through the WAP. Any pointers would be appreciated.
    Thank You!

  12. Marcel

    Hello Marc,
    Thanks for this article. I was able to setup OWA through WAP and ADFS. It works fine when connecting from the internet. When I try to use it internally, I get the ADFS logon page with an error. In the eventlog of the ADFS server are 2 entires Event 511 and 364. I point my internal DNS A records for OWA to the WAP proxy server. Any ideas? Thanks.

  13. asichel

    Hello, thx for this post.
    I had Setup ADFS & WAP for Exchange 2013 in a Testlab. Outlook Anywhere and Autodiscover works fine. Also OWA and ECP. EWS VirtualDirectory is Setup to Basic Authentication. MailTips and OAB download in Outlook Anywhere don’t work. Any Idea?

    • Marc Terblanche

      Those are both EWS related. You will need to enable WindowsAuthentication on the WebServicesVirtualDirectory. This is what it looks like on a working example
      [PS] C:\Windows\system32>Get-WebServicesVirtualDirectory | fl internalau*, externalauth*, windowsau*
      InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
      ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
      WindowsAuthentication : True

  14. Igor Bekerman

    Hi Marc, grate post.
    I have set the the ADFS and the WAP as mentioned in your post, when i hit the adfs page and enter my credentials i get the http 500 error when trying to get the owa page.
    any ideas?
    Thanks

  15. MartinZ

    Nice article – thanks! I have two questions, hopefully you might have some insight.

    1) When you Publish a web application on a Web Application Proxy, is there a way to tie the published app back to a Issuance Authorization Rules (or any claim rule). That is to say, if I publish URL1, URL2 and URL3 – can I create a Claim Rule that only allows access to URL1 if in ADS\Group1, and access to URL2 if in ADS\Group2…etc ? I know how to make the Claim rule, but I’m not sure how to tie it to the Published Application (verses the whole ADFS/WAP).

    2) Since the WAP is Internet facing, is there any logging? I haven’t been able to find anything beyond an operation log (software events).

    TIA

  16. Dan Davies

    I get a HTTP 500 error for OWA and ECP after logging in to ADFS , any ideas?

Comments are closed.