Larry Steinle

In the previous post, Reading Data in Active Directory, we learned how to query Active Directory using OLEDB and .Net Directory Services. We learned that the OLEDB option is simple but has two big restrictions: we are limited to 1,000 objects in a search and we are restricted to single-valued attributes. We also learned how to get past those limitations using Directory Services.

In today’s post we begin our journey to create a data access layer for Active Directory that allows us to query Active Directory using a SQL-like syntax without the paging limit and without the single-valued restriction. Best of all this new data access layer will make it easier to integrate Active Directory management into all of our VS.Net products. When we are done we will use our new Active Directory Data Access Provider to easily construct our own custom, Active Directory Query Analyzer web page.

Active Directory Data Access Layer Series

This is the first post of an eight part series about the Active Directory Data Access Layer. If you would like to download a working copy of the AD DAL please refer to the download on the Code Share page.

• First Post: Active Directory Data Access Layer
• Second Post: Active Directory Connection Strings
• Third Post: AdConnection: Enforcing Active Directory Communication Best Practices
• Fourth Post: AdCommandTextParser: Parsing SQL Statements
• Fifth Post: AdCommand: Running Active Directory Queries
• Sixth Post: AdDataReader: Providing Controlled Access to AD Values
• Seventh Post: AdDataAdapter: Managing Active Directory Data
• Eighth Post: AD Query: Putting it All Together

The Microsoft dot Net Data Access Layer

ADO.Net Interface Model

ADO.Net DB Base Class Model

These classes provide a common interface to manage data in various data sources. They can be bound to controls in Web Forms, Windows Forms and Silverlight. Because of the common interface they introduce tremendous power and flexibility to the .Net framework.

Standing on the Back of Giants

We want to leverage the power and flexibility of the data framework to access Active Directory. Additionally, we want to continue to utilize the SQL code style to manage the data in Active Directory.

AD Data Access Model

In our new AD DAL we will be using code from previous posts:

• Extendending IEnumerable
• String.Split on Steroids
• Use Regular Expressions to Clean SQL Statements
• Use Regular Expressions to Detect SQL Code Injection
• AD Path Helper

Benefits

Our custom Data Access Layer will offer the following benefits:

• Execute Select query with access to both single-valued and multi-valued attributes.
• Paging so that all data can be retrieved.
• Translation of SQL Where clause into an ADSI filter.
  ADSI filters can become very complex quickly. The more “and” and “or” conditions required the more difficult it is to correctly construct an ADSI filter by hand. Using a SQL Where clause format makes ADSI filter much easier to manage!
• Support for the NOT operator.
• Support the following SQL keywords:
  • EXISTS
  • IN
  • LIKE
• Keywords that will make it easier to take advantage of the full power of ADSI filters:
  • Standard math operator comparisons (equal to, less than and greater than).
  • Bitwise operator comparisons (bitwise “or” and bitwise “and”).
  • Support finding users who are a member of a group that they are not directly assigned to via the CHAINDN operator.
  • Keywords to help with finding objects whose attributes:
    • Contains a value,
    • Starts with a value,
    • Ends with a value, or
    • Is similar to a value.
• Execute Insert, Update and Delete actions against a domain in which you have the rights to perform the action.
• Delete an OU tree with the DeleteTree statement which will be modeled after the SQL Delete statement.
• Any special characters found in the ADSI filters will automatically be escaped.
• Any special characters found in the path will automatically be escaped.

Putting it all Together

AD Query Analyzer

Summary

I trust that today’s post has captured your interest. In future posts we will begin constructing our AD DAL until the final post where we will demonstrate its use with our custom AD Query Analyzer web page!