cthrall.com

Disclaimer: I’m definitely not somebody who keeps up with this sort of thing. But I have noticed a couple things recently:

• The steady trickle of non-techie people joining Facebook continues.
• Sites like FriendFeed and Gnip are providing a great aggregation of social networks, while Ping.Fm provides a publishing mechanism (although perhaps I could just as easily post to Twitter, which also shows up on Facebook).
• Most interesting to me: apps like TweetDeck provide a richer interface for existing apps, like Twitter.

Aggregation sites like FriendFeed make sense to me. But a richer experience like the one TweetDeck provides, I hadn’t really thought of. On a whim, I downloaded it and it is pretty nice.

But what’s next? We’ve been here before, in 2000/2001. A few major players (eBay/Amazon, Facebook/Twitter) win the fight for users. What’s interesting now is we have companies like Gnip making it easier for people to use multiple services. I’m not sure that will have an impact on Facebook’s success, though.

I have no idea where I’m going with this. I’ll just keep it ongoing.

This is the first in a series of posts about getting around certificate issues. It is now common for organizations to create their own root CA cert and self-sign everything. The cert chain is then installed on all PCs belonging to the organization and everything validates correctly. This makes a lot of sense.

Unfortunately, there are other scenarios where a cert is self-signed and the cert chain will never be valid. In these cases, we are forced to figure out how to make a HTTPS request that basically accepts any SSL cert, no matter the validity. To be honest, I am somewhat embarrassed to admit the level of cert hackery I have resorted to, but sometimes Getting Things Done trumps the necessity for a tool to validate the cert chain against a third-party appliance that has a self-signed cert. Such is life.

If you are using OpenLDAP and you want to use TLS but you don’t have the proper CA certs, or there is some other issue with the certificate chain, you can bypass it altogether:

• Create a directory C:\OpenLDAP\sysconf (this is Windows, if you’re using Unix you probably have the skills to figure out where ldap.conf should live).
• Create a file there named ldap.conf that contains a single line that reads: TLS_REQCERT never

Rock on. I hope to follow up later with a post on where to store your cert chain to make this work.

I needed to switch from basic authentication to something better that wouldn’t pass the credentials back with every request. I decided to use adLDAP, which uses the LDAP functions built-in to PHP. The built-in LDAP implementation uses OpenLDAP.

What I found was this:

• adLDAP calls ldap_bind to authenticate
• ldap_bind uses the common name (cn). I was passing the sAMAccount name.
• This works in my development environment, because AD can figure out that is the same user via a referral.
• You can configure AD to deny anonymous referrals.
• OpenLDAP does not support non-anonymous referrals.

Sad times.

LDAP geeks will now laugh at me and my lack of LDAP-fu. I finally realized all I had to to was search on sAMAccount name, then ldap_bind to the distinguished name (dn) that is returned.