Kerberos Authentication

Kerberos Authentication

Author: Dan Fuhry
Download: zip, tgz
License: GNU GPL
Mercurial: kerbauth (latest zip)
Report broken link

The Kerberos authentication plugin enables Enano to talk to a back-end Kerberos server for both usernames and passwords. This means that users can sign in to your Enano website using the same credentials as they would use for your own central Kerberos-based account system.

This plugin works in two main modes. The first is a "supplemental" mode that simply asks the Kerberos server if the provided username and password are valid, and if so, it logs the user in.

The second mode is enforced SSO (single sign-on). This means that Enano synchronizes user accounts on demand with your upstream account system. Local password authentication is blocked except for administrators, keeping Enano user accounts completely seamless with those of an enterprise or other large-scale deployment.

There is also a RADIUS authentication plugin on which this Kerberos plugin is based.


Known limitations

  • The kadm5 extension talks to a Kerberos admin server, not KDCs. That's a limitation of the extension. I'm looking into alternatives.

Security considerations

You'll need to close up a couple of holes in Enano that under most circumstances are harmless but can pose problems for enterprise or other large scale deployments.

  • Enano talks to Kerberos ONLY when the user logs on. After that, the local authorization in the form of a session key is considered sufficient. Consider greatly lowering the lifetime of session keys (both "short" and "extended"). If an upstream user account is disabled or deleted, it might remain accessible if the user has a valid Enano session in progress.
  • If SSO enforcement is enabled, then when a user logs in with valid Kerberos credentials but does not have a local account, one is created automatically, and the local password is locked so they can only log in using Kerberos.
  • A valid local password is required when upgrading Enano. The upgrade script does not load plugins, so Kerberos authentication settings will be entirely ignored.
    • If a user account that was originally created via Kerberos needs to be used to authenticate to the upgrade script, you must reset the user's password. Enano does not cache Kerberos passwords locally in any form.
  • If you use a registration agreement (TOU) on your site, automatically created user accounts will be treated as inactive until the TOU is accepted.
  • Enabling SSO enforcement disables local registration.
  • Again, SSO enforcement means that except for administrator accounts, local passwords do not work, even for users that existed before Kerberos was enabled. Make sure your users are aware of this change before switching your site to use Kerberos.
  • Because Enano does not cache any Kerberos details, the plugin will not add any information to the session key salting process.
  • If you use e-mail account activation, make sure that you properly set the e-mail domain in the Kerberos settings panel (under Administration → Security), and that e-mail addresses in the format of principal@domain will result in delivery.
  • Consider using ACLs to deny guests access to most pages if Enano is being used for a site that should be restricted to a specific member base.
[ PHP error: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in [root]/repo/includes/wikiengine/TagSanitizer.php:228 ]