by 

Microsoft’s Active Directory (AD) product had humble beginnings. When it first came on the scene in 2000, Novell Netware was the dominant directory service on the market, and was certainly the most popular directory service to leverage the industry-standard Lightweight Directory Access Protocol (LDAP). Fortunately for AD, after a number of missteps on Novell’s part, combined with Microsoft’s dominant Windows operating system (OS) position in the market, AD has become one of the most popular commercial LDAP-capable directory services on the market today. It’s hard to find any IT shop that has a collection of Windows systems that is not running AD in some form or fashion. As a result, AD has become a key component of many organizations’ identity management systems.

Active Directory’s Role in Identity

But what does that mean exactly? If you run AD on your network, you already know that you’re using it to allow your users to log into their Windows desktops or provide seamless access into Exchange, SQL Server, or any number of other Windows-based server products. In addition, when a user browses to a secure internal Web site from their AD-joined Windows desktop, and the user employs Internet Explorer to access an IIS/ASP.Net Web site that usually requires authentication, and the user is put seamlessly through to the site, that is AD single-sign-on authentication and authorization in action. Microsoft’s own products are built to seamlessly and quietly pass along your AD credentials to all Microsoft products that require it.

But that is not what has made AD a center of attention for identity in many organizations. What has really helped AD move into the mainstream of identity management is the adoption and support of AD as an important identity store by third-party vendors that provide products that need to support some kind of authentication and authorization. Products as widely varied as Oracle databases, IBM Websphere Java Application Servers, UNIX, Linux, and Macintosh OSs as well as line-of-business applications from companies like Oracle/Siebel and SAP all provide built-in ways to leverage AD for authentication and authorization to those platforms and applications.

All this means that increasingly AD is used as a key repository for identifying users and controlling access to critical corporate data, key intellectual property, and critical business functions. But before we dive into this idea, it’s a good idea to set context by talking about two terms that heretofore I’ve glossed over-namely authentication and authorization:

• Authentication is the process by which users identify themselves to a system and prove they are who they say they are. Typically this is done by providing a user name and password to AD, which then authenticates the user by ensuring that their password is correct. Kerberos is the default authentication protocol in AD. However, there are other types of authentication (for example, NT LanMan-NTLM) that can occur, including authentication based on public-key certificates, such as those used in smart cards.
• Authorization is about determining whether an authenticated user has the rights required to view and access a resource. That resource could be anything from a file share on a server to a database or a business application running on a Java Application Server. Regardless of the resource, authorization is the process of determining whether the user who is authenticated to AD has been granted access to the resource. In AD, authorization is usually controlled using AD security groups, but could also use other mechanisms, such as “roles,” which correspond to the user’s business function. This mechanism can include a capability referred to as role-based access control. RBAC encompasses more than just AD security groups but can form part of a strategy for granting access to resources based on a person’s job function.

Click here to download this chapter or book.

Tags: Active Directory