[Resending per moderator direction with a different subject and some
edits.]

On Mon, Jul 02, 2007 at 06:34:53PM -0700, Eric Fitzgerald wrote:

> Regarding security, it doesn't matter if the whole rest of the world
> uses telnet, SNMP and syslog for management, Microsoft cannot afford
> to.

First off, that's a straw man: syslog is only used for auditing, not
for authentication or modifications to servers, so the security
implications are much less dire. That said:

* Microsoft provides a telnet server for Windows 2003. IIRC, it's even
installed as part of a default install, but isn't enabled by default.

http://technet2.microsoft.com/windowsserver/en/library/50e5f563-e055-4d7
1-aa92-ebde2b2794761033.mspx?mfr=true

* Microsoft provides an SNMP server for Windows 2003.

http://technet2.microsoft.com/windowsserver/en/library/4af2771e-80b0-446
3-bb9e-ca058567ee8a1033.mspx?mfr=true

* Microsoft also provides an FTP server for windows 2003 / IIS 6.0.
IIRC, also installed by default.

http://technet2.microsoft.com/windowsserver/en/library/2d89255f-59f7-483
1-9c7a-f1db4fd54e2e1033.mspx?mfr=true

Like many vendors, Microsoft gets away with including telnet, FTP, and
SNMP servers because it also includes more secure alternatives, allows
the insecure servers to be shut off, and doesn't enable the insecure
servers by default. Shipping a syslog agent in a disabled-by-default
mode would be equivalent, and certainly is no worse than shipping
telnet in a disabled-by-default mode.

> I know that many, perhaps a majority, in this forum would like
> Microsoft to drop eventlog and just put a syslog agent in Windows.

No. I would like MSFT to add an officially-supported syslog agent,
not get rid of the existing eventlog. There are third-party products
that already add syslog to Windows, so there is no reason it cannot
come with the OS. It does not need to conflict with existing eventlog
support, just as the telnet server you ship with does not conflict
with MSFT terminal services, and just as the existing third-party
syslog agents do not conflict with the existing eventlog.

> Based on what I know of Microsoft's business interests, technology
> investments and decision making process I do not believe that is
> going to happen, but it's not my decision nor has it ever been.

That's fair enough.

> Regarding management strategy, it's not exactly my idea of fun going
> into a meeting with my VP and trying to explain to them why they
> should spend dev resources on a feature whose sole purpose is to
> enable their Microsoft product to be managed by *nix systems.

There are plenty of people out there running syslog servers such as
Kiwi syslog server and Ciscoworks on Windows servers, in "pure"
Windows environments. They do this to accomodate network devices
(i.e. Cisco, Juniper, Marconi, etc.) and even to accomodate Windows
devices using existing third-party syslog agents. In such an
environment, being able to leverage existing syslog-management tools
makes a lot more sense than needing to incorporate a vendor-specific
tool. This is not theoretical -- I know of such shops.

>From a strategic perspective, this may also be a "foot in the door"
for you guys into pure Unix shops. If a Unix shop has a syslog
infrastructure, and you don't support syslog, said Unix shop can keep
out your servers on the basis that vendor-specific log compliance
tools would be a major expense. The expense is not only for upfront
tool costs, but also for integration with related systems
(i.e. paging, ticketing, operations consoles, etc.) If your servers
can leverage existing log infrastructure, it's easier to incorporate
them.

- Morty
_______________________________________________
LogAnalysis mailing list
LogAnalysis (at) loganalysis (dot) org [email concealed]
http://www.loganalysis.org/mailman/listinfo/loganalysis

[ reply ]