My goal is to create a HTTPS REST service that (in concept) allows a machine account to authenticate using the less- than documented machine$ account.
I have a REST endpoint for an AD connected intranet application. Right now IIS simply echoes the thread CurrentPrincipal when I navigate using Internet Explorer.
Now I'm using the HTTPClient , using default authentication, running a my username, and that also works.
My new goal is to send the AD Connected machineAccount (that ends in the dollar sign $) so that IIS responds with the kerberos name Domain\TestServer$
I attempted creating a Windows Desktop service, running as NetworkService or LocalSystem, and I'm not clear if HttpClientHandler.UseDefaultCredentials is sufficient for running in this (unusual) context or if a different approach is needed to authenticate using the machine account.
Is a PInvoke needed? Is there anything in logonuser32 that needs to be done?
Related
I have an SPA web app using openidconnect for authentication and authorization with local keycloak.
This app is now moving to an windows onprem infrastructure using AD, kerberos tickets and a central SSO.
users log in in their windows session, and then we shall be able to transparently login in our SPA web app. (ie with out entering credentials)
How can I convert kerberos ticket/authentication into Openidconnect world? Where is the magic?
Shall we add some kerberos in our app?
how can we retrieve our access token containing the user role?
thanks
Your SPA should continue to talk to Keycloak using OIDC, and no code in the SPA should need to change. Your APIs will also continue to receive the same access tokens.
You should only need to configure Keycloak to use AD for authentication as an LDAP data source. Here is an article on how to do that. It is an infrastructure job rather than just a coding one, so I would recommend collaboration with AD administrators on the environment setup.
AD is only one possible authentication method, and by doing things this way you keep your options open. You are likely to need to perform account linking, eg to identify users the same before and after the migration. There may be some data setup involved here, eg ensure AD has the same emails as the existing system.
We have a client/server based application that is developed internally. Clients and server communicate over a TCP/IP connection with an application-specific protocol. The clients run on Windows and the server runs on Linux. All machines are in the same Active Directory/Kerberos domain/realm.
Currently, the user enters a username and password when they start the application. The server checks the username and password (authentication). Based on the username, the server also determines access to resources (authorization).
We want to add Single Sign-On (SSO) capabilities to the application. That is, we do not want the user to enter a username and password but we want to automatically logon as the current Windows user.
Of course, determining the current Windows user has to be done securely.
I have come up with the following setup:
I use SSPI (Negotiate) on Windows and GSSAPI on Linux.
When the client connects to the server, it uses AcquireCredentialsHandle (Negotiate) to get the credentials of the current Windows user.
The client uses InitializeSecurityContext (Negotiate) to generate a token based on these credentials.
The client sends the token to the server.
The server uses gss_acquire_cred() to get the credentials of the service. These are stored in a .keytab file.
The server receives the token from the client.
The server uses gss_accept_sec_context() to process the token. This call also returns the "source name", that is the current Windows user of the client.
The server uses the "source name" as the username: the server performs no additional authentication. The server still performs authorization.
This works but I do have some questions:
Is this secure? It should not be possible for the client to specify any other username than the Windows user of the client process. If a user has the credentials to create a process as another user (either legally or illegally) than this is allowed.
Should I perform additional checks to verify the username?
Are there alternative ways to achieve SSO in this setup? What are their pros and cons?
What you've described here is the correct way to authenticate the user. You should not have to worry about the user specifying a different name; that's what Kerberos takes care of for you.
If the client is able to obtain a service ticket, then they must have been able to authenticate against the KDC (Active Directory). The KDC creates a service ticket that includes the user's name, and encrypts it with the service's secret key.
The client would not be able to create a ticket for the server with a fake name, because it doesn't have the necessary key to encrypt the ticket.
Of course, this all assumes that you've set everything up correctly; the client should not have access to the service's keytab file for example, and the service should not have any principals in its key tab except its own.
There's a pretty detailed explanation of how it works here.
I have a self-hosted owin web api service on a test environment, and to give it a better name I use a domain alias, and ARR.
My web api runs on port 8888, and uses Windows Authentication. I have configured my arr to run under testserver:80 with anonymous authentication. I want to deploy a service on the box that will pool the webapi for data. When I try to visit testserver from my web browser on my desktop it works fine. However, when I remote into that box and try to hit testserver it prompts me for credentials. Even if I type them correctly it still will issue me a 401. If I go to localhost:8888 the site will work.
Since, I'd prefer to use the pretty name for the server in my service how do I correct this issue. How do I get it to pass credentials on the same box through ARR?
You might have have an issue with LSA loopback checking.
You get the 401 because ARR forwards your Windows Authentication to localhost, which is not allowed (default setting).
Try to disable LSA loopback checking (restart most probably required). If that works you can limit the disabling of loopback checking to specific websites (to prevent security holes).
See You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version for more information on the LSA loopback check and how to disable it completely or only for specific hostnames.
I just read the article here: http://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/building-real-world-cloud-apps-with-windows-azure/single-sign-on
I have just finished building an app that can authenticate users via WAAD, or via a local installation of ADFS on their corporate network (configuration point allows them to select one or the other).
The app will be hosted in Azure. Can someone tell me if it is possible for users who are on their corporate network to login to this Azure app WITHOUT entering their credentials?
Here is the flow:
user navigates to the cloud app
FAM detects they aren't authenticated, and redirects the browser to their ADFS server on the corporate network
ADFS server replies with 401 challenge (I assume this is what's happening)
user sees a user name/password box, and enters in credentials
user is redirected back to the cloud app with a token containing their claims
I don't understand why #4 is required if the user is already on their corporate network. Shouldn't ADFS use Windows Authentication here so they don't have to enter their password? Is there a way to configure ADFS to do this?
Thank you!
This can be accomplished by adding the Url of the ADFS endpoint to the local intranet or trusted sites of Internet Explorer. By default Internet Explorer will pass in the Windows credentials to sites in those two groups. If that doesn't work, you would have to double check that setting hasn't been modified.
IIS Media Services 4.1:
I have a dedicated website setup on my win 7 dev box. I'm testing the REST service with Windows Auth turned on from both calls from a browser as well as a test C# winform app. Using the browser I try to hit http://iismediatestsite/services/smoothstreaming/publishingpoints.isml I get challeneged (good) but when I put in my domain creds I get into a loop where it keeps prompting for creds. My domain account is an admin on this box. If I use my test app I set UseDefaultCredentials to true but I get a 401 returned.
Using Basic Auth works fine with both clients.
Any ideas?
TIA
Okay apparently this is caused by an issue when authenticating by NTLM via a loopback address. It is better explained and a workaround provided here:
http://support.microsoft.com/kb/896861