Sunteți pe pagina 1din 16

Functional Benefits of AD LDS

Developers using AD LDS have access to the following functional


benefits:
AD LDS uses the same directory service technology as
Active Directory. This means there is a common framework
for both the network operating system (NOS) services of
Active Directory and the application services of AD LDS.
Use of the same directory service technology increases
reusability of design and code between Active Directory
and AD LDS.
AD LDS increases the scalability of directory services by
separating the NOS services from the application services.
Multiple instances of AD LDS, each designed for a specific
application, can run on a single AD LDS installation.
Each AD LDS configuration set has a separate schema,
independent of the Active Directory schema.
AD LDS can use X.500-style naming contexts, such as
O=Fabrikam and C=US.
To increase application security, AD LDS can use Windows
security principals for authentication and access control.
Development for AD LDS can occur on Professional,
Business, Enterprise, and Ultimate SKUs as well as on the
Windows Server operating systems.

Operational Benefits of AD LDS


Developers using AD LDS have access to the following operational
benefits:
AD LDS is easy to deploy. Installation and setup are
simple.
AD LDS can be installed without affecting Active Directory.
AD LDS can be reinstalled or restarted without a restart.

AD LDS uses the same administrative model as Active


Directory.

AD LDS increases reliability by separating application


directory services from NOS directory services.

AD LDS
If youre running Windows 7, the following explanation is the right one for you. For older
versions of the operating system, things are pretty similar though different downloads will
have to be used. For Windows Server 2008, a server role exists for LDS. So, assuming youre
on Windows 7, start by downloading the installation media over here. After installing this,
you should find an entry Active Directory Lightweight Directory Services Setup Wizard
under the Administrative Tools section in Control Panel:

LDS allows you to install multiple instances of directory services on the same machine, just
like SQL Server allows multiple server instances to co-exist. Each instance has a name and
listens on certain ports using the LDP protocol. Starting this wizard which lives under
%SystemRoot%\ADAM\adaminstall.exe, revealing the former product name brings us
here:

After clicking Next, we need to decide whether we create a new unique instance that hasnt
any ties with existing instances, or whether we want to create a replicate of an existing
instance. For our purposes, the first option is what we need:

Next, were asked for an instance name. The instance name will be used for the creation of a
Windows Service, as well as to store some settings. Each instance will get its own Windows
Service. In our sample, well create a directory for the Northwind Employees tables, which
well use to create accounts further on.

Were almost there with the baseline configuration. The next question is to specify a port
number, both for plain TCP and for SSL-encrypted traffic. The default ports, 389 and 636, are
fine for us. Later well be able to connect to the instance by connecting to LDP over port 389,
e.g. using the System.DirectoryServices namespace functionality in .NET. Notice every
instance of LDS should have its own port number, so only one can be using the default port
numbers.

Now that we have completed the physical administration, the wizard moves on to a bit of
logical administration. More specifically, were given the option to create a directory
partition for the application. Here we choose to create such a partition, though in many
concrete deployment scenarios youll want the applications setup to create this at runtime.
Our partitions distinguished name will mimic a Northwind.local domain containing a
partition called Employees:

After this bit of logical administration, some more physical configuration has to be carried
out, specifying the data files location and the account to run the services under. For both, the
default settings are fine. Also the administrative account assigned to manage the LDS
instance can be kept as the currently logged in user, unless you feel the need to change this in
your scenario:

Finally, weve arrived at an interesting step where were given the option to import LDIF
files. And LDIF file, with extension .ldf, contains the definition of a class that can be added to
a directory services schema. Basically those contain things like attributes and their types.
Under the %SystemRoot%\ADAM folder, a set of out-of-the-box .ldf files can be found:

Instead of having to run the ldifde.exe tool, the wizard gives us the option to import LDIF
files directly. Those classes are documented in various places, such as RFC2798 for
inetOrgPerson. On TechNet, information is presented in a more structured manner, e.g
revealing that inetOrgPerson is a subclass of user. Custom classes can be defined and
imported after setup has completed. In this post, we wont extend the schema ourselves but
we will simply be using the built-in User class so lets tick that one:

After clicking Next, we get a last chance to revisit our settings or can confirm the installation.
At this point, the wizard will create the instance setting up the service and import the
LDIF files.

Congratulations! Your first LDS instance has materialized. If everything went alright, the
NorthwindEmployees service should show up:

Inspecting the directory


To inspect the newly created directory instance, a bunch of tools exist. One is ADSI Edit
which you could already see in the Administrative Tools. To set it up, open the MMC-based
tool and go to Action, Connect to In the dialog that appears, specify the server name and
choose Schema as the Naming Context.

For example, if you want to inspect the User class, simply navigate to the Schema node in the
tree and show the properties of the User entry.

To visualize the objects in the application partition, connect using the distinguished name
specified during the installation:

Now its possible to create a new object in the directory using the context menu in the content
pane:

After specifying the class, we get to specify the CN name (for common name) of the
object. In this case, Ill use my full name:

We can also set additional attributes, as shown below (using the


physicalDeliveryOfficeName to specify the office number of the user):

After clicking Set, closing the Attributes dialog and clicking Finish to create the object, we
see it pop up in the items view of the ADSI editor snap-in:

Programmatic population of the directory


Obviously were much more interested in a programmatic way to program Directory
Services. .NET supports the use of directory services and related protocols (LDAP in
particular) through the System.DirectoryServices namespace. In a plain new Console
Application, add a reference to the assembly with the same name (dont both about other
assemblies that deal with account management and protocol stuff):

For this sample, Ill also assume the reader got a Northwind SQL database sitting somewhere
and knows how to get data out of its Employees table as rich objects. Below is how things
look when using the LINQ to SQL designer:

Well just import a few details about the users; its left to the reader to map other properties
onto attributes using the documentation about the user directory services class. Just a few
lines of code suffice to accomplish the task (assuming the System.DirectoryServices
namespace is imported):
static void Main()
{
var path = "LDAP://bartde-hp07/CN=Employees,DC=Northwind,DC=local";
var root = new DirectoryEntry(path);
var ctx = new NorthwindDataContext();
foreach (var e in ctx.Employees)
{
var cn = "CN=" + e.FirstName + e.LastName;

var u = root.Children.Add(cn, "user");


u.Properties["employeeID"].Value = e.EmployeeID;
u.Properties["sn"].Value = e.LastName;
u.Properties["givenName"].Value = e.FirstName;
u.Properties["comment"].Value = e.Notes;
u.Properties["homePhone"].Value = e.HomePhone;
u.Properties["photo"].Value = e.Photo.ToArray();
u.CommitChanges();

After running this code obviously changing the LDAP path to reflect your setup you
should see the following in ADSI Edit (after hitting refresh):

Now its just plain easy to write an application that visualizes the employees with their data.
Well leave that to the UI-savvy reader (just to tease that segment of my audience, Ive also
imported the employees photo as a byte-array).

A small preview of whats coming up


To whet the readers appetite about next episodes on this blog, below is a single screenshot
illustrating something IMHO rather cool (use of LINQ to Active Directory is just an
implementation detail below):

Note: Whats shown here is the result of a very early experiment done as part of my current
job on LINQ to Anything here in the Cloud Data Programmability Team. Please dont
fantasize about it as being a vNext feature of any product involved whatsoever. The core
intent of those experiments is to emphasize the omnipresence of LINQ (and more widely,
monads) in todays (and tomorrows) world. While were not ready to reveal the LINQ to
Anything mission in all its glory (rather think of it as LINQ to the unimaginable), we can
drop some hints.

S-ar putea să vă placă și