Rob's blog
Upgrading my OpenLDAP BDB Backend for Suse 10.3
When I upgraded from OpenSuse 10.2 to OpenSuse 10.3 I should have backed up my LDAP database as LDIF before I started. I didn't do that of course but I thought maybe I could just copy the database over and tweak the config file in /etc/openldap/slapd.conf. The OpenLDAP server, slapd, can be configured to use a few different backends for storage. The most common seems to be a Berkeley Database. On my installation the database resides in /var/lib/ldap. There are a bunch of files there, it looks like a couple log files, a DB_CONFIG file and several database files (they have the extension .bdb). I don't have exact step-by-step directions for how I fixed it but I'll go over the highlights of what worked for me.
A Couple Ways to Debug mod_rewrite
At the risk of turning this into an Apache fan blog, I have to mention the handy directive I found today. Many webmasters run in to mod_rewrite at one time or another and every one of them will have at least a little trouble with it. I just came across the RewriteLog Directive and corresponding RewriteLogLevel Directive. You're not going to be able to turn these on with shared hosting, they can't be used in .htaccess. To set up a debugging log for mod_rewrite, you need to add them to your httpd.conf somewhere. In my case I'm working on a server at home so I added
September's only just started and already I'm behind. It's not just me that's feeling it. Candace is getting started on reading the stack of books for her Masters Degree before classes start in a few days. She's also still moving her stuff in to our place from her old house. My daughter's schedule is full again of skating, piano and gymnastics and still no room for Aikido. I've noticed the past few years (and it seems obvious in retrospect) that September is more than just the back-to-school time. It's when everybody seems to stop relaxing, knuckle down and get back to work on whatever it is they do. I've mentioned before that I have trouble getting myself focused when the workload grows. I don't think it's an uncommon reaction to want to go out and do something different when everything you're in the middle of seems to get boring and stagnate. For example, I had a little success working on a web app login page the other day so last night I sat down at the computer to figure out the next step. And spent an hour-and-a-half reading xkcd. Not just the comic but Randall's blag too. That kind of took me full circle in a "holy shit how does this guy have time on his hands like this" sort of way.
No AuthType Digest with LDAP Authentication Provider for Apache today


Now that I've got an LDAP server up and running I'm trying to get my personal web server set up so it has a blanket authentication for my personal applications, static content and development stuff. The web applications I'm talking about aren't meant to be exposed to the public at large, they're not what you find here on Late Night PC Service or any of my other sites. These are things like PHP Calendar, Task Freak, SugarCRM, a bunch of development versions of apps I'm working on and some static content that might be a single html file or an image. I currently have a server that's accessible through DynDNS and I use basic HTTP authentication on it. The server runs Apache HTTPD 2.2 and has whatever modules I want on it. My next server is roughly the same but I want to make things a little more secure and a little simpler (at the same time no less). So my idea was to move to LDAP as the Authentication Provider and Digest as the Authentication Type.
My LDAP Tree So Far
It took a lot of digging to figure out how I should approach choosing a good LDAP directory layout for my house but Michael Donnelly seems to have an answer I like. I created Organizational Units to hold all the people and all the computers. I want to have a few canonical OUs that hold the base records for each of these things then have other OUs that reference them and group by access. I don't know that I have it all figured out right just yet, but phpLDAPadmin makes it simple to move things around. Just make sure to hit the "Purge caches" link if you move stuff on one computer then view it on another.
Installing Asterisk 1.4 on OpenSuse 10.2

I've had my Asterisk PBX offline for a while now for no good reason, so I decided I'd upgrade and put the latest Asterisk on my new machine. I wrote about the last time I installed, that was on an older AMD Athlon 1200MHz Thunderbird. It worked fine but I got a Linksys PAP2T-NA ATA and became very lazy. The ATA just registers with and I plug a phone in to it, so there's no need for Asterisk for just basic VOIP phone service.

I decided that I'd just use the ATA for a while then I got into some sound quality problems. I switched out many parts of the system trying to determine where the problem was but the best lead that I have so far is that my modem has issues. I'm not sure that the entire problem is with the modem but I do know that my Internet connection overall gets faster if I reboot it and that shouldn't be necessary.

Anyhow, voice quality issues apparently are common with VOIP and more people are using it anyway - the balance of features and cost is still in favour of VOIP. So I figure that if I get used to my system I can work the kinks out of it later. As time goes on and there are more users it should be easier to find help on my specifics too.

Today I want to revisit some of the work I did getting Asterisk 1.2 working and see what I have to do to get Asterisk 1.4 running. It's apparently not that different.

Fixed: Firefox Automatically Adds www. and .com
This has bugged me for a long time but it just took a little searching to fix. I enter the URL http://copper/ and Firefox can't connect so it decides that I really meant This is never what I meant. I don't know who runs, but they can rest assured that they'll stop getting requests from me for the internal web services that I run at home. The same thing happens even if you use the name localhost. I fully expect that most visitors at are Firefox users who are trying to access a web server on their own computer. Apparently it was turned in to a preferences setting years ago as a result of this bug. The feature is called "domain name guessing" or a URL fixup and according to the site that tipped me off to this it might be a feature of Thunderbird as well. In current versions (Firefox 2) it can be found and turned off by entering about:config in the address bar. This brings up a huge list of settings. Find the setting browser.fixup.alternate.enabled (typing the name in the Filter box at the top makes it easy to find). Double click the name of the setting or its value to set it to True or False. You want False to stop this behaviour.
SSO Web Applications

Corporate Websites and Middleware

Websites have come a long way from when everyone just had to have a presence to the point now where every large organization has not only many internal sites but also uses web-based applications for critical internal functions. These internal applications include time-keeping, expense reporting, document approval chains, personnel management, and numerous industry-specific tools for meeting the day-to-day needs of the business. Just like traditional desktop middleware, these web applications all need to consider the security of the data that the user accesses. There are many security considerations but one that most applications share is the simple act of logging on. Traditional desktop applications simply save off the users credentials at login and refresh the credentials with each new session.

Sessions and Web Applications

Since web pages are stateless, each web application has to simulate statefulness by using sessions. Sessions are used with a website to remember information about a user as they travel from page to page and as the different user requests are received and responses are sent. Sessions are generally maintained by setting a cookie in the visitor's browser. In subsequent requests, the user sends the value of that cookie. The value is simply a unique identifier that lets the web server look up the stored session variables to use. Generally each web application that someone uses will set it's own cookie and store it's own independent values. When sessions are done well a web-based application can have the same coherent and responsive behaviour as an installed desktop application. Single Sign-On can be built in to an application in the same way that statefulness has been. Simply put, a cookie can be set for all applications within a domain (this is a limit of cookies) which lets the application identify the user. This can be the same cookie as the session cookie - in fact the user ID can be stored as a session variable.

Getting the User ID in to a Web Application

Web Applications are different from desktop applications in that part of the application runs on the web server and part of it runs on the desktop. The part on the web server is written in a server-side language like PHP, ASP, JSP, Perl, Python, C# or one of the other .Net languages. There are many choices for the server-side language - it can be decided by the organization that runs the server to suit their needs. The client side must almost invariably be presented using HTML, CSS and Javascript. There might be exceptions to this but there are so many users or potential users for an application that anything other than a standards-based, cross-browser approach has a good chance of failing even in a corporate environment. A user normally signs on to a web application in a way that looks the same to them as would a desktop application. They provide a user name and a password. On the server side, the username and password have to be compared to values in a database to check if the user is known and if the password is correct for the user's account. The password in the database is normally encrypted to enhance security. In order to connect a web application with the Single Sign-On technology used elsewhere in the company, the SSO connection has to be performed on the same side of the application as user authentication already occurs - the server side. In the case of using LDAP to authenticate the client for SSO, this means that the web application has to be modified to make query the LDAP server. With most languages this can be done through a software library so that the changes may not run too deep in the application.


There are several ways to get Single Sign-On (SSO) working with new and existing applications. Some are easier than others and there are different security considerations with each. Kerberos, Shibboleth and even OpenID can be used for SSO but I'm going to focus on LDAP. LDAP is actually a protocol (Lightweight Directory Access Protocol) but the acronym is often used to refer to the database, clients and servers that implement the protocol. LDAP is used for controlling access to applications and is designed toward storing information about people. To that end, some of the objects that commonly exist in an LDAP database include user accounts, address books and organization hierarchies (like org charts).

Computer Login

The password that's normally supplied by each user who's going to use a computer can be validated against an LDAP server. An encrypted copy of the password is stored in the LDAP database. When a user enters a password, the text they've entered is encrypted and sent to the LDAP server for comparison. If the values match then the LDAP server indicates that the user is validated and the user can be granted access. There are a lot of variations on this pattern that include different types of security and verification between the client and the server. Which way it's handled precisely depends on the security requirements of the computer network. Logging in with an LDAP server shouldn't be much different from the user's perspective as long as all goes well. When a password needs to be reset then the reset has to be performed by an administrator on the LDAP server or by some tool that has access to the LDAP database. This can be better or worse depending on the user audience. Some users are better off calling a helpdesk to do the password reset for them, others will be put off by the fact they can't fix their own machine. There are costs and benefits to Single Sign-On from the user perspective.

Application Login

After a user is logged on to their computer there are other applications they'll use. Many of these applications will have access to read and change sensitive data. Of course these applications have to be secured against unauthorized access and often have access logged. A simple login and password can facilitate this in many cases. Application developers in the past have added these features to their applications because there was no central repository for Single Sign-On. Since Single Sign-On has been introduced, every method for SSO has some way for application developers to authenticate or check a user's credentials to decide what kind of access to allow. LDAP describes the protocol for an application to authenticate users and find out what type of access they should be allowed. There are software libraries in many programming languages so that an application can avoid implementing the LDAP protocol directly. Instead they just have to use an existing code library and call in from their application to have the library get the authentication information from the LDAP server. An application might need special information added in to the LDAP database that's suitable for it. That's fine because LDAP allows for any needed object to be defined though the use of a Schema. The Schema is the correct place to define what attributes any LDAP object might have. For example, an application that stores medical records could need to know if a user can read, write or if they can edit. A simple Schema can be defined that describes these permissions. For each user that has access to the medical record application, an LDAP object is created and tied to that user's other LDAP information.

A Single Login for Application and Computer

To achieve SSO for the medical application in this example, the LDAP information about a user would have an object that represents the user's account on a computer and it would have another object that indicates the user's access to the medical application. When logging in, the computer contacts the LDAP server to check the password and user name. After they're logged in, the user launches the medical record application. The application then contacts the LDAP server and checks to see if this user has access and if so, what kind of access. This sounds simple but of course every organization has to tailor LDAP to suit their own SSO needs.
What is Single Sign-On?
Many applications require users to log in supplying a username and a password before they can access the application or perform certain functions. Common examples where a log in is required include email applications, a Windows log in, and most web-based applications that store any personal information. Users don't want to log in to an application, what they want is to perform some task or get access to some data. The tasks and data are completely application-specific. When I log in to my email client it's not because I want to log in it's because I want to read or send email. It's a pretty obvious fact but it's important to pay attention to because the act of logging in with a user name and password have become a such a common part of daily life that many people experience Password Fatigue - a condition that results when people are required to remember many passwords as part of their daily living. Many attempts have been made to handle consolidation of user identification across websites such as OpenID. This is not a simple problem to solve. The case is different where you have several applications that all belong to one organization. If all the users and all the applications are run by the same person, company or organization then why have many different user names and passwords? All of a user's passwords and usernames can be stored in one trusted source that meets the requirements of the most demanding application. This concept is called Single Sign-On (SSO). Single Sign-on means that a user can log in one time and have access to many applications for that session. SSO can reduce the number of logins and passwords that a user has to remember from twenty or more all the way down to just one. Like I said at the beginning, users don't log in because they want to log in. They log in to get access to some data or function that the application has. With SSO the user logs in to the computer then they can just open their email without a password. They can access company websites and web applications without a password. They can use time sheets applications, accounting applications, company directories, internal instant messaging and company database applications all without remembering one more password and without compromising data security. This is more than just convenience, it simplifies workflows to enhance productivity. It enhances moral and reduces the moments where users pause and curse an application. It lets users follow directives to choose strong passwords that they can remember because there's only one. Single Sign-On is not nice to have. It is essential for any business that wants to grow and retain loyal employees.
Syndicate content