Oil and Water? - Port 25: The Open Source Community at Microsoft
< Back to Blogs
Oil and Water? by admin on April 21, 2006 09:35PM

Oil and Water?

It’s been an interesting week for Interop inside the lab – we’re running an IPSEC interoperability project to test Fedora, OpenSUSE, RHEL, SLES, Ubuntu, and Mandriva with Windows Networking technology, and ran interviews both with the IDMU (Identity Management for Unix) Program Manager and with Paul Moore, CTO of Centrify.

Today I spoke with Jeremy Moskowitz, a Windows/Linux interoperability expert, to get his take on some of the recurring challenges in starting interop projects and why it matters.  He’s done a lot of work on the topic of group policy, and writes books and teaches on-site classes for IT professionals.

        Sam: What's the main thing that you find people don’t understand about Windows/Linux interop?

Jeremy:  People often don’t realize how many points of contact between the two systems you can actually interoperate. I wrote a book with Thomas Boutell, and in 10 chapters we isolated 8 points, including desktop, applications, email, networking and authentication.

Sam: Authentication is an interesting topic – what do you lay out as the main approaches here?

Jeremy:  There are a lot of different approaches.  For example, if it’s a “mostly Linux” shop that needs to integrate a couple of Windows machines, you’d use OpenLDAP.  If it’s a mixed Windows and Linux/Unix shop running Active Directory, integrate Linux & Unix systems as Windows clients.

Sam: Do you cover that in the book?  Are you using IDMU to run a Windows NIS master?

Jeremy: When we wrote the book, Win2K3 R2 hadn’t shipped and SFU was a separate application.  We decided to write a chapter on updated procedures for Win2K3 R2 as a download from
www.winlinanswers.com. It should be available in May, so check back often.

Sam: What do you usually see as the main obstacle in IT shops to do Windows and Linux integration?

Jeremy:  Windows and Linux guys in a given company don't talk much – they usually only meet up playing softball on opposite teams at the company picnic.

Sam: Sounds like some cultural interop issues?

Jeremy:  There has historically been a religion problem which causes problems in doing these things.  I'm a pragmatist - I have Windows running a bunch of systems but my website runs on LAMP.  I needed a great web designer and a site he could maintain, and what he knew was PHP.

Sam: What's one great thing people will get out of reading your book?

Jeremy:  When I gave my session on interop at LinuxWorld, I asked the audience of about 70 people: “Who here is running Exchange?”  60 people raised their hands.  I said, “Keep your hands up.  Now drop your hand if you're planning on walking away from your Exchange infrastructure and just to have something that runs on Linux.” One person dropped their hand.  Exchange is here and people need to manage it.

So the question is, “How do we use Linux to manage the exchange environment?”  In the book we detail an approach that uses a front end Linux server that will, for free, scrub email, scan for viruses, and verify the delivery address for routing across backend mail servers (Exchange, sendmail, etc).  You offload things that typically run on the Exchange server and bog it down.  By using a Linux box to front-end Exchange, you get more horsepower out of your Exchange server so that you get better performance for what you're paying for.

You can see Jeremy’s new site at http://www.winlinanswers.com, or see other stuff he’s done at http://www.moskowitz-inc.com Jeremy will be answering comments on this thread, so if you have some tough questions about AD interop, OpenLDAP, Samba 3.0, SFU, or related topics, this is the place to ask.

Cheers,
Sam

Comments RSS
  1. What I'd like to know is what is there for Linux that approaches what Apple did for Mac OS X via the Active Directory plugin, where, without a lot of work, you can at least get Macs to play nice in an Active Directory environment.

    I'd like to see Microsoft do more with the lab then just use it as a way to justify Windows over Open Source, but I doubt that will ever happen. It's a shame, because, quite honestly, trying to get non-MS platforms to play nice with Active Directory, or the other way 'round is really like being nibbled to death by baby ducks, and most times, the problems are with Windows.

    If nothing else, I'd love to see SFU get the heck out of NIS, since the Unix world is *running* from that mess as fast as possible, and go from being a "migration to Windows tool", to a "Helps Unix systems plug into Active Directory mo' betta" tool. But again, that would not push people to Windows, so I don't see it happening.

    So while I want interoperability to work, I don't see Microsoft ever doing anything beyond "Dump !Windows, buy Windows, and your world will be perfect."

    posted at 10:31PM 04/21/2006
  2. Sam Ramji said:

    Both Centrify and Quest software ship products that make it easy to integrate Linux and Unix systems plug into Active Directory.  You should take a look at Centrify's DirectControl and Quest Software's VAS.

    Your doubts aren't surprising - you are echoing many older posts here.  However, you are taking the time to post on our site, and more importantly, the site of one of the key teams at Microsoft that is dedicated to interoperability.  I invite you to bring specific suggestions about what you'd like to see, because then we have a way to make progress.

    For example, when you say "most times, the problems are with Windows", it would help if you could add a few specifics about the types of problems you see, so that we can work on them.  Similarly, if you want SFU/IDMU to stop using NIS, then what is it that you want it to support instead?

    I believe you have some solid experience in interop from the statements you're making - if you want to give us a chance to help you, then help us by going into more detail.

    posted at 11:38PM 04/21/2006
  3. jeremym said:

    Jeremy here.. Thanks for your comment jwelch.

    Here's the good news: you don't *need* SFU 3.5 (or R2's NIS) to get "modern day" authentication interop.

    "Modern day" interop can be had using LDAP lookup (or secure LDAP via SSL if you like) and Kerberos authentication.

    So, NIS no longer becomes "the only way" to do authentication interop. Instead, Windows does, indeed,
    talk "modern" interop protocols -- the kind Linux
    admins expect a "good OS" should talk.

    With that said, it's not a cakewalk to configure Linux to "talk" to AD for authentication (at least it wasn't a cakewalk for me to figure out and document in the book.) The steps are a little too numerous to mention here, but, in short, you tell your Linux client to lookup it's account in AD via LDAP, and authenticate via Kerberos. There's some "last mile" stuff which was intense to figure out -- but, again, it CAN be done.

    The 3rd party tools Sam mentions above are interesting, too, because they take that "heavy duty research" I performed and take it out of the equation. They also provide the ability to have a unified commandline between ALL platforms (UNIX, Linux, MAC OS X), and your *NIX machines *becomes* an AD client.

    So, in all -- the "homegrown" method I demonstrate in the book is useful -- very useful -- if you're getting started. But I would also check out the 3rd party tools listed here to get a better feel for what's possible.

    -Jeremy Moskowitz
    WinLinAnswers.com

    posted at 12:28AM 04/22/2006
  4. I'd like to point out to others that I've commented twice that I'd like to hear more about authenticating open source systems against AD. This would appear to be a direct response to this. It certainly points me in the right direction. Thanks Sam.

    Jeremy, thank you for your insight. I would like to get my linux desktops authenticating against AD, but it isn't worth the time and effort for me at the moment. I'd really like to see this road straightened out and widened a bit to make it easier to get through. Are you aware of anyone working on this?

    Do you have things to share about getting systems like Jabber, RequestTracker, Moodle, Drupal, Postfix and the like authenticating users from ActiveDirectory? I understand that all these programs can use AD as their auth database somehow, but there is still the issue of effort. If microsoft was to release some code that all these projects could use that would integrate quickly and simply I'd be impressed.

    Maybe in some cases, the true need is for instructions, not code.

    posted at 07:54PM 04/22/2006
  5. nektar said:

    I would expect that Microsoft, if it wants to help interoperability, that it would release instructions and/or code that could run on non-Windows platforms that which would assist in this direction. From your opening post on this forum you said that Port25 has two role which were, as I saw them, A) to discuss openly about open source, ie. to exchange positions and ideas and B) To show what Microsoft does that would either differenciate it from open source technically or that would assist it to make better software. Nowhere in your targets was mentioned a role of helping the open source community. Nowhere was it mentioned the goal of providing if need be technology and code to assist the open source platforms, and not only Windows, in achieving interoperability. I strongly believe that interoperability cannnot be a Windows only solution but that you should add the goal of enhansing it on other non-Windows platforms in your original targets as well. If not then Port25 would be an interesting place only to talk but not to act.

    posted at 03:56AM 04/23/2006
  6. I'd like to add to Nektar's comments that such helpful actions will be taken by the community as a step in the right direction, but not likely to turn many heads. In fact some might say that these actions by Microsoft only represent Microsoft trying to take advantage of the strengths of Open Source. In order to counter this, Microsoft will have to expand their support of the open source community heavily to areas they don't directly benefit from. Otherwise, it's another embrace to destruction.

    Programs like Google's Summer of Code might make a change among community impressions, assuming the selections of the projects were undeniably without prejudice.

    Novell and Mac have already made transition steps into the FOSS communities favor. A study of these would seem to at least set some guiding principles, but Microsoft would certainly have some unique challenges.

    I'm left wondering, would the FOSS community be as strong if they didn't have something to "struggle against"? History shows that the Christian church, while smaller, was also strongest under persecution. As persecution lifted, it became weak but more widely embraced. Will this be the fate of FOSS? In faith, this represents a concern of mine becaus there is an absolute truth to one side, but in the FOSS community it could mean stronger technology to work with. I admit I'm concerned about the community, but my allegiance is not first to the community of FOSS developers.

    I think humanity, as a whole, will benefit from such a meld. Sure, it won't be perfect. I'm sure another community will rise up to challenge developers to further purify this melded community if they fall too far from the interest of the people. I respect RMS and am sure he would take a place of leadership. Viva la Revolution! The FOSS community willl stagnate if we don't adapt. We've already done it with Novell and Mac.

    Let's hold firm on some things though. DRM shouldn't be something we play with, nor closed proprietary protocols. Interoperability is good, as long as it gives options and doesn't take them away from the people. This expansion puts us in a place of greater influence against the closing of options.

    posted at 02:21PM 04/23/2006
  7. eocasio said:

    Perhaps, you can start by working in an utility like <a href=http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm>explore2fs</a> I found that link in winlinanswers.

    I can read or write my ntfs (read, soon write) and fat (rw) partitions under Linux, but cannot read ext2, ext3 nor reiserf under Windows, which has obvious advantages when we are increasingly working in mixed environments.

    posted at 11:32PM 04/23/2006
  8. nektar said:

    I do agree that reading and writing ext2 and 3 partition under Windows is a much needed but missing option. Also, Linux supports formtting your drives and accessing them with many formats whilst Windows supports only two. The disk tool under Linux are extremely more powerful than Windows. As a result under Linux you have more choice.

    posted at 01:18AM 04/24/2006
  9. einhverfr said:

    Jeremy has outlined the process fairly well.  Basically on the Linux side, you configure the PAM to run against Kerberos and nsswitch to pull account information against LDAP.  Back when I was looking at this first, there were more steps required on the Kerberos side (namely to configure the KDC information on the client), however since more recent MIT Kerberos versions use SRV records, this can be eliminated provided that you have a sufficiently recent version of Kerberos installed.

    There is one more important step:  One needs to extend the active directory schema so that it provides useful information to the Linux client.  The schema requirements are all documented in RFC 2307, and this provides the basis for actually implementing any interop solution.

    Hope this helps,
    Chris Travers
    Metatron Technology Consulting

    posted at 01:47AM 04/24/2006
  10. jeremym said:

    Josiah Ritchie wrote:

    "
    Do you have things to share about getting systems like Jabber, RequestTracker, Moodle, Drupal, Postfix and the like authenticating users from ActiveDirectory? I understand that all these programs can use AD as their auth database somehow, but there is still the issue of effort. If microsoft was to release some code that all these projects could use that would integrate quickly and simply I'd be impressed. Maybe in some cases, the true need is for instructions, not code.
    "

    Jeremy responds:
    Well, again, I'm an "outsider." I don't work for Microsoft... I'm just some guy who finds this stuff
    interesting.

    With that in mind, here's my OPINION on this comment:

    I don't think it's Microsoft's responsibility to write code which hooks into 3rd party applications to make them better interoperate with AD. AD already *TALKS* the correct standards (LDAP, Kerberos, RFC compliance, yadda yadda.)

    The open source community writes a LOT of great stuff. But oftentimes the "last mile" is missing. No GUI (or poor GUI) to make the app easier to work with for "mere mortals", poor documentation (because documentation isn't the 'fun' part of a project.

    (A little side note here... is that my "challenge" to the open source community is to start to take their game to the next level. And, really do that "last mile" stuff in an AMAZING way to *REALLY* raise the bar, software wise.)

    Back to the issue: Microsoft shouldn't write code which hooks into 3rd party apps. That's not their business. That's the business of the developer of the APP! :-) If AD *IS* RFC compliant -- then it should all just "work." If it *DOESN'T* just work -- then, YES, MS should, of course, step up and ADDRESS those areas which are not RFC compliant. (And, btw.. that's precisely what they did with the move from SFU 3.5 to R2, which is not RFC 2307 compliant.)

    However, I can't disagree with one thing: It surely would be nice to have helpful "How to connect product X with AD" documentation. If not produced by Microsoft (which, maybe, I could see) then, surely by the community at large. Heck! That's something I would surely house at WinLinAnswers.com !

    Here's the trick: I'm only one {crazy busy} guy. The point of the 'community' model is that 'everyone pulls his weight.' Well, if people want to write up the "How I connected X to AD" documents for those apps, well, I'd *VALIDATE* them and then HOUSE them.

    So.. it's a good idea, I would get involved and I think that's a great place to be!

    posted at 10:31AM 04/24/2006
Post a Comment
*
*