DirectoryServices

  • Thread starter Thread starter MattC
  • Start date Start date
M

MattC

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
 
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.
Click to expand...

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,

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

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

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
 
Back
Top