RE: Problems with OpenLDAP 2.1.4 and Kerberos

["Anthony Brock" <abrock@georgefox.edu>]

Well,

I have looked through all the available logs and found no applicable
entries. I posted a copy of the "truss" output in my original post (I'm
not a skilled programmer, and the truss output has proven to be less
than helpful). Regarding the sniffer, I will attempt that on Monday.
Will this "AS_REP" be easy to identify? Or should I be looking for
specific patterns?

Thanks again, I entered the command with the options below, and it still
fails (never mentioning "SASL/GSSAPI authentication started" or any of
the other output). When I add the "-x", "-D ..." and "-W' flags, it
works perfectly! It's nice to know that SOMETHING is wrong other than
me!

Tony


Anthony Brock
Director of Network Services
George Fox University

E-Mail: abrock@georgefox.edu
Phone:  (503) 554-2579
FAX:    (503) 554-3834




-----Original Message-----
From: Phil Mayers [mailto:p.mayers@ic.ac.uk] 
Sent: Thursday, September 19, 2002 5:42 PM
To: Anthony Brock
Cc: Quanah Gibson-Mount; openldap-software@OpenLDAP.org
Subject: RE: Problems with OpenLDAP 2.1.4 and Kerberos


That is correct:

[user@wildfire user]$ kinit
Password for user@DOMAIN.COM:
[user@wildfire user]$ ldapsearch -h ads.domain.com -b dc=domain,dc=com
cn=user
SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
version: 2

#
# filter: cn=user
# requesting: ALL
#

# user, dept, Users, domain, com
dn: CN=user,OU=dept,DC=domain,DC=com
<snip>

[user@wildfire user]$ klist
Ticket cache: FILE:/tmp/krb5cc_502
Default principal: user@DOMAIN.COM

Valid starting     Expires            Service principal
09/20/02 01:33:19  09/20/02 09:33:28  krbtgt/DOMAIN.COM@DOMAIN.COM
09/20/02 01:34:06  09/20/02 02:34:06  ldap/ads.domain.com@DOMAIN.COM
09/20/02 01:34:06  09/20/02 02:34:06  ldap/ads.domain.com@DOMAIN.COM

Kerberos 4 ticket cache: /tmp/tkt502
klist: You have no tickets cached

So yes, providing SASL can see the Kerberos/GSSAPI libs, and the
Kerberos libs 
are configured correctly (kinit is working, etc.) you should see an 
ldap/ads.domain.com@DOMAIN.COM ticket in your cred cache after the
search.

If not, I recommend:

1) Checking the syslog
2) Using ethereal to snoop the net traffic - does an AS_REP ever go out?
3) Using (s|l)trace/truss/ktrace to watch the API calls

Hope this helps.

-- 
Regards, 
Phil 

+------------------------------------------+ 
| Phil Mayers                              | 
| Network & Infrastructure Group           | 
| Information & Communication Technologies | 
| Imperial College                         | 
+------------------------------------------+ 


Quoting Anthony Brock <abrock@georgefox.edu>:

> I am attempting to connect to Active Directory using the OpenLDAP
> ldapsearch binary. So far, none of what I am attempting to do involves
> an OpenLDAP server. Given this situation, I agree that the keytab file
> on the UNIX server is not important. However, it does appear that I
> should be receiving a ticket for
> "ldap/ads01.campus.georgefox.edu@CAMPUS.GEORGEFOX.EDU" in my
credentials
> cache if ads01.campus.georgefox.edu is our test server.
> 
> Am I incorrect in this assumption? The learning curve on this is
> amazing.....
> 
> Tony
> 
> 
> Anthony Brock
> Director of Network Services
> George Fox University
> 
> E-Mail: abrock@georgefox.edu
> Phone:  (503) 554-2579
> FAX:    (503) 554-3834
> 
> 
> 
> 
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@stanford.edu] 
> Sent: Thursday, September 19, 2002 1:26 PM
> To: Anthony Brock; openldap-software@OpenLDAP.org
> Subject: RE: Problems with OpenLDAP 2.1.4 and Kerberos
> 
> Tony,
> 
> I'd be more curious about the keytab issue rather than the ticket.  I
> guess 
> I'm not quite sure what you are doing.  You are connecting to active 
> directory with the openldap ldapsearch binary?  Or you are connecting
to
> an 
> openldap server running on Windows?  In the former case, neither the
> keytab 
> nor the ticket will do anything for you.  In the latter, you
definately 
> need the K5 ldap/<host> keytab.
> 
> --Quanah
> 
> --
> Quanah Gibson-Mount
> Senior Systems Administrator
> ITSS/TSS/Computing Systems
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
> 


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/