KFW with NT4 domain

[g.w@hurderos.org]

On Mar 4,  3:43pm, Franco Milicchio wrote:
} Subject: Re: KFW with NT4 domain

Good morning to everyone, hope the day is going well.

> Jeffrey Altman wrote:
> > If you are configuring Samba
> > to use PAM to validate the username/password combination, then you are
> > using plaintext passwords.  In other words, I can sniff the network and
> > watch every username/password combination used on your Windows domain
> > and there in your Kerberos realm.  DO NOT DO THIS!!!
> 
> I'd like to avoid this. I know I can authenticate on a kerberos kdc 
> directly, but the user must exist locally. At least, that's what I 
> understand from MS documentation for kerberos interaction.

> > In order to use NTLMv2, you must have a copy of the password database
> > available to Samba.
> 
> That's a thing I don't know how it is possible. I can also say, don't 
> use kerberos for authentication, but at least, don't use plain text 
> passwords.

> > If you want to use Kerberos to authenticate end users, then you must use
> > Kerberos.  Either deploy an Active Directory with a cross-realm trust
> > to a non-AD KDC or deploy one of the AD workalikes.  You can travel to
> > the future and bring back a copy of Samba 4.  That will do what you
> > desire.
> 
> I don't have a time machine now, sorry :)
> 
> Again there's the fact that AD should be away from me. I know samba can 
> use ldap for authentication, but anyway, will the password run in plain 
> text? Hope not... AD and x-realms add layers, and adding things will 
> just result in more complexity and probable errors... That's why I'm 
> desperately trying to use samba as AFS gateway, along with kerberos. I 
> know there are projects like kSamba & co, but I'd like to stay with my 
> debian stable for server-side hosts.
> 
> It seems that there's really no way of avoiding AD, isn't it?

Its becoming more and more difficult to do so.  A trend which, IMHO,
is reasonably ominous for people interested in maintaining
open-architectures.  I think that in about 5 years people will look
back with chagrin and understand how ominous it was to have a
technology which tied the desktop and applications to a specific
server architecture.

For all the honk and wheeze from the OSS community about enterprise
penetration there would seem to be very little understanding of why
these issues are important.  I've decided that it has to do with the
fact that identity middleware is complext in its level of integration
and not very sexy to work on.  As with most important issues in
technology that certainly doesn't minimize its impact.

But I digress.

More specific to your issues.

There are essentially three ways to authenticate users in the
environment you are working on:

	1.) Secured credentials (ie., Kerberos).
	2.) Encrypted passwords over the wire.
	3.) Un-encrypted passwords over the wire.

Number 1 is what everybody should be striving for.  Unfortunately this
is difficult due to the fact that there is no clean out of the box
solution.  It is also problematic due to the complexities of trying to
play with how the dominant desktop vendor has decided to architect the
desktop.

Number 3 is problematic from a security perspective.  It does allow a
Samba server to authenticate against a centralized authentication
respository such as Kerberos or sub-optimally an LDAP server with
passwords tucked into the user identity object.

Number 2 requires that a copy of the plaintext password be stored
someplace so that the authenticating application can use it to verify
the encrypted password that comes in over the wire.  This has issues,
of course, with respect to security, synchronization and management.

I understand your issues with not wanting to stray very far from your
standard Debian implementation.  I don't think thats a realistic goal
in any type of enterprise management scenario.

I believe that Luke Howard down in Australia already replied back
about their product.  Luke and company are smart guys and their
product certainly would deserve a look.

Our project is trying to address the encrypted password over wire
problem in a manner which preserves Kerberos as the centralized
password management store.  You might be able to use bits and pieces
of what we are developing to help solve your problem.

Release 0.1.3 of Hurderos has an MIT Kereros extension architecture
packaged with it.  This system allows the behavior of a KDC to be
modified using extensions implemented dynamically loaded shared
libraries.

Using this extension architecture we have implemented a facility for
the Kerberos management system to save the raw passwords as encrypted
TL entries associated with the authentication principal.  The theory
is that if a raw password database is needed it would seem to make the
most sense to have the KDC manage and protect it.  Everyone can howl
as they see fit.

We are currently in the process of implementing a centralized
authenticator which hangs off the KDC.  Our plans are to provide
patches to Samba which allow it to send the encrypted password it
receives on the wire up to the centralized authenticator using a
GSSAPI protected conduit.

The authenticator will have access to the raw password which will
allow the encrypted password to be authenticated.  A yea or nay
response goes back to Samba which can then allow or disallow access to
the client.

We might have an initial implementation in 0.1.4 but that depends on
another big project that is hovering over us right now.  If there is
interest in this type of facility we would certainly consider giving
it additional priority.

> Franco Milicchio <mailto:milicchio at wisc.edu>

I hope the above information is useful to you and others faced with
similar challenges.  No really clean solutions right now but hopefully
some progress in the works.

Good luck with your project, best wishes for a productive week.

}-- End of excerpt from Franco Milicchio

As always,
Dr. Greg 'GW' Wettstein
------------------------------------------------------------------------------
                         The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org