An interesting thread on LDAP and authentication came up again today on activedir.org.  In the conversation, I had suggested that it would be a good feature if AD and ADAM had a setting somewhere that could be enabled that would prevent LDAP simple bind from working if the network channel was not secured (via SSL).  The problem with simple bind (for those not in the know) is that the user's credentials are passed over the network in plaintext, which is potentially a huge security risk (depending on the network).  It is actually even worse (by just a little) that HTTP basic authentication, as the credentials aren't even base64 encoded.

Eric Fleischman then pointed out that ADAM actually already has such a switch.  Tomek blogged about it here, so I'll let him cover the details on how to enable this.

I went on to suggest that AD should also have this feature (off by default for backwards compat most likely).  The problem is that without this feature, the AD admin really has no way to prevent apps that use simple bind for auth from sending plaintext credentials on the network, even if SSL has been configured.  You can't just turn off port 389 access to AD without breaking other stuff as you might be able to do in other directories.  Many of the NOS features of AD rely on port 389.

I also suggested adding an ability to audit simple bind attempts over non-SSL channels, including the IP address, so that admins have a way to track down rogue apps.

In many IT organizations these days, we must specify policies about how we are going to treat sensitive data (like passwords!) on the network and can get ourselves into hot water with our auditors if we are found to not be in compliance with our own policies.  At least with this auditing support in place, violations of the policy can be capture and violators may be traceable.

Also note that with most ADSI (and System.DirectoryServices programming in .NET), simple binds are not used.  Windows secure binds (using GSS-SPNEGO, which amounts to Kerberos or NTLM at the heart of it) are used by default.  You can get a simple bind, but you must do more work.  As such, most ADSI script code is not likely to have this problem.  You do have to be careful though.  We go into this in a great deal more detail in ch. 3 of the book.  Simple binds are very common with cross platform apps, and especially those that use non-MS LDAP libraries, as they often do not have the code they need to implement GSS-SPNEGO at all.  Some of them just use simple bind because it is the lowest common denominator protocol that all LDAP directories must support.

Anyway, it will be interesting to see if any of these suggestions come to fruition.  In the mean time, use SSL with your directories (ADAM too!) when doing simple bind.  Getting certs can be painful, but usually not as painful as getting hacked or failing an audit.  Unless your networks are totally secure between the endpoints and there is no threat of snooping, you need a secure channel. 

So, it would appear the one of the pillars of the WiX community, Derek Cicerone, is retiring from WiX and moving on from MS at the same time.  I want to personally, publicly thank Derek for his enormous contributions to this effort.  WiX is typical of most open source projects that have success, in that there is a strong leader and a few key contributors that keep it going.  WiX has a thriving user community, but very few actually contribute to the code base and other key deliverables like documentation (me included).

When one of the pillars of an open source project steps down, it is always leaves a vacuum that is difficult to fill.  I'm sure things will continue to move forward, but it is always a little scary to image how things will be without that person.  Hopefully someone will step up.  It won't be me, so I'm lame.  :)

I've had a few personal email interactions with Derek and have always found him to be a good guy and have admired his leadership and style.  Good luck with your next endeavor.

So, why is an LDAP/Identity guy like me interested in an open source project that facilitates authoring MSI files for software deployment?  Is that a little out of your realm.  Well, as a matter of fact, deployment is something I'm really interested in and had to dig into pretty deeply for one of my projects at work.

My story involves the web single signon project that I was brought in to save 2 years ago when I took on my current role in my company.  It all boils down to having a package of vendor software that needed to be installed on IIS web servers to provide our own customized version of the vendor's software.  The software is a bit tricky, in that there is an ISAPI filter and a web service extension (IIS6 only!), a bunch of login UI pages, some home grown config tools and a Windows service that integrates with the web service extension.  It needs to support install, uninstall, upgrades and migration of settings from one version to another from a custom Apache-style config file.  It is non-trivial.  :)

During this time, I learned many important lessons about setup, most recently how important it is to use ALLUSERS=1 if you want per-machine installs (per-user installs, the default, results in chaos for server components when multiple admins perform tasks on the boxes!). 

I'm also the proud owner of a little component our company uses fairly extensively that is basically an HTTP Module that gets installed in the GAC, registers with VS.NET for "add reference" integration and installs an event log and source.  This thing was whipped up with VS, but I'm converting it to WiX sometime soon so I can get away from the dreaded installer classes (a topic for a different thread at a different time).

So, my angle on setup is really focused on deploying to the enterprise, not commercial software, and doing server side stuff, often with a bunch of .NET stuff, IIS integration and Windows instrumentation features.  At our company (and maybe yours too), we struggle to successfully deploy web apps, especially the complex ones, and have a mandate to make this easier for the admin.  As such,  I think this arc has a future in my career (although we've got a long way to go before this stuff gets institutionalized). 

Anyway, in other news on WiX, Jamie Cansdale (of TestDriven.NET fame, a fellow WiX user for his own product and a hell of a nice guy that I had lunch with at the last MVP summit on our way out of town) reports that WiX v3 may be adopted as the native deployment technology to be integrated into the next VS.NET release.  It looks like the VS team may finally drop their proprietary authoring thingy in favor of something more powerful and integratable (sic) into an automated build process. 

Good call guys.  I hope it works out.

(Update, ~2 hours later)

In going back and rereading Rob's original post, I think he was talking about the VS team's decision to build the VS installer itself with WiX, not an indicator the vdproj files will be WiX-based anytime soon.  Rats.  This is still a good thing, as strong internal commit to use WiX tends to assure some sort of a future (VS.NET, Office, SQL, etc.), but this would have been cool.

Maybe I've got this wrong and they'll shock us?  I think it makes a whole lot of sense, although this is a pretty difficult thing to convert from and a big jump for a lot of people.

So, this whole moving thing has happened pretty quickly.  We started looking at houses before we really had decided whether we were going to move or remodel, and we hadn't really decided where we wanted to live (although it was a toss up between staying in the city or moving to one of two nearby suburbs that are quite city-like; Oak Park or Evanston).

As luck would have it, the house we liked the best was the first one we saw and it was right around the corner.  We decided to move fast on it, so we started the purchase before we had even really thought about getting our house on the market.  Conventional wisdom suggests that one takes care of the sale first before jumping in on the purchase, lest one end up with two mortgages and a world of trouble heading into the winter.  Given the current state of the supposed housing market meltdown, this was a real fear.

However, we did manage to get through the listing process quickly, did a bunch of stuff on the house to make it more presentable and just went for it.  We sold the house in 8 days and arranged a same day closing (no bridge/home equity loan), so basically it all just worked out perfectly.  I think good pricing advice and a great work ethic from our agent was the key here.  Thanks, Lee!  Lee and I know each other from our punk rock drumming days (he is still rocking, while my rocking behavior is much reduced).

One must reasonable conclude that I must lead some sort of a charmed existence. :)

Of course, now I have to pack and move, which is less charming. 

I think more tech blog postings may be a while in coming.  I'm doing a bunch of work with build automation again though, this time with a lot of SQL stuff that I haven't done before, so maybe I'll talk about that some.  I haven't had much time at work for new ADFS, LDAP or Windows security work, so I have nothing new to say there, unfortunately.