Forge Home

kerberos

Manage MIT Kerberos

17,585 downloads

14,136 latest version

4.6 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 0.3.1 (latest)
  • 0.3.0
  • 0.2.0
released Oct 27th 2016
This version is compatible with:
  • RedHat, Debian, Ubuntu

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'edgester-kerberos', '0.3.1'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add edgester-kerberos
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install edgester-kerberos --version 0.3.1

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Download

Documentation

edgester/kerberos — version 0.3.1 Oct 27th 2016

A puppet module for managing MIT Kerberos clients and servers Build Status

License

BSD

Contact

jason@rampaginggeek.com

Support

Please log tickets and issues at our Projects site

Example Use

# Kerberos server (kdc and kadmin)
class {'kerberos':
  master                => true,
  realm                 => 'EXAMPLE.ORG',
  kdc_database_password => 'secret',
}

# kerberos client
class {'kerberos':
  client            => true,
  realm             => 'EXAMPLE.ORG',
  domain_realm      => { '.example.org' => 'EXAMPLE.ORG', },
  kdcs              => ['cellserver.example.org'],
  admin_server      => 'cellserver.example.org',
  allow_weak_crypto => true,
}

Hiera Usage

Define all the main class parameters you'd like to change like this:

kerberos::realm: 'EXAMPLE.ORG'
kerberos::kdcs:
  - 'cellserver.example.org'

Forget about client => true. Just include or hiera_include() any of the following classes:

kerberos::client
kerberos::kdc::master
kerberos::kdc::slave

It is best to store passwords in Hiera; that way, you can have a set of test credentials, and a different set of credentials for production servers. For example, in debug environments, you might use realmone.local and realmtwo.local instead of realmone.com and realmtwo.com, which of course would cause puppet to pull your configuration from different .yaml files. Debug configuration could be checked in to the repository, and production values could be stored in a more secure location.

###kdc1.realmone.com.yaml:

  ---
  kerberos::principals:
    user1:
      password: secretsecret

###kdc2.realmtwo.com.yaml:

  ---
  kerberos::principals:
    user2:
      password: p4ssw0rd!

###production.yaml:

  ---
  kerberos::kdc_database_password: verylongsecurerandomlyproducedpassword

  trusted_realms:
    realms:
      - REALMONE.COM
      - REALMTWO.COM
    password: differentverylongsecurerandomlyproducedpassword

You can also define a additional [capaths] section or additional realms to your [realms] section with Hiera

###capaths.yaml:

  ---
  kerberos::capaths:
    'EXAMPLE.COM':
      - 'OTHER-REALM.COM': '.'
    'US.EXAMPLE.COM':
      - 'OTHER-REALM.COM': 'EXAMPLE.COM'

###extra_realms.yaml:

  ---
  kerberos::extra_realms:
    'EXAMPLE.COM':
      - 'kdc': 'kdc1.example.com'
      - 'kdc': 'kdc2.example.com'
      - 'kdc': 'kdc3.example.com'
    'OTHER-REALM.COM':
      - 'kdc': 'kdc1.other-realm.com'
      - 'kdc': 'kdc2.other-realm.com'