PHP : Microsoft Office 365 and Active Directory

Disclaimer: I am not the biggest fan of Microsoft.  On the contrary.  I keep running into situations, where Microsoft technologies are a constant source of pain.  If that annoys you, please stop reading this post now and go away.  I don’t care.  You’ve been warned.

A few recent projects that I’ve been working on in the office required integration with Microsoft Office 365.  Office 365 is a new kid on the block as far as I am concerned, so I had no experience of integrating with these services.

The first look at what needs to be done resulted in a heavy drinking session and a mild depression.  Here are a few links to get you started on that path, if you are interested:

We’ve discussed the options with the client and decided to go a different route – limit the integration to the single sign-on (SSO) only, and use their Active Directory server (I’m not sure about the exact setup on the client side, but I think they use Active Directory Federation Services to have a local server in the office synchronized with the Office 365 directory).

Exposing the Active Directory server to the entire Internet is not the smartest idea, so we had to wrap this all into a virtual private network (VPN).  You can read my blog post on how to setup the CentOS 7 server as an automated VPN client.

Once the Active Directory was established, PHP LDAP module was very useful for avoiding any low-level programming (sockets and such).  With a bit of Google searching and StackOverflow reading, we managed to figure out the magic combination of parameters for ldap_connect(), ldap_set_option(), and ldap_search().

It took longer than expected, but some of it was due to the non-standard configuration and permissions on the client side.  Anyways, it worked, which were the good news.

The client accepted the implementation and we could just close the chapter, have another drink, and forget about this nightmare.  But something was bothering me about it, so I was thinking the heavy thoughts at the back of my mind.

The things that bother me about this implementation are the following:

  • Although it works, it’s a rather raw implementation, with very limited flexibility (filters, multiple servers, etc).
  • The code is difficult to test, due to the specifics of the AD setup and the network access limitations.
  • There is a lack of elegance to the solution.  Working code is good, but I like things to be beautiful too.  As much as possible at least.

So, I was keeping an eye open and I think today I came across a couple of links that can help make things better:

  1. adLDAP PHP library, which provides LDAP authentication and integration with Active Directory.  I don’t know how I missed it so far, but I think now things will be much easier and cleaner.
  2. Search Filter Syntax documentation on MSDN.
  3. This Reddit thread.  Yes, a lot of the things I’ve learned today are linked from it.  But it’ll be much easier for me to find all this information in my own blog, next time I’ll have to deal with Microsoft again.
  4. Public-facing LDAP server thanks to Georgia Institute of Technology, for testing connection and simple queries.

Armed with this new knowledge, I’m sure the current working solution can be improved a lot – simplified with fewer lines of code, based on the much more robust and tested code base, and given a basic test script to make sure the code works somewhere else, outside of a particular client’s setup.

I wish I came across that all much earlier.


Single Sign-On Between SugarCRM and Request Tracker

As mentioned before, over the last few month I’ve been involved in quite a few integration projects, using mostly SugarCRM and Request Tracker.  One of the interesting challenges was the Single Sign-On (SSO) between the two.

Continue reading “Single Sign-On Between SugarCRM and Request Tracker”

SugarCRM, RoundCube and Request Tracker integration on a single domain

In my years of working as a system administrator I’ve done some pretty complex setups and integration solutions, but I don’t think I’ve done anything as twisted as this one recently.  The setup is part of the large and complex client project, built on their infrastructure, with quite a few requirements and a whole array of limitations.  Several systems were integrated together, but in this particular post I’m focusing primarily on the SugarCRM, RoundCube and Request Tracker.  Also, I am not going to cover the integration to full extent – just the email related parts.

Continue reading “SugarCRM, RoundCube and Request Tracker integration on a single domain”

On using third-party APIs

In the few jobs I had, I was responsible for creating a new system and integrating it with some other systems.   The variety of the systems is pretty much irrelevant – anything from back office systems and CRMs to trading platforms and CMSs.  The common factor between them is the integration is often done through some form of the API.

The most important lesson I’ve learned while working with third-party APIs is this:

Never ever use a third-party API directly from your application.  Instead, create an abstraction layer between your application and third-party API.

This might seem like a bit of extra work, but, trust me, it’s not.  It will save you plenty of time and frustration.  Here are my reasons:

  1. Your own abstraction layer will help smooth out API’s edges.  If you are using third-party API, chances are, it feels weird at times.  It doesn’t matter what sets you off – function names, or required obvious parameters, or maybe the logic or order of calls that you have to make.  Instead of getting annoyed every time, you can abstract all that weirdness into a separate layer, which will probably not change all too often.  And your application coding will be more fun.
  2. Easier maintenance.  Even the best APIs change.  And when it happens, you don’t really want to go through all of your application and change all calls to the old version of the API.  Especially, if the updated version is not fully backward compatible.  Instead, you’d just rather update your API abstraction layer and be done with it.  And if you do, like you should, have unit tests covering your API abstraction layer, it will be trivial for you to see if you broke anything or not.
  3. Easier reuse and more control.  One of the biggest problems with third-party APIs is that you don’t control them.  Third-party introduces features, bugfixes, upgrades, and maintenance down-times whenever THEY want.  You rarely have much say in it.  When you have a layer in between the third-party API and your application, you have more control as to how all those things affect your application.
  4. Easier migration to another third-party API.  And you know that these things do happen.  You’ve been using one provider of the service, and now there is a better one.  If you were using first provider’s API directly from your application, you are pretty much in trouble now.  Going through the whole application replacing calls to the new API, with different set of parameters, data types, and return values, is a huge undertaking.  If only you had an abstraction layer, all you’d have to do now would be to change that instead. Sure, you might need to extend it a bit, or introduce changes to the currently used functionality.  But, from my experience, such changes would be much smaller and simpler (since you are working with your code on both ends).


Google Reader and Google Talk integrated. Sort of.

Google Reader has been recently integrated with Google Talk.  Somewhat.  If you use Google Reader and Google Talk, and you have some buddies in your Google Talk contact list, who also use Google Reader, then from now on you will be able to see each other’s shared items.  Through the “Settings“, you can control who you want and don’t want to see in the “Friends’ shared items“.

This is a really nice piece of functionality.  First of all, it saves you all the effort of finding and subscribing to “Shared items” RSS feeds of all your friends one by one.   Secondly, it helps to highlight interesting stuff from your buddies, even those that you might accidentally omitted from your subscriptions.

So, what am I missing there?  Two things.

First, the option to rename buddies.  I am blessed with contacts who choose all sorts of nicknames and avatars.  I prefer real names.  And I attach real face pictures to all my contacts whenever I can.  And I’ve done it in my Gmail contacts.  That information should be used for the Google Reader friends list.

Secondly, I need an option to enter a discussion with my friends regarding an item in my Google Reader.  That can be something I have shared, or that can be something my friends shared.  I want a “discuss in chat” and “discuss in email” buttons.  “Discuss in email” should be, in this case, different from “Email this item”.  We both (me, and the friend with who I’m entering a discussion) have read the item.  We just need a reference, like a subject, and URL to the item (original article?), just in case we need to run through it again or quote something.

While the second point is harder to implement (requires user studies, interface cluttering, etc), I’m really surprised that the first one wasn’t done.