DirectoryServices

Hi,

A system that is being designed will use ActiveDirectory to store
userinformation for a SQL Server 200 base web app. It was decided that only
the windows account username need be stored in the database for
authentication by the web app.

However I realised that if we chould take this route everytime I wish to
display a users name I will have to do a lookup to get the details from the
to AD after getting the windwos user account from SQL Server.

This sounds rubbish to be frank. Should I just store what I need i.e.,
First name, surname, email address in the database and us the AD purely for
authentication. But then doesn't this loose some of the valu eof the AD and
means there are two sources of info to maintain.

Does anyone have any metrics on connection/transaction time with an AD, if
it is nominal then I will go with the original plan.

Also any advice on the topic would be greatly appreciated.

MattC

P.S. ASP.NET 1.1, C#, SQL SERVER 2000, WindowsServer 2003

Marc
Sat Jul 24 03:49:32 CDT 2004

>However I realised that if we chould take this route everytime I wish to
>display a users name I will have to do a lookup to get the details from the
>to AD after getting the windwos user account from SQL Server.
>
>This sounds rubbish to be frank. Should I just store what I need i.e.,
>First name, surname, email address in the database and us the AD purely for
>authentication. But then doesn't this loose some of the valu eof the AD and
>means there are two sources of info to maintain.

Yes, why would you want to redundantly store user name, e-mail and
such AGAIN in SQL Server, if that's already available in your AD??
That sounds like rubbish! Redundancy is bad - avoid wherever possible!

AD is a directory service that's optimized for read requests - it's
very fast and efficient to read some data from AD - much more so that
from a general purpose SQL server table. AD however is *NOT* optimized
for data that's changing a lot - e..g it would be a bad idea for an
order system or such thing. That's where SQL Server really comes in
handy.

So really, I think the combination of AD for storage of your user data
(which is in there ANYWAY, right?), and SQL Server for your often
changing data *IS* indeed the way to go!

Marc

MattC
Mon Jul 26 03:23:41 CDT 2004

Marc,

How is information retrived at from AD, is it at a sockets levels wrapped up
by classes in the DirectoryServices Namespace?

MattC

"Marc Scheuner [MVP ADSI]" <m.scheuner@inova.SPAMBEGONE.ch> wrote in message
news:eg84g0p48hgtrgbge16g7eq3bjdbausg54@4ax.com...
> >However I realised that if we chould take this route everytime I wish to
> >display a users name I will have to do a lookup to get the details from
the
> >to AD after getting the windwos user account from SQL Server.
> >
> >This sounds rubbish to be frank. Should I just store what I need i.e.,
> >First name, surname, email address in the database and us the AD purely
for
> >authentication. But then doesn't this loose some of the valu eof the AD
and
> >means there are two sources of info to maintain.
>
> Yes, why would you want to redundantly store user name, e-mail and
> such AGAIN in SQL Server, if that's already available in your AD??
> That sounds like rubbish! Redundancy is bad - avoid wherever possible!
>
> AD is a directory service that's optimized for read requests - it's
> very fast and efficient to read some data from AD - much more so that
> from a general purpose SQL server table. AD however is *NOT* optimized
> for data that's changing a lot - e..g it would be a bad idea for an
> order system or such thing. That's where SQL Server really comes in
> handy.
>
> So really, I think the combination of AD for storage of your user data
> (which is in there ANYWAY, right?), and SQL Server for your often
> changing data *IS* indeed the way to go!
>
> Marc

Marc
Tue Jul 27 01:31:31 CDT 2004

>How is information retrived at from AD, is it at a sockets levels wrapped up
>by classes in the DirectoryServices Namespace?

Phew - never had to go in *that* deep.......

Basically, ADSI (a set of COM components) uses LDAP under the wraps,
to communicate with the Active Directory. S.DS in turn uses some ADSI,
some direct LDAP calls (as far as I understand) go get to AD.

Exactly how the LDAP protocol works over the wire is beyond me - but
I'm sure you could google for that - LDAP is an open industry
standard, I'm sure you should be able to find information about
low-level comms stuff on the web.

Marc

================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch