Share via

SharePoint Server and Web Application Proxy – continued

  • Article

So having played around with the Windows Server role “Web Application Proxy” a lot more recently after some initial testing. I’ve learnt a few more things about the two working together that I thought worthy of sharing. Windows Web Application Proxy (WAP for short) is a great way of protecting SharePoint from being exposed directly to the internet at large – it’s not as feature-complete as TMG Server, but it’s a nice wrapper that’s very simple to setup & secure.

Specifically I wanted to focus on the two different ways Web Application Server can be used to front authentication to SharePoint…

SharePoint Authentication Methods – Claims/ADFS or Windows

There’s two modes SharePoint can be used in conjunction with Web Application Proxy + ADFS, depending on how you’ve got SharePoint setup. If you have ADFS already configured in SharePoint you can use Web Application Proxy in claims-aware mode; just selecting an ADFS relying-partner that’s not claims aware is all you have to do, at which point WAP will assume the backend is Kerberos.

In either mode the ADFS server will be used for user logins & authentication for the proxy endpoint; the only difference is how Web Application Proxy validates you on the backend, transparently to the user. Either it’ll pass the token directly to the claims/ADFS SharePoint website or it’ll convert it to a Kerberos ticket for Windows authentication.

Windows Authentication SharePoint Backend

This mode should be used when you want to keep your Windows authentication in SharePoint without migrating to claims and is the most complicated to setup. It needs the WAP server on the same domain SharePoint servers are on, Kerberos configured & working for SharePoint HTTP, and each WAP server needs Kerberos configured too.

This means:

  • SPNs for the external address given to each WAP server machine account.
    • In my example I have proxy.contoso.com for my external address so each WAP server needs HTTP/proxy.contoso.com in the list of service-principal-names.
  • Constrained delegation needs to be enabled for the SharePoint application SPN.
    • Each WAP machine account needs to delegate to SHAREPOINT\svc_app_pool in my example, which has the internal SPN of HTTP/sp15.

Note: NTML doesn’t work for WAP back-ends – it has to be a valid & working Kerberos configuration to the front-ends from the WAP server. I say “valid and working” because it’s possible if you have Kerberos “configured” and WAP doesn’t work that in fact Kerberos wasn’t fully configured and connections were falling-back to NTML for user sessions. Well, this isn’t possible with Web Application Proxy – Kerberos must be fully working if SharePoint is to work with non-claims.

Claims-Aware (ADFS) SharePoint Backend

In this mode WAP let’s ADFS login, the redirects back to the WAP URL with the authentication cookie set just like a normal ADFS login. This is much simpler than a Windows authentication back-end because there’s no conversion needed from the ADFS claims -> Windows token; SharePoint just accepts the ADFS token directly and it all just works.

Another benefit to this mode is that because we’re not delegating Windows identities the WAP server(s) don’t need to be on the same domain as SharePoint, so it’s arguably more secure. The argument being of course that compromising the edge servers won’t get you any closer to domain access, which is true, so there’s that too.

Use Single Authentication-Method Endpoints for WAP-SharePoint Back-ends

Whichever way you configure WAP server, either claims or not, the endpoint that WAP redirects traffic to must have exclusively the same authentication method configured that’s expected for the WAP server.

That’s to say that if proxy address is claims-aware/ADFS then the SharePoint site & zone that the proxy sends to should only and exclusively be configured for the same ADFS provider. Equally, if the proxy endpoint is non-claims aware, the endpoint that WAP sends traffic to should only have Kerberos authentication configured.

In fact, if your Kerberos site also has other authentication methods enabled too then the whole thing breaks. For ADFS sites however, if you don’t have the target zone configured like this:

clip_image001

…after logging into ADFS, users will see this:

clip_image002

Single authentication methods only for internal WAP URLs to avoid this.

Setup Alternative Access Mappings for Web Application Proxy URLs

Finally, SharePoint does need to know about the URLs being used to access the application, both internally and externally. This is only really necessary if the URL being used to access the web application proxy is different to the URL that WAP is redirecting to – if both internal & external URLs are the same then you can skip this bit.

1st, make sure there’s an extranet/custom/whatever zone with the address the web-application-proxy is being accessed on for SharePoint. Then add an internal URL so SharePoint knows how it’s going to be called by WAP.

clip_image004

The URL used has to be added via “internal URLs” pointing at the public zone URL setup for the web-proxy address. In other words, the “extranet” zone is configured for the proxy address (https://spm-webproxy…/) and an internal URL is added for the address WAP is using to forward requests to, pointing at the “extranet” zone. That way SharePoint knows what the “internal” URL is for the outside address, and everything works just fine.

Note: you can’t have a public zone already with the internal address already configured for this internal/external match to work – if you try and add an internal URL that already exists as a public URL then you’ll get an error when you add it.

Anyway, the point is that without this matching perfectly you’ll get errors and specifically with Office, when you try and edit a file, Office is likely to throw its toys out the pram with an “unknown error trying to lock file” error or something similar.

clip_image005

Setup your alternative access mappings correctly and all should work. Also remember that OneDrive for Business will fail to synchronise without AAMs setup correctly.

 

Wrap-up

That’s it! SharePoint with Web Application Proxy both together works great once you know how they fit together. Hopefully this has helped.

Cheers,

// Sam Betts

Comments

  • Anonymous
    August 26, 2015
    Hi Sam, Interesting post as always. In your point "Use Single Authentication-Method Endpoints for WAP-SharePoint Back-ends" you advise to not use the windows authentication, doesn't this mean that you can't crawl the web app anymore, or is there a workaround for that ? Greetings, JP Belgium

  • Anonymous
    April 08, 2016
    Great post !! You made it look so simple :D