LDAP Authentication

Discussion in 'ASP .Net Security' started by Hutty, Feb 2, 2009.

  1. Hutty

    Hutty Guest


    I am trying to authenticate user and password against Sun One LDAP. I am
    getting the following message when trying to connect:

    This provider can target only Active Directory and ADAM directories

    Any ideas why I am getting this messages?
    Here's my connecting info:

    <add name="ADConnectionString"

    " connectionPassword="password"/>

    Hutty, Feb 2, 2009
    1. Advertisements

  2. Hutty

    Joe Kaplan Guest

    I think it is exactly as it says. The provider is specifically designed
    only for AD and ADAM. You mentioned you had Sun One.

    Are you asking how it is that the provider can tell your directory is not AD
    or ADAM?
    Joe Kaplan, Feb 2, 2009
    1. Advertisements

  3. Hutty

    Hutty Guest

    Thanks for the reply Joe.

    Actually, I am trying to connect using Visual Web Studio 2008. Do I need to
    ask for permission to connect using this provider?

    If I can't connect using this method, what are my alternatives?

    Hutty, Feb 2, 2009
  4. Hutty

    Joe Kaplan Guest

    The web server you are running this on shouldn't matter. What matters is
    the backend LDAP store you are trying to use. In your case, the store is
    not supported.

    The membership provider framework is extensible, so you could write your own
    LDAP auth membership provider that is coded to work with Sun One. You could
    use S.DS.Protocols for this which is a lower level, less "MS-specific" LDAP

    You can use a tool like reflector to reverse engineer the existing provider
    to see how it works.
    Joe Kaplan, Feb 3, 2009
  5. Hutty

    Hutty Guest

    Thanks Joe for your responses. Not exactly what I was hoping to hear, but did
    shed some light on the problem at hand. Building my own directory sounds like
    the best course of action. Hopefully that will be straightforward.

    Hutty, Feb 3, 2009
  6. Hutty

    Joe Kaplan Guest

    One of the things with the membership provider framework is that you don't
    actually have to implement every single interface member when building your
    provider. You only really need to implement the members that correspond to
    the features you need. If all you need are the members for checking
    credentials, you don't need to build the methods that write new users, reset
    passwords or look people up for directory searches and such.

    The key will be focusing in on the algorithm used to implement the LDAP
    authentication. Normally, the core of this is a bind operation. In many
    directories, you also must perform some sort of name translation prior to
    the bind. This is because the bind may require that the username be
    submitted in full "distinguished name" yet most users don't know this name
    and it is too long to type anyway, so they supply some sort of short name.
    You frequently need to look up the DN based on the short name but will need
    a service account with permissions to perform this query in order to do so.
    Most of the complexity stems from managing all that stuff and figuring out
    the LDAP details to make that work on your given directory platform.

    I'm sure there are some docs out there that have algorithmic descriptions of
    how to implement LDAP auth on Sun One that can be applied to the .NET LDAP
    APIs as needed.

    Best of luck!

    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    Joe Kaplan, Feb 3, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.