This question is coming from our netops team… I believe the answer is no, but looking for a confirmation and more information:
In a pure windows environment, is there a way to have a client (like IIS, a windows service, etc) authenticate with EventStore automatically though NTLM (SSPI), using the identity that the client application i running under?
If so, how?
If not, what is the recommended practice for securing credential secrets when authenticating to EventStore from .NET API clients through development, QA, staging, and production? Do we need to roll our own password encryption using certificates, or do something else? Plain text credentials should not be an option.
If you are using the HTTP interface, you could use IIS and ARR to do the authentication for you. Ensure you Event Store machines only allow connections from IIS machines.
Does EventStore support SSPI integrated authentication? When hosting an API site in IIS, calling applications authenticate as the user currently running the process. This is a pretty core functionality for windows clients talking to IIS, SQL Server, AD, etc. Is this supported by EventStore?
No, this isn’t supported - it’s something we could consider but it would be part of the commercial product. We encourage people to run on Linux in preference to Windows in any case.
I know, it’s terrible having a tightly integrated single sign on solution; robust remote monitoring and management; dependency based service manager; feature rich ACLs across the solution stack tightly coupled to a multi-master, globally distributed, identity management solution; automated, authenticated certificate distribution; secure dynamic DNS updates; a fault-tolerant DHCP server; and fully featured file system resource management, but, I manage to do what I can. My questions then are:
What benefit does running on Linux bring to the table?
How do you distribute and store credentials?
@DanLudwig: Might have to put IIS in front of EventStore in reverse proxy mode if we don’t want the Linux-style solution of leaving passwords in plain text files littered about the file system.
What benefit does running on Linux bring to the table?
File caching isn’t broken (no need to use cacheset), administration is easier, there is no need to run additional processes to manage as a service, the binaries are statically linked.
How do you distribute and store credentials?
The same way as you’d manage anything else. My personal choice would be to use Vault (HashiCorp) for them, but you could also use Chef databags, encrypted Heira in Puppet, and so forth.
If you have a commercial Event Store license you can use LDAPS, which is known to work with Active Directory. Alternatively if you contact us off list it might be possible to work out some custom development to support SSPI on Windows, but this will not be making it into the OSS distribution.
a) What are the recommended settings for the file system cache on Windows?
b) What makes administration easier?
c) What additional processes? I managed lots of Windows services today, it’s pretty straight forward
d) You can’t build a static binary on Windows? Why does this matter?
I’m asking because I’m going to be running this thing in production, and I have to weigh the substantial benefits Windows brings to the table against “We encourage people to run on Linux in preference to Windows”, so I’m looking for some pretty concrete reasons.
As with most of these things, “it depends”. Some answers in line, don’t have time right now to write up a full response though:
a) What are the recommended settings for the file system cache on Windows?
You’ll need to clear it periodically.
c) What additional processes? I managed lots of Windows services today, it’s pretty straight forward
The open source cluster nodes do not run as Windows services. Consequently you either need to manage this yourself with something like NSSM, or run Manager nodes in addition to the database nodes (this is part of the commercial distribution).
d) You can’t build a static binary on Windows? Why does this matter?
No, you can’t build a static binary on Windows unless you’re prepared to link to Mono instead of the .NET framework. Mono on Windows is something of a mess.
i) Is there a procedure somewhere documented to clear the cache? is this something I can schedule?
ii) So we’ll be buying a license for the commercial distribution. Do I still have to use NSSM? If EventStore is written in .Net, why not just build a native Windows service?
iii) Not sure why I would want to run a 3rd party unsupported alternate implementation of the CLR, especially on Windows, when Microsoft Corporation already builds, ships, tests and supports one for all their supported platforms. Is there some substantial benefit to having a static binary?