Is there a way to configure IIS or mark up my code so that the client (any major modern browser) will always include Kerberos information in the response without having to make any modifications to the client itself?
In this specific server method, I'm using ASP.NET impersonation with delegation enabled in AD and it would seem that from firefox and a few other clients, Kerberos data is not being passed from the client to the server.
My application only has Windows Authentication enabled, but how can I force the requests to pass Kerberos information along?
If it helps, I'm using jquery's ajax to GET or POST my requests to the server.
As long as your server is returning "WWW-Authenticate" headers that indicate it accepts Kerberos authentication ("Negotiate"), the client should automatically supply the necessary credentials. Make sure that Negotiate is listed as a possible provider for Windows Authentication in the Authentication configuration of your application. You'll probably want to disable NTLM in that list.
You can tell if the client is sending Kerberos tickets if you look at the HTTP headers. It should have something like "Authorization: Negotiate YIIN..."; the first few base64 characters of the payload let you distinguish between Kerberos and NTLM.
Related
Is there a way to use the native WindowsIdentity/WindowsPrincipal inside of a C# application running on a corporate domain to be able to request a SAML token from the domain's ADFS server so that the C# application can then make subsequent calls to WS-Federation calls in a service provider that has been federated with the ADFS server?
Seems like we would use WIF to contact the ADFS server to get a token. Is there a way to supply a Kerberos ticket to the WIF, rather than using a username/password?
Looking at WindowsIdentity.GetCurrent() I can see that the user is logged in using kerberos, but don't see how to configure the WIF call to ADFS to use kerberos to automatically get a SAML token without a username/password set of credentials.
Does https://blogs.msdn.microsoft.com/alikl/2011/09/30/how-to-use-ad-fs-endpoints-when-developing-claims-aware-wcf-services-using-wif/ help?
You should make sure you have an endpoint enabled that can do windows integrated auth via kerberos enabled. Something like /adfs/services/trust/2005/windowstransport or /adfs/services/trust/13/windowstransport . You can check that via parsing the /adfs/services/trust/mex endpoint. Occasionally some of these endpoints are disabled by a sysadmin.
Using a kerberos ticket as the credential for the endpoint means your app needs to be running on corpnet with access to domain controllers so it can obtain a ticket for AD FS. If the app use is not required outside corpnet this might be OK for you. Else you need to consider how the app behaves/authenticates inside and outside corpnet.
Have a look at https://www.microsoft.com/en-gb/download/details.aspx?id=4451 for samples but they'll need modifying based on version of WIF you plan to use as outlined in https://learn.microsoft.com/en-us/dotnet/framework/security/guidelines-for-migrating-an-application-built-using-wif-3-5-to-wif-4-5
Lastly you should consider if its possible to use OpenID Connect and OAuth2.0 instead of WS-Federation/WS-Trust in your scenario. If yes, you should review the information at https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-scenarios-for-developers
I have an on-premise hosted WCF service with REST endpoint which is configured for Anonymous authentication only in IIS. I installed and configured Azure App proxy connector on the server. I am able to contact the service fine with Pass-through authentication, but struggling to authenticate from a console app when Azure AD is chosen as security mechanism. I know I could have pass-through in Azure and turn on for example windows authentication in IIS, but this is unfortunately not an option in this case.
Using a browser, I am able to access the application fine, don't even need to enter credentials, our on-premise AD is connected and synchronized with Azure AD.
I followed this walk-through despite it is not regarding application proxy, and reusing parts of code I am able to get the Access Token for my application, but when I run the http request with Authorization header I don't get the result of service operation.
Using Fiddler I can note the following:
I get http 302 (Found). I can see my Authorization header in request, and in response I get a cookie AzureAppProxyAnalyticCookie
That is followed with http 200 to login.microsoftonline.com
Example I provided link for above works fine so it is clear that I am doing something wrong. Why is Authorization header not accepted and why am I being redirected to logon page?
Thanks in advance
This is working for another service, have no idea what was wrong with the first one, but suspecting something with DNS on local server. Won't be spending more time on this, point is that I shouldn't have experienced the redirect at all, although browser handled it and managed to get me authenticated.
I am using Asp.Net Identity and when I login in https login page and come to http home page I am seeing User.Identitiy.IsAuthenticated is false.
Is there someone who can explain why this is happening ?
Thanks
Ünal
If I'm not mistaken, since you've logged in from HTTPS, the cookie is secure and it won't be sent through insecure channels like plain HTTP.
What's the solution? There's no viable solution: if you authenticate users and work with security data, your data exchange must go over the wire through HTTPS or you're absolutely open to man-in-the-middle attacks to steal your users' credentials (and other data like claims)....
Further reading: Reading cookies via HTTPS that were set using HTTP
I am not sure if this is possible, but I am running into an issue where a Web Service call is giving me back a 401 Unauthorized. I have looked at the Fiddler logs and confirmed this, but I am passing in the correct credentials through my app. Is there anyway to get credentials that are being passed to the service by looking at the Fiddler Headers or Auth tabs?
If you click the AUTH tab in Fiddler, it will show you the information about the authentication challenge response.
Note, however, that NTLM and Negotiate don't send the raw password over the network.
Is the target site HTTPS? If so, is Extended Protection enabled?
SharePoint web applications in Claims authentication mode supports NTLM, but only through the following steps:
HTTP 302 redirect to a second location.
HTTP 401 challenge for NTLM auth
HTTP 401 verification
HTTP 302 redirect back to original location (service)
Can I write a custom behavior, channel factory or binding to handle this? Is there a better way to go about this?
What you have listed is the standard NTLM hand shake.
One way to avoid it is to use Kerberos instead of NTLM. See: http://technet.microsoft.com/en-us/library/gg502594.aspx