1 Reply Latest reply on Oct 19, 2009 1:23 AM by Adam Cameron.

    CFLDAP Error Handling


      I'm trying to make a login application that checks against AD using LDAP. I've been able to query LDAP using entered information in forms. As of now, it will forward users to a desired page once correct login information is entered into the form. The problem I'm having is that when users enter incorrect information, instead of forcing them to a desired URL, it's showing a CF error page stating "

      Authentication failed:[LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece ]


      So of course I don't want to show that. Here's the code I'm using in the form handler page.


      <cfldap action="query"







                 attributes = "cn,o,l,st,sn,c,mail,telephonenumber, givenname,homephone, streetaddress, postalcode, SamAccountname, physicalDeliveryOfficeName, department">


      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

      <html xmlns="http://www.w3.org/1999/xhtml">


      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

      <title>Untitled Document</title>




      <body><cfif Results.RecordCount GT 0>

      <cflocation url="http://www.yahoo.com">

      <cfelseif Results.RecordCount EQ 0>

      <cflocation url="http://www.espn.com">







      Any ideas or what I may be doing wrong? This is my first attempt at using CF and LDAP together. I wasn't able to get the Login Wizard to work either.

        • 1. Re: CFLDAP Error Handling
          Adam Cameron. Level 5


          I'm not sure you should be using the user details you're trying to authenticate as the ones to do the LDAP query.  Usually directories are locked down to only allow members of certain groups to run queries like that.  I suspect this is what's causing your problem here.


          In the past I've used a specific user to run the LDAP calls (like one uses a specific user to make DB calls), and simply use the values you want to check as filters on the LDAP query.


          Our coding standard dictates that any calls to external systems (with the exception of DB calls, now that I think about it...) should have try/catch constructs around them.  One is less able to guarantee the robustness of external systems as much as one's own code, so one should code expecting it to not work, and exceptions to be raised.