ClueNet is looking for a new Chief Technical Admin. More information here.

From ClueWiki

Cluenet servers are linked together in such a way that a single Cluenet account is maintained centrally such that it can transparently use all services that it has access to. There are several layers to this structure, the most basic being the authentication and authorization layer. Authentication databases are maintained both in an LDAP directory and in a Kerberos database, and authentication can be performed to either. The passwords between the two are synchronized.

The Cluenet account entries in the LDAP directory use several standard objectclasses as well as some custom schema. The custom objectclasses provide the ability to synchronize SSH public and private keys across servers, store some extra personal information about the user, store information provided at the time of signup, provide provisions for account suspension and deletion, and provide some extra authorization information. The structure of the accounts in the LDAP server is fairly standard. Group dn's are in the form of cn=groupname,ou=Group,dc=cluenet,dc=org and user dn's are in the form uid=username,ou=people,dc=cluenet,dc=org . Account information is stored according to the standard posixAccount objectclass.

Scripts running on individual servers poll the LDAP database for updates on account suspension and deletion to make sure local information is the same as the centrally maintained databases. Cluenet servers are also linked together in their email handling. Mail clients on individual servers use the Cluenet IMAP server to retrieve mail and local MTAs use it as a smarthost to send mail.

The Kerberos authentication database can be used for several authentication services, and allows for things like passwordless access to many services once you have a ticket.