Port 25: The Open Source Community at Microsoft : Technical Analysis, Linux

Technical Analysis: Apache with mod_auth_kerb and Windows Server

jcannon — Fri, 25 Jan 2008 21:58:00 GMT

Abstract: The Apache authentication module mod_auth_kerb allows Apache to authenticate users against a Kerberos KDC including one from ActiveDirectory. Kerberos itself can be fairly complex to set up. This guide will attempt to show the specific steps required to make this possible as well as discuss security limitations specific to the interoperability matters. This guide assumes a basic understanding of Kerberos V and that the Active Directory domain controller is properly configured prior to starting this process.

Note: This paper represents testing and documentation in a lab environment. User Account Control (UAC) is an essential security component to Windows and Microsoft does not recommend turning off UAC in production environments.

Technical Analysis: Active Directory and Linux Identity Management

jcannon — Tue, 11 Dec 2007 19:22:00 GMT

Abstract: This paper is written for a somewhat technical audience and covers how the identity management expectations differ between the Windows Server platform and Linux - and how Windows Server can be used to manage both. This paper assume that the reader is familiar with general Windows administration tasks, such as user management.

Note: This paper represents testing and documentation in a lab environment. User Account Control (UAC) is an essential security component to Windows and Microsoft does not recommend turning off UAC in production environments.

Technical Analysis: Recovering Data from Windows systems by using Linux

jcannon — Tue, 20 Nov 2007 17:19:00 GMT

Abstract:
We have all run into cases where Windows fails to load for one reason or another. The problem may be hardware or a software failure, and the problem may seem to be irrecoverable. Yet often Linux can be used to help recover data that otherwise might be lost. Another application of using Linux recovery is in the creation of disk images for post-mortem analysis of security breaches. While such images are not created according to forensics standards (which usually requires special hardware) and would not be likely to be of help in legal cases, they are helpful in internal reviews following such incidents.

Technical Analysis: Recovering GRUB, Dual Boot Solutions

jcannon — Tue, 30 Oct 2007 18:43:00 GMT

Today's post returns Port 25 to our more regular technical analysis that examine common technical scenarios when running Windows and Linux together, or Windows and other popular open source projects. This week, the lab looks at at disk recovery options using GRUB and dual boot scenarios.

Abstract:
Those of us who dual boot have seen it happen. Somewhere down the line, we overwrite the bootloader (or configure it to ignore one of the operating systems) and suddenly we can only boot into one of the operating systems. Probably the most common causes of these issues involve the use of fdisk /mbr and Windows installations overwriting GRUB or LILO (but it happens with Linux too). In this paper, I will assume that you can only boot into Windows, and that you have decided to use GRUB as your bootloader. A few of these notes are distribution-specific and those portions will be clearly marked. However, most of the process will work on any Linux distribution which conforms to accepted standards.

Data Recovery Using Linux

MichaelF — Thu, 24 May 2007 20:15:00 GMT

It's happened to me and I'm sure it has happened to you: your software won't load and your data is now trapped inside your PC. The problem may be a hardware or a software failure, and the problem may seem to be irrecoverable. Yet often Linux can be used to help recover data that otherwise might be lost. This paper describes how one can use Linux to recover data from a non-functioning Windows machine.

Windows Vista Beta/Linux IPsec Interop Testing

MichaelF — Wed, 09 May 2007 21:27:00 GMT

In addition to technical tips, blogs and video interviews, the Open Source Software Lab at Microsoft conducts a number of technical analysis and research projects throughout the year to help inform and solve key interoperability challenges between Microsoft and open source technologies. This particular research was conducted after reviewing data from our VPN research which was previously posted to Port 25.

Abstract:

This document provides an overview of Linux IPsec solutions as well as detailed discussions on configuring IPsec-Tools for interoperability scenarios between Red Hat Linux Enterprise 4 and Windows Vista Ultimate Beta.

Technical Analysis: Linux VPN & How-To

jcannon — Fri, 09 Mar 2007 19:08:00 GMT

In our continuing series of papers describing both the research undertaken by the Open Source Software Lab, and technical tips, here is the latest networking configuration technical analysis.

Abstract:
This document provides the reader with an analysis of VPN functionality within the Linux operating system. Specifically, it provides a breakdown of VPN components and a description of what is available to Linux Administrators, in terms of manageability and functionality. It also provides a set of HOW-TO’s in the area’s of VPN and IPsec.

Using Vista's Boot Manager to Boot Linux and Dual Booting with BitLocker Protection with TPM Support

MichaelF — Fri, 13 Oct 2006 19:57:00 GMT

Today we are introducing Cyril Voisin, Security Advisor for Microsoft in France where he has worked for 9 years. Cyril is a CISSP (Certified Information Security Systems Professional) and along with his work at Microsoft also teaches systems and network security in local schools as time allows. Cyril has started a blog, primarily focused on security (exact blog intent can be seen here) but occasionally dealing with interoperability as it relates to security.

Cyril has given us permission to syndicate his content on Port 25, the first example is below. Please feel free to post any questions or clarifications below or on Cyril’s blog.

We welcome Cyril to Port 25 and look forward to featuring his work and insight in the future.

-michael

-------------------------------------------------------------------------------------------------------

How to use Windows Vista’s Boot Manager to boot Linux

The Web is full of explanations on how to dual boot Windows and Linux using a Linux boot manager like GRUB or LILO. If you want to dual boot Windows Vista and Linux using Windows Vista’s Boot Manager, please read on. I will assume that you already have installed Linux on your machine using GRUB as your boot loader.

Step 1 – Install GRUB on the Linux partition (outside of MBR)

As Windows Vista will replace the Master Boot Record (MBR) with its own, we need to relocate GRUB elsewhere by running grub-install with the Linux partition as a parameter.

• On Linux, launch a Terminal with root privileges

• Find the name of the partition Linux is installed on by running fdisk –l (the partition you’re looking for is the one whose system is Linux, can be something like /dev/sda1 or /dev/hda1. For the rest of this post, I’ll use /dev/sda1)

• Install GRUB on the Linux partition by running : grub-install /dev/sda1

Step 2 – Get a copy of Linux boot sector

We will need to instruct Windows Boot Manager how to boot correctly Linux using Linux boot sector, which we will extract using dd.

• On Linux, launch a Terminal with root privileges

• Take a copy of Linux boot sector : dd if=/dev/sda1 of=/tmp/linux.bin bs=512 count=1

• Copy linux.bin on a FAT formatted USB key or any storage accessible from Windows Vista

Step 3 – Install Windows Vista

Step 4 – Configure dual booting in Windows Vista

We will create an entry for GRUB in Windows Vista boot configuration data store using bcdedit.

• On Windows Vista, launch a command prompt with administrative privileges (by right clicking on cmd and choosing Run as Administrator)

• Copy Linux boot sector on the root of the Windows boot (active) partition, namely the one containing bootmgr. If you don’t know for sure you can use diskpart or diskmgmt.msc to find out which one it is.

• Create an entry for GRUB :

o bcdedit /create /d “GRUB” /application BOOTSECTOR

o Note: bcdedit will return an ID for this entry that we will call {LinuxID} below. You will need to replace {LinuxID} by the returned identifier in this step. An example of {LinuxID} is {81ed7925-47ee-11db-bd26-cbb4e160eb27}

• Specify which device hosts a copy of the Linux boot sector

o bcdedit /set {LinuxID} device boot

• Specify the path to a copy of the Linux boot sector

o bcdedit /set {LinuxID} PATH \linux.bin

• Add Linux entry to the displayed menu at boot time

o bcdedit /displayorder {LinuxID} /addlast

• Let the menu be displayed 10 seconds to allow for OS selection

o bcdedit /timeout 10

Building a dual boot system with Windows Vista BitLocker protection with TPM support

Many people have wondered if it would be possible to dual boot a TPM-bitlockered instance of Windows Vista with Linux, or another OS. The answer is yes and the following procedure will hopefully help you setup your machine correctly.

Some (simplified) background on Bitlocker:

Bitlocker Drive Encryption allows encryption of Windows Vista’s partition and provides a secure startup process when in use with a TPM (a crypto chip on the motherboard). Basically the BIOS, the TPM, the MBR and the boot sector will collaborate to help verify that there was no modification to the boot sequence since Bitlocker was activated. This is done by using a function of the TPM to compute and store a hash of the code before executing it, at each of the initial steps of the boot sequence. Different hashes will be computed and stored in specific registers of the TPM. Then Windows Vista will ask the TPM to unseal its volume encryption key and the TPM will only provide this key if its registers are correctly set. Therefore if you replace Windows Vista’s MBR by a MBR that is not TPM aware, it won’t hash the boot sector before executing it and a register in the TPM won’t be populated. Same with the boot sector. Therefore Bitlocker will simply refuse to be enabled.

The underlying idea here is to have Bitlocker enabled with the original Windows Vista boot files. Another possibility would be to use a TPM-aware version of GRUB. However this would imply using files in the boot sequence that were not tested by Microsoft, which I would not recommend. Moreover, using original Windows Vista files offers you the benefits of code that went through the Security Development Lifecycle, which I personally find very valuable.

Note: I assume that you have a Bitlocker compatible machine (including TPM 1.2, TCG BIOS). See http://www.microsoft.com/technet/windowsvista/library/c61f2a12-8ae6-4957-b031-97b4d762cf31.mspx#BKMK_require

Step 1 – Install Linux

Note: be sure to leave enough unpartitioned space for Windows Vista: about 11 GB of free unpartitioned space and slots for 2 partitions are needed

Step 2 – Install GRUB on the Linux partition (outside of MBR)

See other post “How to use Windows Vista’s Boot Manager to boot Linux”

Step 3 – Get a copy of Linux boot sector

See other post “How to use Windows Vista’s Boot Manager to boot Linux”

Step 4 – Create partitions for Windows Vista

We need to create 2 primary NTFS formatted partitions on the disk: one active, 1.5GB size minimum and another larger (all the rest for instance with a minimum of 8.5GB). The former will be used to boot the machine (active partition) and will remain unencrypted while the latter will host Windows Vista and will be encrypted when we activate Bitlocker.

You can use diskpart tool to do this (available from Repair options on the Windows Vista DVD). Here is what the instructions may look like :

· select disk 1

· create partition primary size=2048

· active

· create partition primary

Step 5 - Install Windows Vista

Install Windows Vista on the largest NTFS partition.

Step 6 - Set up Windows Vista Boot Manager to boot Linux

See other post “How to use Windows Vista’s Boot Manager to boot Linux”.

Step 7 - Enable BitLocker on Windows Vista

See BitLocker documentation, like http://www.microsoft.com/technet/windowsvista/library/c61f2a12-8ae6-4957-b031-97b4d762cf31.mspx#BKMK_S3

Networking Roles Analysis Part Two: FreeRADIUS

MichaelF — Thu, 14 Sep 2006 15:45:00 GMT

In addition to technical tips, blogs and video interviews, the Open Source Software Lab at Microsoft conducts a number of technical analysis and research projects throughout the year to help inform and solve key interoperability challenges between Microsoft and open source technologies. This paper is part two of three. The first paper in this series discussing DHCP can be found here.

Abstract:

This paper is an evaluation and teardown of the GNU GPL-licensed FreeRADIUS software (http://www.freeradius.org/). This document includes a detailed analysis of the features that are supported by the server as well as an analysis of the configuration, management and overall usability of the system.

Much of the analysis was done on a RedHat Enterprise Linux version 4 (RHEL4) system using the vendor-supplied FreeRADIUS package, which at the time of writing is version 1.0.1. The latest package from the project website is version 1.1.0, which was also analyzed for additional features.

Download the Networking Roles Analysis-Free RADIUS paper (.PDF, 396k)

Honeypots and User Mode Linux Part 2: Forensic Analysis

MichaelF — Fri, 04 Aug 2006 19:50:00 GMT

UML (User Mode Linux) and Forensic Analysis

(Special thanks to Dan Simonton for the testing and writing in support of this tech tip)

Processes running under UML will have no access to the hosting system, accept where explicitly allowed. Because of this UML is an ideal candidate for operating a honeypot. While processes running in UML have no outside access to the host operating system memory or filesystem; hypothetically, if an attacker managed to break out of userspace into some section of the host filesystem, they could do further damage on the host . Best-practice demands that host access be limited within the UML instance wherever possible.

For any of this to be practical, obviously some services would need to be established. We’ll just assume these are already in place and forwarding iptables rules setup on the host. For instance, to forward inbound http connections to your UML instance:

iptables -t nat -A PREROUTING -i eth0 -p tcp -s 0/0 \
--dport 80 -j DNAT --to-destination (uml ip):80

This process could be repeated for any other service you wish to run. Just be sure the appropriate destination port is specified both with the “--dport” option and also at the end of the command. Essentially you are instructing all inbound traffic to port 80 to be forwarded to your UML. The same process could be repeated for ssh,ftp and others.

Typically, the first order of business for an intruder with root access is to wipe out log files. It is best therefore to have log files written to the host (or another remote) machine. To achieve this, the host system’s syslogd daemon must be configured to receive inbound logs. Add “-r” to the runlevel script of the host machine where it invokes syslogd the correct path is: /etc/rc.d/syslog. On the client machine, add the following to /etc/syslog.conf:

*.* @yourhostmachine
(note: @ipaddress will work also)

Now inbound connections to the UML honeypot and activity on the honeypot can be investigated through log files on the host machine.

Conveniently for the purpose of running UML as a honeypot, tty_logging of UML into a directory on the host machine is built as an option into the kernel. The simplest way to achieve this is to add the following to the kernel command line:

tty_log_dir=dir

This way, even if they zap the shell log files on the UML, you will still have an account of their activity on the machine.

There are a few quick and common methods of checking running activity. The following two should be familiar to anyone with a relatively basic understanding Linux, but we’ll mention them here for propriety’s sake:

ps auxwww (check running process table)

netstat –lvnap|less (check open sockets, associated process, and user ids)

In the past, whenever I’ve found any strange binaries (sometimes named something really vague or obscure), I’ll run the following command, sift through, and evaluate the output:

strings (filename)|less

An all-to-commonly overlooked tool for inspecting a system is “lsof” (list of open files). It can be used to check file-to-file access, files listening on a socket and evaluate the state of a running process. It is helpful to know the normal running health of a system for comparison when using lsof. For a quick check of a specific process:

lsof –p (pid)

To get socket info on a process:

lsof -i -nP|grep -i (process name)

To protect against potential outbound denial-of-service attacks, it might be prudent to explicitly declare hosts you wish to allow outbound ICMP traffic to (the host ip being one for example) and deny everything else. This can be done on the host by adding the following rules to iptables. You can add as many “ACCEPT” rules as you need, just be sure to put them before the “DROP” rule.

        iptables -A INPUT -p icmp –s (uml ip) –d (host ip) –j ACCEPT
        iptables –A INPUT –p icmp –s (uml ip) –d (other ip) –j ACCEPT
        iptables –A INPUT –p icmp –s (uml ip) –d 0/0 –j DROP

Similiarly, you could block potential outbound syn-flooding:

   iptables -N syn_flood
     iptables -A INPUT -p tcp --syn –s (uml ip) -d 0/0 -j syn_flood
     iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j
RETURN
   iptables -A syn_flood -j DROP

A quick search of http://sourceforge.net or http://freshmeat.net will quickly realize a vast sea of various analysis tools. Provided the disk image size for your is adequate, any of these can be copied to the drive image or simply downloaded once you have the UML instance running. A few useful tools are:

Tripwire: Useful for monitoring data integrity. In a nutshell, it takes a snapshot of your system binaries (or other specified directory), creates a checksum, runs routine system integrity checks against it, and reports any deviation.

The Coroner's Toolkit: A suite of utilities for checking running process and file/filesystem information, recent changes and other such information.

Snort: Snort is so prevalent, it almost needs no description. Still, it is one of the best tools for traffic analysis and intrusion detection. To accurately provide a description that does this monster justice would be a blog unto itself. There is a great FAQ on their website:

http://www.snort.org/docs/faq/1Q05/

Chkrootkit: A utility for identifying rootkits installed on the system.

This is but a small (microscopic) primer into a much larger world of intrusion detection and integrity analysis, but we hope some may find this useful. We will likely delve into these subjects in the future.

Honeypots and User-Mode-Linux (UML): Part 1

jcannon — Sun, 23 Jul 2006 22:21:00 GMT

Honeypots and User-Mode-Linux (UML)
Part I: Setting up UML

(Special thanks to Dan Simonton for the testing and writing in support of this tech tip)

In technical terms, a honeypot performs a function very similar to that of a “honeypot” in the outside world: a sweet lure. A “honeypot” is a system designed with the purpose of attracting the attention of prospective attackers, to assess how they are attempting to infiltrate the machine and what they doing once they gain access. There are literally thousands of honeypot networks and systems setup by security professionals and hobbyists worldwide. These systems can provide a wealth of information into forensics and assessing trends in network intrusion.

This is Part One of a two part tech tip, which will address the setup of User Mode Linux (UML) for honeypot use. Part Two of the tech tip will cover the containment of intrusions and other security topics that arise while using UML as a honeypot. Also addressed in Part two will be the “forensics” i.e. identifying what exploits were tried on the honeypot.

One of the more popular methods for constructing honeypots in the Linux world is to set up a kernel to run in “user mode” on a host Linux machine. In function, this is very similar to running a “Virtual PC” on a Microsoft Windows or Apple Macintosh system. The primary difference is that “User Mode Linux”, or UML is open source and (depending on your personal depth of knowledge of the Linux kernel) you can really tweak any and every aspect of the host and UML kernel to your liking.

User Mode Linux is essentially an entire operating system running as a program in user space. It masquerades as an OS because for most purposes, it is one. The immediate benefit of running a honeypot this way is that with proper precautions taken, there is no significant threat to the host machine, or its operating system. When or if an attacker gains control of the UML instance, you can simply shut it down and restart at no cost to the hosting machine’s uptime or stability.

The first step is to download a copy of the actual kernel source that you wish to compile on the designated host machine. This can be obtained from http://www.kernel.org/ or any associated mirror site. In this tech tip we will use the 2.6.16 kernel. The patches for the UML kernel can be obtained from:

http://www.user-mode-linux.org/~blaisorblade/patches/skas3-2.6/skas-2.6.16-v8.2/skas-2.6.16-v8.2.patch.bz2

You will also want to create a filesystem for the UML. In the interest of time and space, there are a number of filesystems that can be downloaded for various distributions from:

http://uml.nagafix.co.uk/

In this example we will be using Slackware-10.2

First of all, the standard commands are applied to unpack the source

$ tar –zvxf linux-2.6.16.tar.gz
$ bzip2 –d skas-2.6.16.-v8.2.patch
$ cp skas-2.6.16.-v8.2.patch linux/
$ cd linux-2.6.16/
$ patch –p1 < skas-2.6.16.-v8.2.patch

Note: In every step of the build process, it is crucial that the “ARCH=um” argument be passed along with the various kernel configuration and compilation commands.

Next we will clean out any .config files (if any are present) and generate a default configuration:

$ make mrproper && make mrproper ARCH=um
$ make defconfig ARCH=um

Now we manually check and edit the configuration:

$ make menuconfig ARCH=um

At the very top of the list are UML-specific options. It is important to know what some of these are:

[ ] Tracing thread support
[*] Force a static link
[ ] Host processor type and features --->
[ ] Three-level pagetables (EXPERIMENTAL)
[ ] Memory model (Flat Memory) --->
[*] Networking support
[*] Kernel support for ELF binaries
<M> Kernel support for MISC binaries
< > Host filesystem
< > HoneyPot ProcFS (EXPERIMENTAL)
[*] Management console
[ ] Magic SysRq key
(0) Nesting level
[ ] Highmem support (EXPERIMENTAL)
(2) Kernel stack size order
[*] Real-time Clock

There are two options here in particular to take note of.

The first is the “Host Filesystem” option. This gives the UML Linux kernel access to the host filesystem. If you enable this, be careful how the access is applied. A safe course is to apply extended mount and read-write restrictions over filesystems on the host machine.

The second is the “HoneyPot Procfs” option. This essentially overwrites entries in the /proc filesystem of the UML kernel with that of the host. This is useful in that it removes fingerprints which might otherwise indicate the host is a honeypot. It could also be a potential troublespot for someone could map out the architecture of the hosting machine using this information. This is less of a threat than it is something to keep in mind.

NOTE: Be sure to include general kernel support for ext2, ext3 and reiserfs.

Looking further down from the kernel configuration tree, see the options for UML network devices. If you want to get to the outside world from the user mode kernel, be sure to enable ethertap and tun/tap support. This will allow the user mode kernel to communicate with the host tun/tap device.

Be sure to check any other “non-uml” options for your kernel that might be relevant to your machine. There is one last step before you can build the kernel. Due to a macro called by the patch that is now deprecated, one of the kernel source files must be manually edited. In whatever text editor you prefer, open up the file: (within the source tree) arch/um/os-Linux/sys-i386/registers.c and add the following to the preprocessor directive:

#ifndef JB_PC
#define JB_PC 5
#define JB_SP 4
#define JB_BP 3
#endif

Once all this is done, build the kernel with:

$ make ARCH=um

At this point, we have our hard drive image (with distribution) and a UML Linux kernel. We have a few more things to set up on the host before we are ready to boot our UML instance. First, we need to make /dev/net/tun writable (by the user the UML kernel will be running as). The quick and dirty way to achieve this is to make it world writable (NOTE: not a “best practice”, just a quick way to get from a to b).

Alternatively you could create a separate group with write access to /dev/net/tun. Tun0 which is a tunneled interface to eth0, is used to negotiate traffic between the user mode kernel and the primary physical interface of the host machine. To configure the 1^st interface (tun0)

tunctl –u umluser umldev

This command invokes tunctl, specifies the creation of a device, assigns ownership to user (via –u) to “umluser” and name its “umldev”. The IP side is configured the same way as a standard Ethernet interface via ifconfig:

ifconfig umldev (ip address)

We’re ready to start our instance. We’ll want to specify the Ethernet device on start.

linux ubd0=Slackware-10.2-root_fs mem=256M eth0=tuntap,umldev

Once you are asked for a login, simply enter “root” and it should drop you right to a shell.

dhcpcd: MAC address = fe:fd:00:00:00:00
Starting OpenSSH SSH daemon: /usr/sbin/sshd
Updating shared library links: /sbin/ldconfig

Welcome to Linux 2.6.16-skas3-v8.2 (tty0)

yadda-yadda login: root
Linux 2.6.16-skas3-v8.2.
Last login: Thu Jul 20 00:53:38 +0000 2006 on tty0.
You have mail.
root@yadda-yadda:~#

On the UML side, use ifconfig to give an ip address to eth0. This needs to be something routable by the umldev IP of the host machine. The route then must be set to the outside world (via the host umldev interface).

route add default gw (umldev ip)

On the host, packet forwarding and proxy_arp must be enabled:

Host# echo 1 >/proc/sys/net/ipv4/ip_forward
Host# echo 1>/proc/sys/net/ipv4/conf/umldev/proxy_arp

Now you should be able to reach the outside world from UML:

[uml@yadda-yadda]$ ping www
PING www.yadda-yadda..com (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=127 time=12.1 ms

root@yadda-yadda:~# ssh www.yadda-yadda.com
root@www.yadda-yadda.com’s password:
Last login: Thu Jul 20 11:00:50 2006 from yadda-yadda.com
[root@www ~]#

You should have a functional UML kernel running in its most basic form. You may kick it around, experiment with distributions (see links provided below), or otherwise abuse it as you see fit without consequence to your hosting system. This entry barely scratches the surface of one use of a usermode kernel, but if you have not considered running one before or are new to the idea, we hope this provides some useful information. Below are some links to some other resources, as well as the user-mode-linux project homepage.

http://user-mode-linux.sourceforge.net/ - UML Project homepage
http://www.honeynet.org/misc/project.html - The honeynet project
http://uml.nagafix.co.uk/ - A repository of disk images to use with your kernel

Running Windows Command Line Applications from a Linux Box

admin — Wed, 19 Apr 2006 19:42:00 GMT

Running Command Line Applications on Windows XP/2000 from a Linux Box:

Question:

-----Original Message-----
From: swagner@********
Sent: Thursday, April 13, 2006 2:35 PM
To: Port25 Feedback
Subject: (Port25) : You guys should look into _____
Importance: High

Can you recommend anything for running command line applications on a Windows XP/2000 box from within a program that runs on Linux? For example I want a script to run on a Linux server that will connect to a Windows server, on our network, and run certain commands.

Answer:

One way to do this would be to install an SSH daemon on the Windows machine and run commands via the ssh client on the Linux machine. Simply search the web for information on setting up the Cygwin SSH daemon as a service in Windows (there are docs about this everywhere). You can then run commands with ssh, somewhat like:

ssh administrator@<hostname> 'touch /cygdrive/c/blar'

That will create a file in C:\ called "blar". You can also access Windows commands if you alter the path in the cygwin environment or use the full path to the command:

ssh administrator@<hostname> '/cygdrive/c/windows/system32/net.exe view'

Managing the Lab: SMS and our mixed environment

admin — Fri, 31 Mar 2006 15:00:00 GMT

Getting the Open Source Software Lab up and running presented a number of challenges – not the least of which was how we were going to manage fifty Linux distributions, fifteen versions of UNIX, and multiple Windows instances deployed across literally hundreds of physical and virtual servers. This is quite a job for any management solution. Being the pragmatists we are, we decided to use this to test the viability of SMS (Microsoft Systems Management Server) using VMX (Vintela Management Extensions) in a mixed environment.

We deployed the solution and found it to be capable of handling our environment. Currently a large part of the lab is managed by SMS and VMX. When we describe this to people we are often asked, "Why does Microsoft supports this kind of solution? Why do we care about mixed environments?"

We asked Bill Anderson, Lead Program Manager on the Windows Management Team, and here is what he had to say:

Bill Anderson
Not really, but his lab is less camera-shy.

The first question I always get asked is, “what really was the catalyst for SMS to seek out a partner to provide extensions to OSS/Linux? Simple – our customers demanded it. Our existing SMS customers are managing both desktops and servers, and have a multitude of platforms in production in those environments and wanted to extend the success they have with SMS on Windows to those additional platforms. And, as we’re driving SMS into new customers, it has become one of the top requirements for customers – an integrated solution to manage all their critical platforms.

Now, the second driver was the WAY in which the market was doing cross-platform management. It’s, well, “suboptimal”. You either take 2 management systems (Windows mgmt, non-Windows mgmt) with their own array of servers, agents, and databases – and join the databases, or you try to take one agent that runs on all platforms, and you can then only join the things that are the same/similar. You either get a bunch of extra infrastructure with no leverage of skillsets, or you get a lowest common denominator management experience.

What we did was option 3 – build a single shared infrastructure that was extensible at the protocol, data, and UI layer, and then take the 2 leaders in the field to build from that same plumbing. So, we optimized our agents for the work on Windows, and we worked with the Vintela team as the experts in managing OSS/Linux to really optimize their experience for that platform. So, what does a customer get? 1 database, one UI, one protocol, and agents unique to each platform. Low operational cost, leveraged skillsets, and the opportunity for each vendor to really highlight the best they could do on each platform. Some of the things that Vintela can surface and manage on the Linux platform, using SMS as a pipeline, are pretty amazing! They’ve extended our UI to really expose all the remote functions available on Linux from the different vendors like Red Hat, SuSE, HP, and Sun. My challenge to them was to make Linux look BETTER in SMS than Windows does. We’ll try to make Windows more manageable by adding more, not by restricting. And the results are pretty compelling. As Andi put it in Network World's Network/Systems Management Newsletter: “Yes, you read that correctly - Microsoft tools can make Linux management easier. To its credit, Microsoft has made this easier through partnerships and programs like its Dynamic Systems Initiative - a commitment from Microsoft and its partners to deliver self-managing dynamic systems…(snip). This allows enterprises to leverage their investment in native Windows tools to make them a very effective management platform for diverse networks. “

How the Vintela solution works is really pretty simple. They take a WBEM based agent (they are the project maintainer for OpenWBEM) that runs on the major OSS platforms, that points at a URL that is our Management Point role. They extend our MMC based UI and voila – instant management for Linux! No database schema changes required, no separate middle infrastructure, etc. Initially, there was an ISAPI.dll “gateway” they had built to convert their agent protocol to ours at the Management Point, but we’ve worked to even eliminate that as they are now using our native protocols. As you can see, this is a slam dunk for a customer using SMS already to manage Windows that wants to extend it to manage Linux. It’s amazing to walk to an SMS admin, open their admin UI, have them see machine collections based on Linux versions/vendors, and be able to send software to a group of Linux machines in about 3-4 clicks. But, we’re even seeing customers use THIS as a solution for managing Linux only! Vintela has done a great job of really just using the SMS UI, database, and pipes as their engine, and leveraging all the

manageability on the native Linux platform to provide a great stand-alone tool for managing Linux. Inventory, software distribution, patch management and remote tools – all in one single UI and infrastructure. The other key is really leveraging the OpenWBEM work to provide consistent management on different Linux versions. The Vintela team has done a great job of driving consistency via OpenWBEM, but still leverage all the extra tools and functions provided by each Linux vendor. If I were managing Linux systems (not a lot of that around here by the way!) I’d definitely use it!

For more info, I’d also suggest taking a peek at the EMA document they did for Vintela at http://www.vintela.com/products/vmx/docs/Managing_Heterogeneous_IT_with_SMS_EMA.pdf.