.NET Framework - ADSI

Asked By Chri

29-Nov-07 08:46 PM

Hi All,

I have question about Active Directory. We have developed a site it has 75K
users on SQL server 2005 associated with roles, now we are thinking to change
it to Active directory is it good idea or bad idea? if it is good  how to
migrate it.

Thanks in advance.

Chris

29-Nov-07 10:52 PM

You haven't given us enough information about what you are doing to provide
you with a useful answer.  In terms of size, 75K users is not really
significant for AD from a size perspective.  I wouldn't worry about that.

Migration of users may be tricky, depending a great deal on how you have
stored the users' passwords in SQL and whether your intent is for your users
to have the same password they had before.

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

30-Nov-07 10:24 AM

Joe ,

Thanks for quick respone.

We developed a site with public and privatre applications, for private
applications user need to login those users paswwords we dont want to
distrub, you are rite we want to use same passwords.

Any kind of possible other solutions also welcome( there is no time
constraint for development).

Regards,
Chris

30-Nov-07 10:40 AM

Can you provide more details on how the passwords are stored in the SQL
database?  If they are in plaintext or encrypted in a reversible format,
then you should be able to recover them and use them provision identities in
AD or ADAM such that the users will have the same username and password they
used in SQL.

However, if they are in some sort of 1 way hash format, then it might be
very difficult to recover the plain text.  That would make provisioning in
AD very difficult.

Username format might be a bit of a problem as well, depending the formats
you allow in SQL.  You would want those to be compatible with AD.  ADAM
gives you a little more flexibility here.

I definitely recommend that you try to use the SQL and AD membership
providers for the integration with your web application.  They provide a
nice abstraction layer over the user store that makes it easier for your
application to not have to care where the users are stored.  If you aren't
using the membership providers now, I recommend that as your first step.

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

30-Nov-07 11:08 AM

We are using username as firtsname.lastname  password as plaintext. could
you please provide me more information on using the SQL and AD membership
providers for the integration with web application, how to implement it.

aslo we want to use this AD for MOSS 2007, my question is do I need to have
exchanger server for this to implementation, we are using this for government
site.


Regards,
Chris

30-Nov-07 01:51 PM

I'd suggest reading the patterns and practices guidance documentation on
using the ASP.NET membership provider framework.  There is a ton written on
this topic and you'll get better information by reading the existing
documentation than by asking such a broad question on the newsgroups.  The
newsgroups are much better for asking specific technical questions.  Google
will find the P&P docs very easily for you.

Since your passwords are stored in plain text, it should not be difficult to
provision matching users in AD.  You'll just need some sort of script to do
it.

You don't need Exchange unless you want to use Exchange to provision the AD
users with mailboxes or use Exchange for some other email routing feature.

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

07-Dec-07 01:32 AM

Chris, from what was written above I see no clear case to migrate to
AD.

If you need it for integration with MOSS only, then I'm not sure if AD
will be the best way in that case. SharePoint imports users from AD to
the own SQL database, and it means AD will be as an intermediate-level
with AspNetSqlMembershipProvider to either the local or remote
instance of SQL Server.