Microsoft Warms Up to Linux

prostoalex writes "InfoWorld reports that despite warming to the OS, Microsoft won't be releasing its own distribution of Linux any time soon. From the article: "Hilf acknowledged that Microsoft's commitment to Windows does not preclude the company from continuing a strategy he has led in his 19 months at the software vendor: To see how Microsoft's proprietary technologies can better interoperate with Linux and a host of other open-source software. In fact, that is exactly what will be the focus of a discussion the long-time open-source proponent will lead at this year's upcoming Linuxworld Conference & Expo next month in San Francisco. In a session entitled, 'Managing Linux in a Mixed Environment ... at Microsoft?' Hilf, who polished his open-source evangelism skills working on Linux deployments at IBM Corp., will talk about how he and the team at the Linux/Open Source lab run open source technologies in "the most Microsoft-centric IT environment on the planet." "

Comments

Quick!

[ucahg]

Somebody prove this wrong. Microsoft can't like Linux, it must all be talk, right? *head explodes*

Re:Quick!

[AKAImBatman]

It's just the same Embrace and Extend tactics that Microsoft has always used. When Windows 2000 came out, Microsoft promised perfect Unix interoperability. Of course, they subtly changed the Kerberos protocol and several other protocols to favor Microsoft's OS in the domain controller position, allowing them to later push Unix as legacy stuff Microsoft is helping you get rid of.

The fun part is that I asked a Microsoft rep about the Kerberos problem and he lied to my face.

You've heard of "If you can't beat 'em, join 'em?"
For Microsoft it's, "If you can't beat 'em, pretend to join 'em, then stab them in the back when they're not looking."

Warms up?

[Magada]

You know what they say ... if you can't beat them ... embrace and extend.

It's like gravity

[A beautiful mind]

The big planet-sized MS is starting to feel the Linux moon's effects. Oh wait, that's no moon!

the battle for management is just warming up

[rapiddescent]

I think the Microsoft understand that the battle of the OS is not where the real money is - the real money spinner is beating HP OpenView in the server/desktop management space and also owning the signing-in credentials (Active Directory) - these two things are FAR more important than old wars against Linux and open source. They know that Linux boxes are always going to be in the enterprise so they've thought up a strategy to make sure that they are within the MS management pool. A caring & sharing attitude will also fix some of the perception of arrogance that MS have with the Office of Government Commerce in the UK and similar procurement organisations outside the USA.

for example: In most places I've been to, the customer has MS Active Directory in place. (I'm an enterprise TA specialising in Linux). That makes MS in a very strong position to be first choice for single sign on content management systems, document management platform and also system monitoring & management. The usual BS I hear is that AD makes it easier for the helpdesk to manage users and groups and so on.

MS have been quietly making big investments in enterprise management. remember SCO, how could you forget!, there was one product that SCO sold off to a management buy-out and was rumoured to have been heavily funded by MS - this is Vintela. Vintela sells a single sign on solution for multiple OS (including Linux) that will allow Linux users to sign in as AD citizens into Linux and be managed just like the MS users.

Another example is the new drive for MOM. MOM is essentially where HP Openview was some years ago. HP OpenView has never got the pervasive coverage in organisations because it costs a bloody fortune and HP have been too stupid to commodotise the HPOV server infrastructure into something cheaper. Also, having an enterprise OpenView system takes manpower to setup correctly. The result is a catch 22 - the companies that actually need it; don't have spare manpower - hence the reason they need an enterprise monitoring/management suite! MS MOM is a big step in the direction of Windows simple click (and break!) user interface that is convincing to management who will sign off procurement decisions. The MOM interface is surprisingly better than HPOV - plus MOM will also support Linux and Solaris boxes in the enterprise. I don't think it will be long before MS provides management hooks for JBoss, MySQL, Apache etc into MOM.

By entering the enterprise market like this; MS is targetting products at the areas that control the whole strategy or an organisation: authentication/authorisation and systems management. It is a way of taking control and ensuring that any Linux/otherNix server has MS branding on it because that's how it is looked after...

essentially; Microsoft *have* to include Linux in their plans for their big step into Enterprise domination - Linux is actually helping them in a way because the rapid growth of Linux servers has forced them to consider enterprise platforms that they have not really been competing against in the past.

rd

You are wrong.

[mcc]

I am not personally familiar with Kerberos. However, I know how to read documentation. So let's look at the Kerberos spec, shall we? Any emphasis below is mine.

The client prepares the KRB_TGS_REQ message, providing an authentication header as an element of the
padata field, and including the same fields as used in the KRB_AS_REQ message along with several optional fields: the enc-authorization-
data field for application server use and additional tickets required by some options.

And then later on, multiple things to the effect of:

authorization-data[10] AuthorizationData OPTIONAL

The "data authorizaton" you refer to is-- by the spec-- clearly referred to as "optional" every time it comes up. This means that spec implementors are under no obligation to observe its contents. Now, if you go and look up the original problems with the MS Kerberos extension:

From discussions with Microsoft, which were not under an NDA, the situation appeared to be as follows circa October, 1997. This information comes from the USENIX publication ;Login.

NT 5.0 will indeed use Kerberos. However, the protocol has been "extended" by Microsoft, by adding a digitally signed Privilege Attribute Certificate (PAC) to the Kerberos ticket. The PAC will contain information about the user's 128-bit NT unique id, as well as a list of groups to which the user belongs.

The NT PAC is unfortunately not compatible with the PAC's used by the Open Software Foundation's Distributed Computing Environment (DCE). It is also somewhat debatable whether the NT PAC is legal with respect to RFC-1510, the IETF Kerberos V5 protocol specification. The original intent of RFC-1510 prohibited what Microsoft was trying to do, but Microsoft found what they claimed to be a loophole in RFC-1510 specification.

Many folks, including Paul Hill and Ted T'so at MIT, as well as Cliff Neumann at ISI, have tried to work with Microsoft to find a more compatible way of doing what they wanted to do. To that end, we made changes in the upcoming revision of RFC-1510 to add a clean and compatible way of adding extensions such as Microsoft's PAC to the Kerberos ticket.

To Microsoft's credit, they agreed to change NT 5.0 to use a cleaner and more compatible way of adding extensions to the Kerberos V5 ticket ... [snip]

RFC 1510 specifies that the encrypted part of a ticket may include an optional AuthorizationData field. If the authorization-data are present, they are decrypted using the sub-session key from the authenticator. ... [specified encoding of authorization-data field follows]

Microsoft has not fully disclosed their use of the authorization data field. However some information is public knowledge at this time.... [partial, reverse-engineered microsoft encoding of authorization-data field follows]

So what we are left with is this. The Microsoft kerberos extensions took a field clearly marked in the spec as "optional" and made it non-optional, while other implementations took the optional field and ignored it. Ignoring an optional field would be a correct implementation of the specification; requiring it would not. Meanwhile by the information above, the data Microsoft carried in the field is not only seemingly not the proper encoding of the AuthorizationData field given by the spec, but contains information which was not only outside the scope of the spec, but arbitrarily defined by microsoft and then NOT PUBLICLY DOCUMENTED. Microsoft claims a "loophole" not specified justifies this, but if you use a "loophole" to add information to a protocol which breaks compatibility with existing implementations you cannot possibly blame anyone but yourself for this.

It would appear you either are misinformed or trying to mislead us.