Authentication is the process by which we validate a user's credentials in an attempt to verify who the user purports to be. That is, we are securely identifying our users using some sort of shared secret. For the scenarios we cover in this chapter, this shared secret is the user's password, although it really could be a number of things (once again, see The .NET Developer's Guide to Windows Security, referenced in Chapter 8, for a thorough discussion of authentication in general). As such, authentication really does not tell us much, other than "who" the user is choosing to represent.

In Chapters 3 and 8, we set the groundwork for connecting to the directory and understanding the binding process in detail. In this chapter, we take what we have already learned and apply it to the task of programmatic authentication.

When the user is a Windows or ADAM security principal, we have a number of options available to us for authentication. Since we will specifically be dealing with validating username/password combinations in this chapter, we will discuss the four primary means of password authentication we have available for us to use.

In each scenario, we will take input from the user in the form of a username, a password, and possibly, a domain name. A word of warning: The username can come to us in a few valid formats, so we should always be ready to contend with each one. Typically, we would filter the input or derive our own username format based on the input given to us by the client. For instance, the client might use any of the following formats for their username with Active Directory, as we discussed in Chapter 3:

  • NT Login (DOMAINUsername)
  • NT Username (Username)
  • UPN (
  • DN (CN=User,DC=domain,DC=com)

When using ADAM security principals (as opposed to using passthrough authentication with ADAM), we will typically see the username in only one of two formats[1]:

[1] 1. In actuality, if we do not bind using the DN, ADAM will attempt to resolve the account using DsCrackNames (of which UPN is one format). This means it can accept any format supported by this API (and there are eight), but collisions are possible that prevent UPN from being used effectively. Only the DN format is guaranteed to get what we want.

  • DN (CN=ADAM User,OU=Foo,O=Domain,C=US)
  • UPN (format varies)

It is our job as developers to anticipate that our clients will use any or all of the formats, and we need to be ready to either filter the format to our liking at input time, or deal with the format on the back end. Building the filtering through the UI is a good idea, but we should also be prepared to accept the different username formats on the back end.

Part I: Fundamentals

Introduction to LDAP and Active Directory

Introduction to .NET Directory Services Programming

Binding and CRUD Operations with DirectoryEntry

Searching with the DirectorySearcher

Advanced LDAP Searches

Reading and Writing LDAP Attributes

Active Directory and ADAM Schema

Security in Directory Services Programming

Introduction to the ActiveDirectory Namespace

Part II: Practical Applications

User Management

Group Management


Part III: Appendixes

Appendix A. Three Approaches to COM Interop with ADSI

Appendix B. LDAP Tools for Programmers

Appendix C. Troubleshooting and Help


The. NET Developer's Guide to Directory Services Programming
The .NET Developers Guide to Directory Services Programming
ISBN: 0321350170
EAN: 2147483647
Year: 2004
Pages: 165 © 2008-2020.
If you may any questions please contact us: