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).
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.
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.