LDAP vs Web Services

If you've  been around the site for awhile you know I blog a lot about PowerShell; specifically managing Active Directory with PowerShell.  The two approaches I usually take are to use the free PowerShell cmdlets from Quest Software or the Active Directory PowerShell module that shipped with WIndows Server 2008 R2. There are other approaches as well, but I find these two to be the easiest. But there are also at least two reasons, the latter which I'll get to shortly only recently came into focus.

First, I know there are many organizations that for a variety of reasons can't or won't use the free Quest cmdlets. For some companies if it doesn't ship from Microsoft with all the support bells and whistles, it can't be used.  Ok.  Too bad for the admins, but corporate policies have a life of their own. In this situation, then you want to at least be using the Active Directory module. Remember, this doesn't require a 2008 R2 domain controller. You can install the Active Directory Gateway Service on a Windows 2003 domain controller and still reap the benefits. Although, you still need at least a WIndows 7 desktop running the Remote Server Administration Tools (RSAT), but is usually a lower hurdle.

If you don't use any cmdlets, then you need to rely on ADSI and creatihg your own functions.  My book, Managing Active Directory with Windows PowerShell: TFM offers a lot of guidance on this topic, as well as how to leverage the Quest AD cmdlets. (I'll have to figure out what to do with the book now that the ActiveDirectory module is available). And I'm certainly not saying you have to use PowerShell. There are plenty of good command line tools and even VBScript. But if you want to go the PowerShell route, you want to use cmdlets as much as possible.

But there's another part to this story that only recently came into focus for me. I was chatting with uber-guru Gil Kirkpatrick, about this very topic and your toolset choice also breaks down by how you talk to the domain. The Quest cmdlets, (and also when using ADSI) are utilizing LDAP. This protocol makes a lot of assumptions, most of which are handled for you automatically. The bottom line is that LDAP assumes you are on the same network as your Active Directory infrastructure.

Compare this to the Active Directory module cmdlets and the AD Gateway Service.  Now, we're connecting via a web connection.  We are not using LDAP. Why is this a good thing? For one, it makes network security a little easier because most firewalls already have web ports open. A web service implies you can connect to your AD infrastructure from anywhere. The natural extension of all of this is cloud computing. Perhaps some day your AD infrastructure sits in a cloud somewhere.  LDAP was never designed for that and using a web service now makes a lot of sense.

So perhaps the question to ask yourself as you begin managing Active Directory more and more with PowerShell, is what is your long term strategy? Is some sort of cloud in your future or will you stick with a traditional infrastructure and management paradigm? I know I'm very curious about where you are going so I can help you get there.