LDAP, SSO and Kerberos (was Re: [Gllug] LDAP)

Simon Stewart sms at lateral.net
Wed Sep 26 10:47:32 UTC 2001


Renaming this fork of the thread, because we're getting away from LDAP
on to wider issues....

On Wed, Sep 26, 2001 at 11:11:36AM +0100, Alex Hudson wrote:
> On Wednesday 26 September 2001 10:49, you wrote:
> > > Single-sign on in the true sense of the word requires Kerberos. I.e.,
> > > logon into authentication domain, and automatically be authenticated with
> > > any member of the authentication domain.
> >
> > Agreed, you need something like Kerberos to implement SSO (Novell[1]
> > whispers that it's possible using their products too), but for simple
> > authentication you don't _need_ it.
> 
> But ... we weren't talking about per-server authentication, we were talking 
> about single sign-on. For single sign-on you _do_ need it.

Well, I started out wanting to centralise the administration of
user/group details, so in that respect we (initially) were talking
about per-server authentication, but....

Hang on, I've never said that you don't need Kerberos for SSO; all
I've said is that for simple authentication you _don't_ need
Kerberos --- a password will do. I have a horrible feeling that we're
only a handful of posts away from semantic hair splitting. :)

> > The next question is: do I need SSO? Not often, but it might be useful
> > if I didn't use SSH keys from one central machine (no point having my
> > private key on every machine I use)
> 
> I prefer it. Why should I have to keep typing in my password all over the 
> place? SSO is more secure. Kerb' doesn't just do ktelnet/kssh, you can use it 
> with pop, imap, etc., etc....

Which is one of the nice things about it. Certainly, at some point,
integrating qmail or postfix with LDAP is going to become an
interesting (necessary?) thing to do. But not now. Now, I'm trying to
get up to speed learning how LDAP works, and how it can be used for
reducing the hassle of adminning users and groups on my
network. Kerberos is a part of that, especially if I'm going to wander
into SSO territory and if internal security becomes an issue (which it
undoubtedly will before this thing goes live)

> > I was under the impression that W32 liked to resend your password
> > across the notwork when you want to use a remote resource. 
> 
> Not, not in a Kerberos domain. Windows2000 adheres pretty well to Kerberos. 
> Previously, if you wanted to use Linux within a Windows domain (for example) 
> then you would either have to send your password across the network (if it 
> was an early version of Windows) or participate in NT challenge/response.

Apologies, some sleeting particle of cross-purposes must have slammed
into what passes for my brain ;) You're right, of course. Fortunately,
I'm in a Linux/Mac/BSD shop atm --- I'm glad to say that the Windows
boxes have to try and take part in _our_ domain. Since you appear to
know what you're talking about, how easy is it to get a W2000 machine
to authenticate against an OpenLDAP server using MIT Kerberos?

> > to bet that I've oversimplified and am probably wrong, but it wouldn't
> > surprise me if that's the way it worked.
> 
> That's the way it works on UNIX too, don't forget.

*shrugs* Depends on whether you're using Kerberos :))

> > > > > Why not store your password as an MD5 string in your LDAP database.
> > > > > Then when a user makes a PAM autentication/request just pipe it
> > > > > through an MD5 hash first then send over the network. It will give a
> > > > > measure of security.
> > > >
> > > > That's what I do. Works quite nicely.
> > >
> > > Yes, but not securely, if that _is_ what you actually do. Hashing a
> > > password doesn't make it unsniffable I'm afraid. You're just as insecure
> > > as plaintext.
> >
> > It does depend on how hard it is to crack the hashing algorithm, or to
> > brute force the password, which is why it provides "a measure of
> > security"
> 
> No, it doesn't depend on _any_ of those things. If I sniff your MD5'd 
> password, I can use that to access your servers. I don't need to 'crack' 
> anything. You have _NO_ security from that method whatsoever, it's just like 
> telnetting all over the place.

Okay, point taken. I still trust my internal network while I'm testing
this stuff, though, and I still have a measure of security --- unless
someone decrypts my password they can only log on to those facilities
on the network that offer access via an MD5'd password sent over the
LAN. That's the machines on my desk. You're welcome to come and have a
poke about on them. To get on to my servers, you need to use SSH. And
a completely different password.

> > For now, working in the place I work, I'm willing to trust
> > the LAN with a hash of my password. 
> 
> Then you may as well trust it with your clear-text password: your methods are 
> equivilent.

The methods, from your POV are equivilent, but NO! If I were foolish
enough to use the same password in testing this setup as I use on my
servers then I'd be inviting trouble with clear text passwords!

Cheers,

Simon

-- 
"Today I met with a subliminal advertising executive for just a second."
     Steven Wright

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list