|Case Summary: LDAP/Active Directory Connection String Debugging Hints
|Date Created: ||03/13/2007|
|Last Modified: ||03/13/2007|
|Problem Type: ||Problem Report|
|Item: ||Active Directory/LDAP Integration|
Our connect string is
and as you can see from the attached screenshot, this is essentially composed of two parts:
1) The direct IP number of the machine holding the directory - this is pointing to the machine with the "local" name of issserve-akrsew.smallbusiness.local - which is what ADSI edit "sees" when it is executed on that machine.
2) The dc=smallbusiness,dc=local bit that reflects the next line in the ADSI edit display.
So that is the very simple close-to-default out-of-the-box situation which we have going here.
Now some further thoughts...
I have seen other customers' strings that looked more or less like this instead
I'm going from memory here, but that's what it looked like, i.e. the two DC= parameters seemed to be accomplished with slashes in the URL itself (making them look more like a path to a sub-directory) instead of as distinct separate run-time parameters. I tried this variant on our machine, but it doesn't work worth a darn - I get the usual "table does not exist". But I offer it here just as an observation of what others seem to have been doing for some reason.
I also saw a case where a customer had a mixture of the two - like this:
and that doesn't work in our case either. I have no idea what the reason for these syntactical variants might be - all that our software is doing in this case is taking the string the user provided and plugging it directly into the longer pseudo SQL command which we fire off to the AD server, i.e. the syntax requirements are what is required by LDAP rather than something we invented. Eventually the full built up string that we fire off would look something like this
SELECT givenname, sn, company, physicalDeliveryOfficeName, streetAddress, l, st, postalCode, co,
mail, telephoneNumber, mobile, facsimileTelephoneNumber, sAMAccountName FROM
'LDAP://<our IP number>/dc=smallbusiness,dc=local' WHERE sAMAccountName = 'j*'
Then of course we have had a number of users with more compex trees, where they had to extend this string to navigate to a sub-tree deeper down in the directory, something like
Now in your case, I find it remarkable that the first part of what ADSI edit shows, ie the domain name
happens to reflect almost exactly (and redundantly) what it gives for the 2nd part but without the actual machine name i.e.
So I guess my first attempt would be to try the string as
or maybe chicken out and use the IP number for the first part, and provide the machine name in the 2nd part and specify local instead of .com as we have in our situation here
Those are of course just wild guesses and no more valid maybe than your attempts so far...
Then some other things I've learned from others' experiences
The diagnostic "table does not exist" can mean just about anything went wrong. You might for example try it with a bogus username and/or password - in my case I get "permission denied" but some customers have claimed they get "table does not exist" in this situation.
Then you may want to minimise (at this point) the number of fields you are asking to be returned - if you miss-spell any one of them it causes problems. In our case we get "unspecified error" but again - some customers claim to have gotten the "table does not exist" diagnostic in this case - maybe a reflection of what version of AD is being used. So check spelling of requested fields really carefully.