Honestly, this is the closest response I've received to restating what I already know CAN be done, understanding what I was hoping for, and admitted any possibility of doing anything remotely similar.

Buchan Milne wrote: 
On Thursday 03 April 2008 22:39:26 Wes Modes wrote:
  
So far answers I've received about this have been inconsistent at best
and downright inaccurate at worst.  I'm going to try one more time and
see if, at the very least, someone can give me a lead.  I ask you to
consider what I'm asking remotely possible, and then seek a solution.
(Particularly before one blasts off an ill-thought out message that says
simple, "Can't be done," simple because you've never done it or haven't
heard of it being done.)  So consider this a challenge or a riddle.

   1. I have an OpenLDAP directory server that I am using for user and
      group information.  I would like to use it also to authenticate
      against.  This way, whatever I hook up to it (Samba, webstuff, PHP
      apps, CMS) can both authenticate and authorize from one source.
   2. There is a separate Kerberos server that has users' campus-wide
      passwords.  I have access to it, but do not control it.
   3. I have a separate linux file server running Samba.  PCs and Macs
      will connect to it.
    

Let's ignore the solution you proposed, and look at what you *can* do.

1)You can have the OpenLDAP directory server authenticate simple binds against 
the KDC

Check.  Got there pretty early.
2)You can (if your OpenLDAP directory server has appropriate service 
principals and their tickets or keytabs) authenticate LDAP access to your 
OpenLDAP directory server via Kerberos
Check.  With some help, I got there.  I've set up the OpenLDAP to Kerberos connection using Saslauthd and replacing the hashed userPassword field with {SASL}username@MYREALM.EDU. 
 
3)You can have all your user and group information (including the samba 
password hashes, samba group mappings etc.) in the OpenLDAP directory server.
Check.  This took some doing and the help of smbldap-tools, but I got there too.  I've set up the authentication connection between Samba and OpenLDAP, via smbldap-tools.  It works by adding new fields to the OpenLDAP schema specific to the needs of samba.  Then samba uses those OpenLDAP fields as a hashed password repository. 

The challenge is that these are two methods allow Samba to authenticate via OpenLDAP and allow OpenLDAP to authenticate via Kerberos, they are really intended for different purposes.  In method one, samba is authenticating by comparing the passwords its getting to the OpenLDAP hashed repository.  In method two, OpenLDAP is using saslauthd to authenticate against a Kerberos realm.  They are two different mechanisms with two different security models.

I know now that I can't just plug them in end-to-end and expect them to work.  But I was hoping that experts on this and the OpenLDAP list would suggest creative solutions.  I'm open to creative hacks and use contrary to labeling.  

Thus far, there isn't really a means for you to authenticate access from 
Windows clients accessing your samba server with the same credentials that 
they use for (1) or (2).

However, the "Active Directory Password Cache" overlay sitting in ITS may 
help. Instead of (1), you may rather choose to use the adpwc overlay, simple 
binds against the directory would first try and authenticate with the 
password hash stored in the userPassword attribute in-directory. If that 
fails, the overlay intercepts that, and tries a Kerberos authentication with 
the principal stored in the krbPrincipalName attribute. If this succeeds, the 
overlay hashes the password and stores the has in the userPassword attribute, 
and hashes it with a samba-compatible hash and stores the has in the 
sambaNTPassword attribute.

Now, authentications with the same password will not contact the KDC, and 
samba should be able to authenticate the user with the hash in the OpenLDAP 
directory.

The inconvenience here is that if the password has changed on the KDC, Samba 
won't get the new password until the directory server has seen a simple bind 
with the new password. The inconvenience could be reduced by putting in a 
simple web script allowing users to sync their passwords.

The password expiry aspects also need some looking at ...
There are a few new concepts here for me that I'll go away and learn something about, namely overlays.  And a sneaking worry that your mention of Active Directory might ice me out of the solution since I am running Samba on RHEL. 

Wes
--

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