MS has supported event forwarding since 2003. You can set machines to forward events or have them pulled. The events are XML that conform to a published schema. There is a WMI call that call pull the aggregated events off the collection servers.
I heard this kind of thing from a vendor the other day. It's like people don't even try to learn how it works.
Why are they different? The event log has some transactional guarantees that were required for a specific kind of security evaluation...C2? I can't remember the rest.
The thing is...you don't have to install a client on the domain controllers. You can setup forwarding to some log hosts and collect them there.
It's like people don't even try to learn how it works
It's much harder to know how it works, for some reason. Information like this doesn't make its way into the community and circulate. On a UNIX system you can poke around /etc and get an idea of the scope of what is configurable. The same is very much not true of the registry and only slightly true of WMI.
You are right. The guy that wrote PowerShell says that UNIX is document oriented configuration while windows is API oriented configuration.
To get into it in any depth you have to approach windows programmatically. The most power is through C\C++...to be a good windows admin you need to read the docs about how you interact with different subsystems, even if you aren't going to code against them.
That's a really good point, thank you. I've never really thought about it that way; e.g. the registry is something you should sort of treat as an opaque blob of state (like a smalltalk image?) that you just mutate over time programatically, rather than as a declarative set of configurations to bring the machine to at any time.
After coding for several years, the two aren't all that different.
I'm not saying that I think that the UNIX WAY is ever going to go away...but I do think that extreme scale makes the programmatic approach to configuration make more sense. Instead of treating every system as a "system" you treat it as a simple programmable node among thousands of others. You are already starting to see Linux go this way with systemD. The stuff that the CoreOS people are doing with etcD, fleet, and flannel are really the future of *NIX.
Please cut me some slack...I'm NOT TRYING TO ARGUE ABOUT SYSTEMD. I'm just saying that it's oriented towards developers using API's. That's one of the reasons why admins who are used to the "one true way" dislike it so much. And they should have options if they don't want to use it. I'm just saying that cloud scale deployments are driving changes to infrastructure to make it more "programmable". I'm not even saying it's "right"...Its just a observation.
I think you have it backwards. Sysadmins are not the ones arguing in favor of "the one true way". That is squarely in the newer breed of developer/admin devops hybrid that the systemd camp is pandering.
For sysadmins the nix way of text in and text out allow systems to be as simple or complex as they need to be, because parts can be swapped, added or removed as needed.
The kernel don't care what your initial process is (you can for instance point the Linux kernel straight at the sh binary and be presented with a root shell the moment the kernel is done getting the hardware up and running), and the programs you want to run don't care either.
Thus you can run nix on anything from a dinky single core SoC to a warehouse sized compute cluster.
But systemd is pandering the latter while giving the former the middle finger. This by ignoring the text in text out loose bindings that has been the core of *nix.
I'm not trying to be facetious...What part of X11 matches the text in/text out -- small programs that do one thing -- mode? Even Linus says that "model" doesn't really apply any more.
Maybe systemD and it's author's are whatever...I think that the CoreOS people are demonstrating that programmatic administration is the best model for massive scale. That's my only point.
That's quite the most carefully hedged "please don't kill me" comment I've read in a long time :)
I suspect there's a scaling issue in here as well. Tools optimised for large numbers of systems are always going to look clunky and overdesigned when used on a single system.
With regard to APIs, I think this is one area where the availability of source is quite critical. "Control Panel" is clearly a tool that manipulates some API, as are all the snap-ins, but because I can't see the source
(I recently had to fix a WinCE issue by trawling the source to find the right registry key. While Windows has a power user community, WinCE really doesn't, and is subtly different in enough places to cause problems. Google sometimes makes me feel like I'm the only person using CE 7)
Wow. Before I start...that's cool that you are using CE. What are you using it for? (If you don't mind and have a minute.)
I get what you are saying. I don't think that the programmatic model of administration works for running something like PeopleSoft, right? You use large hosts that are very special and benefit from the traditional admin model. It's very much a "pet"...where the CoreOS model is more "cattle".
I'm more ambivalent about access to source as long as there is good documentation and debugging tools. I'm not going to fix a kernel bug at this point in my development. Maybe one day...
From what I know, you can use Microsoft RPC to pull event logs or you can install a syslog forwarder, or you can do a combination of these two things (have a Windows syslog forwarder that is not a DC that can pull logs from a DC through RPC). The problem with the last option is, adding another Windows server costs an additional license. Installing a client on the DC doesn't. And there are limitations, so in a huge Windows environment, you're installing several extra Windows servers, each individually licensed, just to forward logs.
I've worked in security with several different SIEMs for half a decade and those are the only options I've ever seen. So if there's something else besides this that is easier, it's not just me who is missing it. HP, Dell, Intel and a dozen other companies are missing it as well.
Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller.
Its not just RPC. That's the thing I've noticed about a lot of security people... they don't even really pretend to take windows seriously despite its insanely large footprint and exposure at an organization. For what its worth... most IT people are just as bad. I'm trying to turn that around at my organization. I don't blame people...I get it. It just takes time to disseminate info.
>Any place large enough to need a SIEM wouldn't balk at licensing a server or servers if it was explained to them that you wouldn't need yet another highly privileged agent running on a domain controller.
You'd be surprised at how many organizations will have the management spend $1.5m on a SIEM but the engineers refuse to use another Windows license.
There are ways to collect Windows logs. It's just not as easy as collecting syslog. And syslog doesn't need a user account to collect logs.
I heard this kind of thing from a vendor the other day. It's like people don't even try to learn how it works.
Why are they different? The event log has some transactional guarantees that were required for a specific kind of security evaluation...C2? I can't remember the rest.
The thing is...you don't have to install a client on the domain controllers. You can setup forwarding to some log hosts and collect them there.