Re: AD or ADAM as a user database
- From: BizTalk Benjamin <BizTalkBenjamin@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 17 Aug 2006 14:36:02 -0700
Hi Joe,
Thanks for getting back and the encouraging response. I just checked out
your book on the net and im going to get a copy. I wanted my system to play
well with ADFS since i think it has potential to become part of a corporate
identity management system (we're getting there eventually..looking at how to
roll out ADFS and MIIS etc ...) so ADAM would be better than custom coding a
SQL system.
Thanks again...
benjy
"Joe Kaplan (MVP - ADSI)" wrote:
You can definitely use ADAM as a database like this. ADAM, like AD, has a.
flexible, extensible schema and will allow you to store arbitrary data.
The benefit of using this approach is that you get a built in system for
storing users with passwords and authenticating them, with support for
features like lockout, password expiration and such. That's a whole bunch
of code you don't need in SQL that you also don't have to worry about
implementing incorrectly and compromising your security. ADAM with SSL will
do a nice job here. It is also free to use on 2K3 server and supports
replication for fault tolerance and scalability.
Learning how to design LDAP schema isn't hard as there isn't too much to it,
but it is a little different than SQL. Everything is organized into classes
and attributes. Attributes contain data that adhers to a specific syntax,
of which there are only a few. Attributes can contain multiple values, so
many relational design problems requiring normalization basically just go
away with LDAP.
There is a pretty light chapter in our book (7) on schema design that is
sort of aimed at people coming from a SQL background. Some other books like
Active Directory 3rd Edition are much more thorough.
The downside is that there is a learning curve and LDAP is a more
specialized skill, so it may be harder to find people who are comfortable
with maintaining it. LDAP is also more limited than SQL, and you may be
frustrated by the very simple query processing capabilities of the LDAP spec
compared with SQL. However, it performs well for authenticating a user,
looking up their data and doing stuff with it (such as security, but it
could be anything).
I'd definitely suggest using ADAM vs. AD for this application, as it is
really supporting a specific application here, not a domain with Windows
users. ADAM can also fit into domain authentication scenarios with bind
proxy objects and the like and plays nice with new federation technologies
like ADFS.
HTH,
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"BizTalk Benjamin" <BizTalkBenjamin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:610494AB-1412-401D-9526-9046AC3B5BC8@xxxxxxxxxxxxxxxx
Hi, I'm working on a pretty standard piece of functionality at the moment
attempting to design a user repository. . This repository should hold all
the
registrations of people visting a website and will contain names,
addresses,
user names, passwords, mappings to other back office system references
etc.
The repository itself will be accessed via web services.
Now i've been reading some articles which recommend that LDAP and
specifically ADAM would be the best way to proceed instead of basing this
on
a relational database. I looked up some stuff on ADAM and ASP.NET and all
the
articles seem to talk only about Roles and membership and dont say
anything
about using it as a database.
Does anyone in this newsgroup have any comments on this? Can we use AD or
ADAM for my requirements or would it be better to just build a relational
DB?
TIA,
Benjy
- References:
- Re: AD or ADAM as a user database
- From: Joe Kaplan \(MVP - ADSI\)
- Re: AD or ADAM as a user database
- Prev by Date: Re: recreate a builtin group
- Next by Date: Re: AD or ADAM as a user database
- Previous by thread: Re: AD or ADAM as a user database
- Next by thread: Re: AD or ADAM as a user database
- Index(es):
Relevant Pages
|