To clarify.

To separate and modularize some of these services, we have three
servers: A file server running Samba; A directory server running
OpenLDAP to provide personal and group identities; and an authentication
server running Kerberos (administered by another group). Samba connects
to OpenLDAP through smbldap-tools. And OpenLDAP connects to the
Kerberos server via SASL/GSSAPI.

When someone requests a Samba logon, Samba requests an LDAP bind, which
in turn should use SASL to authenticate via Kerberos.

The connection between Samba and OpenLDAP is working swell. It is the
Kerberos connection that has me flummoxed.

Simply put, OpenLDAP with SASL2 and GSSAPI support will be running on
one server, while the Kerberos KDC will be running on another server. I
haven't found any documents that address this not-so-wacky design.

So when a document says, run kadmin.local, to generate a principle, that
is not available to me. If I can ask specifically for what I want, I
might be able to convince the kerberos administrators to do it for me,
but I have to be pretty specific about what I want.

The docs I'm referring to are

Cyrus SASL for System Administrators
http://www.sendmail.org/~ca/email/cyrus/sysadmin.html


OpenLDAP 2.2 Administrator's Guide - Using SASL
http://www.openldap.org/doc/admin22/...l#Using%20SASL


Thank you for the OpenLDAP config suggestions. Those are more or less
consistent with what I read.

However, in several documents, it was suggested that before you try
connecting OpenLDAP to Kerberos that you test to make sure your Kerberos
configuration is working. That makes a lot of sense to me. So I want
to perform a series of checks, but I don't know what those tests might
be. Here's what I would like to test:

* Can I connect to the Kerberos server directly? (kinit)
* Is direct authentication to the Kerberos server working?
* Am I getting returned a proper ticket? (klist)
* Is the keytab file on my OpenLDAP server being recognized and
accepted by the Kerberos server?
* Is my machine being authenticated as a principle? Does it need to be?
* How do I test SASL2 before getting OpenLDAP involved?
* After making changes to my OpenLDAP config, how do I test the
Kerberos connection through OpenLDAP?

Do you have any pointers here?


Douglas E. Engert wrote:
>
> If this is for an ldap client to an ldap server using GSSAPI:
>
> On OpenLDAP server in slapd.conf:
>
> security sasl=56
> says require sasl authentication, with at least DES.
> You can add other options as well.
>
> The dn of a sasl authenticated user would look like:
> uid=,realm=,cn=gssapi,cn=auth
> where the user's Kerbeors principal would have been
> @
> If the id the default realm of the slapd
> server machines, the dn would be
> uid=,cn=gssapi,cn=auth
>
> Look at the sasl-regexp on how to map these to something else.
>
> The slapd needs a keytab file with a service principal like:
> ldap/@
>
> Where fqdn is the hostname of the ldap server.
>
> Since slapd is not normally run as root, it needs access to
> its own keytab file, and something like this in the
> /etc/default/slapd or /etc/init.d/slapd
>
> KRB5_KTNAME=/etc/ldap/krb5.keytab
> export KRB5_KTNAME
>
>
> On OpenLDAP clients:
>
> The user would have gotten a Kerberos ticket (using kinit), then
>
> ldapsearch -Y GSSAPI -h ldap.server.com ...
>

Incidently, to this I get

[root]# ldapsearch -Y GSSAPI testuser1
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error:
Miscellaneous failure (No credentials cache found)

The logs say:

Feb 19 15:32:47 dir slapd[2694]: ==> sasl_bind: dn="" mech=GSSAPI
datalen=494
Feb 19 15:32:47 dir slapd[2694]: SASL [conn=5650] Failure: GSSAPI Error:
Miscellaneous failure (No principal in keytab matches desired name)
Feb 19 15:32:47 dir slapd[2694]: send_ldap_result: err=80 matched=""
text="SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (No
principal in keytab matches desired name)"

The directory server has a keytab generated on the Kerberos server that
contains "ldap/my-directory-server.ucsc.edu@KERBEROS-SERVER.UCSC.EDU" as
a principle.



>> Specifics:
>>
>> OS: Red Hat Enterprise 4 v2.6.9
>> OpenLDAP v2.2.13
>> Local MIT Kerberos5 v1.3.4
>> KDC: MIT Kerberos5 v?
>> Cyrus SASL v2.1.19
>>
>> Other questions that have come up:
>>
>> What tests can I run here that will help me know if I've configured my
>> end correctly to connect with the Kerberos server?
>>
>> How can I test to see if I have everything I need in the keytab was
>> given by the Kerberos administrators?
>>
>> This project has been delayed weeks and weeks while I climb and climb up
>> Samba, OpenLDAP, and Kerberos' very steep learning curve. So your
>> prompt response will be hugely helpful.
>>
>> Thanks in advance.
>>
>> Wes
>>
>>

>


--

Wes Modes
Server Administrator & Programmer Analyst
McHenry Library
Computing & Network Services
Information and Technology Services
459-5208