Re: issue w/ LDAP that I have encountered

[Pierangelo Masarati <ando@sys-net.it>]

On Thu, 2006-07-06 at 13:06 -0500, Derek R. wrote:
> All,
> I am setting up OpenLDAP w/ the back-sql ( using MySQL ) db module and 
> GSSAPI authentication.  I had the authentication working fine, as well 
> as the SQL database created ( via the scripts included w/ the 
> openldap-servers-sql RPM )  and everything seemed to be fine, except 
> that when I submitted any queries ( for example :
> ldapsearch -h ldap.ui.tlc2.uh.edu -p 389 -D "uid=ldap,cn=gssapi,cn=auth" 
> -W -b"dc=tlc2,dc=uh,dc=edu"
> ), then I would get a no such object error ( something similar, I can't 
> find it in my terminals now, it's been buried under mounds of strace and 
> slapd -d1 output ).

Your idea of "everything seeming to be fine" looks a bit curious, then.

> So I started testing out various parameters for 
> queries and selects and whatnot in slapd.conf ( which, by the way, is here :
<snip>

I don't have time to go thru each of the issues I noted; let me just
tell you that half of the statements in your slapd.conf are pointless,
since they either appear too early (e.g. per-database only statements
before any database) or out of scope anyway (e.g. "index" in back-sql,
which supports none).  I suggest you read the related man pages or the
admin guide to make sure you understand what each statement means and
what's supposed to do.  Note that you'll get all of them pointed out if
you run with "-d config"

> Anyways, I removed the statement 
> ( which, I realized, isn't in the above file :
> 
> has_ldapinfo_dn_ru      no 

This should __always__ be present, unfortunately.

> 
> ) from the file and then restarted slapd.  Now, after this, when I 
> repeated the above command, I get :
> 
> [root@uiln001 bin]# ldapsearch -h ldap.ui.tlc2.uh.edu -p 389 -D 
> "uid=ldap,cn=gssapi,cn=auth" -W -b"dc=tlc2,dc=uh,dc=edu"
> Enter LDAP Password:
> SASL/GSSAPI authentication started
> SASL username: root/admin@TLC2.UH.EDU
> SASL SSF: 56
> SASL installing layers
> # extended LDIF
> #
> # LDAPv3
> # base <dc=tlc2,dc=uh,dc=edu> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
> 
> ldap_result: Can't contact LDAP server (-1)
> 
> and the slapd process dies.  Okay, that's what debugging mode is for, 
> right?  Well, once I run :
> 
> slapd -h ldap:/// ldaps:/// -u ldap -d1

"-d 1" is "almost" pointless unless you know what to do with it.  I
suggest you first go with something very smooth, like "-d stats", so
that you see very basic logging.  Then, when you locate where the
relevant problem is, you can increase the debug level ("increase" means
"combine" different levels so that you get a useful blend of different
logging subsystems; for example, "-d stats,args,trace" is appropriate
for most needs; I wouldn't go "-d packets" unless you really know what
you're doing.  Unless you intended to enable as much debug as possible;
in that case, it's "-d -1".

> 
> slapd will not crash, just returns :
> 
> ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
>         additional info: SASL(-1): generic failure: GSSAPI Error: 
> Miscellaneous failure (Permission denied)
> 
> to my queries, as above.  That's interesting, since when I run it w/out 
> the -d1, it seems to authenticate properly and then crash.

Still no clue.


> ==>backsql_dn2id("dc=tlc2,dc=uh,dc=edu") matched expected
>  backsql_dn2id("dc=tlc2,dc=uh,dc=edu"): id_query "SELECT 
> id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn_ru=?"
>    backsql_dn2id("dc=tlc2,dc=uh,dc=edu"): upperdn="UDE=CD,HU=CD,2CLT=CD"
>    backsql_dn2id("dc=tlc2,dc=uh,dc=edu"): error executing query ("SELECT 
> id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn_ru=?", 
> "UDE=CD,HU=CD,2CLT=CD"):
> Return code: -1
>    Native error code: 1054
>    SQL engine state:  S0022
>    Message:           [unixODBC][MySQL][ODBC 3.51 
> Driver][mysqld-5.0.22]Unknown
> column 'dn_ru' in 'where clause'
> Segmentation fault

There you go: unless you have the column "dn_ru" in your database's
ldap_entries(), you're off.  Well, the reason for the crash is unknown;
I suggest you file an ITS after reading and following instructions at
<http://www.openldap.org/faq/data/cache/56.html>

> 
> That's weird, it appears as if running as the ldap user, there's 
> something we can't access, yet as root, we get it and it causes a 
> SEGFAULT.  Hmm...here's what strace

Don't strace when you can gdb.  Follow instructions above and you might
get help and support.

> What the strace and slapd -d1 output seems to point to is that the
> 
> has_ldapinfo_dn_ru      no
> 
> statement fried something in my SQL database.  From what I can find 
> online, it appears that the statement handles how back-sql maps queries 
> into the database, but I couldn't find one definitive answer ( the most 
> complete answer I found is on Microsoft's website, and I hardly think 
> that would be very compatible w/ OpenLDAP's implementation, unless MS 
> has really changed their definition of the word 'standards' ).  Could 
> someone please explain this to me, and why it is now causing slapd to 
> alternately crash or returns unauthorized?  Also, any hints as to what I 
> was doing wrong in the first place that I wasn't able to find any of the 
> LDAP tables in the first place would be much appreciated.

During its long and troublesome life, back-sql was modified (not sure by
whom, check the CVS) to support "optimized" DN operations by adding a
column in ldap_entries that contained the DN uppercased and reversed, so
that subtree searches could be done by running things like
"MOC=CD,ELPMAXE=CD,%" instead of "UPPER('%,dc=example,dc=com')" and
similar.  Since no-one wants to build and maintain anything like that in
their ldap_entries table, you need to tell back-sql it's not available
(although it could be inferred at startup by reading the schema of the
table; you may submit a feature request...).

I know this is not going to fix your problem, but at least you know why
you wasted so much time.  If we'd ever vote for anything like that, I'd
vote for trimming all that portion of code out of back-sql.

p.




Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------