|Case Summary: Additional hints for configuring integrated Active Directory login with Web+Center. Specifically if you get a "Table does not exist error".
|Date Created: ||08/30/2007|
|Last Modified: ||08/30/2007|
|Problem Type: ||Problem Report|
|Item: ||Active Directory/LDAP Integration|
When trying to do a Directory Lookup, the following error occurs?
Provider error '80040e37'
Table does not exist.
/tech50/DirectoryLookup.asp, line 497
Unfortunately, this is a very generic diagnostic which the AD access mechanism puts out when just about anything goes wrong - it's not at all useful in pinpointing the actual cause.
Failing that, the best I can offer is to ask you to fire up the LDAPConfig module - inside TechCenter, click the "Administration" button and then "System Configuration Menu" then "LDAP Configurator".
Once this is up, click the "Load Configuration" (middle button at bottom of screen) and eyeball all the parameters set up there. Then make sure an appropriate test value is entered in the last line of the form (marked as (2)Name of User-id Field) so that the first field on that line is (probably...) SAMAccountName and the second field is the user ID of somebody you know is in the directory .. and then click on the "Test Directory Access" button (bottom right of screen)
This will result in a stream of debug/progress messages being output to your screen as it executes, and at some point it will (probably) die with the same diagnostics you reported above. We may be able to get a clue however by looking at what point it died within the stream of debug messages it emitted. Specifically did it get as far as outputting the first heading of the table where it shows the contents of each field being retrieved, or did it die before it even got there...
Basically there can be two main causes for the diagnostic you are seeing.
a) One of the field names (in the left hand columns of the main part of the LDAPConfig form) is spelled wrong - implying that this has been changed in the Directory since the system last worked... This is highly unlikely, but I mention it, just in case...
b) The Connect string as defined in the box labelled "LDAP Server Address" is incorrect in some detail - for some reason this address has changed since it last worked. This is the most usual cause of grief, and the hardest to figure out.
One step you might want to do to check (b) above is look as follows:
The steps below refer to the graphic:
First - look in you system (do a file search) to see if you have a file called adsiedit.msc This is a utility program supplied by Microsoft usualy referred to as the Active Directory Schema Editor. If you do not find this file, you will need to install it - it is not normaly installed but is available for installation from a "service pack" or "utilities" disc that should have come with your system
When you have found this file, double-click on it and it will bring up a typical "navigator" style of screen with two main panels - in the left panel the usual kind of hierarchical tree structure, and in the right panel the contents of whichever element has been selected in the left panel. The hierarchy in the left panel is that of your Active Directory - see the attached screenshot.
If you only see three lines in the left panel under the heading "ADSI Edit", then click on the little plus sign on the third line (labelled "Schema" and marked with a red 1 on the attached screenshot) so that it "expands" and shows the next level below it (marked with a red 2 on the attached screenshot).
Now look at the contents of this line (marked with a red 3 on the attached screenshot), specifically the part underlined in red. In our case this happens to read DC=smallbusiness,DC=local because when Active Directory was installed on our machine, the name "smallbusiness" was given by the installer during the install process for the Active Directory.
Take the value that you see here on your system (which will likely be very different) and compare it to (use it as) the last part of your LDAP connect string within the LDAPConfig program. So that your connect string might then be (I'm guessing here... just an example)
In this example I specified a machine identified as "directory.collegeofthedesert.edu" - sometimes it is easier to use the actual IP number of the machine where the directory resides. In fact I'd recommend that as it removes one more unknown from the equation.
Also, if in configuring you directory - if you changed the hierarchical structure in the directory schema from the "default" as reflected in the attached screenshot, then that too has to be accommodated appropriately within your LDAP connect string.
The good news is that it used to work - this sort of thing is very much harder to figure out if it hasn't ever yet worked and you really have no clue where to start looking.