ADFS
4 TopicsSP 2016 ADFS 4.0 Federated Partner Authenticates, but doesn't Authorize
Resource Domain/Forest (resource.local) SP 2016 Farm in Resource Domain webapp.resource.local ADFS 4.0 configured on internal network of resource.local WAP configured in DMZ publishing adfs.resource.local and webapp.resource.local User Domain/Forest (users.local) ADFS 4.0 configure on internal network of users.local WAP configured in DMZ publishing adfs.users.local Federated trust has been created between the two ADFS instances. We can successfully authenticate against either ADFS individually, and we can also authenticate across the federated trust using the idpinitatedsignon.aspx to test. The Issue: When we attempt to login to webapp.resource.local (tested externally because we have no need to test this internally) we can see the trust being traversed and we authenticate, however, we get the "Sorry, the site hasn't been shared with you." page. The users in the resource domain don't have issues authenticating/authorizing to the sites externally through the resource ADFS. I'm not sure what we're missing here. Any help would be greatly appreciated. Trevor SewardSolved1.3KViews0likes3CommentsHow can ADFS communicate with a workgroup server on external network
I ask this question with least knowledge of SSO with ADFS, so pardon my mistakes. we have a situation where we need help and any reply would be of help. Currently our customers have the facility to access our application using SSO via PingFederate and http. However, customers are now planning to move to ADFS and connect via https to our application. The problem is that our servers, where the application is hosted are not exposed to internet and are workgroup servers (not on any domain). The servers sit behind our enterprise firewalls. Current set up is such that, the authenticated PingFederate request is mapped to IP (NAT) at the customer's end and the request is sent via the firewalls which understand the NATing to route the request to our servers. However, customers say that their ADFS generates token only with FQDN and they do not want to covert the request to IP based request. I would like to know what options do we have to receive the FQDN token requests generated at customer's ADFS on our machines. 1. Customers can convert it to IP based and send it through firewall similar to the Pingfederate method. 2. We move our servers from workgroup into our company domain and issue SSL certificates with a domain name. I would like to know, if there is any other option what we can employ to solve this. FYI - Our servers are using IBM WAS (not IIS or webserver). Cheers982Views0likes0CommentsSharePoint on-prem, ADFS, and OneDrive for Business
I have a SharePoint 2016 farm on-premises using ADFS authentication. I'm having problems integrating the farm with OneDrive for Business. I set up my ADFS IdentifierClaim for SP is using sAMAccountName, and I'm wondering if that is causing the problem. Is it a requirement (or strongly encouraged) to use email address for the Identifier Claim when creating a new SharePoint SPTrustedIdentityTokenIssuer?4.9KViews0likes3CommentsI need a guide for SP2016 on prem setting up WAP and ADFS
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?7.8KViews0likes13Comments