Wes Modes wrote:
> Thanks, Sean. I've set up the OpenLDAP to Kerberos connection using
> Saslauthd and the {SASL}username@MYREALM.EDU. That part at least is
> indeed possible.
> [..]
> 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.

Maybe you should think about why "creative hacks" are not a good idea
and therefore the experts do not suggest any. Kerberos has a certain
security model. For security reasons the TGT is not something which
should be stored everywhere. I also consider the saslauthd hack with
{SASL}username@MYREALM.EDU to be not acceptable.

Ciao, Michael.

Michael Ströder wrote:
> Wes Modes wrote:
>
>> Thanks, Sean. I've set up the OpenLDAP to Kerberos connection using
>> Saslauthd and the {SASL}username@MYREALM.EDU. That part at least is
>> indeed possible.
>> [..]
>> 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.
>>
>
> Maybe you should think about why "creative hacks" are not a good idea
> and therefore the experts do not suggest any. Kerberos has a certain
> security model. For security reasons the TGT is not something which
> should be stored everywhere. I also consider the saslauthd hack with
> {SASL}username@MYREALM.EDU to be not acceptable.
>
> Ciao, Michael.
I've been a sysadmin since 1984, and while I hardly know everything (in
fact, there are holes in my knowledge you could drive a fleet of trucks
through), I am more than familiar with the reasons why creative hacks
are problematic. However, not everyone is totally closed to creative
solutions and looking beyond only the things they are familiar with.

The sactamonious and arrogant attitude of list denizens towards people
who do not already know everything there is to know about a subject, do
nothing to make the development community more secure or more
competent. In fact, it create a culture of hyper-criticism in which
people are afraid to ask perfectly reasonable and important questions.

Another more patient and creative list member, Buchan Milne, pointed me
at the Active Directory Password Cache overlay for OpenLDAP, which seems
to offer more or less what I'm trying to do. Thought you might be
interested because it allows one to sync a Kerberos, OpenLDAP, and Samba
passwords invisibly.

Active Directory Password Cache
===============================


Active Directory does not provide any means to read user credentials on any
public API. It is possible, to install additional libraries as password sniffer to
catch and forward cleartext passwords on changes. In case you cannot or simply
dont want to install such libraries, the Active Directory Password Cache overlay
is your option.

The Active Directory Password Cache overlay allows to mirror user account
credentials without any modification on the AD server. It only takes one
occasional simple bind authentication against the OpenLDAP server.

If the credential has not been mirrored yet, the overlay uses the
krbPrincipalName
and the password provided by the user to perform a Kerberos init against the
Active Directory. A successful Kerberos init guarantees a correct password for
this principal, and therefor the bind finally succeeds.

Within this overlay operation, the password gets encrypted with the default
OpenLDAP hash alorithm and stored as userPassword attribute. There is an option
to update the sambaNTPassword also (using code borrowed from Howard Chu's
smbk5pwd overlay). All following simple bind authentications will first try
these cached credentials, making the OpenLDAP server independent from AD.

In case the user changes its password on the Active Directory server, the old
password stays valid in OpenLDAP until the user first presents the new password
for an simple bind. Within this bind operation, the overlay performs another
Kerberos init and updates the cached credentials in OpenLDAP.


W.

--

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

Wes Modes wrote:
> Michael Ströder wrote:
>>
>> Maybe you should think about why "creative hacks" are not a good idea
>> and therefore the experts do not suggest any. Kerberos has a certain
>> security model. For security reasons the TGT is not something which
>> should be stored everywhere. I also consider the saslauthd hack with
>> {SASL}username@MYREALM.EDU to be not acceptable.
>
> The sactamonious and arrogant attitude of list denizens towards people
> who do not already know everything there is to know about a subject, do
> nothing to make the development community more secure or more
> competent. In fact, it create a culture of hyper-criticism in which
> people are afraid to ask perfectly reasonable and important questions.

I whole-heartly agree. But funny that *you* mention that.

Ciao, Michael.