In a corporate desktop scenario, where the user is logged in to an Active Directory domain, I'd like my application to issue HTTP requests using the same proxy as Internet Explorer uses. The problem is that the proxy requires NTLM authentication using the credentials of the currently logged in user, which is something I don't know how my application could acquire.
Besides asking the user for his/her password (for which I found a lot of solutions), is there a way to do it the right, like using some native API? I'm not picky about programming languages in this case, if it works in this scenario, I accept it, although I'd prefer C/C++.
Since you are on Windows, and you are using domain logins, you should rather rely on Kerberos. Anyway, you now several options:
If you use WinHTTP , you simple have to enable it.
Use libcurl on Windows and it will compile with SSPI support by default.
If you use sockets by yourself, you have to call SSPI with the Negotiate package and exchange tokens per HTTP all by yourself.
Related
In Azure DevOps services, when you connect an agent to the server, you have different types of ways to authenticate to the server. You can see here for example, about connecting a Linux agent, that you have these 4 types:
Alternate (Basic authentication)
PAT
Negotiate - Connect as a user other than the signed-in user via a scheme such as Kerberos or NTLM.
Integrated - Not supported in Linux
The integrated type is mentioned in the page about connecting a Windows agent as "Windows default credentials"
Bare with me please.
In my organization, we have a Active Directory domain with a Single-Sign-On, I suppose it uses Kerberos as the authentication protocol. Sometimes I use Powershell scripts to access the API of our internal Azure DevOps Server, and I use the -UseDefaultCredentials flag so the user won't have to enter username and password - it will just authenticate based on the logged-in user.
That got me thinking that the -UseDefaultCredentials flag is using Kerberos to authenticate.
But from the above, it seems that Integrated is using "Default credentials", which is something else than "Negotiate" which uses Kerberos.
Can someone help me understand this?
The UseDefaultCredentials flag tells the underlying system to try and use the caller's SSO credentials, which in most cases is the credential used to log into the system interactively or otherwise.
Strictly speaking it does not indicate which protocol to use. What it's actually saying is "dear system internals: please figure it out for me". The way this works is by selecting the negotiate protocol, which as it's name suggests negotiates the use of specific authentication protocols based on the client credentials as well as information from the server. This is called the SPNEGO protocol. It is transparent to the caller.
SPNEGO is fairly simple in nature. The client has a list of known authentication protocols (Kerberos, NTLM, etc.) and will send that list to the server saying 'pick one please'. The server can select any of them and respond telling them what to use, and the client then goes and uses it. Fin.
SPNEGO is also relatively smart because it can reasonably predict what it thinks the server will accept and will attempt to optimistically provide a token up front using the first protocol in the list. So if it thinks it needs Kerberos it'll go and get a Kerberos ticket up front and send it first. The server might think that's fine, or it might fail and return a response saying
"no, I really need NTLM", and so the client tries again with NTLM.
Default authentication package for windows domain authentication is Kerberos. But it is possible to perform pass-the-hash by using Windows Credentials Editor, for example (even in Windows 8). WCE works with NTLM credentials, and attack is possible despite the fact that default protocol is Kerberos. Why?
Am I wrong or client can somehow initiate NTLM authentication?
The short is that yes it is possible to initiate NTLM auth.
For MS, it is not possible to fix it completely because that would break the backward compatibility.
You can read more about it on this thread http://www.reddit.com/r/netsec/comments/1ypdo1/sorry_microsoft_pass_the_hash_on_windows_81_still/
We have a Windows app hosting a WebBrowser control that hits our REST APIs. We like to restrict access to the APIs to be only coming from withing the Windows app itself (for example, the APIs cannot be accessed in a browser, etc).
How can we accomplish that? what is the most secure way without having to expose any kind of credential (for example, if we use HTTP Basic auth, the username and password can be seen by reverse engineering the app itself)?
Thanks a bunch!
EDIT: We plan to distribute the application freely so we have no control over where the connection will be made from.
Restrict the REST interface to only accept connections from 127.0.0.1 (home) and then connect from your rest-consuming application only with http://localhost or http://127.0.0.1 in the URLs (if you use the external IP or DNS name of your machine it'll be treated as a remote connection and denied access).
You can do this with web server settings, or within the code of your REST APIs
I had a similar situation during a project where we distributed an iPhone app that also connected to a REST api that my team developed.
For security we used somewhat of a three-legged scenario. The app was required to authenticate using the user's credentials against a standalone service responsible only for authenticating and generating access tokens. Once the app received a valid access token, subsequent requests to the api required sending this token in the Authorization header.
You could do something similar. If you come up with a credential scheme to authenticate your app as valid API consumers you could use basic auth over HTTPS to obtain tokens, and then only by using those tokens could a consumer gain access to the rest of the API.
Is it possible, safe and practical to use Windows Integrated Security on an Extranet?
E.g. there is an IIS website on the intranet that can be used over the LAN with integrated authentication. When the user disconnects from the LAN he wants to be able to use the browser on his domain-joined-notebook to connect to the same website over the internet (no VPN) without having to logon separately.
The question of whether it's "safe" is a question of what additional security threats you're exposing the user to in the Internet scenario, that they weren't exposed to in the Intranet scenario. Additionally, are you exposing the server to additional security threats - and assuming that the question isn't "whether to allow access to the server from the Internet" but rather "which authentication methods should we allow for this server-now-exposed-to-the-Internet", this secondary question boils down to "is it better to use Windows integrated authentication protocols or require the use of Basic, Digest or digital certificates"?
Security threats to user/client: are the user's credentials reasonably protected from attackers who "sniff them from the wire"? Windows-integrated authentication uses either NTLM or Kerberos; in extranet scenarios, the user/client can't generally rely on Kerberos, since that would require transparent access to a KDC (i.e. an Active Directory domain controller) from the Internet as well. While this can be done, it's unusual to see a security-conscious organization allow that. So we're talking about NTLM - which hashes the user's password with a "nonce" (random set of characters) that are sent from the server, so that the user's password doesn't appear in plaintext over the wire. Compare NTLM to Basic and it's a clear win; compare NTLM to Digest authentication, and it's somewhat equivalent; compare NTLM to client certificate authentication, and certs always win for security (but lose on the deployment/bootstrapping challenges). Generally you'll find your security or server admins will want to use an SSL certificate for the IIS listener that's exposed to the Internet, so that user's credentials are even more protected against "sniffers". SSL is hardly perfect and doesn't protect against more sophisticated attackers in the middle (or someone who has a trojan/bot on the client device), but it costs very little for an extra layer of peace of mind. SSL + NTLM is a reasonable choice made by many.
Security threats to server: server is exposed to unauthorized attackers trying to gain access to authenticated resources. If the server allows any AD-authenticated authentication protocols then it's equally susceptible (or not) to attacks that try to brute force a user's password, and some sort of IDS solution that raises alarm bells for repeated bad password attempts is advisable (but quite a challenge to get the signal/noise ratio down to manageable levels). The server is also exposed to the possibility that any exploitable holes (primarily in IIS, or anything else exposed through the firewall) can be used to gain privileged access to the server by an outside attacker. Better be prepared for frequent patching. Other less likely but scary-sounding security threats are possible, but that's the big ones to tackle first.
Yes, it is definitely possible to use integrated security. But, it also depends on the framework you are using for authentication. In ASP.NET you can use built in authentication module. You to set the authentication mode to "Windows" and .Net will manage it for you. You can also have different roles for managing different types of users in your web app. You web app must be available outside your LAN(i.e. your firewall should not block incoming HTTP requests)
Vamyip
As ParanoidMike points out by exposing a webapplication to the internet that uses windows authentication you are creating a brute force attack vector to hackers. To try and mitigate this threat you should consider taking the following actions:
Restrict Access by IP address
Set Accounts to Lock out after n failed login attempts.
Admin accounts cannot be set to lockout so choose obscure usernames for them.
I'm currently investigating if it is possible to exclude admin accounts all together
I heard that on Windows you can login from a web browser to the web server without going through the usual login entering username and password but using instead the credentials from Windows directly, using the NTLM protocol.
How is this achieved? Does the web server need to support some additional authentication?
Update: I'm asking for a generic web server, not just IIS. How to do that on Apache for instance?
The webserver just needs to be configured to support Windows authentication (which will be NTLM, or - better - Kerberos if both client and server are W2K or later). I believe that IIS or Apache can be configured to do that.
The browser also has to support this - at least IE does so (not sure about the others, it may be possible). edit: looks like firefox has some support for this too, and safari on MacOS
edit: for details on apache, google modules for NTLM authentication. Kerberos modules also exist. as per other answers, this really only works on an Intranet - not just because the browser needs to be in an Intranet zone (only applies to IE), but because any intervening firewall will typically stop this working, and because the necessary interdomain trusts will probably not exist. It's also a bit trickier to make work if the apache server is on UNIX, and especially if you also have Kerberos servers on UNIX in the mix, but still possible.
It will only be seamless in a specific situation; namely the webserver needs to support NTLM (for example, IIS), and it needs to be in a zone that the client is configured to trust (The "Intranet Zone" in IE parlance, unless the end user has tweaked their settings)
If your webserver and client pc's are on a network secured by Active Directory or similar, you can set 'Windows Integrated Security' in IIS on the web server for the website which automatically logs in all I.E clients (That are allowed).
As stated previously, NTLM is typically used if your back end is Windows Managed (MS Active Directory). However, there are also modules available for Apache that will tie into this: mod_ntlm.
Since this is it's own protocol, it is required that the browser is able to understand this protocol and reply to the authentication challenges. I don't know which browsers support this off hand, but my assumption would be that most do.
From my experience, kerberos is more of a prefered method, but I have not worked with it much, so unfortunately, I don't have much advise as far as that goes.
On a side note, I recall reading somewhere that the JRE also has ways of tying into NTLM on your web server in order to obtain identity information for the authenticated user. As stated previously, .NET has support for this as well.
Also, Firefox does not support NTLM by default but it can be configured using the following tut: http://www.crossedconnections.org/w/?p=89
If you set the IIS settings to require authentication then your users will need to log in to access the page. They then have any rights (if not an interface) to anything on that server that they would if they logged in the normal way (from the console).
Other than this, I am not sure what you are referring to.
Yes this is possible. It is often used in intranet applications where users are. windows uses NTLM or Kerberos to authorize the user against a central service, typically Active Directory on the windows platform. On the .NET platform the current user information can be accessed through the System.Threading.Thread.CurrentPrincipal.Identity instance.
You might also want to look into Jespa. It seems a little bit more straight forward than Kerberos but provides good ntlm sso capabilities.
I was looking for more information about Kerberos (because NTLM, even v2, become deprecated with AD 2008), and I found this article, explaining how make it work with Apache (as you mentionned it).
http://blog.scottlowe.org/2006/08/10/kerberos-based-sso-with-apache/
This question is probably outdated (or at least solved), but if it can help someone ...