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.
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.
I am trying to kerberize my RESTful backend and I am not seeing anywhere in the GSS-API documentation how could I add a user/service - i.e., I understand the authentication process with GSS-API, but not the signup process. To make my question simpler : kinit is the command line tool used to add principals, is there an equivalent for GSS-API ? If the answer is no - should I go and look at the kinit source code and port it to my project (using system("kinit ...") raises security questions/problems so I am not thinking about using it) ?
Users should be added to the Kerberos database using API provided by Kerberos Distribution Centre. In Microsoft Active Directory, KDC uses LDAP as its database, so users can be added/removed using JNDI, as described here: http://cyberlizard.livejournal.com/120080.html.
kinit not a tool for adding users but for (simply speaking) "logging in", or (technically speaking) it's a tool that "obtains and caches an initial ticket-granting ticket for principal" (see: http://web.mit.edu/kerberos/krb5-devel/doc/user/user_commands/kinit.html), i.e. it takes credentials (i.e. for example principal and password, connects to KDC and tries to receive initial TGT from it. Client).
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).
What is the best way to send a password to a Windows Service? Our application needs a password in order to start. I don't care that services are "normally" supposed to run without user interaction. Its good enough for us that an operator can start the application and then log off.
On a unix system, I would just echo the password over stdin but the service has no stdin.
Currently, we use the DPAPI to just store the password using CryptProtectData. While this, works, it presents other problems that are beginning to become troublesome.
I'm guessing that I'll need to use some form of IPC between the service and the application that is sending the password but I'm not sure which method is appropriate, if any.
Thanks
Two main options:
You could listen on a socket on startup and wait for the required password to be supplied (maybe embed an SSH server in there, so that the password cannot be snooped over the wire)
My preferred option would be to read the password from a configuration file (that can be secured to the minimum readership) or registry setting (again, sufficiently secure such that only your service and administrators can read/change it)
Thanks for responding Rowland.
You could listen on a socket on
startup and wait for the required
password to be supplied (maybe embed
an SSH server in there, so that the
password cannot be snooped over the
wire)
I considered that but without certificate verification, wouldn't that leave us open to a man in the middle attack?
My preferred option would be to read
the password from a configuration file
(that can be secured to the minimum
readership) or registry setting
(again, sufficiently secure such that
only your service and administrators
can read/change it)
We're trying to follow "defense in depth" as much as possible such that if an attacker compromised the machine, he would not able to access our application.
You can use kerberos mutual authentication. There are few options and examples there.
But just wondering. On a compromised machine, There may be a key logger. So typing the password is never secure if you want to maintain security in this environment. The same problem exist afaik for unix terminals.
DPAPI in UserMode is really the best option, and storing the encrypted data in a protected location, e.g. registry key with limited ACL.
What exactly were the problems that are beginning to be troublesome? Maybe we can just solve those...
What exactly were the problems that
are beginning to be troublesome? Maybe
we can just solve those...
Currently, the application runs as the Local System account.
Our application stores a number of credentials in an encrypted file and uses the DPAPI (in UserMode) for the encryption.
Thus, when the application is installed, the installer is run as the Local System account. We also have a set of tools that ship with the application, some of which need access to this encrypted file and thus, they too need to run as the Local System account.
By the time the application is installed and started, we're heavily dependent on that account.
We're running into problems because one of our users wants to use the application to access a shared network drive. The Local System account has no such privileges and we can't simply run our service as a different user because our encrypted information is protected under the Local System Account.
We've tried to avoid the process of setting up a user account just for our application because it is installed across many different customers and environments, all of whom have wildly different security policies.
You can access a remote drive from a service running under system account. However, you will need to have credentials & share information to connect to the remote machine. You can use the API wnetaddconnection to gain access. Probably your encrypted file can store this credential as well.
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 ...