“Understanding AD Access Control Entries” is a quick and simple article describing some of the madness of the Active Directory access control entities. This is particularly useful for those of us who had to deal with Active Directory, without having much experience with MS Windows. I’m sure this will come handy again in the future.
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:
- Get Started with Windows Azure Active Directory (Developer Preview)
- PHP Calendar API Sample
- PHP Connect sample using Microsoft Graph
- Logging into Office365 email using PHP
- Using PHP and LDAP to connect to Microsoft Office 365
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:
- 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.
- Search Filter Syntax documentation on MSDN.
- 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.
- 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.
Yet another bug that I submitted to Red Hat Bugzilla got fixed. This time it took more than a year – from 21 May 2004 until 12 September 2005 – but a workaround was found much earlier and could be easily applied.
P.S.: I was stupid enough not to notice that the bug was closed and add another comment today. Nuthead!
LDAP saga continues… Finally I have found something that Microsoft did actually good. I have found out that
ldifde.exe -f myfile.ldf will export the whole Active Directory structure into myfile.ldf file in LDIF file format (human readable). That is extremely usefull when migrating I have also found Exchange-HOWTO an interesting read.
I have started to learn LDAP today. Here is how I did it:
- Install new Red Hat Linux 7.2 server.
- During install
- Specify to authenticate through LDAP which is located at 127.0.0.1
- I forgot to permit SSH connection during firewall configuration
- In boot manager configuration, I have specified to use GRUB with which I don’t have any experience yet.
When I did all this, I have found myself in situation where machine refused any connections via secure shell, refused any logins locally, Result:
- Unusable machine
- Frozen butt (a/c in the server room)
- Complete reinstall
- Linux LDAP Tutorial