Re: User Mangment: LDAP, AFS, Kerberos
Raffaele Sandrini <rasa@gmx.ch> writes:
> I'm thinking about creating a central managed user and data system
> here. It should use AFS (OpenAFS) as virtual filesystem and LDAP
> (OpenLDAP) as User and Comuter info Database. I tried this earlier
> but it ended in more than one user database (LDAP and AFS (kerberos
> 4)). I thought of using Kerberos 5 as login and credentials manager
> because its very secure.
(You might clarify your terminology and motivations here. Do you have
other services that would benefit from having Kerberos around [IMAP
comes to mind]? I've generally heard it recommended that people use
the krb5 KDC with OpenAFS, but you can in principle use the AFS
kaserver just as well.)
> I am not sure if it is possible for this three compnents (AFS,LDAP
> and Kerberos 5) to interact together using LDAP as central
> infobase. M$ has managed to get that to work with its AD and Login
> system and DFS wich is all kerberos 5 based.
At MIT, there's some local very ugly glue that tries to keep
everything synchronized. At the very least, you need to make sure
that a given user has a Kerberos identity, an AFS pts identity, and an
AFS home directory, in addition to an LDAP entry. When new users are
created, all of these things need to be set up, and when users are
deactivated, they need to go away. You also might consider that it's
possible to give a machine a Kerberos entry (and a /etc/krb5.keytab)
but not give it a pts identity, or a pts identity but not an AFS
directory.
> There are several issues wich need to be thought about:
> - Is there a need for Kerberos 5? Is LDAP over SSL not equal secure?
"Is there a need for breakfast cereal? Does not copy paper provide
fiber?" Really, these are two completely separate things.
> - Is there a possiblity to trim OpenAFS to LDAP so that it not uses
> its own userdatabases?
I don't believe so.
> - If Kerberos 5 is needed is there a way to trim it to LDAP?
I don't believe so. (But you have the same issues with kaserver as
you would with the krb5 KDC.)
> The system should be the most secure and the most simple one :)).
You should consider what you really mean as "secure". On Athena
(MIT's computing system), for example, the root password for cluster
machines is fairly public, but being root on a given machine gives you
very little power to break into other people's accounts. Unencrypted
telnet and FTP have both been disabled on officially maintained
machines to try to limit the amount of password sniffing on the
network, but denial-of-service attacks (in the form of file-sharing
programs) are a major issue. Sadly, security and simplicity generally
don't go together. (Consider that your pointy-haired boss probably
wants everything to be available on the Web, but Kerberos and HTTP
don't play together well, and the browser they want to use is probably
closed-source anyways.)
--
David Maze dmaze@debian.org http://people.debian.org/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: