Monday, April 28, 2008

PHP and LDAP

The joys of authentication. So, now I am working on running some of our PHP apps to authenticate against Active Directory (AD). Well, my limited knowledge in AD is telling me that it shouldn't be too hard. After all, AD is just a Microsoft interface to LDAP. Right?

Well, it turns out that, yeah, from a PHP perspective, it is. It is actually pretty easy, once you are comfortable with working with an LDAP structure.

So, here is the basics of it. I have a simple page that all it does is print out the results of a simple authentication to an AD server:
<html>
<body> 
<h1>AD Test</h1>
<?php
// Variables to use with ldap_bind
$ldapuser  = 'username@some.domain.com';     // ldap username with suffix
$ldappasswd = 'notmyrealpw';  // associated password

// connect to AD server
$adconn = ldap_connect("ad_controler.myco.com")
or die("Could not connect to LDAP server.");

// if a connection was made attempt a binding
if ($adconn) {

// bind to ldap
$ldapbind = ldap_bind($ldapconn, $ldapuser , $ldappass);  

// Check authentication
if ($ldapbind) {
echo "User is authenticated.";
} else {
echo "User was not authenticated.";
}

// unbind the connection
ldap_unbind($adconn);
}
?>
</body>
</html>


Basically, you have your username, for example avgwebgeek. Then you have a suffix, which is your account suffix for your domain, for example "@myco.com". Put them together (along with a password) and you have your AD authentication information. Of course, the username and password would be sent through request parameters. Granted, this is a pretty simplistic view of AD authentication. You can do a whole lot more, like searching, and updating AD information. I learned all about it by looking through the adLDAP Project. The hard part was realizing that I didn't have PHP enabled on my server. Hint: if you get a message like "Call to undefined function: ldap_connect() ", that means that your LDAP isn't enabled for PHP. The adLDAP page has a FAQ that explains that as well.

Wednesday, April 23, 2008

Where’s my data coming from?????

I work on applications that interface with other applications using Web Services, and XML feeds. These apps help track employee information for different companies to track thing like pay, performance, and security issues. The problem is, I don’t know where the actual content is originating from. That can be problematic, because you are assuming that your data provider will let you know if there is a format change or discontinuation coming down the pipe. Typically, the provider will let you know, somehow. However, in the case of systems “piggy backing” on data of other systems, then in turn, providing that data to further systems, eventually, the message of change gets lost.

I found this out the hard way a couple weeks ago. Luckily for me, it was for a low priority system. I manage a series of blogs for a corporation. I don’t manage the content, but I taker care of the themes and plugins. One of the plugins that I wrote was a “Company Updates” plugin, basically an RSS type of news reader that uses plain XML, and not the RSS standard. The data was coming from what I thought to be the HR department. However, they were just sending it to me through a XML feed, as they were getting it from a small group in the company who were generating the data by hand. Well this group changed the format of the XML tags, and notified HR. But HR didn’t notify me. All of a sudden, I come to work and all of the Blog users were calling me because the “Company Updates” feed was busted. I noticed the change in the XML feed, so I fixed the problem. However I couldn’t understand why I wasn’t notified.

I contacted HR, and they didn’t know anything because they never wrote the Change notification down. Apparently the employee who was notified about the change assumed that in my super natural power over XML feeds, my plugin would have updated dynamically with the XML change. True, if I had a DTD or Schema, I could have written a more intelligent plugin, but I didn’t have a DTD or Schema, and this was a pretty small system. In this case, it is easier to modify the code as changes occur. Anyway, the HR people got me in touch with the group who produces the feed. They told me about the notifications. Needless to say, I switched the origin of the feed to this group.

The moral of the story is that documentation is a REALLY good thing. In this case the problem was small, and easily rectified. However, it made me review my other interfaces, and I decided to write up a Provider/Consumer agreement about data, so the actual origin of the data is known. This agreement is review by all parties in involved and helps to keep me in the loop when changes happen.