Im doing a little research about Windows password and I've a little question.
Windows encrypt user passwords and store them on: C:\WINDOWS\system32\config\SAM encrypting them by the NTLM algorithm (plus Syskey)
NTLM is also a network authentication protocols, so I'm messing up with this.
I would like to know if the NTLM encryption is the same of the NTLM network protocol. I mean, in Windows, when you type your user and password, if the system starts a network protocol on the same system (localhost), as it would if they were too different computers (ip).
Or otherwise, if they are two different things with the same name.
It would be great if someone could give me a little explanation about the difference of both methods.
Hope you can understand my question, as I'm not English!
Thanks in advance!
Disclaimer: I work for Microsoft, but not on Windows or any team that developed NTLM. This knowledge comes from external sources and thus may not be accurate.
NTLM is two things: a one-way hash algorithm and an authentication protocol.
The one-way hash function is what the Windows OS uses to store passwords (in the secrets file, as you note.) This is, of course, so that plaintext passwords need not be stored on disk. When you type your password on the login screen, it will be hashed with the NTLM hash algorithm and compared against the existing hash in the secrets file. If they match, you'll be authenticated. If not, you'll be prompted to enter your password again.
The authentication protocol is a challenge/response protocol that authenticates some on-the-wire protocol like CIFS or HTTP. The algorithm utilizes the aforementioned NTLM hash algorithms in order to build the responses to the server's challenges based on the password that the user typed. The protocol specification for the NTLM authentication protocol is available from Microsoft under their Open Specifications license.
To answer your question, when you log in to Windows, it's likely just using the NTLM hash and checking it against the on-disk file, not doing some network call. Of course, if your machine happened to be a domain controller (and, somehow, couldn't do Kerberos) then it may do NTLM authentication over the network to localhost, but that's a pretty contrived example. Of course, if you're hitting a network resource on that local machine (say, CIFS file sharing or hitting a web site) then you'll be using the network authentication protocol, not going directly to the secrets file.
NTLM is not a network protocol. It's an authentication protocol. They are totally separate things.
There's a pretty good discussion of NTLM here. Pay special attention to the fact that NTLM isn't used any longer (it's been replaced by Kerberos and NTLM2, both of which are defined and discussed in the linked article).
Related
I want to implement kerberos authentication for a software where both the server and the clients run on Windows and are implemented in C++.
When both, the clients and the server are on the same Windows domain it is straight forward to use SSPI and I assume this will work also for cross-realm environments.
When for any reason the server cannot be member of the domain this straigth forward approach will not work.
How is it possible to achieve Kerberos authentiaction against a server that is not member of the domain?
If my research is correct java applications or linux use a keytab file instead of implicitly retrieving the key from AD. Apparently SSPI does not support keytab files. Is there a way to use keytab files in this scenario?
SSPI does not "retrieve the key from AD" – the service key is always stored locally, but with SSPI it's the machine account password which was generated during AD join process (and uploaded to AD rather than retrieved from) that acts in place of the keytab. Windows stores the machine password in LSA and derives the key from it in memory, but it has the same purpose as a keytab file.
There may be a way to store a machine password in a non-AD machine (using ksetup.exe), but it is very much a system-wide change – it seems to make certain parts of the Windows login process function as if the system was domain-joined – so I would not recommend doing so, except in a test VM.
Instead, you can use another Kerberos implementation – MIT Kerberos and Heimdal are the two major non-AD Kerberos implementations that come in the form of C libraries (both are Windows-compatible, though their focus is on Linux/Unix-like systems). Both libraries provide the GSSAPI interface, which is similar to Windows SSPI, and both use keytab files for service credentials.
For C#, Kerberos.NET is available. For Rust, sspi-rs seems to be in active development (it isn't just a binding to Windows SSPI but a standalone implementation as well). Java of course has its own Kerberos implementation built-in as part of JAAS although Apache Kerby exists as well.
Most of those implementations support the same keytab format because they mimic MIT Kerberos to some extent (which was the original Kerberos 5 implementation).
Both MIT Krb5 and Heimdal include not just a library but a KDC service as well, though that part won't run on Windows. (Kerby and Kerberos.NET could also be used to build minimal KDCs.)
The above is more important for servers; however, a client can use SSPI to authenticate to Kerberos services without any requirement to be a domain member.
For realms that are AD-based (regardless of the specific server being domain-joined or not), it is enough to provide a UPN-format username (in the form of user#domain) and a password to SSPI; it will automatically discover KDCs and obtain tickets.
The same works for Kerberos realms that are not AD-based as long as the realm is marked as a "MIT realm" either via registry or using ksetup /AddRealmFlags. (The principal user#REALM needs to be specified as username in this case.) Unlike the earlier mentioned case, this ksetup.exe usage seems to have no negative side effects.
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.
Given a windows domain, and two win7 systems, how can I establish a user verified connection from the first computer to the second without prompting for the user to re-enter credentials.
A good summary of this is: A TCP connection, server-side, has no idea what user is originating the connection. How can implementing a TCP based program permit user validation.
Work around ideas:
- I could write a WMI provider and use the underlying WMI infrastructure to verify the user.
I'd prefer not to get a work-around, as I've been working around not really understanding how to authenticate over the network using Windows for many years. Please help me to understand how Windows is actually performing this step so that I can implement the technique. If the answer is kerberos some example code on how to generate/send something from the client (without prompting for credentials, just use the logged in user) that the server can process/validate.
I think this may have already been answered here: Windows authentication token C++
(Will need some time to implement/test before I will be sure.)
The magic answer I was looking for back then was SSPI (Kerberos). A similar solution exists with OpenSSL. For others looking for this you will also be interested in SSL, TLS (the new SSL), and SASL (a mechanism for deciding on the fly which identification algorithm to use) and it's Microsoft counterpart SSPI.
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
If I uncheck the "Enable anonymous access" checkbox in IIS, so as to password protect a site, i.e. by restricting read access to designated Windows accounts, does the resulting password dialogue which is then presented to all anonymous http requests, represent a security risk in that it (seemingly) offers all and sundry an unlimited number of attempts to guess at any Windows account password?
EDIT:
Okay, not much joy with this so far, so I'm attaching a bounty. Just 50 points sorry, I am a man of modest means. To clarify what I'm after: does disabling anonymous access in IIS offer a password guessing opportunity to the public which did not exist previously, or is it the case that the browser's user credentials dialogue can be simulated by including a username and password in a http request directly, and that the response would indicate whether the combination was correct even though the page was open to anonymous users anyway? Furthermore, are incorrect password attempts submitted via http subject to the same lockout policy enforced for internal logins, and if so does this represent a very easy opportunity to deliberately lock out known usernames, or alternatively, if not, is there anything that can be done to mitigate this unlimited password guessing opportunity?
The short answer to your question is yes. Any time you give any remote access to any resource on your network it presents a security risk. Your best bet would be to follow IIS best practices and then take some precautions of your own. Rename your built in administrator account. Enforce strong password policies. Change the server header. Removing anonymous access, while a password guessing risk, is a very manageable one if used with the proper layered security model.
When you choose an authentication other than Anonymous, you certainly can be subject to password hacking. However, the account that is uses is subject to the standard account lockout policies set in Local Security Policy and your Domain's security policy.
For example, if you have a local account "FRED" and the account lockout policy is set to 5 invalid attempts within 30 minutes, then this effectively prevents account password guessing, at the risk of a denial of service attack. However, setting the reset window to a value (15 minutes?) effectively limits the DOS.
Basic Authentication is not recommeded for a non-SSL connection since the password will travel in plain text.
Digest Authentication requires passwords to be stored on the server using a reversible encryption, so while better than Basic, Digest has its flaws.
Windows Integrated Authentication
includes NTLM and Kerberos.
The IIS Server should be configured via Group Policy or Local Security settings to disable LM authentication ( Network security: LAN Manager authentication level set to "Send NTLMv2 response only" or higher, preferred is "Send NTLMv2 response only\refuse LM & NTLM") to prevent trivial LM hash cracking and to prevent NTLM man in the middle proxy attacks.
Kerberos can be used, however it only works if both machines are members of the same domain and the DC's can be reached. Since this doesn't typically happen over the internet, you can ignore Kerberos.
So the end result is, yes, disabling anonymous does open you up for password cracking attempts and DOS attacks, but these can be prevented and mitigated.
You should read about differnet authentication mechanisms available: Basic, Digest, NTLM, Certificates, etc. The IETF compiled a document that dicusses the pros and cons of some of these (NTLM is propriatary MS protocol).
Bottom line is: You are not done with just disabling anonymous access. You definitely have to consider carefully what the attack scenarios are, what the potential damage might be, what user may be willing to accept and so on.
If you introduce authorization you need to address the risk of credentials being compromised. You should also think if what you actually want to achieve is confidential transport of the content: In this case you will have to instroduce transport layer security like SSL.
I am by know means a hosting guru and I imagine there are ways and means of doing this but my personal opinion is that what you are talking about doing is defiantly an unnecessary security risk. If this site is to be available on the internet i.e. it will have public access then you probably don't want to disable anonymous access in IIS.
Please remember that the idea of being able to configure the anonymous access for a site in IIS is so that you can create a user which has specific permission to read the relevant files for a particular site. What we are talking about here is file access on a physical disc. For one thing a public web server should be in a DMZ and not part of your companies domain so users should not be able to log in with their domain credentials anyway.
The only reason why I could imagine that you would want to switch off anonymous access and force users to input their Windows credentials is for a site which will only be used internally and even then I would probably not choose to restrict access in this manner.
If you want to restrict access to content on a public website then you would probably be better of writing something which handles authentication as part of the site itself or a service which the site can consume. Then if someone were to obtain user credentials then at least all they will be able to do is gain access to the site and there is no potential for a breach of your internal network by any means.
There is a reason why developers spend allot of time writing user management solutions. You will find plenty of advice on how to write something like this and plenty of libraries that will do most of the work for you.