3

I am trying to write an WPF client which uses ADAL to authenticate against ADFS on a Windows Server 2012 R2. I have successfully implemented this using "Forms Authentication" where the user is prompted for the domain username and password. However, I want to take advantage of SSO and use the currently logged on domain user to authenticate against the ADFS.

Unfortunately, I'm only getting an error message saying:

This method overload is not supported by '< ADFS servername>'

I have done a lot of searching, but find some of the information contradictive:

Is it a fact that Windows Server 2016 is required to perform SSO in conjunction with ADAL? Is there any other way to do it?

EDIT:

After upgrading to the latest alpha of ADAL (3.9.302111717-alpha) I'm getting the more detailed error message

MSIS9611: The authorization server does not support the requested 'grant_type'. The authorization server only supports 'authorization_code' or 'refresh_token' as the grant type.

The code I'm executing is this:

string authority = "https://myServer.com/adfs";
string resourceURI = "http://myApp/";
string clientId = "XXXX-XXX-XXXX-XXXX-XXXXX";
string clientReturnUri = "http://anarbitraryreturnuri/";

var ac = new AuthenticationContext(authority, false);
var token = await ac.AcquireTokenAsync(resourceURI, clientId,new UserCredential());

I was able to implement a working solution using WS-Trust, so I am confident that the machine I'm running on has the privacy settings to enable the app to find the currently logged on user.

The Oauth2 endpoint looks as follows: OAuth2 endpoint configuration

Also, my global authentication policy is set up like this:

Global Authentication Policy settings

Community
  • 1
  • 1

1 Answers1

1

Windows Server 2016 is only required for the password grant - in which you provide raw username and password. Your question seems to suggest you want to sign on with the currently signed in user, which would leverage Kerberos instead. Kerberos based authentication should work with ADFS "3" and ADFS 2016 indifferently - as long as your client is connected to the domain network, the local machine does not have privacy settings that prevent your app from finding out the domain user currently logged in and the correct endpoints are enabled on the ADFS instance.

vibronet
  • 7,364
  • 2
  • 19
  • 21
  • Thanks, @vibronet. However, I'm still having issues. I've updated my post with additional information. Can you see anything that could be the source of my problems? – Julian Hanssen Feb 17 '16 at 08:53
  • Now I understand better your scenario, thanks for the extra details. With Windows Server 2012 R2 that method won't work directly against ADFS - it only works if ADFS is federated with Azure AD. If you want to stick with 2012, you need to call AcquireToken just like you would for forms authentication - but use PromptBehavior.Never. *From the intranet* this shoudl result in SSO, given that it uses an invisible browser that should auth directly against the Kerberos endpoint. – vibronet Feb 17 '16 at 09:01
  • Thanks again. Changing to using Promptbehavior.Never gives "The requested resource requires user authentication.". Promptbehavior.Auto pops a Windows Security log in but after logging in Adal fails with "The request could not be processed by the server due to invalid syntax." I'm suspecting my ADFS config might be off, this is my first time setting it up. – Julian Hanssen Feb 17 '16 at 17:30
  • Using Fiddler I'm also noticing that adal is using Mozilla/4.0 as the User agent for the http request to the oauth2 endpoint on my ADFS. Can this be the problem? Is there any way to change this to use IE (which supports WIA)? – Julian Hanssen Feb 18 '16 at 08:24
  • 1
    After correcting a wrong SPN for ADFS and adding my ADFS server to the list of trusted intranet sites in IE I seem to have it working. – Julian Hanssen Feb 18 '16 at 21:55