Raffaele Sandrini <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
