Jeffrey Altman wrote:
> Wes Modes wrote:
>> 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.

> smbldap-tools contacts the KDC (Kerberos server) and obtains a service
> ticket for the
> OpenLDAP server. In order for this to be possible there must be a
> service principal
> in the KDC database for the OpenLDAP service and a keytab containing
> the matching
> key(s) must be installed on the OpenLDAP server.

I understand that you are saying that instead of the ldap-bind, one can
configure smbldap-tools to do a Kerberos authentication instead. In
that configuration, one would not need SASL at all.

In my case, smbldap-tools are running on the Samba server, and while it
might be possible (and I might be forced to) configure smbldap-tools to
do the kerberos auth, I'd like to do it indirectly via LDAP and
SASL/GSSAPI. Reason for this is that eventually, our campus kerberos
service will be replaced with a secure LDAP auth.

But it remains an open question for me whether it is possible to have
Samba/smbldap-tools ask LDAP/GSSAPI which indirectly asks Kerberos for
>> When someone requests a Samba logon, Samba requests an LDAP bind, which
>> in turn should use SASL to authenticate via Kerberos.

> The service ticket for the OpenLDAP server is used to authenticate the
> connection between
> Samba and OpenLDAP.

Right now I don't have a problem connecting OpenLDAP and Samba via TLS
>> The connection between Samba and OpenLDAP is working swell. It is the
>> Kerberos connection that has me flummoxed.

> For what purpose is the OpenLDAP server communicating with the KDC?

See above.
>> 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,

> kadmin.local is a version of the kadmin tool that works only on the
> local system.
> If you are not on the local system you use the 'kadmin' tool.

I get

root# kadmin
Authenticating as principal wmodes/admin@CATS.UCSC.EDU with password.
kadmin: Client not found in Kerberos database while initializing kadmin

>> 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.

> You have to explain what you want in this forum as well, otherwise you
> won't get
> very many useful answers.
>> The docs I'm referring to are
>> Cyrus SASL for System Administrators
>> OpenLDAP 2.2 Administrator's Guide - Using SASL
>> 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.

> Again the question is connecting OpenLDAP to Kerberos for what purpose?
> The KDC is not under your control so you do not have the ability to
> create new
> principals or alter the configurations of the existing ones.

Well I have access but only through the proxy of its system

> Are you really expecting the OpenLDAP server to establish a network
> channel
> with the KDC? What messages are you expecting to have sent?

I'm hoping that where it now does an ldap-bind at the request of the SMB
server, it can instead authenticate against the KDC via GSSAPI.

> Or are you simply confused about the concept of a service principal
> and the
> associated key?

As I understand it, before the KDC will allow a server access, it needs
to ensure that the server is allowed that access. So it does a key
match to certify that the server is who it says it is, and checks to see
if it is a principle.

Or I may just be completely confused about everything. Which would
certainly account for some of my vagueness, for which I apologize. On
the other hand, if I understood enough to ask perfectly intelligent
questions, I suspect I might have already been able to suss out the
answer from the reams of info I've already read.



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