Fedora directory users - Dec 2006 - Re: Kerberos/Samba/LDAP? Was: FDS - using one password for Samba

> Date: Wed, 27 Dec 2006 10:01:42 -0800
> From: Jim Hogan <jimh@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/

Howard,

Howard Chu wrote:
>> Date: Wed, 27 Dec 2006 10:01:42 -0800
>> From: Jim Hogan <jimh@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. 
That happens on a regular basis :(   To say that I understand Kerberos 
poorly would be charitable.
> 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.
Yes.  While my little diagram might still hold some water from a 
"desired effect" basis, the more I looked at it, the more it seemed 
obvious that there would need to be a client TGT, not some imagined LDAP 
pass-through.
> 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.
Thanks for your contributions on all fronts.  I debated OpenLDAP vs. FDS 
for some time, and wound up deploying FDS in part due to admin tools and 
some built-in self-service functionality.
> 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.
The gent who can answer that question is on vacation, but I bet I am 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.
Some of the necessary steps here seem to imply a degree of control (NTLM 
Keys) over Kerberos infrastructure which I will never have.  Whatever I 
do WRT our university Kerberos, it will have to be as a basic, 
unprivileged client.  I don''t know enough to contemplate whether
ruuning
our own Kerberos service of some type would be of any use.
> 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.)
I don''t think any brute force is in my future (''tho you just
reminded me
to try to figure out why my smb.conf minimum password length isn''t 
working!!)

Thanks very much for this exhaustive reply.  Being restless during this 
break week I posted a similar question to Samba list, but perhaps I can 
reference your response there to forestall any other time-consuming 
effort to reply..... 

Cheers,

Jim