I need a guide for SP2016 on prem setting up WAP and ADFS

[Benjamin Bartels]

I have a typical SP2106 on prem site as an intranet and would like to set up Web Application Proxy to allow external employees to access the SharePoint system.  The ADFS and WAP servers are established and are unique to this SharePoint project (no other web apps).  I find several web references to various aspects of setting up the adfs, wap, and SP2016, but several seem to be for older versions and the instructions don't match what I'm seeing during the setup process.  

Is there an online guide that helps me fit these components together in an easy to follow format?

[#2]

It's a simple process, but to start with, are you going to use SAML on your SharePoint Web Application(s) or are you going to use Windows auth (NTLM or Kerberos) instead? I prefer the latter myself.

[#3]

We're using Windows Auth with NTLM (not Kerberos).  

I didn't think SAML was available on 2016.  It's also my understanding that 2016 is claims based authentication only.  But, whatever...  We also saw an article that lead us to believe that we may have to set up SP2016 with Trusted Identity provider.  I did this in the past with a 3rd party provider and hope to not have to do it with WAP.

Questions we ran into:

1) From the WAP side, do we provide access via passthrough or ADFS pre-authenticated?

2) I've seen articles showing that you have your LAN intranet access (inet.company.com).  And when you WAP your external access, you have to have a different subdomain (enet.company.com) via alternate access mappings.  Is this the case?  Can't my external portal be the same subdomain as internal (provided that the DNS entries are correct)?

| It's a simple process...

I'll let the team now.  ;)  We've been sort of banging our heads against the wall here.

[#4]

SAML is a form of Claims, and yes it is available but comes with some UX issues (namely the People Picker will resolve any value you put into it, though that's solved by solutions like http://ldapcp.com/).

Anyhow, you still must join WAP to the domain, configure Kerberos on the SharePoint Web Application and implement KCD between WAP and the SharePoint service account(s). That's outlined on a post I created years ago at https://thesharepointfarm.com/2014/02/sharepoint-and-the-web-application-proxy-role/.

As for authentication, it will be ADFS Pre-Auth.

For URLs, no you don't have to have a different URL as long as the FQDN is resolvable from the outside world (which would point to the IP for WAP).

[#5]

have you considered getting a SPOnline tenant and connecting that in a hybrid configuration with your 2016 farm? this would allow you to easily collaborate with external users without adding any additional infrastructure.

[#6]

External *employees* ;) Putting WAP (or any pre-auth reverse proxy) in front of on-prem resources is a good security measure.

[#7]

The company will not utilize resources (O365) outside of our firewall.  Too parinoid.

[#8]

Are you running Advanced Threat Analytics (or something similar) to analyze your network for suspicious behavior. If not, you may want to take a look at https://docs.microsoft.com/en-us/advanced-threat-analytics/what-is-ata

[#9]

Hi Everyone. My name is Carl and I am working with Benjamin who started the post earlier.

We would like to allow external access to our on-prem SharePoint 2016 on Windows Server 2016.

We have a Windows Server 2016 system configured for WAP setup in a DMZ.

We also have a Windows Server 2016 system with ADFS 4.0 on our LAN.

We would prefer not to join our WAP server to the domain.

What are the methods for WAP and ADFS to do this?

If we are using WAP and SAML to pre-authenticate external access can we still use WIA for internal users?

[#10]

You can either use WIA which requires joining WAP to the domain or use SAML which does not require joining WAP to the domain. To SharePoint, even with the same User object in Active Directory, a user is different if using Windows or SAML. There is no way to "attach" the user objects together.

I'd strongly suggest converting all Web Applications to SAML should you choose to use SAML. Mixing WIA and SAML generally doesn't work out too well. This will also prevent duplicate User Profiles (one Windows Claims, the other SAML) which can lead to failures in OAuth-based applications such as Workflow Manager.

And of course there are user experience issues with SAML, such as resolving anything typed into the People Picker. Tools like LDAPCP help with this, but IMO the experience still isn't as good as WIA.

[#11]

I would like to know more about the negative user experience you get when using SAML. I noticed this warning in a few other threads as well.

Do you know any blogs/resources that discuss these issues?

BTW - I'm just a generic IT person who is trying to help the actual SharePoint guy get what he needs. 

[#12]

Generally it surrounds the People Picker. As there is no source of truth to work off for SAML, the People Picker will accept any value, unlike when using NTLM/Kerberos. One must also change the UPSA to leverage the identity attribute sent via SAML. MMS also has special considerations with regards to migration of permissions, e.g. https://technet.microsoft.com/en-us/library/dn745644.aspx?f=255&MSPPError=-2147217396#MMS.

[#13]

I can understand the people picker issue.  I also wondered, if a SharePoint 2016 site were converted from WIA to SAML, are all of the internal references to users (like item lists 'created by', 'modified by') messed up?  If they currently reference #0!:domain\FLastname using WIA, do they have to be converted to another format using SAML?  If so, that sounds like a scary proposition.

You mentioned that we can remain with SharePoint in WIA, but then we would have to connect WAP to our domain.  In doing so, this comes with certain risks of it's own regarding security.  Do you feel the security risk to be minimal?  Is it something people just don't worry about?  Or is there other safeguards that we should consider implementing?

For example, our WAP sits in the DMZ outside the firewall.  Should we be looking into specific firewall rules?  Special ADFS settings?  MIM?  

Thanks for you assistance.  ...  I see you wrote a book about SP2016.  I'll suggest to my boss to purchase it.

[#14]

When you do the conversion, you use Convert-SPWebApplication which updates the references across the farm.

As for the risk of WAP being domain joined, that is primarily dependent on your security policy and strategy. Does it have more risks than a machine in a workgroup? I suppose it might if someone compromised the machine and gained local access. But there's always ways to mitigate these issues.

As far as ADFS/MIM, nothing changes there when using WIA.