1:14 p.m.
Date: Wed, 27 Dec 2006 10:01:42 -0800
From: Jim Hogan <jimh(a)u.washington.edu>
I have a brand-new Samba 3.x domain working with LDAP/FDS backend;
this
is just for my small (university) department of ~350 users. The
university operates an overarching Kerberos realm. My best possible
case would be to use that Kerberos realm for authentication/password but
continue to maintain department LDAP for actual user/group
authorization/rights. If I can get everything to use people's existing
university password, that would be very sweet; failing that, I have to
give out about 300 passwords in the next month :(
I see the FDS Kerberos Howto, and it seems to make Kerberos integration
pretty simple, but what is not clear to me is whether it is possible to
pass this Kerberos authentication through to Samba clients. The few
references I see to Samba-Kerberos integration modify the smb.conf with
direct references to kerberos realm and keytab that would seem to result in:
Samba ----> Kerberos
_____ <---- ________
where what I think I want is more like:
Samba ----> LDAP ----> Kerberos
_____ <---- ____ <---- ________
(sorry for the awful ASCII!) where I retain "passdb backend =
ldapsam:ldap://x.x.x.x" as the user/group store, but where LDAP refers
to Kerberos for authn/passwd.
I was going to pose this question to the Samba users list, but I thought
there might be more value to ask first whether anyone has worked on this
in a FDS context. Not to say anything bad about other LDAP servers, but
I can sometimes find it hard to map integration discussions that use
OpenLDAP examples to my situation.
So, anyone on the list running a completely integrated
Samba/FDS/Kerberos setup that references an overarching Kerberos realm?
You're confusing some of these steps. First of all, the direct Samba ->
Kerberos route is only talking about a very special case - an SMB client
with its own TGT, getting a service ticket from Kerberos for talking to
Samba. In this case, Samba uses Kerberos as the actual client
authentication mechanism. And as noted here:
http://www.mail-archive.com/samba@lists.samba.org/msg80208.html
this only works in Samba3 when Samba is talking to a real
ActiveDirectory server.
When Samba is configured to talk directly to LDAP, it only uses it as a
data store, not as an authentication mechanism. In that case, it is
expecting to find sambaNTPassword or sambaLMPassword attributes in the
LDAP store, so that it can validate the authentication itself. As such,
your Samba -> LDAP -> Kerberos picture doesn't apply.
Currently the only way to have all of these things integrated in one
place is to use the OpenLDAP server with smbk5pwd module, with Heimdal
KDC using OpenLDAP as its data store, and Samba using OpenLDAP as its
data store. I've contributed code to the Fedora project to assist them
along these same lines but it's still missing secure ldapi:// support
and a few other things, so AFAIK OpenLDAP is the only solution at the
moment.
The only way you could set things up so that authentication works as you
want is if the clients send plaintext passwords over the wire. That's
obviously a bad idea to begin with, and for recent clients (W2K etc)
it's not even an option.
If your existing Kerberos KDC is not Heimdal, and you don't have the
option of migrating to Heimdal, then I think you're out of luck. I know
that there's preliminary support for LDAP in recent MIT releases, but my
experience with MIT Kerberos has been pretty unsatisfactory over the
years. They only recently took steps to make their library thread-safe,
and their library performance is still several times slower than
Heimdal's, making it unsuitable for busy sites. Even if you decided to
switch to using Heimdal integrated with LDAP, you still need the NTLM
keys, which you cannot derive from the Kerberos keys, so I think you're
looking at regenerating your ~300 passwords regardless.
Of course, there's always the brute force approach of running a password
cracker on the KDC database to try to guess the original plaintext. It's
a self-defeating activity but I've been cajoled into doing it in the
past. (It takes a long time, you may not successfully crack all the
accounts, and succeeding only means that your users have poorly chosen
passwords that they ought to change anyway.)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/