mirror of
https://git.freebsd.org/src.git
synced 2026-01-16 23:02:24 +00:00
krb5: Import MIT 1.21.3
Import MIT KRB5 1.21.3, which will gracefully replace KTH Heimdal. The tarball used in this import is the same tarball used in ports/krb5-121. The Makefiles to add MIT KRB5 to the build will be added later. Obtained from: http://web.mit.edu/kerberos/dist/ Sponsored by: The FreeBSD Foundation Add 'crypto/krb5/' from commit '8f7d3ef26dec89a92ec0665de84a5936310a5574' git-subtree-dir: crypto/krb5 git-subtree-mainline:bf6873c578git-subtree-split:8f7d3ef26d
This commit is contained in:
Cy Schubert
commit
7f2fe78b9d
4459 changed files with 977490 additions and 0 deletions
104
crypto/krb5/.github/workflows/build.yml
vendored
Normal file
104
crypto/krb5/.github/workflows/build.yml
vendored
Normal file
|
|
@ -0,0 +1,104 @@
|
|||
name: Build
|
||||
|
||||
on:
|
||||
push: {paths: [src/**, .github/workflows/build.yml]}
|
||||
pull_request: {paths: [src/**, .github/workflows/build.yml]}
|
||||
|
||||
jobs:
|
||||
|
||||
unix:
|
||||
runs-on: ${{ matrix.os }}
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
name: [linux-clang, linux-clang-openssl, linux-gcc]
|
||||
include:
|
||||
- name: linux-clang
|
||||
os: ubuntu-latest
|
||||
compiler: clang
|
||||
makevars: CPPFLAGS=-Werror
|
||||
configureopts: --enable-asan
|
||||
- name: linux-clang-openssl
|
||||
os: ubuntu-latest
|
||||
compiler: clang
|
||||
makevars: CPPFLAGS=-Werror
|
||||
configureopts: --with-crypto-impl=openssl
|
||||
- name: linux-gcc
|
||||
os: ubuntu-latest
|
||||
compiler: gcc
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v1
|
||||
- name: Linux setup
|
||||
if: startsWith(matrix.os, 'ubuntu')
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y bison gettext keyutils ldap-utils libcmocka-dev libldap2-dev libkeyutils-dev libsasl2-dev libssl-dev python3-kdcproxy python3-pip slapd tcsh
|
||||
pip3 install pyrad
|
||||
- name: Build
|
||||
env:
|
||||
CC: ${{ matrix.compiler }}
|
||||
MAKEVARS: ${{ matrix.makevars }}
|
||||
CONFIGURE_OPTS: ${{ matrix.configureopts }}
|
||||
run: |
|
||||
cd src
|
||||
autoreconf
|
||||
./configure --enable-maintainer-mode --with-ldap $CONFIGURE_OPTS --prefix=$HOME/inst
|
||||
make $MAKEVARS
|
||||
make check
|
||||
make install
|
||||
- name: Display skipped tests
|
||||
run: cat src/skiptests
|
||||
- name: Check for files unexpectedly not removed by make distclean
|
||||
run: |
|
||||
cd src
|
||||
make distclean
|
||||
rm -rf autom4te.cache configure include/autoconf.h.in
|
||||
if [ -n "$(git ls-files -o)" ]; then
|
||||
echo "Files not removed by make distclean:"
|
||||
git ls-files -o
|
||||
exit 1
|
||||
fi
|
||||
|
||||
windows:
|
||||
runs-on: windows-latest
|
||||
env:
|
||||
KRB_INSTALL_DIR: C:\kfw
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v1
|
||||
- name: Setup
|
||||
shell: cmd
|
||||
run: |
|
||||
mkdir %KRB_INSTALL_DIR%
|
||||
- uses: ilammy/msvc-dev-cmd@v1
|
||||
with:
|
||||
arch: x86
|
||||
- name: Build 32-bit
|
||||
shell: cmd
|
||||
run: |
|
||||
cd src
|
||||
set
|
||||
set PATH=%PATH%;%wix%bin
|
||||
nmake -f Makefile.in prep-windows
|
||||
nmake
|
||||
nmake install
|
||||
cd windows\installer\wix
|
||||
nmake
|
||||
rename kfw.msi kfw32.msi
|
||||
- uses: ilammy/msvc-dev-cmd@v1
|
||||
with:
|
||||
arch: x64
|
||||
- name: Build 64-bit
|
||||
shell: cmd
|
||||
run: |
|
||||
cd src
|
||||
set
|
||||
set PATH=%PATH%;%wix%bin;"%WindowsSdkVerBinPath%"\x86
|
||||
nmake clean
|
||||
nmake
|
||||
nmake install
|
||||
cd windows\installer\wix
|
||||
nmake clean
|
||||
nmake
|
||||
rename kfw.msi kfw64.msi
|
||||
41
crypto/krb5/.github/workflows/doc.yml
vendored
Normal file
41
crypto/krb5/.github/workflows/doc.yml
vendored
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
name: Doc
|
||||
|
||||
on:
|
||||
push: {paths: [doc/**, src/doc/*, src/include/krb5/krb5.hin, .github/workflows/doc.yml]}
|
||||
pull_request: {paths: [doc/**, src/doc/*, src/include/krb5/krb5.hin, .github/workflows/doc.yml]}
|
||||
|
||||
jobs:
|
||||
doc-older-sphinx:
|
||||
runs-on: ubuntu-22.04
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v1
|
||||
- name: Linux setup
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y doxygen python3-lxml python3-pip python3-sphinx
|
||||
pip3 install Cheetah3
|
||||
- name: Build documentation
|
||||
run: |
|
||||
cd src/doc
|
||||
make -f Makefile.in SPHINX_ARGS=-W htmlsrc
|
||||
doc-newest-sphinx:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v1
|
||||
- name: Linux setup
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y doxygen python3-lxml python3-pip
|
||||
pip3 install Cheetah3 sphinx
|
||||
- name: Build documentation
|
||||
run: |
|
||||
cd src/doc
|
||||
make -f Makefile.in SPHINX_ARGS=-W htmlsrc
|
||||
- name: Upload HTML
|
||||
uses: actions/upload-artifact@v2
|
||||
with:
|
||||
name: html
|
||||
path: doc/html
|
||||
retention-days: 7
|
||||
1384
crypto/krb5/NOTICE
Normal file
1384
crypto/krb5/NOTICE
Normal file
File diff suppressed because it is too large
Load diff
578
crypto/krb5/README
Normal file
578
crypto/krb5/README
Normal file
|
|
@ -0,0 +1,578 @@
|
|||
Kerberos Version 5, Release 1.21
|
||||
|
||||
Release Notes
|
||||
The MIT Kerberos Team
|
||||
|
||||
Copyright and Other Notices
|
||||
---------------------------
|
||||
|
||||
Copyright (C) 1985-2024 by the Massachusetts Institute of Technology
|
||||
and its contributors. All rights reserved.
|
||||
|
||||
Please see the file named NOTICE for additional notices.
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
Unified documentation for Kerberos V5 is available in both HTML and
|
||||
PDF formats. The table of contents of the HTML format documentation
|
||||
is at doc/html/index.html, and the PDF format documentation is in the
|
||||
doc/pdf directory.
|
||||
|
||||
Additionally, you may find copies of the HTML format documentation
|
||||
online at
|
||||
|
||||
https://web.mit.edu/kerberos/krb5-latest/doc/
|
||||
|
||||
for the most recent supported release, or at
|
||||
|
||||
https://web.mit.edu/kerberos/krb5-devel/doc/
|
||||
|
||||
for the release under development.
|
||||
|
||||
More information about Kerberos may be found at
|
||||
|
||||
https://web.mit.edu/kerberos/
|
||||
|
||||
and at the MIT Kerberos Consortium web site
|
||||
|
||||
https://kerberos.org/
|
||||
|
||||
Building and Installing Kerberos 5
|
||||
----------------------------------
|
||||
|
||||
Build documentation is in doc/html/build/index.html or
|
||||
doc/pdf/build.pdf.
|
||||
|
||||
The installation guide is in doc/html/admin/install.html or
|
||||
doc/pdf/install.pdf.
|
||||
|
||||
If you are attempting to build under Windows, please see the
|
||||
src/windows/README file.
|
||||
|
||||
Reporting Bugs
|
||||
--------------
|
||||
|
||||
Please report any problems/bugs/comments by sending email to
|
||||
krb5-bugs@mit.edu.
|
||||
|
||||
You may view bug reports by visiting
|
||||
|
||||
https://krbdev.mit.edu/rt/
|
||||
|
||||
and using the "Guest Login" button. Please note that the web
|
||||
interface to our bug database is read-only for guests, and the primary
|
||||
way to interact with our bug database is via email.
|
||||
|
||||
PAC transitions
|
||||
---------------
|
||||
|
||||
Beginning with release 1.20, the KDC will include minimal PACs in
|
||||
tickets instead of AD-SIGNEDPATH authdata. S4U requests (protocol
|
||||
transition and constrained delegation) must now contain valid PACs in
|
||||
the incoming tickets. Beginning with release 1.21, service ticket
|
||||
PACs will contain a new KDC checksum buffer, to mitigate a hash
|
||||
collision attack against the old KDC checksum. If only some KDCs in a
|
||||
realm have been upgraded across versions 1.20 or 1.21, the upgraded
|
||||
KDCs will reject S4U requests containing tickets from non-upgraded
|
||||
KDCs and vice versa.
|
||||
|
||||
Triple-DES and RC4 transitions
|
||||
------------------------------
|
||||
|
||||
Beginning with the krb5-1.21 release, the KDC will not issue tickets
|
||||
with triple-DES or RC4 session keys unless explicitly configured using
|
||||
the new allow_des3 and allow_rc4 variables in [libdefaults]. To
|
||||
facilitate the negotiation of session keys, the KDC will assume that
|
||||
all services can handle aes256-sha1 session keys unless the service
|
||||
principal has a session_enctypes string attribute.
|
||||
|
||||
Beginning with the krb5-1.19 release, a warning will be issued if
|
||||
initial credentials are acquired using the des3-cbc-sha1 encryption
|
||||
type. Beginning with the krb5-1.21 release, a warning will also be
|
||||
issued for the arcfour-hmac encryption type. In future releases,
|
||||
these encryption types will be disabled by default and eventually
|
||||
removed.
|
||||
|
||||
Beginning with the krb5-1.18 release, all support for single-DES
|
||||
encryption types has been removed.
|
||||
|
||||
Major changes in 1.21.3 (2024-06-26)
|
||||
------------------------------------
|
||||
|
||||
This is a bug fix release.
|
||||
|
||||
* Fix vulnerabilities in GSS message token handling [CVE-2024-37370,
|
||||
CVE-2024-37371].
|
||||
|
||||
* Fix a potential bad pointer free in krb5_cccol_have_contents().
|
||||
|
||||
* Fix a memory leak in the macOS ccache type.
|
||||
|
||||
krb5-1.21.2 changes by ticket ID
|
||||
--------------------------------
|
||||
|
||||
9102 Eliminate sim_client include of getopt.h
|
||||
9103 segfault trying to free a garbage pointer
|
||||
9104 Work around Doxygen 1.9.7 change
|
||||
9107 In PKINIT, check for null PKCS7 enveloped fields
|
||||
9109 memory leak on macos
|
||||
9115 Fix leak in KDC NDR encoding
|
||||
9125 Formatting error in realm_config.rst
|
||||
9128 Fix vulnerabilities in GSS message token handling
|
||||
|
||||
Major changes in 1.21.2 (2023-08-14)
|
||||
------------------------------------
|
||||
|
||||
This is a bug fix release.
|
||||
|
||||
* Fix double-free in KDC TGS processing [CVE-2023-39975].
|
||||
|
||||
krb5-1.21.2 changes by ticket ID
|
||||
--------------------------------
|
||||
|
||||
9101 Fix double-free in KDC TGS processing
|
||||
|
||||
Major changes in 1.21.1 (2023-07-10)
|
||||
------------------------------------
|
||||
|
||||
This is a bug fix release.
|
||||
|
||||
* Fix potential uninitialized pointer free in kadm5 XDR parsing
|
||||
[CVE-2023-36054].
|
||||
|
||||
krb5-1.21.1 changes by ticket ID
|
||||
--------------------------------
|
||||
|
||||
9099 Ensure array count consistency in kadm5 RPC
|
||||
|
||||
Major changes in 1.21 (2023-06-05)
|
||||
----------------------------------
|
||||
|
||||
User experience:
|
||||
|
||||
* Added a credential cache type providing compatibility with the macOS
|
||||
11 native credential cache.
|
||||
|
||||
Developer experience:
|
||||
|
||||
* libkadm5 will use the provided krb5_context object to read
|
||||
configuration values, instead of creating its own.
|
||||
|
||||
* Added an interface to retrieve the ticket session key from a GSS
|
||||
context.
|
||||
|
||||
Protocol evolution:
|
||||
|
||||
* The KDC will no longer issue tickets with RC4 or triple-DES session
|
||||
keys unless explicitly configured with the new allow_rc4 or
|
||||
allow_des3 variables respectively.
|
||||
|
||||
* The KDC will assume that all services can handle aes256-sha1 session
|
||||
keys unless the service principal has a session_enctypes string
|
||||
attribute.
|
||||
|
||||
* Support for PAC full KDC checksums has been added to mitigate an
|
||||
S4U2Proxy privilege escalation attack.
|
||||
|
||||
* The PKINIT client will advertise a more modern set of supported CMS
|
||||
algorithms.
|
||||
|
||||
Code quality:
|
||||
|
||||
* Removed unused code in libkrb5, libkrb5support, and the PKINIT
|
||||
module.
|
||||
|
||||
* Modernized the KDC code for processing TGS requests, the code for
|
||||
encrypting and decrypting key data, the PAC handling code, and the
|
||||
GSS library packet parsing and composition code.
|
||||
|
||||
* Improved the test framework's detection of memory errors in daemon
|
||||
processes when used with asan.
|
||||
|
||||
krb5-1.21 changes by ticket ID
|
||||
------------------------------
|
||||
|
||||
9052 Support macOS 11 native credential cache
|
||||
9053 Make kprop work for dump files larger than 4GB
|
||||
9054 Replace macros with typedefs in gssrpc types.h
|
||||
9055 Use SHA-256 instead of SHA-1 for PKINIT CMS digest
|
||||
9057 Omit LDFLAGS from krb5-config --libs output
|
||||
9058 Add configure variable for default PKCS#11 module
|
||||
9059 Use context profile for libkadm5 configuration
|
||||
9066 Set reasonable supportedCMSTypes in PKINIT
|
||||
9069 Update error checking for OpenSSL CMS_verify
|
||||
9071 Add and use ts_interval() helper
|
||||
9072 Avoid small read overrun in UTF8 normalization
|
||||
9076 Use memmove() in Unicode functions
|
||||
9077 Fix aclocal.m4 syntax error for autoconf 2.72
|
||||
9078 Fix profile crash on memory exhaustion
|
||||
9079 Fix preauth crash on memory exhaustion
|
||||
9080 Fix gic_keytab crash on memory exhaustion
|
||||
9082 Fix policy DB fallback error handling
|
||||
9083 Fix kpropd crash with unrecognized option
|
||||
9084 Add PAC full checksums
|
||||
9085 Fix read overruns in SPNEGO parsing
|
||||
9086 Fix possible double-free during KDB creation
|
||||
9087 Fix meridian type in getdate.y
|
||||
9088 Use control flow guard flag in Windows builds
|
||||
9089 Add pac_privsvr_enctype string attribute
|
||||
9090 Convey realm names to certauth modules
|
||||
9091 Add GSS_C_INQ_ODBC_SESSION_KEY
|
||||
9092 Fix maintainer-mode build for binutils 2.37
|
||||
9093 Add PA-REDHAT-PASSKEY padata type
|
||||
|
||||
Acknowledgements
|
||||
----------------
|
||||
|
||||
Past Sponsors of the MIT Kerberos Consortium:
|
||||
|
||||
Apple
|
||||
Carnegie Mellon University
|
||||
Centrify Corporation
|
||||
Columbia University
|
||||
Cornell University
|
||||
The Department of Defense of the United States of America (DoD)
|
||||
Fidelity Investments
|
||||
Google
|
||||
Iowa State University
|
||||
MIT
|
||||
Michigan State University
|
||||
Microsoft
|
||||
MITRE Corporation
|
||||
Morgan-Stanley
|
||||
The National Aeronautics and Space Administration
|
||||
of the United States of America (NASA)
|
||||
Network Appliance (NetApp)
|
||||
Nippon Telephone and Telegraph (NTT)
|
||||
US Government Office of the National Coordinator for Health
|
||||
Information Technology (ONC)
|
||||
Oracle
|
||||
Pennsylvania State University
|
||||
Red Hat
|
||||
Stanford University
|
||||
TeamF1, Inc.
|
||||
The University of Alaska
|
||||
The University of Michigan
|
||||
The University of Pennsylvania
|
||||
|
||||
Past and present members of the Kerberos Team at MIT:
|
||||
|
||||
Danilo Almeida
|
||||
Jeffrey Altman
|
||||
Justin Anderson
|
||||
Richard Basch
|
||||
Mitch Berger
|
||||
Jay Berkenbilt
|
||||
Andrew Boardman
|
||||
Bill Bryant
|
||||
Steve Buckley
|
||||
Joe Calzaretta
|
||||
John Carr
|
||||
Mark Colan
|
||||
Don Davis
|
||||
Sarah Day
|
||||
Alexandra Ellwood
|
||||
Carlos Garay
|
||||
Dan Geer
|
||||
Nancy Gilman
|
||||
Matt Hancher
|
||||
Thomas Hardjono
|
||||
Sam Hartman
|
||||
Paul Hill
|
||||
Marc Horowitz
|
||||
Eva Jacobus
|
||||
Miroslav Jurisic
|
||||
Barry Jaspan
|
||||
Benjamin Kaduk
|
||||
Geoffrey King
|
||||
Kevin Koch
|
||||
John Kohl
|
||||
HaoQi Li
|
||||
Jonathan Lin
|
||||
Peter Litwack
|
||||
Scott McGuire
|
||||
Steve Miller
|
||||
Kevin Mitchell
|
||||
Cliff Neuman
|
||||
Paul Park
|
||||
Ezra Peisach
|
||||
Chris Provenzano
|
||||
Ken Raeburn
|
||||
Jon Rochlis
|
||||
Jeff Schiller
|
||||
Jen Selby
|
||||
Robert Silk
|
||||
Bill Sommerfeld
|
||||
Jennifer Steiner
|
||||
Ralph Swick
|
||||
Brad Thompson
|
||||
Harry Tsai
|
||||
Zhanna Tsitkova
|
||||
Ted Ts'o
|
||||
Marshall Vale
|
||||
Taylor Yu
|
||||
|
||||
The following external contributors have provided code, patches, bug
|
||||
reports, suggestions, and valuable resources:
|
||||
|
||||
Ian Abbott
|
||||
Daniel Albers
|
||||
Brandon Allbery
|
||||
Russell Allbery
|
||||
Brian Almeida
|
||||
Michael B Allen
|
||||
Pooja Anil
|
||||
Jeffrey Arbuckle
|
||||
Heinz-Ado Arnolds
|
||||
Derek Atkins
|
||||
Mark Bannister
|
||||
David Bantz
|
||||
Alex Baule
|
||||
Nikhil Benesch
|
||||
David Benjamin
|
||||
Thomas Bernard
|
||||
Adam Bernstein
|
||||
Arlene Berry
|
||||
Jeff Blaine
|
||||
Toby Blake
|
||||
Radoslav Bodo
|
||||
Alexander Bokovoy
|
||||
Sumit Bose
|
||||
Emmanuel Bouillon
|
||||
Isaac Boukris
|
||||
Ulf Bremer
|
||||
Pavel Březina
|
||||
Philip Brown
|
||||
Samuel Cabrero
|
||||
Michael Calmer
|
||||
Andrea Campi
|
||||
Julien Chaffraix
|
||||
Jacob Champion
|
||||
Puran Chand
|
||||
Ravi Channavajhala
|
||||
Srinivas Cheruku
|
||||
Leonardo Chiquitto
|
||||
Rachit Chokshi
|
||||
Seemant Choudhary
|
||||
Howard Chu
|
||||
Andrea Cirulli
|
||||
Christopher D. Clausen
|
||||
Kevin Coffman
|
||||
Simon Cooper
|
||||
Sylvain Cortes
|
||||
Ian Crowther
|
||||
Arran Cudbard-Bell
|
||||
Adam Dabrowski
|
||||
Jeff D'Angelo
|
||||
Nalin Dahyabhai
|
||||
Mark Davies
|
||||
Dennis Davis
|
||||
Alex Dehnert
|
||||
Misty De Meo
|
||||
Mark Deneen
|
||||
Günther Deschner
|
||||
John Devitofranceschi
|
||||
Marc Dionne
|
||||
Roland Dowdeswell
|
||||
Ken Dreyer
|
||||
Dorian Ducournau
|
||||
Viktor Dukhovni
|
||||
Jason Edgecombe
|
||||
Mark Eichin
|
||||
Shawn M. Emery
|
||||
Douglas E. Engert
|
||||
Peter Eriksson
|
||||
Juha Erkkilä
|
||||
Gilles Espinasse
|
||||
Sergey Fedorov
|
||||
Ronni Feldt
|
||||
Bill Fellows
|
||||
JC Ferguson
|
||||
Remi Ferrand
|
||||
Paul Fertser
|
||||
Fabiano Fidêncio
|
||||
Frank Filz
|
||||
William Fiveash
|
||||
Jacques Florent
|
||||
Oliver Freyermuth
|
||||
Ákos Frohner
|
||||
Sebastian Galiano
|
||||
Marcus Granado
|
||||
Dylan Gray
|
||||
Norm Green
|
||||
Scott Grizzard
|
||||
Helmut Grohne
|
||||
Steve Grubb
|
||||
Philip Guenther
|
||||
Timo Gurr
|
||||
Dominic Hargreaves
|
||||
Robbie Harwood
|
||||
John Hascall
|
||||
Jakob Haufe
|
||||
Matthieu Hautreux
|
||||
Jochen Hein
|
||||
Paul B. Henson
|
||||
Kihong Heo
|
||||
Jeff Hodges
|
||||
Christopher Hogan
|
||||
Love Hörnquist Åstrand
|
||||
Ken Hornstein
|
||||
Henry B. Hotz
|
||||
Luke Howard
|
||||
Jakub Hrozek
|
||||
Shumon Huque
|
||||
Jeffrey Hutzelman
|
||||
Sergey Ilinykh
|
||||
Wyllys Ingersoll
|
||||
Holger Isenberg
|
||||
Spencer Jackson
|
||||
Diogenes S. Jesus
|
||||
Mike Jetzer
|
||||
Pavel Jindra
|
||||
Brian Johannesmeyer
|
||||
Joel Johnson
|
||||
Lutz Justen
|
||||
Ganesh Kamath
|
||||
Alexander Karaivanov
|
||||
Anders Kaseorg
|
||||
Bar Katz
|
||||
Zentaro Kavanagh
|
||||
Mubashir Kazia
|
||||
W. Trevor King
|
||||
Patrik Kis
|
||||
Martin Kittel
|
||||
Thomas Klausner
|
||||
Tomasz Kłoczko
|
||||
Matthew Krupcale
|
||||
Mikkel Kruse
|
||||
Reinhard Kugler
|
||||
Harshawardhan Kulkarni
|
||||
Tomas Kuthan
|
||||
Pierre Labastie
|
||||
Andreas Ladanyi
|
||||
Chris Leick
|
||||
Volker Lendecke
|
||||
Jan iankko Lieskovsky
|
||||
Todd Lipcon
|
||||
Oliver Loch
|
||||
Chris Long
|
||||
Kevin Longfellow
|
||||
Frank Lonigro
|
||||
Jon Looney
|
||||
Nuno Lopes
|
||||
Todd Lubin
|
||||
Ryan Lynch
|
||||
Glenn Machin
|
||||
Roland Mainz
|
||||
Sorin Manolache
|
||||
Robert Marshall
|
||||
Andrei Maslennikov
|
||||
Michael Mattioli
|
||||
Nathaniel McCallum
|
||||
Greg McClement
|
||||
Cameron Meadors
|
||||
Vipul Mehta
|
||||
Alexey Melnikov
|
||||
Ivan A. Melnikov
|
||||
Franklyn Mendez
|
||||
Mantas Mikulėnas
|
||||
Markus Moeller
|
||||
Kyle Moffett
|
||||
Jon Moore
|
||||
Paul Moore
|
||||
Keiichi Mori
|
||||
Michael Morony
|
||||
Robert Morris
|
||||
Sam Morris
|
||||
Zbysek Mraz
|
||||
Edward Murrell
|
||||
Joshua Neuheisel
|
||||
Nikos Nikoleris
|
||||
Demi Obenour
|
||||
Felipe Ortega
|
||||
Michael Osipov
|
||||
Andrej Ota
|
||||
Dmitri Pal
|
||||
Javier Palacios
|
||||
Dilyan Palauzov
|
||||
Tom Parker
|
||||
Eric Pauly
|
||||
Leonard Peirce
|
||||
Ezra Peisach
|
||||
Alejandro Perez
|
||||
Zoran Pericic
|
||||
W. Michael Petullo
|
||||
Mark Phalan
|
||||
Sharwan Ram
|
||||
Brett Randall
|
||||
Jonathan Reams
|
||||
Jonathan Reed
|
||||
Robert Relyea
|
||||
Tony Reix
|
||||
Martin Rex
|
||||
Pat Riehecky
|
||||
Julien Rische
|
||||
Jason Rogers
|
||||
Matt Rogers
|
||||
Nate Rosenblum
|
||||
Solly Ross
|
||||
Mike Roszkowski
|
||||
Guillaume Rousse
|
||||
Joshua Schaeffer
|
||||
Alexander Scheel
|
||||
Jens Schleusener
|
||||
Ryan Schmidt
|
||||
Andreas Schneider
|
||||
Paul Seyfert
|
||||
Tom Shaw
|
||||
Jim Shi
|
||||
Jerry Shipman
|
||||
Peter Shoults
|
||||
Richard Silverman
|
||||
Cel Skeggs
|
||||
Simo Sorce
|
||||
Anthony Sottile
|
||||
Michael Spang
|
||||
Michael Ströder
|
||||
Bjørn Tore Sund
|
||||
Ondřej Surý
|
||||
Joseph Sutton
|
||||
Joe Travaglini
|
||||
Sergei Trofimovich
|
||||
Greg Troxel
|
||||
Fraser Tweedale
|
||||
Tim Uglow
|
||||
Rathor Vipin
|
||||
Denis Vlasenko
|
||||
Thomas Wagner
|
||||
Jorgen Wahlsten
|
||||
Stef Walter
|
||||
Max (Weijun) Wang
|
||||
John Washington
|
||||
Stef Walter
|
||||
Xi Wang
|
||||
Nehal J Wani
|
||||
Kevin Wasserman
|
||||
Margaret Wasserman
|
||||
Marcus Watts
|
||||
Andreas Wiese
|
||||
Simon Wilkinson
|
||||
Nicolas Williams
|
||||
Ross Wilper
|
||||
Augustin Wolf
|
||||
Garrett Wollman
|
||||
David Woodhouse
|
||||
Tsu-Phong Wu
|
||||
Xu Qiang
|
||||
Neng Xue
|
||||
Zhaomo Yang
|
||||
Tianjiao Yin
|
||||
Nickolai Zeldovich
|
||||
Bean Zhang
|
||||
ChenChen Zhou
|
||||
Hanz van Zijst
|
||||
Gertjan Zwartjes
|
||||
|
||||
The above is not an exhaustive list; many others have contributed in
|
||||
various ways to the MIT Kerberos development effort over the years.
|
||||
56
crypto/krb5/doc/README
Normal file
56
crypto/krb5/doc/README
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
BUILDING
|
||||
========
|
||||
|
||||
See doc/build_this.rst for details about how to build the
|
||||
documentation.
|
||||
|
||||
|
||||
CONVENTIONS
|
||||
===========
|
||||
|
||||
We use the following conventions:
|
||||
|
||||
* Use four-space indentation where indentation levels are arbitrary.
|
||||
Do not use tabs anywhere. Avoid trailing whitespace at the end of
|
||||
lines or files.
|
||||
|
||||
* Fill lines to 70 columns (the emacs default) where lines can be
|
||||
wrapped.
|
||||
|
||||
* For section headers, use === underlines for page titles, --- for
|
||||
sections, ~~~ for subsections, and ### for sub-subsections. Make
|
||||
underlines exactly as long as titles. Do not include trailing
|
||||
punctuation in section headers. Do not capitalize section headers
|
||||
(except for the first word) except in source files intended to
|
||||
generate man pages.
|
||||
|
||||
* For bullet lists, use * for top-level bullets and - for sub-bullets.
|
||||
Do not indent bullet or enumerated lists relative to the surrounding
|
||||
text.
|
||||
|
||||
* Use italics (*word*) for words representing variables or parameters.
|
||||
Use boldface (**word**) for command options, subcommands of programs
|
||||
like kadmin, and krb5.conf/kdc.conf parameter names. Use literal
|
||||
text (``text``) for examples and multi-component pathnames. For
|
||||
command names, single-component filenames, and krb5.conf/kdc.conf
|
||||
section names, use references (like :ref:`kadmin(1)`) if introducing
|
||||
them, or just use them unadorned otherwise.
|
||||
|
||||
* In man pages for commands with subcommands, make a subsection for
|
||||
each subcommand. Start the subcommand with an indented synopsis,
|
||||
then follow with non-indented text describing the subcommand and its
|
||||
options. See kadmin_local.rst for an example.
|
||||
|
||||
* In man page synopses, put a newline in the RST source before each
|
||||
option. Put all parts of the synopsis at the same indentation
|
||||
level. Ideally we would want a hanging indent to the width of the
|
||||
command or subcommand name, but RST doesn't support that. Use
|
||||
boldface for literal text in the synopsis, italics for variable
|
||||
text, and unadorned text for syntax symbols (such as square brackets
|
||||
to indicate optional parameters). If immediately following one kind
|
||||
of inline markup with another or putting inline markup next to
|
||||
punctuation, you may need to use "\ " as a dummy separator.
|
||||
|
||||
* For directives that take a content block (e.g., note, error, and
|
||||
warning), leave a blank line before the content block (after any
|
||||
arguments or options that may be present).
|
||||
169
crypto/krb5/doc/_static/kerb.css_t
vendored
Normal file
169
crypto/krb5/doc/_static/kerb.css_t
vendored
Normal file
|
|
@ -0,0 +1,169 @@
|
|||
/*
|
||||
* kerb.css
|
||||
* ~~~~~~~~~~~
|
||||
*
|
||||
* Sphinx stylesheet -- modification to agogo theme.
|
||||
*
|
||||
*/
|
||||
div.body {
|
||||
padding-right: .5em;
|
||||
text-align: left;
|
||||
overflow-x: hidden;
|
||||
}
|
||||
|
||||
/* Page layout */
|
||||
|
||||
div.header, div.content, div.footer {
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
padding-left: 1em;
|
||||
padding-right: 1em;
|
||||
max-width: 60em;
|
||||
}
|
||||
|
||||
div.header-wrapper {
|
||||
background: white;
|
||||
border-bottom: 3px solid #2e3436;
|
||||
border-top: 13px solid #5d1509;
|
||||
}
|
||||
|
||||
/* Header */
|
||||
|
||||
div.header {
|
||||
padding-top: 10px;
|
||||
padding-bottom: 0px;
|
||||
}
|
||||
|
||||
div.header h1 {
|
||||
font-family: "Georgia", "Times New Roman", serif, black;
|
||||
font-weight: normal;
|
||||
}
|
||||
|
||||
div.header h1 a {
|
||||
color: {{ theme_bgcolor }};
|
||||
font-size: 120%;
|
||||
padding-top: 10px;
|
||||
}
|
||||
|
||||
div.header div.right a {
|
||||
color: #fcaf3e;
|
||||
letter-spacing: .1em;
|
||||
text-transform: lowercase;
|
||||
float: right;
|
||||
}
|
||||
|
||||
div.header div.rel {
|
||||
font-family: "Georgia", "Times New Roman", serif, black;
|
||||
font-weight: normal;
|
||||
margin-bottom: 1.6em;
|
||||
}
|
||||
|
||||
/* Content */
|
||||
|
||||
div.document {
|
||||
width: 80%;
|
||||
float: left;
|
||||
margin: 0;
|
||||
background-color: white;
|
||||
padding-top: 20px;
|
||||
padding-bottom: 20px;
|
||||
}
|
||||
|
||||
div.document div.section h1 {
|
||||
margin-bottom: 20px;
|
||||
padding: 1px;
|
||||
line-height: 130%;
|
||||
}
|
||||
|
||||
div.document div.section dl {
|
||||
margin-top: 15px;
|
||||
margin-bottom: 5px;
|
||||
padding: 1px;
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
/* Sidebar */
|
||||
|
||||
div.sidebar {
|
||||
float: right;
|
||||
font-size: .9em;
|
||||
width: 20%;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
background-color: #F9F9F9;
|
||||
}
|
||||
|
||||
div.sidebar ul {
|
||||
list-style-type: none;
|
||||
margin-left: .5em;
|
||||
}
|
||||
|
||||
div.sidebar li.toctree-l1 a {
|
||||
margin-left: .5em;
|
||||
}
|
||||
|
||||
div.sidebar li.toctree-l2 a {
|
||||
margin-left: .5em;
|
||||
}
|
||||
|
||||
div.sidebar li.toctree-l3 a {
|
||||
margin-left: .5em;
|
||||
}
|
||||
|
||||
div.sidebar li.toctree-l2.current a {
|
||||
border-right: 2px solid #fcaf3e !important;
|
||||
}
|
||||
|
||||
div.sidebar li.toctree-l3.current a {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
div.sidebar li.toctree-l4 a {
|
||||
display: none;
|
||||
}
|
||||
|
||||
div.sidebar input[type=text] {
|
||||
width: auto;
|
||||
}
|
||||
|
||||
/* Other body styles */
|
||||
|
||||
dt:target, .highlighted {
|
||||
background-color: #c1c1c1;
|
||||
}
|
||||
|
||||
/* Code displays */
|
||||
|
||||
pre {
|
||||
overflow: auto;
|
||||
overflow-y: hidden;
|
||||
}
|
||||
|
||||
td.linenos pre {
|
||||
padding: 5px 0px;
|
||||
border: 0;
|
||||
background-color: transparent;
|
||||
color: #aaa;
|
||||
}
|
||||
|
||||
/* ordered lists */
|
||||
|
||||
ol.arabic {
|
||||
list-style: decimal;
|
||||
}
|
||||
|
||||
ol.loweralpha {
|
||||
list-style: lower-alpha;
|
||||
}
|
||||
|
||||
ol.upperalpha {
|
||||
list-style: upper-alpha;
|
||||
}
|
||||
|
||||
ol.lowerroman {
|
||||
list-style-type: lower-roman;
|
||||
}
|
||||
|
||||
ol.upperroman {
|
||||
list-style-type: upper-roman;
|
||||
}
|
||||
73
crypto/krb5/doc/_templates/layout.html
vendored
Normal file
73
crypto/krb5/doc/_templates/layout.html
vendored
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
{% extends "!layout.html" %}
|
||||
{% set rellinks = [('search', 'Enter search criteria', 'S', 'Search')] +
|
||||
rellinks +
|
||||
[('index', 'Full Table of Contents', 'C', 'Contents')] %}
|
||||
|
||||
{# Add a "feedback" button to the rellinks #}
|
||||
{%- macro feedback_rellinks() %}
|
||||
{%- for rellink in rellinks|reverse %}
|
||||
<a href="{{ pathto(rellink[0]) }}" title="{{ rellink[1]|striptags|e }}"
|
||||
{{ accesskey(rellink[2]) }}>{{ rellink[3] }}</a>{{ reldelim2 }}
|
||||
{%- endfor %}
|
||||
<a href="mailto:krb5-bugs@mit.edu?subject=Documentation__{{ title }}">feedback</a>
|
||||
{%- endmacro %}
|
||||
|
||||
{% block footer %}
|
||||
<div class="footer-wrapper">
|
||||
<div class="footer" >
|
||||
<div class="right" ><i>Release: {{ release }}</i><br />
|
||||
{%- if show_copyright %}
|
||||
{%- if hasdoc('copyright') %}
|
||||
{% trans path=pathto('copyright'), copyright=copyright|e %}© <a href="{{ path }}">Copyright</a> {{ copyright }}.{% endtrans %}
|
||||
{%- else %}
|
||||
{% trans copyright=copyright|e %}© Copyright {{ copyright }}.{% endtrans %}
|
||||
{%- endif %}
|
||||
{%- endif %}
|
||||
</div>
|
||||
<div class="left">
|
||||
{{ feedback_rellinks() }}
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
{% endblock %}
|
||||
|
||||
{% block header %}
|
||||
<div class="header-wrapper">
|
||||
<div class="header">
|
||||
{% if logo %}
|
||||
<p class="logo">
|
||||
{# Link logo to kerberos.org #}
|
||||
<a href="https://kerberos.org"> <img class="logo"
|
||||
src="{{ pathto('_static/' + logo, 1) }}" alt="Logo" /></a>
|
||||
</p>
|
||||
{% endif %}
|
||||
{% block headertitle %}
|
||||
<h1><a href="{{ pathto(master_doc) }}">{{ shorttitle|e }}</a></h1>
|
||||
{% endblock %}
|
||||
<div class="rel">
|
||||
{{ feedback_rellinks() }}
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
{% endblock %}
|
||||
|
||||
{%- block sidebartoc %}
|
||||
<h2>{{ _('On this page') }}</h2>
|
||||
{{ toc }}
|
||||
<br/>
|
||||
<h2>{{ _('Table of contents') }}</h2>
|
||||
{{ toctree(collapse=true, maxdepth=3, titles_only=true,
|
||||
includehidden=false) }}
|
||||
<br/>
|
||||
<h4><a href="{{ pathto('index') }}">Full Table of Contents</a></h4>
|
||||
{%- endblock %}
|
||||
|
||||
{%- block sidebarsearch %}
|
||||
<h4>{{ _('Search') }}</h4>
|
||||
<form class="search" action="{{ pathto('search') }}" method="get">
|
||||
<input type="text" name="q" size="18" />
|
||||
<input type="submit" value="{{ _('Go') }}" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
{%- endblock %}
|
||||
35
crypto/krb5/doc/about.rst
Normal file
35
crypto/krb5/doc/about.rst
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
Contributing to the MIT Kerberos Documentation
|
||||
==============================================
|
||||
|
||||
We are looking for documentation writers and editors who could contribute
|
||||
towards improving the MIT KC documentation content. If you are an experienced
|
||||
Kerberos developer and/or administrator, please consider sharing your knowledge
|
||||
and experience with the Kerberos Community. You can suggest your own topic or
|
||||
write about any of the topics listed
|
||||
`here <https://k5wiki.kerberos.org/wiki/Projects/Documentation_Tasks>`__.
|
||||
|
||||
If you have any questions, comments, or suggestions on the existing documents,
|
||||
please send your feedback via email to krb5-bugs@mit.edu. The HTML version of
|
||||
this documentation has a "FEEDBACK" link to the krb5-bugs@mit.edu email
|
||||
address with a pre-constructed subject line.
|
||||
|
||||
|
||||
Background
|
||||
----------
|
||||
|
||||
Starting with release 1.11, the Kerberos documentation set is
|
||||
unified in a central form. Man pages, HTML documentation, and PDF
|
||||
documents are compiled from reStructuredText sources, and the application
|
||||
developer documentation incorporates Doxygen markup from the source
|
||||
tree. This project was undertaken along the outline described
|
||||
`here <https://k5wiki.kerberos.org/wiki/Projects/Kerberos_Documentation>`__.
|
||||
|
||||
Previous versions of Kerberos 5 attempted to maintain separate documentation
|
||||
in the texinfo format, with separate groff manual pages. Having the API
|
||||
documentation disjoint from the source code implementing that API
|
||||
resulted in the documentation becoming stale, and over time the documentation
|
||||
ceased to match reality. With a fresh start and a source format that is
|
||||
easier to use and maintain, reStructuredText-based documents should provide
|
||||
an improved experience for the user. Consolidating all the documentation
|
||||
formats into a single source document makes the documentation set easier
|
||||
to maintain.
|
||||
17
crypto/krb5/doc/admin/admin_commands/index.rst
Normal file
17
crypto/krb5/doc/admin/admin_commands/index.rst
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
Administration programs
|
||||
========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
kadmin_local.rst
|
||||
kadmind.rst
|
||||
kdb5_util.rst
|
||||
kdb5_ldap_util.rst
|
||||
krb5kdc.rst
|
||||
kprop.rst
|
||||
kpropd.rst
|
||||
kproplog.rst
|
||||
ktutil.rst
|
||||
k5srvutil.rst
|
||||
sserver.rst
|
||||
69
crypto/krb5/doc/admin/admin_commands/k5srvutil.rst
Normal file
69
crypto/krb5/doc/admin/admin_commands/k5srvutil.rst
Normal file
|
|
@ -0,0 +1,69 @@
|
|||
.. _k5srvutil(1):
|
||||
|
||||
k5srvutil
|
||||
=========
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**k5srvutil** *operation*
|
||||
[**-i**]
|
||||
[**-f** *filename*]
|
||||
[**-e** *keysalts*]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
k5srvutil allows an administrator to list keys currently in
|
||||
a keytab, to obtain new keys for a principal currently in a keytab,
|
||||
or to delete non-current keys from a keytab.
|
||||
|
||||
*operation* must be one of the following:
|
||||
|
||||
**list**
|
||||
Lists the keys in a keytab, showing version number and principal
|
||||
name.
|
||||
|
||||
**change**
|
||||
Uses the kadmin protocol to update the keys in the Kerberos
|
||||
database to new randomly-generated keys, and updates the keys in
|
||||
the keytab to match. If a key's version number doesn't match the
|
||||
version number stored in the Kerberos server's database, then the
|
||||
operation will fail. If the **-i** flag is given, k5srvutil will
|
||||
prompt for confirmation before changing each key. If the **-k**
|
||||
option is given, the old and new keys will be displayed.
|
||||
Ordinarily, keys will be generated with the default encryption
|
||||
types and key salts. This can be overridden with the **-e**
|
||||
option. Old keys are retained in the keytab so that existing
|
||||
tickets continue to work, but **delold** should be used after
|
||||
such tickets expire, to prevent attacks against the old keys.
|
||||
|
||||
**delold**
|
||||
Deletes keys that are not the most recent version from the keytab.
|
||||
This operation should be used some time after a change operation
|
||||
to remove old keys, after existing tickets issued for the service
|
||||
have expired. If the **-i** flag is given, then k5srvutil will
|
||||
prompt for confirmation for each principal.
|
||||
|
||||
**delete**
|
||||
Deletes particular keys in the keytab, interactively prompting for
|
||||
each key.
|
||||
|
||||
In all cases, the default keytab is used unless this is overridden by
|
||||
the **-f** option.
|
||||
|
||||
k5srvutil uses the :ref:`kadmin(1)` program to edit the keytab in
|
||||
place.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kadmin(1)`, :ref:`ktutil(1)`, :ref:`kerberos(7)`
|
||||
985
crypto/krb5/doc/admin/admin_commands/kadmin_local.rst
Normal file
985
crypto/krb5/doc/admin/admin_commands/kadmin_local.rst
Normal file
|
|
@ -0,0 +1,985 @@
|
|||
.. _kadmin(1):
|
||||
|
||||
kadmin
|
||||
======
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
.. _kadmin_synopsis:
|
||||
|
||||
**kadmin**
|
||||
[**-O**\|\ **-N**]
|
||||
[**-r** *realm*]
|
||||
[**-p** *principal*]
|
||||
[**-q** *query*]
|
||||
[[**-c** *cache_name*]\|[**-k** [**-t** *keytab*]]\|\ **-n**]
|
||||
[**-w** *password*]
|
||||
[**-s** *admin_server*\ [:*port*]]
|
||||
[command args...]
|
||||
|
||||
**kadmin.local**
|
||||
[**-r** *realm*]
|
||||
[**-p** *principal*]
|
||||
[**-q** *query*]
|
||||
[**-d** *dbname*]
|
||||
[**-e** *enc*:*salt* ...]
|
||||
[**-m**]
|
||||
[**-x** *db_args*]
|
||||
[command args...]
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
kadmin and kadmin.local are command-line interfaces to the Kerberos V5
|
||||
administration system. They provide nearly identical functionalities;
|
||||
the difference is that kadmin.local directly accesses the KDC
|
||||
database, while kadmin performs operations using :ref:`kadmind(8)`.
|
||||
Except as explicitly noted otherwise, this man page will use "kadmin"
|
||||
to refer to both versions. kadmin provides for the maintenance of
|
||||
Kerberos principals, password policies, and service key tables
|
||||
(keytabs).
|
||||
|
||||
The remote kadmin client uses Kerberos to authenticate to kadmind
|
||||
using the service principal ``kadmin/admin`` or ``kadmin/ADMINHOST``
|
||||
(where *ADMINHOST* is the fully-qualified hostname of the admin
|
||||
server). If the credentials cache contains a ticket for one of these
|
||||
principals, and the **-c** credentials_cache option is specified, that
|
||||
ticket is used to authenticate to kadmind. Otherwise, the **-p** and
|
||||
**-k** options are used to specify the client Kerberos principal name
|
||||
used to authenticate. Once kadmin has determined the principal name,
|
||||
it requests a service ticket from the KDC, and uses that service
|
||||
ticket to authenticate to kadmind.
|
||||
|
||||
Since kadmin.local directly accesses the KDC database, it usually must
|
||||
be run directly on the primary KDC with sufficient permissions to read
|
||||
the KDC database. If the KDC database uses the LDAP database module,
|
||||
kadmin.local can be run on any host which can access the LDAP server.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
.. _kadmin_options:
|
||||
|
||||
**-r** *realm*
|
||||
Use *realm* as the default database realm.
|
||||
|
||||
**-p** *principal*
|
||||
Use *principal* to authenticate. Otherwise, kadmin will append
|
||||
``/admin`` to the primary principal name of the default ccache,
|
||||
the value of the **USER** environment variable, or the username as
|
||||
obtained with getpwuid, in order of preference.
|
||||
|
||||
**-k**
|
||||
Use a keytab to decrypt the KDC response instead of prompting for
|
||||
a password. In this case, the default principal will be
|
||||
``host/hostname``. If there is no keytab specified with the
|
||||
**-t** option, then the default keytab will be used.
|
||||
|
||||
**-t** *keytab*
|
||||
Use *keytab* to decrypt the KDC response. This can only be used
|
||||
with the **-k** option.
|
||||
|
||||
**-n**
|
||||
Requests anonymous processing. Two types of anonymous principals
|
||||
are supported. For fully anonymous Kerberos, configure PKINIT on
|
||||
the KDC and configure **pkinit_anchors** in the client's
|
||||
:ref:`krb5.conf(5)`. Then use the **-n** option with a principal
|
||||
of the form ``@REALM`` (an empty principal name followed by the
|
||||
at-sign and a realm name). If permitted by the KDC, an anonymous
|
||||
ticket will be returned. A second form of anonymous tickets is
|
||||
supported; these realm-exposed tickets hide the identity of the
|
||||
client but not the client's realm. For this mode, use ``kinit
|
||||
-n`` with a normal principal name. If supported by the KDC, the
|
||||
principal (but not realm) will be replaced by the anonymous
|
||||
principal. As of release 1.8, the MIT Kerberos KDC only supports
|
||||
fully anonymous operation.
|
||||
|
||||
**-c** *credentials_cache*
|
||||
Use *credentials_cache* as the credentials cache. The cache
|
||||
should contain a service ticket for the ``kadmin/admin`` or
|
||||
``kadmin/ADMINHOST`` (where *ADMINHOST* is the fully-qualified
|
||||
hostname of the admin server) service; it can be acquired with the
|
||||
:ref:`kinit(1)` program. If this option is not specified, kadmin
|
||||
requests a new service ticket from the KDC, and stores it in its
|
||||
own temporary ccache.
|
||||
|
||||
**-w** *password*
|
||||
Use *password* instead of prompting for one. Use this option with
|
||||
care, as it may expose the password to other users on the system
|
||||
via the process list.
|
||||
|
||||
**-q** *query*
|
||||
Perform the specified query and then exit.
|
||||
|
||||
**-d** *dbname*
|
||||
Specifies the name of the KDC database. This option does not
|
||||
apply to the LDAP database module.
|
||||
|
||||
**-s** *admin_server*\ [:*port*]
|
||||
Specifies the admin server which kadmin should contact.
|
||||
|
||||
**-m**
|
||||
If using kadmin.local, prompt for the database master password
|
||||
instead of reading it from a stash file.
|
||||
|
||||
**-e** "*enc*:*salt* ..."
|
||||
Sets the keysalt list to be used for any new keys created. See
|
||||
:ref:`Keysalt_lists` in :ref:`kdc.conf(5)` for a list of possible
|
||||
values.
|
||||
|
||||
**-O**
|
||||
Force use of old AUTH_GSSAPI authentication flavor.
|
||||
|
||||
**-N**
|
||||
Prevent fallback to AUTH_GSSAPI authentication flavor.
|
||||
|
||||
**-x** *db_args*
|
||||
Specifies the database specific arguments. See the next section
|
||||
for supported options.
|
||||
|
||||
Starting with release 1.14, if any command-line arguments remain after
|
||||
the options, they will be treated as a single query to be executed.
|
||||
This mode of operation is intended for scripts and behaves differently
|
||||
from the interactive mode in several respects:
|
||||
|
||||
* Query arguments are split by the shell, not by kadmin.
|
||||
* Informational and warning messages are suppressed. Error messages
|
||||
and query output (e.g. for **get_principal**) will still be
|
||||
displayed.
|
||||
* Confirmation prompts are disabled (as if **-force** was given).
|
||||
Password prompts will still be issued as required.
|
||||
* The exit status will be non-zero if the query fails.
|
||||
|
||||
The **-q** option does not carry these behavior differences; the query
|
||||
will be processed as if it was entered interactively. The **-q**
|
||||
option cannot be used in combination with a query in the remaining
|
||||
arguments.
|
||||
|
||||
.. _dboptions:
|
||||
|
||||
DATABASE OPTIONS
|
||||
----------------
|
||||
|
||||
Database options can be used to override database-specific defaults.
|
||||
Supported options for the DB2 module are:
|
||||
|
||||
**-x dbname=**\ \*filename*
|
||||
Specifies the base filename of the DB2 database.
|
||||
|
||||
**-x lockiter**
|
||||
Make iteration operations hold the lock for the duration of
|
||||
the entire operation, rather than temporarily releasing the
|
||||
lock while handling each principal. This is the default
|
||||
behavior, but this option exists to allow command line
|
||||
override of a [dbmodules] setting. First introduced in
|
||||
release 1.13.
|
||||
|
||||
**-x unlockiter**
|
||||
Make iteration operations unlock the database for each
|
||||
principal, instead of holding the lock for the duration of the
|
||||
entire operation. First introduced in release 1.13.
|
||||
|
||||
Supported options for the LDAP module are:
|
||||
|
||||
**-x host=**\ *ldapuri*
|
||||
Specifies the LDAP server to connect to by a LDAP URI.
|
||||
|
||||
**-x binddn=**\ *bind_dn*
|
||||
Specifies the DN used to bind to the LDAP server.
|
||||
|
||||
**-x bindpwd=**\ *password*
|
||||
Specifies the password or SASL secret used to bind to the LDAP
|
||||
server. Using this option may expose the password to other
|
||||
users on the system via the process list; to avoid this,
|
||||
instead stash the password using the **stashsrvpw** command of
|
||||
:ref:`kdb5_ldap_util(8)`.
|
||||
|
||||
**-x sasl_mech=**\ *mechanism*
|
||||
Specifies the SASL mechanism used to bind to the LDAP server.
|
||||
The bind DN is ignored if a SASL mechanism is used. New in
|
||||
release 1.13.
|
||||
|
||||
**-x sasl_authcid=**\ *name*
|
||||
Specifies the authentication name used when binding to the
|
||||
LDAP server with a SASL mechanism, if the mechanism requires
|
||||
one. New in release 1.13.
|
||||
|
||||
**-x sasl_authzid=**\ *name*
|
||||
Specifies the authorization name used when binding to the LDAP
|
||||
server with a SASL mechanism. New in release 1.13.
|
||||
|
||||
**-x sasl_realm=**\ *realm*
|
||||
Specifies the realm used when binding to the LDAP server with
|
||||
a SASL mechanism, if the mechanism uses one. New in release
|
||||
1.13.
|
||||
|
||||
**-x debug=**\ *level*
|
||||
sets the OpenLDAP client library debug level. *level* is an
|
||||
integer to be interpreted by the library. Debugging messages
|
||||
are printed to standard error. New in release 1.12.
|
||||
|
||||
|
||||
COMMANDS
|
||||
--------
|
||||
|
||||
When using the remote client, available commands may be restricted
|
||||
according to the privileges specified in the :ref:`kadm5.acl(5)` file
|
||||
on the admin server.
|
||||
|
||||
.. _add_principal:
|
||||
|
||||
add_principal
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**add_principal** [*options*] *newprinc*
|
||||
|
||||
Creates the principal *newprinc*, prompting twice for a password. If
|
||||
no password policy is specified with the **-policy** option, and the
|
||||
policy named ``default`` is assigned to the principal if it exists.
|
||||
However, creating a policy named ``default`` will not automatically
|
||||
assign this policy to previously existing principals. This policy
|
||||
assignment can be suppressed with the **-clearpolicy** option.
|
||||
|
||||
This command requires the **add** privilege.
|
||||
|
||||
Aliases: **addprinc**, **ank**
|
||||
|
||||
Options:
|
||||
|
||||
**-expire** *expdate*
|
||||
(:ref:`getdate` string) The expiration date of the principal.
|
||||
|
||||
**-pwexpire** *pwexpdate*
|
||||
(:ref:`getdate` string) The password expiration date.
|
||||
|
||||
**-maxlife** *maxlife*
|
||||
(:ref:`duration` or :ref:`getdate` string) The maximum ticket life
|
||||
for the principal.
|
||||
|
||||
**-maxrenewlife** *maxrenewlife*
|
||||
(:ref:`duration` or :ref:`getdate` string) The maximum renewable
|
||||
life of tickets for the principal.
|
||||
|
||||
**-kvno** *kvno*
|
||||
The initial key version number.
|
||||
|
||||
**-policy** *policy*
|
||||
The password policy used by this principal. If not specified, the
|
||||
policy ``default`` is used if it exists (unless **-clearpolicy**
|
||||
is specified).
|
||||
|
||||
**-clearpolicy**
|
||||
Prevents any policy from being assigned when **-policy** is not
|
||||
specified.
|
||||
|
||||
{-\|+}\ **allow_postdated**
|
||||
**-allow_postdated** prohibits this principal from obtaining
|
||||
postdated tickets. **+allow_postdated** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_forwardable**
|
||||
**-allow_forwardable** prohibits this principal from obtaining
|
||||
forwardable tickets. **+allow_forwardable** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_renewable**
|
||||
**-allow_renewable** prohibits this principal from obtaining
|
||||
renewable tickets. **+allow_renewable** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_proxiable**
|
||||
**-allow_proxiable** prohibits this principal from obtaining
|
||||
proxiable tickets. **+allow_proxiable** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_dup_skey**
|
||||
**-allow_dup_skey** disables user-to-user authentication for this
|
||||
principal by prohibiting others from obtaining a service ticket
|
||||
encrypted in this principal's TGT session key.
|
||||
**+allow_dup_skey** clears this flag.
|
||||
|
||||
{-\|+}\ **requires_preauth**
|
||||
**+requires_preauth** requires this principal to preauthenticate
|
||||
before being allowed to kinit. **-requires_preauth** clears this
|
||||
flag. When **+requires_preauth** is set on a service principal,
|
||||
the KDC will only issue service tickets for that service principal
|
||||
if the client's initial authentication was performed using
|
||||
preauthentication.
|
||||
|
||||
{-\|+}\ **requires_hwauth**
|
||||
**+requires_hwauth** requires this principal to preauthenticate
|
||||
using a hardware device before being allowed to kinit.
|
||||
**-requires_hwauth** clears this flag. When **+requires_hwauth** is
|
||||
set on a service principal, the KDC will only issue service tickets
|
||||
for that service principal if the client's initial authentication was
|
||||
performed using a hardware device to preauthenticate.
|
||||
|
||||
{-\|+}\ **ok_as_delegate**
|
||||
**+ok_as_delegate** sets the **okay as delegate** flag on tickets
|
||||
issued with this principal as the service. Clients may use this
|
||||
flag as a hint that credentials should be delegated when
|
||||
authenticating to the service. **-ok_as_delegate** clears this
|
||||
flag.
|
||||
|
||||
{-\|+}\ **allow_svr**
|
||||
**-allow_svr** prohibits the issuance of service tickets for this
|
||||
principal. In release 1.17 and later, user-to-user service
|
||||
tickets are still allowed unless the **-allow_dup_skey** flag is
|
||||
also set. **+allow_svr** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_tgs_req**
|
||||
**-allow_tgs_req** specifies that a Ticket-Granting Service (TGS)
|
||||
request for a service ticket for this principal is not permitted.
|
||||
**+allow_tgs_req** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_tix**
|
||||
**-allow_tix** forbids the issuance of any tickets for this
|
||||
principal. **+allow_tix** clears this flag.
|
||||
|
||||
{-\|+}\ **needchange**
|
||||
**+needchange** forces a password change on the next initial
|
||||
authentication to this principal. **-needchange** clears this
|
||||
flag.
|
||||
|
||||
{-\|+}\ **password_changing_service**
|
||||
**+password_changing_service** marks this principal as a password
|
||||
change service principal.
|
||||
|
||||
{-\|+}\ **ok_to_auth_as_delegate**
|
||||
**+ok_to_auth_as_delegate** allows this principal to acquire
|
||||
forwardable tickets to itself from arbitrary users, for use with
|
||||
constrained delegation.
|
||||
|
||||
{-\|+}\ **no_auth_data_required**
|
||||
**+no_auth_data_required** prevents PAC or AD-SIGNEDPATH data from
|
||||
being added to service tickets for the principal.
|
||||
|
||||
{-\|+}\ **lockdown_keys**
|
||||
**+lockdown_keys** prevents keys for this principal from leaving
|
||||
the KDC via kadmind. The chpass and extract operations are denied
|
||||
for a principal with this attribute. The chrand operation is
|
||||
allowed, but will not return the new keys. The delete and rename
|
||||
operations are also denied if this attribute is set, in order to
|
||||
prevent a malicious administrator from replacing principals like
|
||||
krbtgt/* or kadmin/* with new principals without the attribute.
|
||||
This attribute can be set via the network protocol, but can only
|
||||
be removed using kadmin.local.
|
||||
|
||||
**-randkey**
|
||||
Sets the key of the principal to a random value.
|
||||
|
||||
**-nokey**
|
||||
Causes the principal to be created with no key. New in release
|
||||
1.12.
|
||||
|
||||
**-pw** *password*
|
||||
Sets the password of the principal to the specified string and
|
||||
does not prompt for a password. Note: using this option in a
|
||||
shell script may expose the password to other users on the system
|
||||
via the process list.
|
||||
|
||||
**-e** *enc*:*salt*,...
|
||||
Uses the specified keysalt list for setting the keys of the
|
||||
principal. See :ref:`Keysalt_lists` in :ref:`kdc.conf(5)` for a
|
||||
list of possible values.
|
||||
|
||||
**-x** *db_princ_args*
|
||||
Indicates database-specific options. The options for the LDAP
|
||||
database module are:
|
||||
|
||||
**-x dn=**\ *dn*
|
||||
Specifies the LDAP object that will contain the Kerberos
|
||||
principal being created.
|
||||
|
||||
**-x linkdn=**\ *dn*
|
||||
Specifies the LDAP object to which the newly created Kerberos
|
||||
principal object will point.
|
||||
|
||||
**-x containerdn=**\ *container_dn*
|
||||
Specifies the container object under which the Kerberos
|
||||
principal is to be created.
|
||||
|
||||
**-x tktpolicy=**\ *policy*
|
||||
Associates a ticket policy to the Kerberos principal.
|
||||
|
||||
.. note::
|
||||
|
||||
- The **containerdn** and **linkdn** options cannot be
|
||||
specified with the **dn** option.
|
||||
- If the *dn* or *containerdn* options are not specified while
|
||||
adding the principal, the principals are created under the
|
||||
principal container configured in the realm or the realm
|
||||
container.
|
||||
- *dn* and *containerdn* should be within the subtrees or
|
||||
principal container configured in the realm.
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: addprinc jennifer
|
||||
No policy specified for "jennifer@ATHENA.MIT.EDU";
|
||||
defaulting to no policy.
|
||||
Enter password for principal jennifer@ATHENA.MIT.EDU:
|
||||
Re-enter password for principal jennifer@ATHENA.MIT.EDU:
|
||||
Principal "jennifer@ATHENA.MIT.EDU" created.
|
||||
kadmin:
|
||||
|
||||
.. _modify_principal:
|
||||
|
||||
modify_principal
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
**modify_principal** [*options*] *principal*
|
||||
|
||||
Modifies the specified principal, changing the fields as specified.
|
||||
The options to **add_principal** also apply to this command, except
|
||||
for the **-randkey**, **-pw**, and **-e** options. In addition, the
|
||||
option **-clearpolicy** will clear the current policy of a principal.
|
||||
|
||||
This command requires the *modify* privilege.
|
||||
|
||||
Alias: **modprinc**
|
||||
|
||||
Options (in addition to the **addprinc** options):
|
||||
|
||||
**-unlock**
|
||||
Unlocks a locked principal (one which has received too many failed
|
||||
authentication attempts without enough time between them according
|
||||
to its password policy) so that it can successfully authenticate.
|
||||
|
||||
.. _rename_principal:
|
||||
|
||||
rename_principal
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
**rename_principal** [**-force**] *old_principal* *new_principal*
|
||||
|
||||
Renames the specified *old_principal* to *new_principal*. This
|
||||
command prompts for confirmation, unless the **-force** option is
|
||||
given.
|
||||
|
||||
This command requires the **add** and **delete** privileges.
|
||||
|
||||
Alias: **renprinc**
|
||||
|
||||
.. _delete_principal:
|
||||
|
||||
delete_principal
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
**delete_principal** [**-force**] *principal*
|
||||
|
||||
Deletes the specified *principal* from the database. This command
|
||||
prompts for deletion, unless the **-force** option is given.
|
||||
|
||||
This command requires the **delete** privilege.
|
||||
|
||||
Alias: **delprinc**
|
||||
|
||||
.. _change_password:
|
||||
|
||||
change_password
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
**change_password** [*options*] *principal*
|
||||
|
||||
Changes the password of *principal*. Prompts for a new password if
|
||||
neither **-randkey** or **-pw** is specified.
|
||||
|
||||
This command requires the **changepw** privilege, or that the
|
||||
principal running the program is the same as the principal being
|
||||
changed.
|
||||
|
||||
Alias: **cpw**
|
||||
|
||||
The following options are available:
|
||||
|
||||
**-randkey**
|
||||
Sets the key of the principal to a random value.
|
||||
|
||||
**-pw** *password*
|
||||
Set the password to the specified string. Using this option in a
|
||||
script may expose the password to other users on the system via
|
||||
the process list.
|
||||
|
||||
**-e** *enc*:*salt*,...
|
||||
Uses the specified keysalt list for setting the keys of the
|
||||
principal. See :ref:`Keysalt_lists` in :ref:`kdc.conf(5)` for a
|
||||
list of possible values.
|
||||
|
||||
**-keepold**
|
||||
Keeps the existing keys in the database. This flag is usually not
|
||||
necessary except perhaps for ``krbtgt`` principals.
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: cpw systest
|
||||
Enter password for principal systest@BLEEP.COM:
|
||||
Re-enter password for principal systest@BLEEP.COM:
|
||||
Password for systest@BLEEP.COM changed.
|
||||
kadmin:
|
||||
|
||||
.. _purgekeys:
|
||||
|
||||
purgekeys
|
||||
~~~~~~~~~
|
||||
|
||||
**purgekeys** [**-all**\|\ **-keepkvno** *oldest_kvno_to_keep*] *principal*
|
||||
|
||||
Purges previously retained old keys (e.g., from **change_password
|
||||
-keepold**) from *principal*. If **-keepkvno** is specified, then
|
||||
only purges keys with kvnos lower than *oldest_kvno_to_keep*. If
|
||||
**-all** is specified, then all keys are purged. The **-all** option
|
||||
is new in release 1.12.
|
||||
|
||||
This command requires the **modify** privilege.
|
||||
|
||||
.. _get_principal:
|
||||
|
||||
get_principal
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**get_principal** [**-terse**] *principal*
|
||||
|
||||
Gets the attributes of principal. With the **-terse** option, outputs
|
||||
fields as quoted tab-separated strings.
|
||||
|
||||
This command requires the **inquire** privilege, or that the principal
|
||||
running the the program to be the same as the one being listed.
|
||||
|
||||
Alias: **getprinc**
|
||||
|
||||
Examples::
|
||||
|
||||
kadmin: getprinc tlyu/admin
|
||||
Principal: tlyu/admin@BLEEP.COM
|
||||
Expiration date: [never]
|
||||
Last password change: Mon Aug 12 14:16:47 EDT 1996
|
||||
Password expiration date: [never]
|
||||
Maximum ticket life: 0 days 10:00:00
|
||||
Maximum renewable life: 7 days 00:00:00
|
||||
Last modified: Mon Aug 12 14:16:47 EDT 1996 (bjaspan/admin@BLEEP.COM)
|
||||
Last successful authentication: [never]
|
||||
Last failed authentication: [never]
|
||||
Failed password attempts: 0
|
||||
Number of keys: 1
|
||||
Key: vno 1, aes256-cts-hmac-sha384-192
|
||||
MKey: vno 1
|
||||
Attributes:
|
||||
Policy: [none]
|
||||
|
||||
kadmin: getprinc -terse systest
|
||||
systest@BLEEP.COM 3 86400 604800 1
|
||||
785926535 753241234 785900000
|
||||
tlyu/admin@BLEEP.COM 786100034 0 0
|
||||
kadmin:
|
||||
|
||||
.. _list_principals:
|
||||
|
||||
list_principals
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
**list_principals** [*expression*]
|
||||
|
||||
Retrieves all or some principal names. *expression* is a shell-style
|
||||
glob expression that can contain the wild-card characters ``?``,
|
||||
``*``, and ``[]``. All principal names matching the expression are
|
||||
printed. If no expression is provided, all principal names are
|
||||
printed. If the expression does not contain an ``@`` character, an
|
||||
``@`` character followed by the local realm is appended to the
|
||||
expression.
|
||||
|
||||
This command requires the **list** privilege.
|
||||
|
||||
Alias: **listprincs**, **get_principals**, **getprincs**
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: listprincs test*
|
||||
test3@SECURE-TEST.OV.COM
|
||||
test2@SECURE-TEST.OV.COM
|
||||
test1@SECURE-TEST.OV.COM
|
||||
testuser@SECURE-TEST.OV.COM
|
||||
kadmin:
|
||||
|
||||
.. _get_strings:
|
||||
|
||||
get_strings
|
||||
~~~~~~~~~~~
|
||||
|
||||
**get_strings** *principal*
|
||||
|
||||
Displays string attributes on *principal*.
|
||||
|
||||
This command requires the **inquire** privilege.
|
||||
|
||||
Alias: **getstrs**
|
||||
|
||||
.. _set_string:
|
||||
|
||||
set_string
|
||||
~~~~~~~~~~
|
||||
|
||||
**set_string** *principal* *name* *value*
|
||||
|
||||
Sets a string attribute on *principal*. String attributes are used to
|
||||
supply per-principal configuration to the KDC and some KDC plugin
|
||||
modules. The following string attribute names are recognized by the
|
||||
KDC:
|
||||
|
||||
**require_auth**
|
||||
Specifies an authentication indicator which is required to
|
||||
authenticate to the principal as a service. Multiple indicators
|
||||
can be specified, separated by spaces; in this case any of the
|
||||
specified indicators will be accepted. (New in release 1.14.)
|
||||
|
||||
**session_enctypes**
|
||||
Specifies the encryption types supported for session keys when the
|
||||
principal is authenticated to as a server. See
|
||||
:ref:`Encryption_types` in :ref:`kdc.conf(5)` for a list of the
|
||||
accepted values.
|
||||
|
||||
**otp**
|
||||
Enables One Time Passwords (OTP) preauthentication for a client
|
||||
*principal*. The *value* is a JSON string representing an array
|
||||
of objects, each having optional ``type`` and ``username`` fields.
|
||||
|
||||
**pkinit_cert_match**
|
||||
Specifies a matching expression that defines the certificate
|
||||
attributes required for the client certificate used by the
|
||||
principal during PKINIT authentication. The matching expression
|
||||
is in the same format as those used by the **pkinit_cert_match**
|
||||
option in :ref:`krb5.conf(5)`. (New in release 1.16.)
|
||||
|
||||
**pac_privsvr_enctype**
|
||||
Forces the encryption type of the PAC KDC checksum buffers to the
|
||||
specified encryption type for tickets issued to this server, by
|
||||
deriving a key from the local krbtgt key if it is of a different
|
||||
encryption type. It may be necessary to set this value to
|
||||
"aes256-sha1" on the cross-realm krbtgt entry for an Active
|
||||
Directory realm when using aes-sha2 keys on the local krbtgt
|
||||
entry.
|
||||
|
||||
This command requires the **modify** privilege.
|
||||
|
||||
Alias: **setstr**
|
||||
|
||||
Example::
|
||||
|
||||
set_string host/foo.mit.edu session_enctypes aes128-cts
|
||||
set_string user@FOO.COM otp "[{""type"":""hotp"",""username"":""al""}]"
|
||||
|
||||
.. _del_string:
|
||||
|
||||
del_string
|
||||
~~~~~~~~~~
|
||||
|
||||
**del_string** *principal* *key*
|
||||
|
||||
Deletes a string attribute from *principal*.
|
||||
|
||||
This command requires the **delete** privilege.
|
||||
|
||||
Alias: **delstr**
|
||||
|
||||
.. _add_policy:
|
||||
|
||||
add_policy
|
||||
~~~~~~~~~~
|
||||
|
||||
**add_policy** [*options*] *policy*
|
||||
|
||||
Adds a password policy named *policy* to the database.
|
||||
|
||||
This command requires the **add** privilege.
|
||||
|
||||
Alias: **addpol**
|
||||
|
||||
The following options are available:
|
||||
|
||||
**-maxlife** *time*
|
||||
(:ref:`duration` or :ref:`getdate` string) Sets the maximum
|
||||
lifetime of a password.
|
||||
|
||||
**-minlife** *time*
|
||||
(:ref:`duration` or :ref:`getdate` string) Sets the minimum
|
||||
lifetime of a password.
|
||||
|
||||
**-minlength** *length*
|
||||
Sets the minimum length of a password.
|
||||
|
||||
**-minclasses** *number*
|
||||
Sets the minimum number of character classes required in a
|
||||
password. The five character classes are lower case, upper case,
|
||||
numbers, punctuation, and whitespace/unprintable characters.
|
||||
|
||||
**-history** *number*
|
||||
Sets the number of past keys kept for a principal. This option is
|
||||
not supported with the LDAP KDC database module.
|
||||
|
||||
.. _policy_maxfailure:
|
||||
|
||||
**-maxfailure** *maxnumber*
|
||||
Sets the number of authentication failures before the principal is
|
||||
locked. Authentication failures are only tracked for principals
|
||||
which require preauthentication. The counter of failed attempts
|
||||
resets to 0 after a successful attempt to authenticate. A
|
||||
*maxnumber* value of 0 (the default) disables lockout.
|
||||
|
||||
.. _policy_failurecountinterval:
|
||||
|
||||
**-failurecountinterval** *failuretime*
|
||||
(:ref:`duration` or :ref:`getdate` string) Sets the allowable time
|
||||
between authentication failures. If an authentication failure
|
||||
happens after *failuretime* has elapsed since the previous
|
||||
failure, the number of authentication failures is reset to 1. A
|
||||
*failuretime* value of 0 (the default) means forever.
|
||||
|
||||
.. _policy_lockoutduration:
|
||||
|
||||
**-lockoutduration** *lockouttime*
|
||||
(:ref:`duration` or :ref:`getdate` string) Sets the duration for
|
||||
which the principal is locked from authenticating if too many
|
||||
authentication failures occur without the specified failure count
|
||||
interval elapsing. A duration of 0 (the default) means the
|
||||
principal remains locked out until it is administratively unlocked
|
||||
with ``modprinc -unlock``.
|
||||
|
||||
**-allowedkeysalts**
|
||||
Specifies the key/salt tuples supported for long-term keys when
|
||||
setting or changing a principal's password/keys. See
|
||||
:ref:`Keysalt_lists` in :ref:`kdc.conf(5)` for a list of the
|
||||
accepted values, but note that key/salt tuples must be separated
|
||||
with commas (',') only. To clear the allowed key/salt policy use
|
||||
a value of '-'.
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: add_policy -maxlife "2 days" -minlength 5 guests
|
||||
kadmin:
|
||||
|
||||
.. _modify_policy:
|
||||
|
||||
modify_policy
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**modify_policy** [*options*] *policy*
|
||||
|
||||
Modifies the password policy named *policy*. Options are as described
|
||||
for **add_policy**.
|
||||
|
||||
This command requires the **modify** privilege.
|
||||
|
||||
Alias: **modpol**
|
||||
|
||||
.. _delete_policy:
|
||||
|
||||
delete_policy
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**delete_policy** [**-force**] *policy*
|
||||
|
||||
Deletes the password policy named *policy*. Prompts for confirmation
|
||||
before deletion. The command will fail if the policy is in use by any
|
||||
principals.
|
||||
|
||||
This command requires the **delete** privilege.
|
||||
|
||||
Alias: **delpol**
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: del_policy guests
|
||||
Are you sure you want to delete the policy "guests"?
|
||||
(yes/no): yes
|
||||
kadmin:
|
||||
|
||||
.. _get_policy:
|
||||
|
||||
get_policy
|
||||
~~~~~~~~~~
|
||||
|
||||
**get_policy** [ **-terse** ] *policy*
|
||||
|
||||
Displays the values of the password policy named *policy*. With the
|
||||
**-terse** flag, outputs the fields as quoted strings separated by
|
||||
tabs.
|
||||
|
||||
This command requires the **inquire** privilege.
|
||||
|
||||
Alias: **getpol**
|
||||
|
||||
Examples::
|
||||
|
||||
kadmin: get_policy admin
|
||||
Policy: admin
|
||||
Maximum password life: 180 days 00:00:00
|
||||
Minimum password life: 00:00:00
|
||||
Minimum password length: 6
|
||||
Minimum number of password character classes: 2
|
||||
Number of old keys kept: 5
|
||||
Reference count: 17
|
||||
|
||||
kadmin: get_policy -terse admin
|
||||
admin 15552000 0 6 2 5 17
|
||||
kadmin:
|
||||
|
||||
The "Reference count" is the number of principals using that policy.
|
||||
With the LDAP KDC database module, the reference count field is not
|
||||
meaningful.
|
||||
|
||||
.. _list_policies:
|
||||
|
||||
list_policies
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**list_policies** [*expression*]
|
||||
|
||||
Retrieves all or some policy names. *expression* is a shell-style
|
||||
glob expression that can contain the wild-card characters ``?``,
|
||||
``*``, and ``[]``. All policy names matching the expression are
|
||||
printed. If no expression is provided, all existing policy names are
|
||||
printed.
|
||||
|
||||
This command requires the **list** privilege.
|
||||
|
||||
Aliases: **listpols**, **get_policies**, **getpols**.
|
||||
|
||||
Examples::
|
||||
|
||||
kadmin: listpols
|
||||
test-pol
|
||||
dict-only
|
||||
once-a-min
|
||||
test-pol-nopw
|
||||
|
||||
kadmin: listpols t*
|
||||
test-pol
|
||||
test-pol-nopw
|
||||
kadmin:
|
||||
|
||||
.. _ktadd:
|
||||
|
||||
ktadd
|
||||
~~~~~
|
||||
|
||||
| **ktadd** [options] *principal*
|
||||
| **ktadd** [options] **-glob** *princ-exp*
|
||||
|
||||
Adds a *principal*, or all principals matching *princ-exp*, to a
|
||||
keytab file. Each principal's keys are randomized in the process.
|
||||
The rules for *princ-exp* are described in the **list_principals**
|
||||
command.
|
||||
|
||||
This command requires the **inquire** and **changepw** privileges.
|
||||
With the **-glob** form, it also requires the **list** privilege.
|
||||
|
||||
The options are:
|
||||
|
||||
**-k[eytab]** *keytab*
|
||||
Use *keytab* as the keytab file. Otherwise, the default keytab is
|
||||
used.
|
||||
|
||||
**-e** *enc*:*salt*,...
|
||||
Uses the specified keysalt list for setting the new keys of the
|
||||
principal. See :ref:`Keysalt_lists` in :ref:`kdc.conf(5)` for a
|
||||
list of possible values.
|
||||
|
||||
**-q**
|
||||
Display less verbose information.
|
||||
|
||||
**-norandkey**
|
||||
Do not randomize the keys. The keys and their version numbers stay
|
||||
unchanged. This option cannot be specified in combination with the
|
||||
**-e** option.
|
||||
|
||||
An entry for each of the principal's unique encryption types is added,
|
||||
ignoring multiple keys with the same encryption type but different
|
||||
salt types.
|
||||
|
||||
Alias: **xst**
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: ktadd -k /tmp/foo-new-keytab host/foo.mit.edu
|
||||
Entry for principal host/foo.mit.edu@ATHENA.MIT.EDU with kvno 3,
|
||||
encryption type aes256-cts-hmac-sha1-96 added to keytab
|
||||
FILE:/tmp/foo-new-keytab
|
||||
kadmin:
|
||||
|
||||
.. _ktremove:
|
||||
|
||||
ktremove
|
||||
~~~~~~~~
|
||||
|
||||
**ktremove** [options] *principal* [*kvno* | *all* | *old*]
|
||||
|
||||
Removes entries for the specified *principal* from a keytab. Requires
|
||||
no permissions, since this does not require database access.
|
||||
|
||||
If the string "all" is specified, all entries for that principal are
|
||||
removed; if the string "old" is specified, all entries for that
|
||||
principal except those with the highest kvno are removed. Otherwise,
|
||||
the value specified is parsed as an integer, and all entries whose
|
||||
kvno match that integer are removed.
|
||||
|
||||
The options are:
|
||||
|
||||
**-k[eytab]** *keytab*
|
||||
Use *keytab* as the keytab file. Otherwise, the default keytab is
|
||||
used.
|
||||
|
||||
**-q**
|
||||
Display less verbose information.
|
||||
|
||||
Alias: **ktrem**
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: ktremove kadmin/admin all
|
||||
Entry for principal kadmin/admin with kvno 3 removed from keytab
|
||||
FILE:/etc/krb5.keytab
|
||||
kadmin:
|
||||
|
||||
lock
|
||||
~~~~
|
||||
|
||||
Lock database exclusively. Use with extreme caution! This command
|
||||
only works with the DB2 KDC database module.
|
||||
|
||||
unlock
|
||||
~~~~~~
|
||||
|
||||
Release the exclusive database lock.
|
||||
|
||||
list_requests
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Lists available for kadmin requests.
|
||||
|
||||
Aliases: **lr**, **?**
|
||||
|
||||
quit
|
||||
~~~~
|
||||
|
||||
Exit program. If the database was locked, the lock is released.
|
||||
|
||||
Aliases: **exit**, **q**
|
||||
|
||||
|
||||
HISTORY
|
||||
-------
|
||||
|
||||
The kadmin program was originally written by Tom Yu at MIT, as an
|
||||
interface to the OpenVision Kerberos administration program.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kpasswd(1)`, :ref:`kadmind(8)`, :ref:`kerberos(7)`
|
||||
129
crypto/krb5/doc/admin/admin_commands/kadmind.rst
Normal file
129
crypto/krb5/doc/admin/admin_commands/kadmind.rst
Normal file
|
|
@ -0,0 +1,129 @@
|
|||
.. _kadmind(8):
|
||||
|
||||
kadmind
|
||||
=======
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**kadmind**
|
||||
[**-x** *db_args*]
|
||||
[**-r** *realm*]
|
||||
[**-m**]
|
||||
[**-nofork**]
|
||||
[**-proponly**]
|
||||
[**-port** *port-number*]
|
||||
[**-P** *pid_file*]
|
||||
[**-p** *kdb5_util_path*]
|
||||
[**-K** *kprop_path*]
|
||||
[**-k** *kprop_port*]
|
||||
[**-F** *dump_file*]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
kadmind starts the Kerberos administration server. kadmind typically
|
||||
runs on the primary Kerberos server, which stores the KDC database.
|
||||
If the KDC database uses the LDAP module, the administration server
|
||||
and the KDC server need not run on the same machine. kadmind accepts
|
||||
remote requests from programs such as :ref:`kadmin(1)` and
|
||||
:ref:`kpasswd(1)` to administer the information in these database.
|
||||
|
||||
kadmind requires a number of configuration files to be set up in order
|
||||
for it to work:
|
||||
|
||||
:ref:`kdc.conf(5)`
|
||||
The KDC configuration file contains configuration information for
|
||||
the KDC and admin servers. kadmind uses settings in this file to
|
||||
locate the Kerberos database, and is also affected by the
|
||||
**acl_file**, **dict_file**, **kadmind_port**, and iprop-related
|
||||
settings.
|
||||
|
||||
:ref:`kadm5.acl(5)`
|
||||
kadmind's ACL (access control list) tells it which principals are
|
||||
allowed to perform administration actions. The pathname to the
|
||||
ACL file can be specified with the **acl_file** :ref:`kdc.conf(5)`
|
||||
variable; by default, it is |kdcdir|\ ``/kadm5.acl``.
|
||||
|
||||
After the server begins running, it puts itself in the background and
|
||||
disassociates itself from its controlling terminal.
|
||||
|
||||
kadmind can be configured for incremental database propagation.
|
||||
Incremental propagation allows replica KDC servers to receive
|
||||
principal and policy updates incrementally instead of receiving full
|
||||
dumps of the database. This facility can be enabled in the
|
||||
:ref:`kdc.conf(5)` file with the **iprop_enable** option. Incremental
|
||||
propagation requires the principal ``kiprop/PRIMARY\@REALM`` (where
|
||||
PRIMARY is the primary KDC's canonical host name, and REALM the realm
|
||||
name). In release 1.13, this principal is automatically created and
|
||||
registered into the datebase.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
**-r** *realm*
|
||||
specifies the realm that kadmind will serve; if it is not
|
||||
specified, the default realm of the host is used.
|
||||
|
||||
**-m**
|
||||
causes the master database password to be fetched from the
|
||||
keyboard (before the server puts itself in the background, if not
|
||||
invoked with the **-nofork** option) rather than from a file on
|
||||
disk.
|
||||
|
||||
**-nofork**
|
||||
causes the server to remain in the foreground and remain
|
||||
associated to the terminal.
|
||||
|
||||
**-proponly**
|
||||
causes the server to only listen and respond to Kerberos replica
|
||||
incremental propagation polling requests. This option can be used
|
||||
to set up a hierarchical propagation topology where a replica KDC
|
||||
provides incremental updates to other Kerberos replicas.
|
||||
|
||||
**-port** *port-number*
|
||||
specifies the port on which the administration server listens for
|
||||
connections. The default port is determined by the
|
||||
**kadmind_port** configuration variable in :ref:`kdc.conf(5)`.
|
||||
|
||||
**-P** *pid_file*
|
||||
specifies the file to which the PID of kadmind process should be
|
||||
written after it starts up. This file can be used to identify
|
||||
whether kadmind is still running and to allow init scripts to stop
|
||||
the correct process.
|
||||
|
||||
**-p** *kdb5_util_path*
|
||||
specifies the path to the kdb5_util command to use when dumping the
|
||||
KDB in response to full resync requests when iprop is enabled.
|
||||
|
||||
**-K** *kprop_path*
|
||||
specifies the path to the kprop command to use to send full dumps
|
||||
to replicas in response to full resync requests.
|
||||
|
||||
**-k** *kprop_port*
|
||||
specifies the port by which the kprop process that is spawned by
|
||||
kadmind connects to the replica kpropd, in order to transfer the
|
||||
dump file during an iprop full resync request.
|
||||
|
||||
**-F** *dump_file*
|
||||
specifies the file path to be used for dumping the KDB in response
|
||||
to full resync requests when iprop is enabled.
|
||||
|
||||
**-x** *db_args*
|
||||
specifies database-specific arguments. See :ref:`Database Options
|
||||
<dboptions>` in :ref:`kadmin(1)` for supported arguments.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kpasswd(1)`, :ref:`kadmin(1)`, :ref:`kdb5_util(8)`,
|
||||
:ref:`kdb5_ldap_util(8)`, :ref:`kadm5.acl(5)`, :ref:`kerberos(7)`
|
||||
449
crypto/krb5/doc/admin/admin_commands/kdb5_ldap_util.rst
Normal file
449
crypto/krb5/doc/admin/admin_commands/kdb5_ldap_util.rst
Normal file
|
|
@ -0,0 +1,449 @@
|
|||
.. _kdb5_ldap_util(8):
|
||||
|
||||
kdb5_ldap_util
|
||||
===============
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
.. _kdb5_ldap_util_synopsis:
|
||||
|
||||
**kdb5_ldap_util**
|
||||
[**-D** *user_dn* [**-w** *passwd*]]
|
||||
[**-H** *ldapuri*]
|
||||
**command**
|
||||
[*command_options*]
|
||||
|
||||
.. _kdb5_ldap_util_synopsis_end:
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
kdb5_ldap_util allows an administrator to manage realms, Kerberos
|
||||
services and ticket policies.
|
||||
|
||||
|
||||
COMMAND-LINE OPTIONS
|
||||
--------------------
|
||||
|
||||
.. _kdb5_ldap_util_options:
|
||||
|
||||
**-r** *realm*
|
||||
Specifies the realm to be operated on.
|
||||
|
||||
**-D** *user_dn*
|
||||
Specifies the Distinguished Name (DN) of the user who has
|
||||
sufficient rights to perform the operation on the LDAP server.
|
||||
|
||||
**-w** *passwd*
|
||||
Specifies the password of *user_dn*. This option is not
|
||||
recommended.
|
||||
|
||||
**-H** *ldapuri*
|
||||
Specifies the URI of the LDAP server.
|
||||
|
||||
By default, kdb5_ldap_util operates on the default realm (as specified
|
||||
in :ref:`krb5.conf(5)`) and connects and authenticates to the LDAP
|
||||
server in the same manner as :ref:kadmind(8)` would given the
|
||||
parameters in :ref:`dbdefaults` in :ref:`kdc.conf(5)`.
|
||||
|
||||
.. _kdb5_ldap_util_options_end:
|
||||
|
||||
|
||||
COMMANDS
|
||||
--------
|
||||
|
||||
create
|
||||
~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_create:
|
||||
|
||||
**create**
|
||||
[**-subtrees** *subtree_dn_list*]
|
||||
[**-sscope** *search_scope*]
|
||||
[**-containerref** *container_reference_dn*]
|
||||
[**-k** *mkeytype*]
|
||||
[**-kv** *mkeyVNO*]
|
||||
[**-M** *mkeyname*]
|
||||
[**-m|-P** *password*\|\ **-sf** *stashfilename*]
|
||||
[**-s**]
|
||||
[**-maxtktlife** *max_ticket_life*]
|
||||
[**-maxrenewlife** *max_renewable_ticket_life*]
|
||||
[*ticket_flags*]
|
||||
|
||||
Creates realm in directory. Options:
|
||||
|
||||
**-subtrees** *subtree_dn_list*
|
||||
Specifies the list of subtrees containing the principals of a
|
||||
realm. The list contains the DNs of the subtree objects separated
|
||||
by colon (``:``).
|
||||
|
||||
**-sscope** *search_scope*
|
||||
Specifies the scope for searching the principals under the
|
||||
subtree. The possible values are 1 or one (one level), 2 or sub
|
||||
(subtrees).
|
||||
|
||||
**-containerref** *container_reference_dn*
|
||||
Specifies the DN of the container object in which the principals
|
||||
of a realm will be created. If the container reference is not
|
||||
configured for a realm, the principals will be created in the
|
||||
realm container.
|
||||
|
||||
**-k** *mkeytype*
|
||||
Specifies the key type of the master key in the database. The
|
||||
default is given by the **master_key_type** variable in
|
||||
:ref:`kdc.conf(5)`.
|
||||
|
||||
**-kv** *mkeyVNO*
|
||||
Specifies the version number of the master key in the database;
|
||||
the default is 1. Note that 0 is not allowed.
|
||||
|
||||
**-M** *mkeyname*
|
||||
Specifies the principal name for the master key in the database.
|
||||
If not specified, the name is determined by the
|
||||
**master_key_name** variable in :ref:`kdc.conf(5)`.
|
||||
|
||||
**-m**
|
||||
Specifies that the master database password should be read from
|
||||
the TTY rather than fetched from a file on the disk.
|
||||
|
||||
**-P** *password*
|
||||
Specifies the master database password. This option is not
|
||||
recommended.
|
||||
|
||||
**-sf** *stashfilename*
|
||||
Specifies the stash file of the master database password.
|
||||
|
||||
**-s**
|
||||
Specifies that the stash file is to be created.
|
||||
|
||||
**-maxtktlife** *max_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum ticket life for
|
||||
principals in this realm.
|
||||
|
||||
**-maxrenewlife** *max_renewable_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum renewable life of
|
||||
tickets for principals in this realm.
|
||||
|
||||
*ticket_flags*
|
||||
Specifies global ticket flags for the realm. Allowable flags are
|
||||
documented in the description of the **add_principal** command in
|
||||
:ref:`kadmin(1)`.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU create -subtrees o=org -sscope SUB
|
||||
Password for "cn=admin,o=org":
|
||||
Initializing database for realm 'ATHENA.MIT.EDU'
|
||||
You will be prompted for the database Master Password.
|
||||
It is important that you NOT FORGET this password.
|
||||
Enter KDC database master key:
|
||||
Re-enter KDC database master key to verify:
|
||||
|
||||
.. _kdb5_ldap_util_create_end:
|
||||
|
||||
modify
|
||||
~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_modify:
|
||||
|
||||
**modify**
|
||||
[**-subtrees** *subtree_dn_list*]
|
||||
[**-sscope** *search_scope*]
|
||||
[**-containerref** *container_reference_dn*]
|
||||
[**-maxtktlife** *max_ticket_life*]
|
||||
[**-maxrenewlife** *max_renewable_ticket_life*]
|
||||
[*ticket_flags*]
|
||||
|
||||
Modifies the attributes of a realm. Options:
|
||||
|
||||
**-subtrees** *subtree_dn_list*
|
||||
Specifies the list of subtrees containing the principals of a
|
||||
realm. The list contains the DNs of the subtree objects separated
|
||||
by colon (``:``). This list replaces the existing list.
|
||||
|
||||
**-sscope** *search_scope*
|
||||
Specifies the scope for searching the principals under the
|
||||
subtrees. The possible values are 1 or one (one level), 2 or sub
|
||||
(subtrees).
|
||||
|
||||
**-containerref** *container_reference_dn* Specifies the DN of the
|
||||
container object in which the principals of a realm will be
|
||||
created.
|
||||
|
||||
**-maxtktlife** *max_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum ticket life for
|
||||
principals in this realm.
|
||||
|
||||
**-maxrenewlife** *max_renewable_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum renewable life of
|
||||
tickets for principals in this realm.
|
||||
|
||||
*ticket_flags*
|
||||
Specifies global ticket flags for the realm. Allowable flags are
|
||||
documented in the description of the **add_principal** command in
|
||||
:ref:`kadmin(1)`.
|
||||
|
||||
Example::
|
||||
|
||||
shell% kdb5_ldap_util -r ATHENA.MIT.EDU -D cn=admin,o=org -H
|
||||
ldaps://ldap-server1.mit.edu modify +requires_preauth
|
||||
Password for "cn=admin,o=org":
|
||||
shell%
|
||||
|
||||
.. _kdb5_ldap_util_modify_end:
|
||||
|
||||
view
|
||||
~~~~
|
||||
|
||||
.. _kdb5_ldap_util_view:
|
||||
|
||||
**view**
|
||||
|
||||
Displays the attributes of a realm.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU view
|
||||
Password for "cn=admin,o=org":
|
||||
Realm Name: ATHENA.MIT.EDU
|
||||
Subtree: ou=users,o=org
|
||||
Subtree: ou=servers,o=org
|
||||
SearchScope: ONE
|
||||
Maximum ticket life: 0 days 01:00:00
|
||||
Maximum renewable life: 0 days 10:00:00
|
||||
Ticket flags: DISALLOW_FORWARDABLE REQUIRES_PWCHANGE
|
||||
|
||||
.. _kdb5_ldap_util_view_end:
|
||||
|
||||
destroy
|
||||
~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_destroy:
|
||||
|
||||
**destroy** [**-f**]
|
||||
|
||||
Destroys an existing realm. Options:
|
||||
|
||||
**-f**
|
||||
If specified, will not prompt the user for confirmation.
|
||||
|
||||
Example::
|
||||
|
||||
shell% kdb5_ldap_util -r ATHENA.MIT.EDU -D cn=admin,o=org -H
|
||||
ldaps://ldap-server1.mit.edu destroy
|
||||
Password for "cn=admin,o=org":
|
||||
Deleting KDC database of 'ATHENA.MIT.EDU', are you sure?
|
||||
(type 'yes' to confirm)? yes
|
||||
OK, deleting database of 'ATHENA.MIT.EDU'...
|
||||
shell%
|
||||
|
||||
.. _kdb5_ldap_util_destroy_end:
|
||||
|
||||
list
|
||||
~~~~
|
||||
|
||||
.. _kdb5_ldap_util_list:
|
||||
|
||||
**list**
|
||||
|
||||
Lists the names of realms under the container.
|
||||
|
||||
Example::
|
||||
|
||||
shell% kdb5_ldap_util -D cn=admin,o=org -H
|
||||
ldaps://ldap-server1.mit.edu list
|
||||
Password for "cn=admin,o=org":
|
||||
ATHENA.MIT.EDU
|
||||
OPENLDAP.MIT.EDU
|
||||
MEDIA-LAB.MIT.EDU
|
||||
shell%
|
||||
|
||||
.. _kdb5_ldap_util_list_end:
|
||||
|
||||
stashsrvpw
|
||||
~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_stashsrvpw:
|
||||
|
||||
**stashsrvpw**
|
||||
[**-f** *filename*]
|
||||
*name*
|
||||
|
||||
Allows an administrator to store the password for service object in a
|
||||
file so that KDC and Administration server can use it to authenticate
|
||||
to the LDAP server. Options:
|
||||
|
||||
**-f** *filename*
|
||||
Specifies the complete path of the service password file. By
|
||||
default, ``/usr/local/var/service_passwd`` is used.
|
||||
|
||||
*name*
|
||||
Specifies the name of the object whose password is to be stored.
|
||||
If :ref:`krb5kdc(8)` or :ref:`kadmind(8)` are configured for
|
||||
simple binding, this should be the distinguished name it will
|
||||
use as given by the **ldap_kdc_dn** or **ldap_kadmind_dn**
|
||||
variable in :ref:`kdc.conf(5)`. If the KDC or kadmind is
|
||||
configured for SASL binding, this should be the authentication
|
||||
name it will use as given by the **ldap_kdc_sasl_authcid** or
|
||||
**ldap_kadmind_sasl_authcid** variable.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util stashsrvpw -f /home/andrew/conf_keyfile
|
||||
cn=service-kdc,o=org
|
||||
Password for "cn=service-kdc,o=org":
|
||||
Re-enter password for "cn=service-kdc,o=org":
|
||||
|
||||
.. _kdb5_ldap_util_stashsrvpw_end:
|
||||
|
||||
create_policy
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_create_policy:
|
||||
|
||||
**create_policy**
|
||||
[**-maxtktlife** *max_ticket_life*]
|
||||
[**-maxrenewlife** *max_renewable_ticket_life*]
|
||||
[*ticket_flags*]
|
||||
*policy_name*
|
||||
|
||||
Creates a ticket policy in the directory. Options:
|
||||
|
||||
**-maxtktlife** *max_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum ticket life for
|
||||
principals.
|
||||
|
||||
**-maxrenewlife** *max_renewable_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum renewable life of
|
||||
tickets for principals.
|
||||
|
||||
*ticket_flags*
|
||||
Specifies the ticket flags. If this option is not specified, by
|
||||
default, no restriction will be set by the policy. Allowable
|
||||
flags are documented in the description of the **add_principal**
|
||||
command in :ref:`kadmin(1)`.
|
||||
|
||||
*policy_name*
|
||||
Specifies the name of the ticket policy.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU create_policy -maxtktlife "1 day"
|
||||
-maxrenewlife "1 week" -allow_postdated +needchange
|
||||
-allow_forwardable tktpolicy
|
||||
Password for "cn=admin,o=org":
|
||||
|
||||
.. _kdb5_ldap_util_create_policy_end:
|
||||
|
||||
modify_policy
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_modify_policy:
|
||||
|
||||
**modify_policy**
|
||||
[**-maxtktlife** *max_ticket_life*]
|
||||
[**-maxrenewlife** *max_renewable_ticket_life*]
|
||||
[*ticket_flags*]
|
||||
*policy_name*
|
||||
|
||||
Modifies the attributes of a ticket policy. Options are same as for
|
||||
**create_policy**.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H
|
||||
ldaps://ldap-server1.mit.edu -r ATHENA.MIT.EDU modify_policy
|
||||
-maxtktlife "60 minutes" -maxrenewlife "10 hours"
|
||||
+allow_postdated -requires_preauth tktpolicy
|
||||
Password for "cn=admin,o=org":
|
||||
|
||||
.. _kdb5_ldap_util_modify_policy_end:
|
||||
|
||||
view_policy
|
||||
~~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_view_policy:
|
||||
|
||||
**view_policy**
|
||||
*policy_name*
|
||||
|
||||
Displays the attributes of the named ticket policy.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU view_policy tktpolicy
|
||||
Password for "cn=admin,o=org":
|
||||
Ticket policy: tktpolicy
|
||||
Maximum ticket life: 0 days 01:00:00
|
||||
Maximum renewable life: 0 days 10:00:00
|
||||
Ticket flags: DISALLOW_FORWARDABLE REQUIRES_PWCHANGE
|
||||
|
||||
.. _kdb5_ldap_util_view_policy_end:
|
||||
|
||||
destroy_policy
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_destroy_policy:
|
||||
|
||||
**destroy_policy**
|
||||
[**-force**]
|
||||
*policy_name*
|
||||
|
||||
Destroys an existing ticket policy. Options:
|
||||
|
||||
**-force**
|
||||
Forces the deletion of the policy object. If not specified, the
|
||||
user will be prompted for confirmation before deleting the policy.
|
||||
|
||||
*policy_name*
|
||||
Specifies the name of the ticket policy.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU destroy_policy tktpolicy
|
||||
Password for "cn=admin,o=org":
|
||||
This will delete the policy object 'tktpolicy', are you sure?
|
||||
(type 'yes' to confirm)? yes
|
||||
** policy object 'tktpolicy' deleted.
|
||||
|
||||
.. _kdb5_ldap_util_destroy_policy_end:
|
||||
|
||||
list_policy
|
||||
~~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_list_policy:
|
||||
|
||||
**list_policy**
|
||||
|
||||
Lists ticket policies.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU list_policy
|
||||
Password for "cn=admin,o=org":
|
||||
tktpolicy
|
||||
tmppolicy
|
||||
userpolicy
|
||||
|
||||
.. _kdb5_ldap_util_list_policy_end:
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kadmin(1)`, :ref:`kerberos(7)`
|
||||
502
crypto/krb5/doc/admin/admin_commands/kdb5_util.rst
Normal file
502
crypto/krb5/doc/admin/admin_commands/kdb5_util.rst
Normal file
|
|
@ -0,0 +1,502 @@
|
|||
.. _kdb5_util(8):
|
||||
|
||||
kdb5_util
|
||||
=========
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
.. _kdb5_util_synopsis:
|
||||
|
||||
**kdb5_util**
|
||||
[**-r** *realm*]
|
||||
[**-d** *dbname*]
|
||||
[**-k** *mkeytype*]
|
||||
[**-kv** *mkeyVNO*]
|
||||
[**-M** *mkeyname*]
|
||||
[**-m**]
|
||||
[**-sf** *stashfilename*]
|
||||
[**-P** *password*]
|
||||
[**-x** *db_args*]
|
||||
*command* [*command_options*]
|
||||
|
||||
.. _kdb5_util_synopsis_end:
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
kdb5_util allows an administrator to perform maintenance procedures on
|
||||
the KDC database. Databases can be created, destroyed, and dumped to
|
||||
or loaded from ASCII files. kdb5_util can create a Kerberos master
|
||||
key stash file or perform live rollover of the master key.
|
||||
|
||||
When kdb5_util is run, it attempts to acquire the master key and open
|
||||
the database. However, execution continues regardless of whether or
|
||||
not kdb5_util successfully opens the database, because the database
|
||||
may not exist yet or the stash file may be corrupt.
|
||||
|
||||
Note that some KDC database modules may not support all kdb5_util
|
||||
commands.
|
||||
|
||||
|
||||
COMMAND-LINE OPTIONS
|
||||
--------------------
|
||||
|
||||
.. _kdb5_util_options:
|
||||
|
||||
**-r** *realm*
|
||||
specifies the Kerberos realm of the database.
|
||||
|
||||
**-d** *dbname*
|
||||
specifies the name under which the principal database is stored;
|
||||
by default the database is that listed in :ref:`kdc.conf(5)`. The
|
||||
password policy database and lock files are also derived from this
|
||||
value.
|
||||
|
||||
**-k** *mkeytype*
|
||||
specifies the key type of the master key in the database. The
|
||||
default is given by the **master_key_type** variable in
|
||||
:ref:`kdc.conf(5)`.
|
||||
|
||||
**-kv** *mkeyVNO*
|
||||
Specifies the version number of the master key in the database;
|
||||
the default is 1. Note that 0 is not allowed.
|
||||
|
||||
**-M** *mkeyname*
|
||||
principal name for the master key in the database. If not
|
||||
specified, the name is determined by the **master_key_name**
|
||||
variable in :ref:`kdc.conf(5)`.
|
||||
|
||||
**-m**
|
||||
specifies that the master database password should be read from
|
||||
the keyboard rather than fetched from a file on disk.
|
||||
|
||||
**-sf** *stash_file*
|
||||
specifies the stash filename of the master database password. If
|
||||
not specified, the filename is determined by the
|
||||
**key_stash_file** variable in :ref:`kdc.conf(5)`.
|
||||
|
||||
**-P** *password*
|
||||
specifies the master database password. Using this option may
|
||||
expose the password to other users on the system via the process
|
||||
list.
|
||||
|
||||
**-x** *db_args*
|
||||
specifies database-specific options. See :ref:`kadmin(1)` for
|
||||
supported options.
|
||||
|
||||
.. _kdb5_util_options_end:
|
||||
|
||||
|
||||
COMMANDS
|
||||
--------
|
||||
|
||||
create
|
||||
~~~~~~
|
||||
|
||||
.. _kdb5_util_create:
|
||||
|
||||
**create** [**-s**]
|
||||
|
||||
Creates a new database. If the **-s** option is specified, the stash
|
||||
file is also created. This command fails if the database already
|
||||
exists. If the command is successful, the database is opened just as
|
||||
if it had already existed when the program was first run.
|
||||
|
||||
.. _kdb5_util_create_end:
|
||||
|
||||
destroy
|
||||
~~~~~~~
|
||||
|
||||
.. _kdb5_util_destroy:
|
||||
|
||||
**destroy** [**-f**]
|
||||
|
||||
Destroys the database, first overwriting the disk sectors and then
|
||||
unlinking the files, after prompting the user for confirmation. With
|
||||
the **-f** argument, does not prompt the user.
|
||||
|
||||
.. _kdb5_util_destroy_end:
|
||||
|
||||
stash
|
||||
~~~~~
|
||||
|
||||
.. _kdb5_util_stash:
|
||||
|
||||
**stash** [**-f** *keyfile*]
|
||||
|
||||
Stores the master principal's keys in a stash file. The **-f**
|
||||
argument can be used to override the *keyfile* specified in
|
||||
:ref:`kdc.conf(5)`.
|
||||
|
||||
.. _kdb5_util_stash_end:
|
||||
|
||||
dump
|
||||
~~~~
|
||||
|
||||
.. _kdb5_util_dump:
|
||||
|
||||
**dump** [**-b7**\|\ **-r13**\|\ **-r18**]
|
||||
[**-verbose**] [**-mkey_convert**] [**-new_mkey_file**
|
||||
*mkey_file*] [**-rev**] [**-recurse**] [*filename*
|
||||
[*principals*...]]
|
||||
|
||||
Dumps the current Kerberos and KADM5 database into an ASCII file. By
|
||||
default, the database is dumped in current format, "kdb5_util
|
||||
load_dump version 7". If filename is not specified, or is the string
|
||||
"-", the dump is sent to standard output. Options:
|
||||
|
||||
**-b7**
|
||||
causes the dump to be in the Kerberos 5 Beta 7 format ("kdb5_util
|
||||
load_dump version 4"). This was the dump format produced on
|
||||
releases prior to 1.2.2.
|
||||
|
||||
**-r13**
|
||||
causes the dump to be in the Kerberos 5 1.3 format ("kdb5_util
|
||||
load_dump version 5"). This was the dump format produced on
|
||||
releases prior to 1.8.
|
||||
|
||||
**-r18**
|
||||
causes the dump to be in the Kerberos 5 1.8 format ("kdb5_util
|
||||
load_dump version 6"). This was the dump format produced on
|
||||
releases prior to 1.11.
|
||||
|
||||
**-verbose**
|
||||
causes the name of each principal and policy to be printed as it
|
||||
is dumped.
|
||||
|
||||
**-mkey_convert**
|
||||
prompts for a new master key. This new master key will be used to
|
||||
re-encrypt principal key data in the dumpfile. The principal keys
|
||||
themselves will not be changed.
|
||||
|
||||
**-new_mkey_file** *mkey_file*
|
||||
the filename of a stash file. The master key in this stash file
|
||||
will be used to re-encrypt the key data in the dumpfile. The key
|
||||
data in the database will not be changed.
|
||||
|
||||
**-rev**
|
||||
dumps in reverse order. This may recover principals that do not
|
||||
dump normally, in cases where database corruption has occurred.
|
||||
|
||||
**-recurse**
|
||||
causes the dump to walk the database recursively (btree only).
|
||||
This may recover principals that do not dump normally, in cases
|
||||
where database corruption has occurred. In cases of such
|
||||
corruption, this option will probably retrieve more principals
|
||||
than the **-rev** option will.
|
||||
|
||||
.. versionchanged:: 1.15
|
||||
Release 1.15 restored the functionality of the **-recurse**
|
||||
option.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
The **-recurse** option ceased working until release 1.15,
|
||||
doing a normal dump instead of a recursive traversal.
|
||||
|
||||
.. _kdb5_util_dump_end:
|
||||
|
||||
load
|
||||
~~~~
|
||||
|
||||
.. _kdb5_util_load:
|
||||
|
||||
**load** [**-b7**\|\ **-r13**\|\ **-r18**] [**-hash**]
|
||||
[**-verbose**] [**-update**] *filename*
|
||||
|
||||
Loads a database dump from the named file into the named database. If
|
||||
no option is given to determine the format of the dump file, the
|
||||
format is detected automatically and handled as appropriate. Unless
|
||||
the **-update** option is given, **load** creates a new database
|
||||
containing only the data in the dump file, overwriting the contents of
|
||||
any previously existing database. Note that when using the LDAP KDC
|
||||
database module, the **-update** flag is required.
|
||||
|
||||
Options:
|
||||
|
||||
**-b7**
|
||||
requires the database to be in the Kerberos 5 Beta 7 format
|
||||
("kdb5_util load_dump version 4"). This was the dump format
|
||||
produced on releases prior to 1.2.2.
|
||||
|
||||
**-r13**
|
||||
requires the database to be in Kerberos 5 1.3 format ("kdb5_util
|
||||
load_dump version 5"). This was the dump format produced on
|
||||
releases prior to 1.8.
|
||||
|
||||
**-r18**
|
||||
requires the database to be in Kerberos 5 1.8 format ("kdb5_util
|
||||
load_dump version 6"). This was the dump format produced on
|
||||
releases prior to 1.11.
|
||||
|
||||
**-hash**
|
||||
stores the database in hash format, if using the DB2 database
|
||||
type. If this option is not specified, the database will be
|
||||
stored in btree format. This option is not recommended, as
|
||||
databases stored in hash format are known to corrupt data and lose
|
||||
principals.
|
||||
|
||||
**-verbose**
|
||||
causes the name of each principal and policy to be printed as it
|
||||
is dumped.
|
||||
|
||||
**-update**
|
||||
records from the dump file are added to or updated in the existing
|
||||
database. Otherwise, a new database is created containing only
|
||||
what is in the dump file and the old one destroyed upon successful
|
||||
completion.
|
||||
|
||||
.. _kdb5_util_load_end:
|
||||
|
||||
ark
|
||||
~~~
|
||||
|
||||
**ark** [**-e** *enc*:*salt*,...] *principal*
|
||||
|
||||
Adds new random keys to *principal* at the next available key version
|
||||
number. Keys for the current highest key version number will be
|
||||
preserved. The **-e** option specifies the list of encryption and
|
||||
salt types to be used for the new keys.
|
||||
|
||||
add_mkey
|
||||
~~~~~~~~
|
||||
|
||||
**add_mkey** [**-e** *etype*] [**-s**]
|
||||
|
||||
Adds a new master key to the master key principal, but does not mark
|
||||
it as active. Existing master keys will remain. The **-e** option
|
||||
specifies the encryption type of the new master key; see
|
||||
:ref:`Encryption_types` in :ref:`kdc.conf(5)` for a list of possible
|
||||
values. The **-s** option stashes the new master key in the stash
|
||||
file, which will be created if it doesn't already exist.
|
||||
|
||||
After a new master key is added, it should be propagated to replica
|
||||
servers via a manual or periodic invocation of :ref:`kprop(8)`. Then,
|
||||
the stash files on the replica servers should be updated with the
|
||||
kdb5_util **stash** command. Once those steps are complete, the key
|
||||
is ready to be marked active with the kdb5_util **use_mkey** command.
|
||||
|
||||
use_mkey
|
||||
~~~~~~~~
|
||||
|
||||
**use_mkey** *mkeyVNO* [*time*]
|
||||
|
||||
Sets the activation time of the master key specified by *mkeyVNO*.
|
||||
Once a master key becomes active, it will be used to encrypt newly
|
||||
created principal keys. If no *time* argument is given, the current
|
||||
time is used, causing the specified master key version to become
|
||||
active immediately. The format for *time* is :ref:`getdate` string.
|
||||
|
||||
After a new master key becomes active, the kdb5_util
|
||||
**update_princ_encryption** command can be used to update all
|
||||
principal keys to be encrypted in the new master key.
|
||||
|
||||
list_mkeys
|
||||
~~~~~~~~~~
|
||||
|
||||
**list_mkeys**
|
||||
|
||||
List all master keys, from most recent to earliest, in the master key
|
||||
principal. The output will show the kvno, enctype, and salt type for
|
||||
each mkey, similar to the output of :ref:`kadmin(1)` **getprinc**. A
|
||||
``*`` following an mkey denotes the currently active master key.
|
||||
|
||||
purge_mkeys
|
||||
~~~~~~~~~~~
|
||||
|
||||
**purge_mkeys** [**-f**] [**-n**] [**-v**]
|
||||
|
||||
Delete master keys from the master key principal that are not used to
|
||||
protect any principals. This command can be used to remove old master
|
||||
keys all principal keys are protected by a newer master key.
|
||||
|
||||
**-f**
|
||||
does not prompt for confirmation.
|
||||
|
||||
**-n**
|
||||
performs a dry run, showing master keys that would be purged, but
|
||||
not actually purging any keys.
|
||||
|
||||
**-v**
|
||||
gives more verbose output.
|
||||
|
||||
update_princ_encryption
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**update_princ_encryption** [**-f**] [**-n**] [**-v**]
|
||||
[*princ-pattern*]
|
||||
|
||||
Update all principal records (or only those matching the
|
||||
*princ-pattern* glob pattern) to re-encrypt the key data using the
|
||||
active database master key, if they are encrypted using a different
|
||||
version, and give a count at the end of the number of principals
|
||||
updated. If the **-f** option is not given, ask for confirmation
|
||||
before starting to make changes. The **-v** option causes each
|
||||
principal processed to be listed, with an indication as to whether it
|
||||
needed updating or not. The **-n** option performs a dry run, only
|
||||
showing the actions which would have been taken.
|
||||
|
||||
tabdump
|
||||
~~~~~~~
|
||||
|
||||
**tabdump** [**-H**] [**-c**] [**-e**] [**-n**] [**-o** *outfile*]
|
||||
*dumptype*
|
||||
|
||||
Dump selected fields of the database in a tabular format suitable for
|
||||
reporting (e.g., using traditional Unix text processing tools) or
|
||||
importing into relational databases. The data format is tab-separated
|
||||
(default), or optionally comma-separated (CSV), with a fixed number of
|
||||
columns. The output begins with a header line containing field names,
|
||||
unless suppression is requested using the **-H** option.
|
||||
|
||||
The *dumptype* parameter specifies the name of an output table (see
|
||||
below).
|
||||
|
||||
Options:
|
||||
|
||||
**-H**
|
||||
suppress writing the field names in a header line
|
||||
|
||||
**-c**
|
||||
use comma separated values (CSV) format, with minimal quoting,
|
||||
instead of the default tab-separated (unquoted, unescaped) format
|
||||
|
||||
**-e**
|
||||
write empty hexadecimal string fields as empty fields instead of
|
||||
as "-1".
|
||||
|
||||
**-n**
|
||||
produce numeric output for fields that normally have symbolic
|
||||
output, such as enctypes and flag names. Also requests output of
|
||||
time stamps as decimal POSIX time_t values.
|
||||
|
||||
**-o** *outfile*
|
||||
write the dump to the specified output file instead of to standard
|
||||
output
|
||||
|
||||
Dump types:
|
||||
|
||||
**keydata**
|
||||
principal encryption key information, including actual key data
|
||||
(which is still encrypted in the master key)
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**keyindex**
|
||||
index of this key in the principal's key list
|
||||
**kvno**
|
||||
key version number
|
||||
**enctype**
|
||||
encryption type
|
||||
**key**
|
||||
key data as a hexadecimal string
|
||||
**salttype**
|
||||
salt type
|
||||
**salt**
|
||||
salt data as a hexadecimal string
|
||||
|
||||
**keyinfo**
|
||||
principal encryption key information (as in **keydata** above),
|
||||
excluding actual key data
|
||||
|
||||
**princ_flags**
|
||||
principal boolean attributes. Flag names print as hexadecimal
|
||||
numbers if the **-n** option is specified, and all flag positions
|
||||
are printed regardless of whether or not they are set. If **-n**
|
||||
is not specified, print all known flag names for each principal,
|
||||
but only print hexadecimal flag names if the corresponding flag is
|
||||
set.
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**flag**
|
||||
flag name
|
||||
**value**
|
||||
boolean value (0 for clear, or 1 for set)
|
||||
|
||||
**princ_lockout**
|
||||
state information used for tracking repeated password failures
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**last_success**
|
||||
time stamp of most recent successful authentication
|
||||
**last_failed**
|
||||
time stamp of most recent failed authentication
|
||||
**fail_count**
|
||||
count of failed attempts
|
||||
|
||||
**princ_meta**
|
||||
principal metadata
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**modby**
|
||||
name of last principal to modify this principal
|
||||
**modtime**
|
||||
timestamp of last modification
|
||||
**lastpwd**
|
||||
timestamp of last password change
|
||||
**policy**
|
||||
policy object name
|
||||
**mkvno**
|
||||
key version number of the master key that encrypts this
|
||||
principal's key data
|
||||
**hist_kvno**
|
||||
key version number of the history key that encrypts the key
|
||||
history data for this principal
|
||||
|
||||
**princ_stringattrs**
|
||||
string attributes (key/value pairs)
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**key**
|
||||
attribute name
|
||||
**value**
|
||||
attribute value
|
||||
|
||||
**princ_tktpolicy**
|
||||
per-principal ticket policy data, including maximum ticket
|
||||
lifetimes
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**expiration**
|
||||
principal expiration date
|
||||
**pw_expiration**
|
||||
password expiration date
|
||||
**max_life**
|
||||
maximum ticket lifetime
|
||||
**max_renew_life**
|
||||
maximum renewable ticket lifetime
|
||||
|
||||
Examples::
|
||||
|
||||
$ kdb5_util tabdump -o keyinfo.txt keyinfo
|
||||
$ cat keyinfo.txt
|
||||
name keyindex kvno enctype salttype salt
|
||||
K/M@EXAMPLE.COM 0 1 aes256-cts-hmac-sha384-192 normal -1
|
||||
foo@EXAMPLE.COM 0 1 aes128-cts-hmac-sha1-96 normal -1
|
||||
bar@EXAMPLE.COM 0 1 aes128-cts-hmac-sha1-96 normal -1
|
||||
$ sqlite3
|
||||
sqlite> .mode tabs
|
||||
sqlite> .import keyinfo.txt keyinfo
|
||||
sqlite> select * from keyinfo where enctype like 'aes256-%';
|
||||
K/M@EXAMPLE.COM 1 1 aes256-cts-hmac-sha384-192 normal -1
|
||||
sqlite> .quit
|
||||
$ awk -F'\t' '$4 ~ /aes256-/ { print }' keyinfo.txt
|
||||
K/M@EXAMPLE.COM 1 1 aes256-cts-hmac-sha384-192 normal -1
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kadmin(1)`, :ref:`kerberos(7)`
|
||||
60
crypto/krb5/doc/admin/admin_commands/kprop.rst
Normal file
60
crypto/krb5/doc/admin/admin_commands/kprop.rst
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
.. _kprop(8):
|
||||
|
||||
kprop
|
||||
=====
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**kprop**
|
||||
[**-r** *realm*]
|
||||
[**-f** *file*]
|
||||
[**-d**]
|
||||
[**-P** *port*]
|
||||
[**-s** *keytab*]
|
||||
*replica_host*
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
kprop is used to securely propagate a Kerberos V5 database dump file
|
||||
from the primary Kerberos server to a replica Kerberos server, which is
|
||||
specified by *replica_host*. The dump file must be created by
|
||||
:ref:`kdb5_util(8)`.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
**-r** *realm*
|
||||
Specifies the realm of the primary server.
|
||||
|
||||
**-f** *file*
|
||||
Specifies the filename where the dumped principal database file is
|
||||
to be found; by default the dumped database file is normally
|
||||
|kdcdir|\ ``/replica_datatrans``.
|
||||
|
||||
**-P** *port*
|
||||
Specifies the port to use to contact the :ref:`kpropd(8)` server
|
||||
on the remote host.
|
||||
|
||||
**-d**
|
||||
Prints debugging information.
|
||||
|
||||
**-s** *keytab*
|
||||
Specifies the location of the keytab file.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kpropd(8)`, :ref:`kdb5_util(8)`, :ref:`krb5kdc(8)`,
|
||||
:ref:`kerberos(7)`
|
||||
144
crypto/krb5/doc/admin/admin_commands/kpropd.rst
Normal file
144
crypto/krb5/doc/admin/admin_commands/kpropd.rst
Normal file
|
|
@ -0,0 +1,144 @@
|
|||
.. _kpropd(8):
|
||||
|
||||
kpropd
|
||||
======
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**kpropd**
|
||||
[**-r** *realm*]
|
||||
[**-A** *admin_server*]
|
||||
[**-a** *acl_file*]
|
||||
[**-f** *replica_dumpfile*]
|
||||
[**-F** *principal_database*]
|
||||
[**-p** *kdb5_util_prog*]
|
||||
[**-P** *port*]
|
||||
[**--pid-file**\ =\ *pid_file*]
|
||||
[**-D**]
|
||||
[**-d**]
|
||||
[**-s** *keytab_file*]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
The *kpropd* command runs on the replica KDC server. It listens for
|
||||
update requests made by the :ref:`kprop(8)` program. If incremental
|
||||
propagation is enabled, it periodically requests incremental updates
|
||||
from the primary KDC.
|
||||
|
||||
When the replica receives a kprop request from the primary, kpropd
|
||||
accepts the dumped KDC database and places it in a file, and then runs
|
||||
:ref:`kdb5_util(8)` to load the dumped database into the active
|
||||
database which is used by :ref:`krb5kdc(8)`. This allows the primary
|
||||
Kerberos server to use :ref:`kprop(8)` to propagate its database to
|
||||
the replica servers. Upon a successful download of the KDC database
|
||||
file, the replica Kerberos server will have an up-to-date KDC
|
||||
database.
|
||||
|
||||
Where incremental propagation is not used, kpropd is commonly invoked
|
||||
out of inetd(8) as a nowait service. This is done by adding a line to
|
||||
the ``/etc/inetd.conf`` file which looks like this::
|
||||
|
||||
kprop stream tcp nowait root /usr/local/sbin/kpropd kpropd
|
||||
|
||||
kpropd can also run as a standalone daemon, backgrounding itself and
|
||||
waiting for connections on port 754 (or the port specified with the
|
||||
**-P** option if given). Standalone mode is required for incremental
|
||||
propagation. Starting in release 1.11, kpropd automatically detects
|
||||
whether it was run from inetd and runs in standalone mode if it is
|
||||
not. Prior to release 1.11, the **-S** option is required to run
|
||||
kpropd in standalone mode; this option is now accepted for backward
|
||||
compatibility but does nothing.
|
||||
|
||||
Incremental propagation may be enabled with the **iprop_enable**
|
||||
variable in :ref:`kdc.conf(5)`. If incremental propagation is
|
||||
enabled, the replica periodically polls the primary KDC for updates, at
|
||||
an interval determined by the **iprop_replica_poll** variable. If the
|
||||
replica receives updates, kpropd updates its log file with any updates
|
||||
from the primary. :ref:`kproplog(8)` can be used to view a summary of
|
||||
the update entry log on the replica KDC. If incremental propagation
|
||||
is enabled, the principal ``kiprop/replicahostname@REALM`` (where
|
||||
*replicahostname* is the name of the replica KDC host, and *REALM* is
|
||||
the name of the Kerberos realm) must be present in the replica's
|
||||
keytab file.
|
||||
|
||||
:ref:`kproplog(8)` can be used to force full replication when iprop is
|
||||
enabled.
|
||||
|
||||
|
||||
OPTIONS
|
||||
--------
|
||||
|
||||
**-r** *realm*
|
||||
Specifies the realm of the primary server.
|
||||
|
||||
**-A** *admin_server*
|
||||
Specifies the server to be contacted for incremental updates; by
|
||||
default, the primary admin server is contacted.
|
||||
|
||||
**-f** *file*
|
||||
Specifies the filename where the dumped principal database file is
|
||||
to be stored; by default the dumped database file is |kdcdir|\
|
||||
``/from_master``.
|
||||
|
||||
**-F** *kerberos_db*
|
||||
Path to the Kerberos database file, if not the default.
|
||||
|
||||
**-p**
|
||||
Allows the user to specify the pathname to the :ref:`kdb5_util(8)`
|
||||
program; by default the pathname used is |sbindir|\
|
||||
``/kdb5_util``.
|
||||
|
||||
**-D**
|
||||
In this mode, kpropd will not detach itself from the current job
|
||||
and run in the background. Instead, it will run in the
|
||||
foreground.
|
||||
|
||||
**-d**
|
||||
Turn on debug mode. kpropd will print out debugging messages
|
||||
during the database propogation and will run in the foreground
|
||||
(implies **-D**).
|
||||
|
||||
**-P**
|
||||
Allow for an alternate port number for kpropd to listen on. This
|
||||
is only useful in combination with the **-S** option.
|
||||
|
||||
**-a** *acl_file*
|
||||
Allows the user to specify the path to the kpropd.acl file; by
|
||||
default the path used is |kdcdir|\ ``/kpropd.acl``.
|
||||
|
||||
**--pid-file**\ =\ *pid_file*
|
||||
In standalone mode, write the process ID of the daemon into
|
||||
*pid_file*.
|
||||
|
||||
**-s** *keytab_file*
|
||||
Path to a keytab to use for acquiring acceptor credentials.
|
||||
|
||||
**-x** *db_args*
|
||||
Database-specific arguments. See :ref:`Database Options
|
||||
<dboptions>` in :ref:`kadmin(1)` for supported arguments.
|
||||
|
||||
|
||||
FILES
|
||||
-----
|
||||
|
||||
kpropd.acl
|
||||
Access file for kpropd; the default location is
|
||||
``/usr/local/var/krb5kdc/kpropd.acl``. Each entry is a line
|
||||
containing the principal of a host from which the local machine
|
||||
will allow Kerberos database propagation via :ref:`kprop(8)`.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kprop(8)`, :ref:`kdb5_util(8)`, :ref:`krb5kdc(8)`,
|
||||
:ref:`kerberos(7)`, inetd(8)
|
||||
85
crypto/krb5/doc/admin/admin_commands/kproplog.rst
Normal file
85
crypto/krb5/doc/admin/admin_commands/kproplog.rst
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
.. _kproplog(8):
|
||||
|
||||
kproplog
|
||||
========
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**kproplog** [**-h**] [**-e** *num*] [-v]
|
||||
**kproplog** [-R]
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
The kproplog command displays the contents of the KDC database update
|
||||
log to standard output. It can be used to keep track of incremental
|
||||
updates to the principal database. The update log file contains the
|
||||
update log maintained by the :ref:`kadmind(8)` process on the primary
|
||||
KDC server and the :ref:`kpropd(8)` process on the replica KDC
|
||||
servers. When updates occur, they are logged to this file.
|
||||
Subsequently any KDC replica configured for incremental updates will
|
||||
request the current data from the primary KDC and update their log
|
||||
file with any updates returned.
|
||||
|
||||
The kproplog command requires read access to the update log file. It
|
||||
will display update entries only for the KDC it runs on.
|
||||
|
||||
If no options are specified, kproplog displays a summary of the update
|
||||
log. If invoked on the primary, kproplog also displays all of the
|
||||
update entries. If invoked on a replica KDC server, kproplog displays
|
||||
only a summary of the updates, which includes the serial number of the
|
||||
last update received and the associated time stamp of the last update.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
**-R**
|
||||
Reset the update log. This forces full resynchronization. If
|
||||
used on a replica then that replica will request a full resync.
|
||||
If used on the primary then all replicas will request full
|
||||
resyncs.
|
||||
|
||||
**-h**
|
||||
Display a summary of the update log. This information includes
|
||||
the database version number, state of the database, the number of
|
||||
updates in the log, the time stamp of the first and last update,
|
||||
and the version number of the first and last update entry.
|
||||
|
||||
**-e** *num*
|
||||
Display the last *num* update entries in the log. This is useful
|
||||
when debugging synchronization between KDC servers.
|
||||
|
||||
**-v**
|
||||
Display individual attributes per update. An example of the
|
||||
output generated for one entry::
|
||||
|
||||
Update Entry
|
||||
Update serial # : 4
|
||||
Update operation : Add
|
||||
Update principal : test@EXAMPLE.COM
|
||||
Update size : 424
|
||||
Update committed : True
|
||||
Update time stamp : Fri Feb 20 23:37:42 2004
|
||||
Attributes changed : 6
|
||||
Principal
|
||||
Key data
|
||||
Password last changed
|
||||
Modifying principal
|
||||
Modification time
|
||||
TL data
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kpropd(8)`, :ref:`kerberos(7)`
|
||||
114
crypto/krb5/doc/admin/admin_commands/krb5kdc.rst
Normal file
114
crypto/krb5/doc/admin/admin_commands/krb5kdc.rst
Normal file
|
|
@ -0,0 +1,114 @@
|
|||
.. _krb5kdc(8):
|
||||
|
||||
krb5kdc
|
||||
=======
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**krb5kdc**
|
||||
[**-x** *db_args*]
|
||||
[**-d** *dbname*]
|
||||
[**-k** *keytype*]
|
||||
[**-M** *mkeyname*]
|
||||
[**-p** *portnum*]
|
||||
[**-m**]
|
||||
[**-r** *realm*]
|
||||
[**-n**]
|
||||
[**-w** *numworkers*]
|
||||
[**-P** *pid_file*]
|
||||
[**-T** *time_offset*]
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
krb5kdc is the Kerberos version 5 Authentication Service and Key
|
||||
Distribution Center (AS/KDC).
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
The **-r** *realm* option specifies the realm for which the server
|
||||
should provide service. This option may be specified multiple times
|
||||
to serve multiple realms. If no **-r** option is given, the default
|
||||
realm (as specified in :ref:`krb5.conf(5)`) will be served.
|
||||
|
||||
The **-d** *dbname* option specifies the name under which the
|
||||
principal database can be found. This option does not apply to the
|
||||
LDAP database.
|
||||
|
||||
The **-k** *keytype* option specifies the key type of the master key
|
||||
to be entered manually as a password when **-m** is given; the default
|
||||
is |defmkey|.
|
||||
|
||||
The **-M** *mkeyname* option specifies the principal name for the
|
||||
master key in the database (usually ``K/M`` in the KDC's realm).
|
||||
|
||||
The **-m** option specifies that the master database password should
|
||||
be fetched from the keyboard rather than from a stash file.
|
||||
|
||||
The **-n** option specifies that the KDC does not put itself in the
|
||||
background and does not disassociate itself from the terminal.
|
||||
|
||||
The **-P** *pid_file* option tells the KDC to write its PID into
|
||||
*pid_file* after it starts up. This can be used to identify whether
|
||||
the KDC is still running and to allow init scripts to stop the correct
|
||||
process.
|
||||
|
||||
The **-p** *portnum* option specifies the default UDP and TCP port
|
||||
numbers which the KDC should listen on for Kerberos version 5
|
||||
requests, as a comma-separated list. This value overrides the port
|
||||
numbers specified in the :ref:`kdcdefaults` section of
|
||||
:ref:`kdc.conf(5)`, but may be overridden by realm-specific values.
|
||||
If no value is given from any source, the default port is 88.
|
||||
|
||||
The **-w** *numworkers* option tells the KDC to fork *numworkers*
|
||||
processes to listen to the KDC ports and process requests in parallel.
|
||||
The top level KDC process (whose pid is recorded in the pid file if
|
||||
the **-P** option is also given) acts as a supervisor. The supervisor
|
||||
will relay SIGHUP signals to the worker subprocesses, and will
|
||||
terminate the worker subprocess if the it is itself terminated or if
|
||||
any other worker process exits.
|
||||
|
||||
The **-x** *db_args* option specifies database-specific arguments.
|
||||
See :ref:`Database Options <dboptions>` in :ref:`kadmin(1)` for
|
||||
supported arguments.
|
||||
|
||||
The **-T** *offset* option specifies a time offset, in seconds, which
|
||||
the KDC will operate under. It is intended only for testing purposes.
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
|
||||
The KDC may service requests for multiple realms (maximum 32 realms).
|
||||
The realms are listed on the command line. Per-realm options that can
|
||||
be specified on the command line pertain for each realm that follows
|
||||
it and are superseded by subsequent definitions of the same option.
|
||||
|
||||
For example::
|
||||
|
||||
krb5kdc -p 2001 -r REALM1 -p 2002 -r REALM2 -r REALM3
|
||||
|
||||
specifies that the KDC listen on port 2001 for REALM1 and on port 2002
|
||||
for REALM2 and REALM3. Additionally, per-realm parameters may be
|
||||
specified in the :ref:`kdc.conf(5)` file. The location of this file
|
||||
may be specified by the **KRB5_KDC_PROFILE** environment variable.
|
||||
Per-realm parameters specified in this file take precedence over
|
||||
options specified on the command line. See the :ref:`kdc.conf(5)`
|
||||
description for further details.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kdb5_util(8)`, :ref:`kdc.conf(5)`, :ref:`krb5.conf(5)`,
|
||||
:ref:`kdb5_ldap_util(8)`, :ref:`kerberos(7)`
|
||||
129
crypto/krb5/doc/admin/admin_commands/ktutil.rst
Normal file
129
crypto/krb5/doc/admin/admin_commands/ktutil.rst
Normal file
|
|
@ -0,0 +1,129 @@
|
|||
.. _ktutil(1):
|
||||
|
||||
ktutil
|
||||
======
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**ktutil**
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
The ktutil command invokes a command interface from which an
|
||||
administrator can read, write, or edit entries in a keytab. (Kerberos
|
||||
V4 srvtab files are no longer supported.)
|
||||
|
||||
|
||||
COMMANDS
|
||||
--------
|
||||
|
||||
list
|
||||
~~~~
|
||||
|
||||
**list** [**-t**] [**-k**] [**-e**]
|
||||
|
||||
Displays the current keylist. If **-t**, **-k**, and/or **-e** are
|
||||
specified, also display the timestamp, key contents, or enctype
|
||||
(respectively).
|
||||
|
||||
Alias: **l**
|
||||
|
||||
read_kt
|
||||
~~~~~~~
|
||||
|
||||
**read_kt** *keytab*
|
||||
|
||||
Read the Kerberos V5 keytab file *keytab* into the current keylist.
|
||||
|
||||
Alias: **rkt**
|
||||
|
||||
write_kt
|
||||
~~~~~~~~
|
||||
|
||||
**write_kt** *keytab*
|
||||
|
||||
Write the current keylist into the Kerberos V5 keytab file *keytab*.
|
||||
|
||||
Alias: **wkt**
|
||||
|
||||
clear_list
|
||||
~~~~~~~~~~
|
||||
|
||||
**clear_list**
|
||||
|
||||
Clear the current keylist.
|
||||
|
||||
Alias: **clear**
|
||||
|
||||
delete_entry
|
||||
~~~~~~~~~~~~
|
||||
|
||||
**delete_entry** *slot*
|
||||
|
||||
Delete the entry in slot number *slot* from the current keylist.
|
||||
|
||||
Alias: **delent**
|
||||
|
||||
add_entry
|
||||
~~~~~~~~~
|
||||
|
||||
**add_entry** {**-key**\|\ **-password**} **-p** *principal*
|
||||
**-k** *kvno* [**-e** *enctype*] [**-f**\|\ **-s** *salt*]
|
||||
|
||||
Add *principal* to keylist using key or password. If the **-f** flag
|
||||
is specified, salt information will be fetched from the KDC; in this
|
||||
case the **-e** flag may be omitted, or it may be supplied to force a
|
||||
particular enctype. If the **-f** flag is not specified, the **-e**
|
||||
flag must be specified, and the default salt will be used unless
|
||||
overridden with the **-s** option.
|
||||
|
||||
Alias: **addent**
|
||||
|
||||
list_requests
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**list_requests**
|
||||
|
||||
Displays a listing of available commands.
|
||||
|
||||
Aliases: **lr**, **?**
|
||||
|
||||
quit
|
||||
~~~~
|
||||
|
||||
**quit**
|
||||
|
||||
Quits ktutil.
|
||||
|
||||
Aliases: **exit**, **q**
|
||||
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
|
||||
::
|
||||
|
||||
ktutil: add_entry -password -p alice@BLEEP.COM -k 1 -e
|
||||
aes128-cts-hmac-sha1-96
|
||||
Password for alice@BLEEP.COM:
|
||||
ktutil: add_entry -password -p alice@BLEEP.COM -k 1 -e
|
||||
aes256-cts-hmac-sha1-96
|
||||
Password for alice@BLEEP.COM:
|
||||
ktutil: write_kt alice.keytab
|
||||
ktutil:
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kadmin(1)`, :ref:`kdb5_util(8)`, :ref:`kerberos(7)`
|
||||
112
crypto/krb5/doc/admin/admin_commands/sserver.rst
Normal file
112
crypto/krb5/doc/admin/admin_commands/sserver.rst
Normal file
|
|
@ -0,0 +1,112 @@
|
|||
.. _sserver(8):
|
||||
|
||||
sserver
|
||||
=======
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**sserver**
|
||||
[ **-p** *port* ]
|
||||
[ **-S** *keytab* ]
|
||||
[ *server_port* ]
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
sserver and :ref:`sclient(1)` are a simple demonstration client/server
|
||||
application. When sclient connects to sserver, it performs a Kerberos
|
||||
authentication, and then sserver returns to sclient the Kerberos
|
||||
principal which was used for the Kerberos authentication. It makes a
|
||||
good test that Kerberos has been successfully installed on a machine.
|
||||
|
||||
The service name used by sserver and sclient is sample. Hence,
|
||||
sserver will require that there be a keytab entry for the service
|
||||
``sample/hostname.domain.name@REALM.NAME``. This keytab is generated
|
||||
using the :ref:`kadmin(1)` program. The keytab file is usually
|
||||
installed as |keytab|.
|
||||
|
||||
The **-S** option allows for a different keytab than the default.
|
||||
|
||||
sserver is normally invoked out of inetd(8), using a line in
|
||||
``/etc/inetd.conf`` that looks like this::
|
||||
|
||||
sample stream tcp nowait root /usr/local/sbin/sserver sserver
|
||||
|
||||
Since ``sample`` is normally not a port defined in ``/etc/services``,
|
||||
you will usually have to add a line to ``/etc/services`` which looks
|
||||
like this::
|
||||
|
||||
sample 13135/tcp
|
||||
|
||||
When using sclient, you will first have to have an entry in the
|
||||
Kerberos database, by using :ref:`kadmin(1)`, and then you have to get
|
||||
Kerberos tickets, by using :ref:`kinit(1)`. Also, if you are running
|
||||
the sclient program on a different host than the sserver it will be
|
||||
connecting to, be sure that both hosts have an entry in /etc/services
|
||||
for the sample tcp port, and that the same port number is in both
|
||||
files.
|
||||
|
||||
When you run sclient you should see something like this::
|
||||
|
||||
sendauth succeeded, reply is:
|
||||
reply len 32, contents:
|
||||
You are nlgilman@JIMI.MIT.EDU
|
||||
|
||||
|
||||
COMMON ERROR MESSAGES
|
||||
---------------------
|
||||
|
||||
1) kinit returns the error::
|
||||
|
||||
kinit: Client not found in Kerberos database while getting
|
||||
initial credentials
|
||||
|
||||
This means that you didn't create an entry for your username in the
|
||||
Kerberos database.
|
||||
|
||||
2) sclient returns the error::
|
||||
|
||||
unknown service sample/tcp; check /etc/services
|
||||
|
||||
This means that you don't have an entry in /etc/services for the
|
||||
sample tcp port.
|
||||
|
||||
3) sclient returns the error::
|
||||
|
||||
connect: Connection refused
|
||||
|
||||
This probably means you didn't edit /etc/inetd.conf correctly, or
|
||||
you didn't restart inetd after editing inetd.conf.
|
||||
|
||||
4) sclient returns the error::
|
||||
|
||||
sclient: Server not found in Kerberos database while using
|
||||
sendauth
|
||||
|
||||
This means that the ``sample/hostname@LOCAL.REALM`` service was not
|
||||
defined in the Kerberos database; it should be created using
|
||||
:ref:`kadmin(1)`, and a keytab file needs to be generated to make
|
||||
the key for that service principal available for sclient.
|
||||
|
||||
5) sclient returns the error::
|
||||
|
||||
sendauth rejected, error reply is:
|
||||
"No such file or directory"
|
||||
|
||||
This probably means sserver couldn't find the keytab file. It was
|
||||
probably not installed in the proper directory.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`sclient(1)`, :ref:`kerberos(7)`, services(5), inetd(8)
|
||||
8
crypto/krb5/doc/admin/advanced/index.rst
Normal file
8
crypto/krb5/doc/admin/advanced/index.rst
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
Advanced topics
|
||||
===============
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
retiring-des.rst
|
||||
422
crypto/krb5/doc/admin/advanced/retiring-des.rst
Normal file
422
crypto/krb5/doc/admin/advanced/retiring-des.rst
Normal file
|
|
@ -0,0 +1,422 @@
|
|||
.. _retiring-des:
|
||||
|
||||
Retiring DES
|
||||
=======================
|
||||
|
||||
Version 5 of the Kerberos protocol was originally implemented using
|
||||
the Data Encryption Standard (DES) as a block cipher for encryption.
|
||||
While it was considered secure at the time, advancements in computational
|
||||
ability have rendered DES vulnerable to brute force attacks on its 56-bit
|
||||
keyspace. As such, it is now considered insecure and should not be
|
||||
used (:rfc:`6649`).
|
||||
|
||||
History
|
||||
-------
|
||||
|
||||
DES was used in the original Kerberos implementation, and was the
|
||||
only cryptosystem in krb5 1.0. Partial support for triple-DES (3DES) was
|
||||
added in version 1.1, with full support following in version 1.2.
|
||||
The Advanced Encryption Standard (AES), which supersedes DES, gained
|
||||
partial support in version 1.3.0 of krb5 and full support in version 1.3.2.
|
||||
However, deployments of krb5 using Kerberos databases created with older
|
||||
versions of krb5 will not necessarily start using strong crypto for
|
||||
ordinary operation without administrator intervention.
|
||||
|
||||
MIT krb5 began flagging deprecated encryption types with release 1.17,
|
||||
and removed DES (single-DES) support in release 1.18. As a
|
||||
consequence, a release prior to 1.18 is required to perform these
|
||||
migrations.
|
||||
|
||||
Types of keys
|
||||
-------------
|
||||
|
||||
* The database master key: This key is not exposed to user requests,
|
||||
but is used to encrypt other key material stored in the kerberos
|
||||
database. The database master key is currently stored as ``K/M``
|
||||
by default.
|
||||
* Password-derived keys: User principals frequently have keys
|
||||
derived from a password. When a new password is set, the KDC
|
||||
uses various string2key functions to generate keys in the database
|
||||
for that principal.
|
||||
* Keytab keys: Application server principals generally use random
|
||||
keys which are not derived from a password. When the database
|
||||
entry is created, the KDC generates random keys of various enctypes
|
||||
to enter in the database, which are conveyed to the application server
|
||||
and stored in a keytab.
|
||||
* Session keys: These are short-term keys generated by the KDC while
|
||||
processing client requests, with an enctype selected by the KDC.
|
||||
|
||||
For details on the various enctypes and how enctypes are selected by the KDC
|
||||
for session keys and client/server long-term keys, see :ref:`enctypes`.
|
||||
When using the :ref:`kadmin(1)` interface to generate new long-term keys,
|
||||
the **-e** argument can be used to force a particular set of enctypes,
|
||||
overriding the KDC default values.
|
||||
|
||||
.. note::
|
||||
|
||||
When the KDC is selecting a session key, it has no knowledge about the
|
||||
kerberos installation on the server which will receive the service ticket,
|
||||
only what keys are in the database for the service principal.
|
||||
In order to allow uninterrupted operation to
|
||||
clients while migrating away from DES, care must be taken to ensure that
|
||||
kerberos installations on application server machines are configured to
|
||||
support newer encryption types before keys of those new encryption types
|
||||
are created in the Kerberos database for those server principals.
|
||||
|
||||
Upgrade procedure
|
||||
-----------------
|
||||
|
||||
This procedure assumes that the KDC software has already been upgraded
|
||||
to a modern version of krb5 that supports non-DES keys, so that the
|
||||
only remaining task is to update the actual keys used to service requests.
|
||||
The realm used for demonstrating this procedure, ZONE.MIT.EDU,
|
||||
is an example of the worst-case scenario, where all keys in the realm
|
||||
are DES. The realm was initially created with a very old version of krb5,
|
||||
and **supported_enctypes** in :ref:`kdc.conf(5)` was set to a value
|
||||
appropriate when the KDC was installed, but was not updated as the KDC
|
||||
was upgraded:
|
||||
|
||||
::
|
||||
|
||||
[realms]
|
||||
ZONE.MIT.EDU = {
|
||||
[...]
|
||||
master_key_type = des-cbc-crc
|
||||
supported_enctypes = des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
|
||||
}
|
||||
|
||||
This resulted in the keys for all principals in the realm being forced
|
||||
to DES-only, unless specifically requested using :ref:`kadmin(1)`.
|
||||
|
||||
Before starting the upgrade, all KDCs were running krb5 1.11,
|
||||
and the database entries for some "high-value" principals were:
|
||||
|
||||
::
|
||||
|
||||
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q 'getprinc krbtgt/ZONE.MIT.EDU'
|
||||
[...]
|
||||
Number of keys: 1
|
||||
Key: vno 1, des-cbc-crc:v4
|
||||
[...]
|
||||
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q 'getprinc kadmin/admin'
|
||||
[...]
|
||||
Number of keys: 1
|
||||
Key: vno 15, des-cbc-crc
|
||||
[...]
|
||||
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q 'getprinc kadmin/changepw'
|
||||
[...]
|
||||
Number of keys: 1
|
||||
Key: vno 14, des-cbc-crc
|
||||
[...]
|
||||
|
||||
The ``krbtgt/REALM`` key appears to have never been changed since creation
|
||||
(its kvno is 1), and all three database entries have only a des-cbc-crc key.
|
||||
|
||||
The krbtgt key and KDC keys
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Perhaps the biggest single-step improvement in the security of the cell
|
||||
is gained by strengthening the key of the ticket-granting service principal,
|
||||
``krbtgt/REALM``---if this principal's key is compromised, so is the
|
||||
entire realm. Since the server that will handle service tickets
|
||||
for this principal is the KDC itself, it is easy to guarantee that it
|
||||
will be configured to support any encryption types which might be
|
||||
selected. However, the default KDC behavior when creating new keys is to
|
||||
remove the old keys, which would invalidate all existing tickets issued
|
||||
against that principal, rendering the TGTs cached by clients useless.
|
||||
Instead, a new key can be created with the old key retained, so that
|
||||
existing tickets will still function until their scheduled expiry
|
||||
(see :ref:`changing_krbtgt_key`).
|
||||
|
||||
::
|
||||
|
||||
[root@casio krb5kdc]# enctypes=aes256-cts-hmac-sha1-96:normal,\
|
||||
> aes128-cts-hmac-sha1-96:normal,des3-hmac-sha1:normal,des-cbc-crc:normal
|
||||
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q "cpw -e ${enctypes} -randkey \
|
||||
> -keepold krbtgt/ZONE.MIT.EDU"
|
||||
Authenticating as principal root/admin@ZONE.MIT.EDU with password.
|
||||
Key for "krbtgt/ZONE.MIT.EDU@ZONE.MIT.EDU" randomized.
|
||||
|
||||
.. note::
|
||||
|
||||
The new ``krbtgt@REALM`` key should be propagated to replica KDCs
|
||||
immediately so that TGTs issued by the primary KDC can be used to
|
||||
issue service tickets on replica KDCs. Replica KDCs will refuse
|
||||
requests using the new TGT kvno until the new krbtgt entry has
|
||||
been propagated to them.
|
||||
|
||||
It is necessary to explicitly specify the enctypes for the new database
|
||||
entry, since **supported_enctypes** has not been changed. Leaving
|
||||
**supported_enctypes** unchanged makes a potential rollback operation
|
||||
easier, since all new keys of new enctypes are the result of explicit
|
||||
administrator action and can be easily enumerated.
|
||||
Upgrading the krbtgt key should have minimal user-visible disruption other
|
||||
than that described in the note above, since only clients which list the
|
||||
new enctypes as supported will use them, per the procedure
|
||||
in :ref:`session_key_selection`.
|
||||
Once the krbtgt key is updated, the session and ticket keys for user
|
||||
TGTs will be strong keys, but subsequent requests
|
||||
for service tickets will still get DES keys until the service principals
|
||||
have new keys generated. Application service
|
||||
remains uninterrupted due to the key-selection procedure on the KDC.
|
||||
|
||||
After the change, the database entry is now:
|
||||
|
||||
::
|
||||
|
||||
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q 'getprinc krbtgt/ZONE.MIT.EDU'
|
||||
[...]
|
||||
Number of keys: 5
|
||||
Key: vno 2, aes256-cts-hmac-sha1-96
|
||||
Key: vno 2, aes128-cts-hmac-sha1-96
|
||||
Key: vno 2, des3-cbc-sha1
|
||||
Key: vno 2, des-cbc-crc
|
||||
Key: vno 1, des-cbc-crc:v4
|
||||
[...]
|
||||
|
||||
Since the expected disruptions from rekeying the krbtgt principal are
|
||||
minor, after a short testing period, it is
|
||||
appropriate to rekey the other high-value principals, ``kadmin/admin@REALM``
|
||||
and ``kadmin/changepw@REALM``. These are the service principals used for
|
||||
changing user passwords and updating application keytabs. The kadmin
|
||||
and password-changing services are regular kerberized services, so the
|
||||
session-key-selection algorithm described in :ref:`session_key_selection`
|
||||
applies. It is particularly important to have strong session keys for
|
||||
these services, since user passwords and new long-term keys are conveyed
|
||||
over the encrypted channel.
|
||||
|
||||
::
|
||||
|
||||
[root@casio krb5kdc]# enctypes=aes256-cts-hmac-sha1-96:normal,\
|
||||
> aes128-cts-hmac-sha1-96:normal,des3-hmac-sha1:normal
|
||||
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q "cpw -e ${enctypes} -randkey \
|
||||
> kadmin/admin"
|
||||
Authenticating as principal root/admin@ZONE.MIT.EDU with password.
|
||||
Key for "kadmin/admin@ZONE.MIT.EDU" randomized.
|
||||
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q "cpw -e ${enctypes} -randkey \
|
||||
> kadmin/changepw"
|
||||
Authenticating as principal root/admin@ZONE.MIT.EDU with password.
|
||||
Key for "kadmin/changepw@ZONE.MIT.EDU" randomized.
|
||||
|
||||
It is not necessary to retain a single-DES key for these services, since
|
||||
password changes are not part of normal daily workflow, and disruption
|
||||
from a client failure is likely to be minimal. Furthermore, if a kerberos
|
||||
client experiences failure changing a user password or keytab key,
|
||||
this indicates that that client will become inoperative once services
|
||||
are rekeyed to non-DES enctypes. Such problems can be detected early
|
||||
at this stage, giving more time for corrective action.
|
||||
|
||||
Adding strong keys to application servers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Before switching the default enctypes for new keys over to strong enctypes,
|
||||
it may be desired to test upgrading a handful of services with the
|
||||
new configuration before flipping the switch for the defaults. This
|
||||
still requires using the **-e** argument in :ref:`kadmin(1)` to get non-default
|
||||
enctypes:
|
||||
|
||||
::
|
||||
|
||||
[root@casio krb5kdc]# enctypes=aes256-cts-hmac-sha1-96:normal,\
|
||||
> aes128-cts-hmac-sha1-96:normal,des3-cbc-sha1:normal,des-cbc-crc:normal
|
||||
[root@casio krb5kdc]# kadmin -r ZONE.MIT.EDU -p zephyr/zephyr@ZONE.MIT.EDU -k -t \
|
||||
> /etc/zephyr/krb5.keytab -q "ktadd -e ${enctypes} \
|
||||
> -k /etc/zephyr/krb5.keytab zephyr/zephyr@ZONE.MIT.EDU"
|
||||
Authenticating as principal zephyr/zephyr@ZONE.MIT.EDU with keytab /etc/zephyr/krb5.keytab.
|
||||
Entry for principal zephyr/zephyr@ZONE.MIT.EDU with kvno 4, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/zephyr/krb5.keytab.
|
||||
Entry for principal zephyr/zephyr@ZONE.MIT.EDU with kvno 4, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/zephyr/krb5.keytab.
|
||||
Entry for principal zephyr/zephyr@ZONE.MIT.EDU with kvno 4, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/zephyr/krb5.keytab.
|
||||
Entry for principal zephyr/zephyr@ZONE.MIT.EDU with kvno 4, encryption type des-cbc-crc added to keytab WRFILE:/etc/zephyr/krb5.keytab.
|
||||
|
||||
Be sure to remove the old keys from the application keytab, per best
|
||||
practice.
|
||||
|
||||
::
|
||||
|
||||
[root@casio krb5kdc]# k5srvutil -f /etc/zephyr/krb5.keytab delold
|
||||
Authenticating as principal zephyr/zephyr@ZONE.MIT.EDU with keytab /etc/zephyr/krb5.keytab.
|
||||
Entry for principal zephyr/zephyr@ZONE.MIT.EDU with kvno 3 removed from keytab WRFILE:/etc/zephyr/krb5.keytab.
|
||||
|
||||
Adding strong keys by default
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Once the high-visibility services have been rekeyed, it is probably
|
||||
appropriate to change :ref:`kdc.conf(5)` to generate keys with the new
|
||||
encryption types by default. This enables server administrators to generate
|
||||
new enctypes with the **change** subcommand of :ref:`k5srvutil(1)`,
|
||||
and causes user password
|
||||
changes to add new encryption types for their entries. It will probably
|
||||
be necessary to implement administrative controls to cause all user
|
||||
principal keys to be updated in a reasonable period of time, whether
|
||||
by forcing password changes or a password synchronization service that
|
||||
has access to the current password and can add the new keys.
|
||||
|
||||
::
|
||||
|
||||
[realms]
|
||||
ZONE.MIT.EDU = {
|
||||
supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal des3-hmac-sha1:normal des-cbc-crc:normal
|
||||
|
||||
.. note::
|
||||
|
||||
The krb5kdc process must be restarted for these changes to take effect.
|
||||
|
||||
At this point, all service administrators can update their services and the
|
||||
servers behind them to take advantage of strong cryptography.
|
||||
If necessary, the server's krb5 installation should be configured and/or
|
||||
upgraded to a version supporting non-DES keys. See :ref:`enctypes` for
|
||||
krb5 version and configuration settings.
|
||||
Only when the service is configured to accept non-DES keys should
|
||||
the key version number be incremented and new keys generated
|
||||
(``k5srvutil change && k5srvutil delold``).
|
||||
|
||||
::
|
||||
|
||||
root@dr-willy:~# k5srvutil change
|
||||
Authenticating as principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with keytab /etc/krb5.keytab.
|
||||
Entry for principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5.keytab.
|
||||
Entry for principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5.keytab.
|
||||
Entry for principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
|
||||
Entry for principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
|
||||
root@dr-willy:~# klist -e -k -t /etc/krb5.keytab
|
||||
Keytab name: WRFILE:/etc/krb5.keytab
|
||||
KVNO Timestamp Principal
|
||||
---- ----------------- --------------------------------------------------------
|
||||
2 10/10/12 17:03:59 host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU (DES cbc mode with CRC-32)
|
||||
3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU (AES-256 CTS mode with 96-bit SHA-1 HMAC)
|
||||
3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU (AES-128 CTS mode with 96-bit SHA-1 HMAC)
|
||||
3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU (Triple DES cbc mode with HMAC/sha1)
|
||||
3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU (DES cbc mode with CRC-32)
|
||||
root@dr-willy:~# k5srvutil delold
|
||||
Authenticating as principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with keytab /etc/krb5.keytab.
|
||||
Entry for principal host/dr-willy.xvm.mit.edu@ZONE.MIT.EDU with kvno 2 removed from keytab WRFILE:/etc/krb5.keytab.
|
||||
|
||||
When a single service principal is shared by multiple backend servers in
|
||||
a load-balanced environment, it may be necessary to schedule downtime
|
||||
or adjust the population in the load-balanced pool in order to propagate
|
||||
the updated keytab to all hosts in the pool with minimal service interruption.
|
||||
|
||||
Removing DES keys from usage
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This situation remains something of a testing or transitory state,
|
||||
as new DES keys are still being generated, and will be used if requested
|
||||
by a client. To make more progress removing DES from the realm, the KDC
|
||||
should be configured to not generate such keys by default.
|
||||
|
||||
.. note::
|
||||
|
||||
An attacker posing as a client can implement a brute force attack against
|
||||
a DES key for any principal, if that key is in the current (highest-kvno)
|
||||
key list. This attack is only possible if **allow_weak_crypto = true**
|
||||
is enabled on the KDC. Setting the **+requires_preauth** flag on a
|
||||
principal forces this attack to be an online attack, much slower than
|
||||
the offline attack otherwise available to the attacker. However, setting
|
||||
this flag on a service principal is not always advisable; see the entry in
|
||||
:ref:`add_principal` for details.
|
||||
|
||||
The following KDC configuration will not generate DES keys by default:
|
||||
|
||||
::
|
||||
|
||||
[realms]
|
||||
ZONE.MIT.EDU = {
|
||||
supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal des3-hmac-sha1:normal
|
||||
|
||||
.. note::
|
||||
|
||||
As before, the KDC process must be restarted for this change to take
|
||||
effect. It is best practice to update kdc.conf on all KDCs, not just the
|
||||
primary, to avoid unpleasant surprises should the primary fail and a
|
||||
replica need to be promoted.
|
||||
|
||||
It is now appropriate to remove the legacy single-DES key from the
|
||||
``krbtgt/REALM`` entry:
|
||||
|
||||
::
|
||||
|
||||
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q "cpw -randkey -keepold \
|
||||
> krbtgt/ZONE.MIT.EDU"
|
||||
Authenticating as principal host/admin@ATHENA.MIT.EDU with password.
|
||||
Key for "krbtgt/ZONE.MIT.EDU@ZONE.MIT.EDU" randomized.
|
||||
|
||||
After the maximum ticket lifetime has passed, the old database entry
|
||||
should be removed.
|
||||
|
||||
::
|
||||
|
||||
[root@casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q 'purgekeys krbtgt/ZONE.MIT.EDU'
|
||||
Authenticating as principal root/admin@ZONE.MIT.EDU with password.
|
||||
Old keys for principal "krbtgt/ZONE.MIT.EDU@ZONE.MIT.EDU" purged.
|
||||
|
||||
After the KDC is restarted with the new **supported_enctypes**,
|
||||
all user password changes and application keytab updates will not
|
||||
generate DES keys by default.
|
||||
|
||||
::
|
||||
|
||||
contents-vnder-pressvre:~> kpasswd zonetest@ZONE.MIT.EDU
|
||||
Password for zonetest@ZONE.MIT.EDU: [enter old password]
|
||||
Enter new password: [enter new password]
|
||||
Enter it again: [enter new password]
|
||||
Password changed.
|
||||
contents-vnder-pressvre:~> kadmin -r ZONE.MIT.EDU -q 'getprinc zonetest'
|
||||
[...]
|
||||
Number of keys: 3
|
||||
Key: vno 9, aes256-cts-hmac-sha1-96
|
||||
Key: vno 9, aes128-cts-hmac-sha1-96
|
||||
Key: vno 9, des3-cbc-sha1
|
||||
[...]
|
||||
|
||||
[kaduk@glossolalia ~]$ kadmin -p kaduk@ZONE.MIT.EDU -r ZONE.MIT.EDU -k \
|
||||
> -t kaduk-zone.keytab -q 'ktadd -k kaduk-zone.keytab kaduk@ZONE.MIT.EDU'
|
||||
Authenticating as principal kaduk@ZONE.MIT.EDU with keytab kaduk-zone.keytab.
|
||||
Entry for principal kaduk@ZONE.MIT.EDU with kvno 3, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:kaduk-zone.keytab.
|
||||
Entry for principal kaduk@ZONE.MIT.EDU with kvno 3, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:kaduk-zone.keytab.
|
||||
Entry for principal kaduk@ZONE.MIT.EDU with kvno 3, encryption type des3-cbc-sha1 added to keytab WRFILE:kaduk-zone.keytab.
|
||||
|
||||
Once all principals have been re-keyed, DES support can be disabled on the
|
||||
KDC (**allow_weak_crypto = false**), and client machines can remove
|
||||
**allow_weak_crypto = true** from their :ref:`krb5.conf(5)` configuration
|
||||
files, completing the migration. **allow_weak_crypto** takes precedence over
|
||||
all places where DES enctypes could be explicitly configured. DES keys will
|
||||
not be used, even if they are present, when **allow_weak_crypto = false**.
|
||||
|
||||
Support for legacy services
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If there remain legacy services which do not support non-DES enctypes
|
||||
(such as older versions of AFS), **allow_weak_crypto** must remain
|
||||
enabled on the KDC. Client machines need not have this setting,
|
||||
though---applications which require DES can use API calls to allow
|
||||
weak crypto on a per-request basis, overriding the system krb5.conf.
|
||||
However, having **allow_weak_crypto** set on the KDC means that any
|
||||
principals which have a DES key in the database could still use those
|
||||
keys. To minimize the use of DES in the realm and restrict it to just
|
||||
legacy services which require DES, it is necessary to remove all other
|
||||
DES keys. The realm has been configured such that at password and
|
||||
keytab change, no DES keys will be generated by default. The task
|
||||
then reduces to requiring user password changes and having server
|
||||
administrators update their service keytabs. Administrative outreach
|
||||
will be necessary, and if the desire to eliminate DES is sufficiently
|
||||
strong, the KDC administrators may choose to randkey any principals
|
||||
which have not been rekeyed after some timeout period, forcing the
|
||||
user to contact the helpdesk for access.
|
||||
|
||||
The Database Master Key
|
||||
-----------------------
|
||||
|
||||
This procedure does not alter ``K/M@REALM``, the key used to encrypt key
|
||||
material in the Kerberos database. (This is the key stored in the stash file
|
||||
on the KDC if stash files are used.) However, the security risk of
|
||||
a single-DES key for ``K/M`` is minimal, given that access to material
|
||||
encrypted in ``K/M`` (the Kerberos database) is generally tightly controlled.
|
||||
If an attacker can gain access to the encrypted database, they likely
|
||||
have access to the stash file as well, rendering the weak cryptography
|
||||
broken by non-cryptographic means. As such, upgrading ``K/M`` to a stronger
|
||||
encryption type is unlikely to be a high-priority task.
|
||||
|
||||
Is is possible to upgrade the master key used for the database, if
|
||||
desired. Using :ref:`kdb5_util(8)`'s **add_mkey**, **use_mkey**, and
|
||||
**update_princ_encryption** commands, a new master key can be added
|
||||
and activated for use on new key material, and the existing entries
|
||||
converted to the new master key.
|
||||
171
crypto/krb5/doc/admin/appl_servers.rst
Normal file
171
crypto/krb5/doc/admin/appl_servers.rst
Normal file
|
|
@ -0,0 +1,171 @@
|
|||
Application servers
|
||||
===================
|
||||
|
||||
If you need to install the Kerberos V5 programs on an application
|
||||
server, please refer to the Kerberos V5 Installation Guide. Once you
|
||||
have installed the software, you need to add that host to the Kerberos
|
||||
database (see :ref:`principals`), and generate a keytab for that host,
|
||||
that contains the host's key. You also need to make sure the host's
|
||||
clock is within your maximum clock skew of the KDCs.
|
||||
|
||||
|
||||
Keytabs
|
||||
-------
|
||||
|
||||
A keytab is a host's copy of its own keylist, which is analogous to a
|
||||
user's password. An application server that needs to authenticate
|
||||
itself to the KDC has to have a keytab that contains its own principal
|
||||
and key. Just as it is important for users to protect their
|
||||
passwords, it is equally important for hosts to protect their keytabs.
|
||||
You should always store keytab files on local disk, and make them
|
||||
readable only by root, and you should never send a keytab file over a
|
||||
network in the clear. Ideally, you should run the :ref:`kadmin(1)`
|
||||
command to extract a keytab on the host on which the keytab is to
|
||||
reside.
|
||||
|
||||
|
||||
.. _add_princ_kt:
|
||||
|
||||
Adding principals to keytabs
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To generate a keytab, or to add a principal to an existing keytab, use
|
||||
the **ktadd** command from kadmin. Here is a sample session, using
|
||||
configuration files that enable only AES encryption::
|
||||
|
||||
kadmin: ktadd host/daffodil.mit.edu@ATHENA.MIT.EDU
|
||||
Entry for principal host/daffodil.mit.edu with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab
|
||||
Entry for principal host/daffodil.mit.edu with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab
|
||||
|
||||
|
||||
Removing principals from keytabs
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To remove a principal from an existing keytab, use the kadmin
|
||||
**ktremove** command::
|
||||
|
||||
kadmin: ktremove host/daffodil.mit.edu@ATHENA.MIT.EDU
|
||||
Entry for principal host/daffodil.mit.edu with kvno 2 removed from keytab FILE:/etc/krb5.keytab.
|
||||
Entry for principal host/daffodil.mit.edu with kvno 2 removed from keytab FILE:/etc/krb5.keytab.
|
||||
|
||||
|
||||
Using a keytab to acquire client credentials
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
While keytabs are ordinarily used to accept credentials from clients,
|
||||
they can also be used to acquire initial credentials, allowing one
|
||||
service to authenticate to another.
|
||||
|
||||
To manually obtain credentials using a keytab, use the :ref:`kinit(1)`
|
||||
**-k** option, together with the **-t** option if the keytab is not in
|
||||
the default location.
|
||||
|
||||
Beginning with release 1.11, GSSAPI applications can be configured to
|
||||
automatically obtain initial credentials from a keytab as needed. The
|
||||
recommended configuration is as follows:
|
||||
|
||||
#. Create a keytab containing a single entry for the desired client
|
||||
identity.
|
||||
|
||||
#. Place the keytab in a location readable by the service, and set the
|
||||
**KRB5_CLIENT_KTNAME** environment variable to its filename.
|
||||
Alternatively, use the **default_client_keytab_name** profile
|
||||
variable in :ref:`libdefaults`, or use the default location of
|
||||
|ckeytab|.
|
||||
|
||||
#. Set **KRB5CCNAME** to a filename writable by the service, which
|
||||
will not be used for any other purpose. Do not manually obtain
|
||||
credentials at this location. (Another credential cache type
|
||||
besides **FILE** can be used if desired, as long the cache will not
|
||||
conflict with another use. A **MEMORY** cache can be used if the
|
||||
service runs as a long-lived process. See :ref:`ccache_definition`
|
||||
for details.)
|
||||
|
||||
#. Start the service. When it authenticates using GSSAPI, it will
|
||||
automatically obtain credentials from the client keytab into the
|
||||
specified credential cache, and refresh them before they expire.
|
||||
|
||||
|
||||
Clock Skew
|
||||
----------
|
||||
|
||||
A Kerberos application server host must keep its clock synchronized or
|
||||
it will reject authentication requests from clients. Modern operating
|
||||
systems typically provide a facility to maintain the correct time;
|
||||
make sure it is enabled. This is especially important on virtual
|
||||
machines, where clocks tend to drift more rapidly than normal machine
|
||||
clocks.
|
||||
|
||||
The default allowable clock skew is controlled by the **clockskew**
|
||||
variable in :ref:`libdefaults`.
|
||||
|
||||
|
||||
Getting DNS information correct
|
||||
-------------------------------
|
||||
|
||||
Several aspects of Kerberos rely on name service. When a hostname is
|
||||
used to name a service, clients may canonicalize the hostname using
|
||||
forward and possibly reverse name resolution. The result of this
|
||||
canonicalization must match the principal entry in the host's keytab,
|
||||
or authentication will fail. To work with all client canonicalization
|
||||
configurations, each host's canonical name must be the fully-qualified
|
||||
host name (including the domain), and each host's IP address must
|
||||
reverse-resolve to the canonical name.
|
||||
|
||||
Configuration of hostnames varies by operating system. On the
|
||||
application server itself, canonicalization will typically use the
|
||||
``/etc/hosts`` file rather than the DNS. Ensure that the line for the
|
||||
server's hostname is in the following form::
|
||||
|
||||
IP address fully-qualified hostname aliases
|
||||
|
||||
Here is a sample ``/etc/hosts`` file::
|
||||
|
||||
# this is a comment
|
||||
127.0.0.1 localhost localhost.mit.edu
|
||||
10.0.0.6 daffodil.mit.edu daffodil trillium wake-robin
|
||||
|
||||
The output of ``klist -k`` for this example host should look like::
|
||||
|
||||
viola# klist -k
|
||||
Keytab name: /etc/krb5.keytab
|
||||
KVNO Principal
|
||||
---- ------------------------------------------------------------
|
||||
2 host/daffodil.mit.edu@ATHENA.MIT.EDU
|
||||
|
||||
If you were to ssh to this host with a fresh credentials cache (ticket
|
||||
file), and then :ref:`klist(1)`, the output should list a service
|
||||
principal of ``host/daffodil.mit.edu@ATHENA.MIT.EDU``.
|
||||
|
||||
|
||||
.. _conf_firewall:
|
||||
|
||||
Configuring your firewall to work with Kerberos V5
|
||||
--------------------------------------------------
|
||||
|
||||
If you need off-site users to be able to get Kerberos tickets in your
|
||||
realm, they must be able to get to your KDC. This requires either
|
||||
that you have a replica KDC outside your firewall, or that you
|
||||
configure your firewall to allow UDP requests into at least one of
|
||||
your KDCs, on whichever port the KDC is running. (The default is port
|
||||
88; other ports may be specified in the KDC's :ref:`kdc.conf(5)`
|
||||
file.) Similarly, if you need off-site users to be able to change
|
||||
their passwords in your realm, they must be able to get to your
|
||||
Kerberos admin server on the kpasswd port (which defaults to 464). If
|
||||
you need off-site users to be able to administer your Kerberos realm,
|
||||
they must be able to get to your Kerberos admin server on the
|
||||
administrative port (which defaults to 749).
|
||||
|
||||
If your on-site users inside your firewall will need to get to KDCs in
|
||||
other realms, you will also need to configure your firewall to allow
|
||||
outgoing TCP and UDP requests to port 88, and to port 464 to allow
|
||||
password changes. If your on-site users inside your firewall will
|
||||
need to get to Kerberos admin servers in other realms, you will also
|
||||
need to allow outgoing TCP and UDP requests to port 749.
|
||||
|
||||
If any of your KDCs are outside your firewall, you will need to allow
|
||||
kprop requests to get through to the remote KDC. :ref:`kprop(8)` uses
|
||||
the ``krb5_prop`` service on port 754 (tcp).
|
||||
|
||||
The book *UNIX System Security*, by David Curry, is a good starting
|
||||
point for learning to configure firewalls.
|
||||
57
crypto/krb5/doc/admin/auth_indicator.rst
Normal file
57
crypto/krb5/doc/admin/auth_indicator.rst
Normal file
|
|
@ -0,0 +1,57 @@
|
|||
.. _auth_indicator:
|
||||
|
||||
Authentication indicators
|
||||
=========================
|
||||
|
||||
As of release 1.14, the KDC can be configured to annotate tickets if
|
||||
the client authenticated using a stronger preauthentication mechanism
|
||||
such as :ref:`PKINIT <pkinit>` or :ref:`OTP <otp_preauth>`. These
|
||||
annotations are called "authentication indicators." Service
|
||||
principals can be configured to require particular authentication
|
||||
indicators in order to authenticate to that service. An
|
||||
authentication indicator value can be any string chosen by the KDC
|
||||
administrator; there are no pre-set values.
|
||||
|
||||
To use authentication indicators with PKINIT or OTP, first configure
|
||||
the KDC to include an indicator when that preauthentication mechanism
|
||||
is used. For PKINIT, use the **pkinit_indicator** variable in
|
||||
:ref:`kdc.conf(5)`. For OTP, use the **indicator** variable in the
|
||||
token type definition, or specify the indicators in the **otp** user
|
||||
string as described in :ref:`otp_preauth`.
|
||||
|
||||
To require an indicator to be present in order to authenticate to a
|
||||
service principal, set the **require_auth** string attribute on the
|
||||
principal to the indicator value to be required. If you wish to allow
|
||||
one of several indicators to be accepted, you can specify multiple
|
||||
indicator values separated by spaces.
|
||||
|
||||
For example, a realm could be configured to set the authentication
|
||||
indicator value "strong" when PKINIT is used to authenticate, using a
|
||||
setting in the :ref:`kdc_realms` subsection::
|
||||
|
||||
pkinit_indicator = strong
|
||||
|
||||
A service principal could be configured to require the "strong"
|
||||
authentication indicator value::
|
||||
|
||||
$ kadmin setstr host/high.value.server require_auth strong
|
||||
Password for user/admin@KRBTEST.COM:
|
||||
|
||||
A user who authenticates with PKINIT would be able to obtain a ticket
|
||||
for the service principal::
|
||||
|
||||
$ kinit -X X509_user_identity=FILE:/my/cert.pem,/my/key.pem user
|
||||
$ kvno host/high.value.server
|
||||
host/high.value.server@KRBTEST.COM: kvno = 1
|
||||
|
||||
but a user who authenticates with a password would not::
|
||||
|
||||
$ kinit user
|
||||
Password for user@KRBTEST.COM:
|
||||
$ kvno host/high.value.server
|
||||
kvno: KDC policy rejects request while getting credentials for
|
||||
host/high.value.server@KRBTEST.COM
|
||||
|
||||
GSSAPI server applications can inspect authentication indicators
|
||||
through the :ref:`auth-indicators <gssapi_authind_attr>` name
|
||||
attribute.
|
||||
34
crypto/krb5/doc/admin/backup_host.rst
Normal file
34
crypto/krb5/doc/admin/backup_host.rst
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
Backups of secure hosts
|
||||
=======================
|
||||
|
||||
When you back up a secure host, you should exclude the host's keytab
|
||||
file from the backup. If someone obtained a copy of the keytab from a
|
||||
backup, that person could make any host masquerade as the host whose
|
||||
keytab was compromised. In many configurations, knowledge of the
|
||||
host's keytab also allows root access to the host. This could be
|
||||
particularly dangerous if the compromised keytab was from one of your
|
||||
KDCs. If the machine has a disk crash and the keytab file is lost, it
|
||||
is easy to generate another keytab file. (See :ref:`add_princ_kt`.)
|
||||
If you are unable to exclude particular files from backups, you should
|
||||
ensure that the backups are kept as secure as the host's root
|
||||
password.
|
||||
|
||||
|
||||
Backing up the Kerberos database
|
||||
--------------------------------
|
||||
|
||||
As with any file, it is possible that your Kerberos database could
|
||||
become corrupted. If this happens on one of the replica KDCs, you
|
||||
might never notice, since the next automatic propagation of the
|
||||
database would install a fresh copy. However, if it happens to the
|
||||
primary KDC, the corrupted database would be propagated to all of the
|
||||
replicas during the next propagation. For this reason, MIT recommends
|
||||
that you back up your Kerberos database regularly. Because the primary
|
||||
KDC is continuously dumping the database to a file in order to
|
||||
propagate it to the replica KDCs, it is a simple matter to have a cron
|
||||
job periodically copy the dump file to a secure machine elsewhere on
|
||||
your network. (Of course, it is important to make the host where
|
||||
these backups are stored as secure as your KDCs, and to encrypt its
|
||||
transmission across your network.) Then if your database becomes
|
||||
corrupted, you can load the most recent dump onto the primary KDC.
|
||||
(See :ref:`restore_from_dump`.)
|
||||
20
crypto/krb5/doc/admin/conf_files/index.rst
Normal file
20
crypto/krb5/doc/admin/conf_files/index.rst
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
Configuration Files
|
||||
===================
|
||||
|
||||
Kerberos uses configuration files to allow administrators to specify
|
||||
settings on a per-machine basis. :ref:`krb5.conf(5)` applies to all
|
||||
applications using the Kerboros library, on clients and servers.
|
||||
For KDC-specific applications, additional settings can be specified in
|
||||
:ref:`kdc.conf(5)`; the two files are merged into a configuration profile
|
||||
used by applications accessing the KDC database directly. :ref:`kadm5.acl(5)`
|
||||
is also only used on the KDC, it controls permissions for modifying the
|
||||
KDC database.
|
||||
|
||||
Contents
|
||||
--------
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
krb5_conf
|
||||
kdc_conf
|
||||
kadm5_acl
|
||||
163
crypto/krb5/doc/admin/conf_files/kadm5_acl.rst
Normal file
163
crypto/krb5/doc/admin/conf_files/kadm5_acl.rst
Normal file
|
|
@ -0,0 +1,163 @@
|
|||
.. _kadm5.acl(5):
|
||||
|
||||
kadm5.acl
|
||||
=========
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
The Kerberos :ref:`kadmind(8)` daemon uses an Access Control List
|
||||
(ACL) file to manage access rights to the Kerberos database.
|
||||
For operations that affect principals, the ACL file also controls
|
||||
which principals can operate on which other principals.
|
||||
|
||||
The default location of the Kerberos ACL file is
|
||||
|kdcdir|\ ``/kadm5.acl`` unless this is overridden by the *acl_file*
|
||||
variable in :ref:`kdc.conf(5)`.
|
||||
|
||||
SYNTAX
|
||||
------
|
||||
|
||||
Empty lines and lines starting with the sharp sign (``#``) are
|
||||
ignored. Lines containing ACL entries have the format::
|
||||
|
||||
principal permissions [target_principal [restrictions] ]
|
||||
|
||||
.. note::
|
||||
|
||||
Line order in the ACL file is important. The first matching entry
|
||||
will control access for an actor principal on a target principal.
|
||||
|
||||
*principal*
|
||||
(Partially or fully qualified Kerberos principal name.) Specifies
|
||||
the principal whose permissions are to be set.
|
||||
|
||||
Each component of the name may be wildcarded using the ``*``
|
||||
character.
|
||||
|
||||
*permissions*
|
||||
Specifies what operations may or may not be performed by a
|
||||
*principal* matching a particular entry. This is a string of one or
|
||||
more of the following list of characters or their upper-case
|
||||
counterparts. If the character is *upper-case*, then the operation
|
||||
is disallowed. If the character is *lower-case*, then the operation
|
||||
is permitted.
|
||||
|
||||
== ======================================================
|
||||
a [Dis]allows the addition of principals or policies
|
||||
c [Dis]allows the changing of passwords for principals
|
||||
d [Dis]allows the deletion of principals or policies
|
||||
e [Dis]allows the extraction of principal keys
|
||||
i [Dis]allows inquiries about principals or policies
|
||||
l [Dis]allows the listing of all principals or policies
|
||||
m [Dis]allows the modification of principals or policies
|
||||
p [Dis]allows the propagation of the principal database (used in :ref:`incr_db_prop`)
|
||||
s [Dis]allows the explicit setting of the key for a principal
|
||||
x Short for admcilsp. All privileges (except ``e``)
|
||||
\* Same as x.
|
||||
== ======================================================
|
||||
|
||||
.. note::
|
||||
|
||||
The ``extract`` privilege is not included in the wildcard
|
||||
privilege; it must be explicitly assigned. This privilege
|
||||
allows the user to extract keys from the database, and must be
|
||||
handled with great care to avoid disclosure of important keys
|
||||
like those of the kadmin/* or krbtgt/* principals. The
|
||||
**lockdown_keys** principal attribute can be used to prevent
|
||||
key extraction from specific principals regardless of the
|
||||
granted privilege.
|
||||
|
||||
*target_principal*
|
||||
(Optional. Partially or fully qualified Kerberos principal name.)
|
||||
Specifies the principal on which *permissions* may be applied.
|
||||
Each component of the name may be wildcarded using the ``*``
|
||||
character.
|
||||
|
||||
*target_principal* can also include back-references to *principal*,
|
||||
in which ``*number`` matches the corresponding wildcard in
|
||||
*principal*.
|
||||
|
||||
*restrictions*
|
||||
(Optional) A string of flags. Allowed restrictions are:
|
||||
|
||||
{+\|-}\ *flagname*
|
||||
flag is forced to the indicated value. The permissible flags
|
||||
are the same as those for the **default_principal_flags**
|
||||
variable in :ref:`kdc.conf(5)`.
|
||||
|
||||
*-clearpolicy*
|
||||
policy is forced to be empty.
|
||||
|
||||
*-policy pol*
|
||||
policy is forced to be *pol*.
|
||||
|
||||
-{*expire, pwexpire, maxlife, maxrenewlife*} *time*
|
||||
(:ref:`getdate` string) associated value will be forced to
|
||||
MIN(*time*, requested value).
|
||||
|
||||
The above flags act as restrictions on any add or modify operation
|
||||
which is allowed due to that ACL line.
|
||||
|
||||
.. warning::
|
||||
|
||||
If the kadmind ACL file is modified, the kadmind daemon needs to be
|
||||
restarted for changes to take effect.
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
|
||||
Here is an example of a kadm5.acl file::
|
||||
|
||||
*/admin@ATHENA.MIT.EDU * # line 1
|
||||
joeadmin@ATHENA.MIT.EDU ADMCIL # line 2
|
||||
joeadmin/*@ATHENA.MIT.EDU i */root@ATHENA.MIT.EDU # line 3
|
||||
*/root@ATHENA.MIT.EDU ci *1@ATHENA.MIT.EDU # line 4
|
||||
*/root@ATHENA.MIT.EDU l * # line 5
|
||||
sms@ATHENA.MIT.EDU x * -maxlife 9h -postdateable # line 6
|
||||
|
||||
(line 1) Any principal in the ``ATHENA.MIT.EDU`` realm with an
|
||||
``admin`` instance has all administrative privileges except extracting
|
||||
keys.
|
||||
|
||||
(lines 1-3) The user ``joeadmin`` has all permissions except
|
||||
extracting keys with his ``admin`` instance,
|
||||
``joeadmin/admin@ATHENA.MIT.EDU`` (matches line 1). He has no
|
||||
permissions at all with his null instance, ``joeadmin@ATHENA.MIT.EDU``
|
||||
(matches line 2). His ``root`` and other non-``admin``, non-null
|
||||
instances (e.g., ``extra`` or ``dbadmin``) have inquire permissions
|
||||
with any principal that has the instance ``root`` (matches line 3).
|
||||
|
||||
(line 4) Any ``root`` principal in ``ATHENA.MIT.EDU`` can inquire
|
||||
or change the password of their null instance, but not any other
|
||||
null instance. (Here, ``*1`` denotes a back-reference to the
|
||||
component matching the first wildcard in the actor principal.)
|
||||
|
||||
(line 5) Any ``root`` principal in ``ATHENA.MIT.EDU`` can generate
|
||||
the list of principals in the database, and the list of policies
|
||||
in the database. This line is separate from line 4, because list
|
||||
permission can only be granted globally, not to specific target
|
||||
principals.
|
||||
|
||||
(line 6) Finally, the Service Management System principal
|
||||
``sms@ATHENA.MIT.EDU`` has all permissions except extracting keys, but
|
||||
any principal that it creates or modifies will not be able to get
|
||||
postdateable tickets or tickets with a life of longer than 9 hours.
|
||||
|
||||
MODULE BEHAVIOR
|
||||
---------------
|
||||
|
||||
The ACL file can coexist with other authorization modules in release
|
||||
1.16 and later, as configured in the :ref:`kadm5_auth` section of
|
||||
:ref:`krb5.conf(5)`. The ACL file will positively authorize
|
||||
operations according to the rules above, but will never
|
||||
authoritatively deny an operation, so other modules can authorize
|
||||
operations in addition to those authorized by the ACL file.
|
||||
|
||||
To operate without an ACL file, set the *acl_file* variable in
|
||||
:ref:`kdc.conf(5)` to the empty string with ``acl_file = ""``.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kdc.conf(5)`, :ref:`kadmind(8)`
|
||||
976
crypto/krb5/doc/admin/conf_files/kdc_conf.rst
Normal file
976
crypto/krb5/doc/admin/conf_files/kdc_conf.rst
Normal file
|
|
@ -0,0 +1,976 @@
|
|||
.. _kdc.conf(5):
|
||||
|
||||
kdc.conf
|
||||
========
|
||||
|
||||
The kdc.conf file supplements :ref:`krb5.conf(5)` for programs which
|
||||
are typically only used on a KDC, such as the :ref:`krb5kdc(8)` and
|
||||
:ref:`kadmind(8)` daemons and the :ref:`kdb5_util(8)` program.
|
||||
Relations documented here may also be specified in krb5.conf; for the
|
||||
KDC programs mentioned, krb5.conf and kdc.conf will be merged into a
|
||||
single configuration profile.
|
||||
|
||||
Normally, the kdc.conf file is found in the KDC state directory,
|
||||
|kdcdir|. You can override the default location by setting the
|
||||
environment variable **KRB5_KDC_PROFILE**.
|
||||
|
||||
Please note that you need to restart the KDC daemon for any configuration
|
||||
changes to take effect.
|
||||
|
||||
Structure
|
||||
---------
|
||||
|
||||
The kdc.conf file is set up in the same format as the
|
||||
:ref:`krb5.conf(5)` file.
|
||||
|
||||
|
||||
Sections
|
||||
--------
|
||||
|
||||
The kdc.conf file may contain the following sections:
|
||||
|
||||
==================== =================================================
|
||||
:ref:`kdcdefaults` Default values for KDC behavior
|
||||
:ref:`kdc_realms` Realm-specific database configuration and settings
|
||||
:ref:`dbdefaults` Default database settings
|
||||
:ref:`dbmodules` Per-database settings
|
||||
:ref:`logging` Controls how Kerberos daemons perform logging
|
||||
==================== =================================================
|
||||
|
||||
|
||||
.. _kdcdefaults:
|
||||
|
||||
[kdcdefaults]
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Some relations in the [kdcdefaults] section specify default values for
|
||||
realm variables, to be used if the [realms] subsection does not
|
||||
contain a relation for the tag. See the :ref:`kdc_realms` section for
|
||||
the definitions of these relations.
|
||||
|
||||
* **host_based_services**
|
||||
* **kdc_listen**
|
||||
* **kdc_ports**
|
||||
* **kdc_tcp_listen**
|
||||
* **kdc_tcp_ports**
|
||||
* **no_host_referral**
|
||||
* **restrict_anonymous_to_tgt**
|
||||
|
||||
The following [kdcdefaults] variables have no per-realm equivalent:
|
||||
|
||||
**kdc_max_dgram_reply_size**
|
||||
Specifies the maximum packet size that can be sent over UDP. The
|
||||
default value is 4096 bytes.
|
||||
|
||||
**kdc_tcp_listen_backlog**
|
||||
(Integer.) Set the size of the listen queue length for the KDC
|
||||
daemon. The value may be limited by OS settings. The default
|
||||
value is 5.
|
||||
|
||||
**spake_preauth_kdc_challenge**
|
||||
(String.) Specifies the group for a SPAKE optimistic challenge.
|
||||
See the **spake_preauth_groups** variable in :ref:`libdefaults`
|
||||
for possible values. The default is not to issue an optimistic
|
||||
challenge. (New in release 1.17.)
|
||||
|
||||
|
||||
.. _kdc_realms:
|
||||
|
||||
[realms]
|
||||
~~~~~~~~
|
||||
|
||||
Each tag in the [realms] section is the name of a Kerberos realm. The
|
||||
value of the tag is a subsection where the relations define KDC
|
||||
parameters for that particular realm. The following example shows how
|
||||
to define one parameter for the ATHENA.MIT.EDU realm::
|
||||
|
||||
[realms]
|
||||
ATHENA.MIT.EDU = {
|
||||
max_renewable_life = 7d 0h 0m 0s
|
||||
}
|
||||
|
||||
The following tags may be specified in a [realms] subsection:
|
||||
|
||||
**acl_file**
|
||||
(String.) Location of the access control list file that
|
||||
:ref:`kadmind(8)` uses to determine which principals are allowed
|
||||
which permissions on the Kerberos database. To operate without an
|
||||
ACL file, set this relation to the empty string with ``acl_file =
|
||||
""``. The default value is |kdcdir|\ ``/kadm5.acl``. For more
|
||||
information on Kerberos ACL file see :ref:`kadm5.acl(5)`.
|
||||
|
||||
**database_module**
|
||||
(String.) This relation indicates the name of the configuration
|
||||
section under :ref:`dbmodules` for database-specific parameters
|
||||
used by the loadable database library. The default value is the
|
||||
realm name. If this configuration section does not exist, default
|
||||
values will be used for all database parameters.
|
||||
|
||||
**database_name**
|
||||
(String, deprecated.) This relation specifies the location of the
|
||||
Kerberos database for this realm, if the DB2 module is being used
|
||||
and the :ref:`dbmodules` configuration section does not specify a
|
||||
database name. The default value is |kdcdir|\ ``/principal``.
|
||||
|
||||
**default_principal_expiration**
|
||||
(:ref:`abstime` string.) Specifies the default expiration date of
|
||||
principals created in this realm. The default value is 0, which
|
||||
means no expiration date.
|
||||
|
||||
**default_principal_flags**
|
||||
(Flag string.) Specifies the default attributes of principals
|
||||
created in this realm. The format for this string is a
|
||||
comma-separated list of flags, with '+' before each flag that
|
||||
should be enabled and '-' before each flag that should be
|
||||
disabled. The **postdateable**, **forwardable**, **tgt-based**,
|
||||
**renewable**, **proxiable**, **dup-skey**, **allow-tickets**, and
|
||||
**service** flags default to enabled.
|
||||
|
||||
There are a number of possible flags:
|
||||
|
||||
**allow-tickets**
|
||||
Enabling this flag means that the KDC will issue tickets for
|
||||
this principal. Disabling this flag essentially deactivates
|
||||
the principal within this realm.
|
||||
|
||||
**dup-skey**
|
||||
Enabling this flag allows the KDC to issue user-to-user
|
||||
service tickets for this principal.
|
||||
|
||||
**forwardable**
|
||||
Enabling this flag allows the principal to obtain forwardable
|
||||
tickets.
|
||||
|
||||
**hwauth**
|
||||
If this flag is enabled, then the principal is required to
|
||||
preauthenticate using a hardware device before receiving any
|
||||
tickets.
|
||||
|
||||
**no-auth-data-required**
|
||||
Enabling this flag prevents PAC or AD-SIGNEDPATH data from
|
||||
being added to service tickets for the principal.
|
||||
|
||||
**ok-as-delegate**
|
||||
If this flag is enabled, it hints the client that credentials
|
||||
can and should be delegated when authenticating to the
|
||||
service.
|
||||
|
||||
**ok-to-auth-as-delegate**
|
||||
Enabling this flag allows the principal to use S4USelf tickets.
|
||||
|
||||
**postdateable**
|
||||
Enabling this flag allows the principal to obtain postdateable
|
||||
tickets.
|
||||
|
||||
**preauth**
|
||||
If this flag is enabled on a client principal, then that
|
||||
principal is required to preauthenticate to the KDC before
|
||||
receiving any tickets. On a service principal, enabling this
|
||||
flag means that service tickets for this principal will only
|
||||
be issued to clients with a TGT that has the preauthenticated
|
||||
bit set.
|
||||
|
||||
**proxiable**
|
||||
Enabling this flag allows the principal to obtain proxy
|
||||
tickets.
|
||||
|
||||
**pwchange**
|
||||
Enabling this flag forces a password change for this
|
||||
principal.
|
||||
|
||||
**pwservice**
|
||||
If this flag is enabled, it marks this principal as a password
|
||||
change service. This should only be used in special cases,
|
||||
for example, if a user's password has expired, then the user
|
||||
has to get tickets for that principal without going through
|
||||
the normal password authentication in order to be able to
|
||||
change the password.
|
||||
|
||||
**renewable**
|
||||
Enabling this flag allows the principal to obtain renewable
|
||||
tickets.
|
||||
|
||||
**service**
|
||||
Enabling this flag allows the the KDC to issue service tickets
|
||||
for this principal. In release 1.17 and later, user-to-user
|
||||
service tickets are still allowed if the **dup-skey** flag is
|
||||
set.
|
||||
|
||||
**tgt-based**
|
||||
Enabling this flag allows a principal to obtain tickets based
|
||||
on a ticket-granting-ticket, rather than repeating the
|
||||
authentication process that was used to obtain the TGT.
|
||||
|
||||
**dict_file**
|
||||
(String.) Location of the dictionary file containing strings that
|
||||
are not allowed as passwords. The file should contain one string
|
||||
per line, with no additional whitespace. If none is specified or
|
||||
if there is no policy assigned to the principal, no dictionary
|
||||
checks of passwords will be performed.
|
||||
|
||||
**disable_pac**
|
||||
(Boolean value.) If true, the KDC will not issue PACs for this
|
||||
realm, and S4U2Self and S4U2Proxy operations will be disabled.
|
||||
The default is false, which will permit the KDC to issue PACs.
|
||||
New in release 1.20.
|
||||
|
||||
**encrypted_challenge_indicator**
|
||||
(String.) Specifies the authentication indicator value that the KDC
|
||||
asserts into tickets obtained using FAST encrypted challenge
|
||||
pre-authentication. New in 1.16.
|
||||
|
||||
**host_based_services**
|
||||
(Whitespace- or comma-separated list.) Lists services which will
|
||||
get host-based referral processing even if the server principal is
|
||||
not marked as host-based by the client.
|
||||
|
||||
**iprop_enable**
|
||||
(Boolean value.) Specifies whether incremental database
|
||||
propagation is enabled. The default value is false.
|
||||
|
||||
**iprop_ulogsize**
|
||||
(Integer.) Specifies the maximum number of log entries to be
|
||||
retained for incremental propagation. The default value is 1000.
|
||||
Prior to release 1.11, the maximum value was 2500. New in release
|
||||
1.19.
|
||||
|
||||
**iprop_master_ulogsize**
|
||||
The name for **iprop_ulogsize** prior to release 1.19. Its value is
|
||||
used as a fallback if **iprop_ulogsize** is not specified.
|
||||
|
||||
**iprop_replica_poll**
|
||||
(Delta time string.) Specifies how often the replica KDC polls
|
||||
for new updates from the primary. The default value is ``2m``
|
||||
(that is, two minutes). New in release 1.17.
|
||||
|
||||
**iprop_slave_poll**
|
||||
(Delta time string.) The name for **iprop_replica_poll** prior to
|
||||
release 1.17. Its value is used as a fallback if
|
||||
**iprop_replica_poll** is not specified.
|
||||
|
||||
**iprop_listen**
|
||||
(Whitespace- or comma-separated list.) Specifies the iprop RPC
|
||||
listening addresses and/or ports for the :ref:`kadmind(8)` daemon.
|
||||
Each entry may be an interface address, a port number, or an
|
||||
address and port number separated by a colon. If the address
|
||||
contains colons, enclose it in square brackets. If no address is
|
||||
specified, the wildcard address is used. If kadmind fails to bind
|
||||
to any of the specified addresses, it will fail to start. The
|
||||
default (when **iprop_enable** is true) is to bind to the wildcard
|
||||
address at the port specified in **iprop_port**. New in release
|
||||
1.15.
|
||||
|
||||
**iprop_port**
|
||||
(Port number.) Specifies the port number to be used for
|
||||
incremental propagation. When **iprop_enable** is true, this
|
||||
relation is required in the replica KDC configuration file, and
|
||||
this relation or **iprop_listen** is required in the primary
|
||||
configuration file, as there is no default port number. Port
|
||||
numbers specified in **iprop_listen** entries will override this
|
||||
port number for the :ref:`kadmind(8)` daemon.
|
||||
|
||||
**iprop_resync_timeout**
|
||||
(Delta time string.) Specifies the amount of time to wait for a
|
||||
full propagation to complete. This is optional in configuration
|
||||
files, and is used by replica KDCs only. The default value is 5
|
||||
minutes (``5m``). New in release 1.11.
|
||||
|
||||
**iprop_logfile**
|
||||
(File name.) Specifies where the update log file for the realm
|
||||
database is to be stored. The default is to use the
|
||||
**database_name** entry from the realms section of the krb5 config
|
||||
file, with ``.ulog`` appended. (NOTE: If **database_name** isn't
|
||||
specified in the realms section, perhaps because the LDAP database
|
||||
back end is being used, or the file name is specified in the
|
||||
[dbmodules] section, then the hard-coded default for
|
||||
**database_name** is used. Determination of the **iprop_logfile**
|
||||
default value will not use values from the [dbmodules] section.)
|
||||
|
||||
**kadmind_listen**
|
||||
(Whitespace- or comma-separated list.) Specifies the kadmin RPC
|
||||
listening addresses and/or ports for the :ref:`kadmind(8)` daemon.
|
||||
Each entry may be an interface address, a port number, or an
|
||||
address and port number separated by a colon. If the address
|
||||
contains colons, enclose it in square brackets. If no address is
|
||||
specified, the wildcard address is used. If kadmind fails to bind
|
||||
to any of the specified addresses, it will fail to start. The
|
||||
default is to bind to the wildcard address at the port specified
|
||||
in **kadmind_port**, or the standard kadmin port (749). New in
|
||||
release 1.15.
|
||||
|
||||
**kadmind_port**
|
||||
(Port number.) Specifies the port on which the :ref:`kadmind(8)`
|
||||
daemon is to listen for this realm. Port numbers specified in
|
||||
**kadmind_listen** entries will override this port number. The
|
||||
assigned port for kadmind is 749, which is used by default.
|
||||
|
||||
**key_stash_file**
|
||||
(String.) Specifies the location where the master key has been
|
||||
stored (via kdb5_util stash). The default is |kdcdir|\
|
||||
``/.k5.REALM``, where *REALM* is the Kerberos realm.
|
||||
|
||||
**kdc_listen**
|
||||
(Whitespace- or comma-separated list.) Specifies the UDP
|
||||
listening addresses and/or ports for the :ref:`krb5kdc(8)` daemon.
|
||||
Each entry may be an interface address, a port number, or an
|
||||
address and port number separated by a colon. If the address
|
||||
contains colons, enclose it in square brackets. If no address is
|
||||
specified, the wildcard address is used. If no port is specified,
|
||||
the standard port (88) is used. If the KDC daemon fails to bind
|
||||
to any of the specified addresses, it will fail to start. The
|
||||
default is to bind to the wildcard address on the standard port.
|
||||
New in release 1.15.
|
||||
|
||||
**kdc_ports**
|
||||
(Whitespace- or comma-separated list, deprecated.) Prior to
|
||||
release 1.15, this relation lists the ports for the
|
||||
:ref:`krb5kdc(8)` daemon to listen on for UDP requests. In
|
||||
release 1.15 and later, it has the same meaning as **kdc_listen**
|
||||
if that relation is not defined.
|
||||
|
||||
**kdc_tcp_listen**
|
||||
(Whitespace- or comma-separated list.) Specifies the TCP
|
||||
listening addresses and/or ports for the :ref:`krb5kdc(8)` daemon.
|
||||
Each entry may be an interface address, a port number, or an
|
||||
address and port number separated by a colon. If the address
|
||||
contains colons, enclose it in square brackets. If no address is
|
||||
specified, the wildcard address is used. If no port is specified,
|
||||
the standard port (88) is used. To disable listening on TCP, set
|
||||
this relation to the empty string with ``kdc_tcp_listen = ""``.
|
||||
If the KDC daemon fails to bind to any of the specified addresses,
|
||||
it will fail to start. The default is to bind to the wildcard
|
||||
address on the standard port. New in release 1.15.
|
||||
|
||||
**kdc_tcp_ports**
|
||||
(Whitespace- or comma-separated list, deprecated.) Prior to
|
||||
release 1.15, this relation lists the ports for the
|
||||
:ref:`krb5kdc(8)` daemon to listen on for UDP requests. In
|
||||
release 1.15 and later, it has the same meaning as
|
||||
**kdc_tcp_listen** if that relation is not defined.
|
||||
|
||||
**kpasswd_listen**
|
||||
(Comma-separated list.) Specifies the kpasswd listening addresses
|
||||
and/or ports for the :ref:`kadmind(8)` daemon. Each entry may be
|
||||
an interface address, a port number, or an address and port number
|
||||
separated by a colon. If the address contains colons, enclose it
|
||||
in square brackets. If no address is specified, the wildcard
|
||||
address is used. If kadmind fails to bind to any of the specified
|
||||
addresses, it will fail to start. The default is to bind to the
|
||||
wildcard address at the port specified in **kpasswd_port**, or the
|
||||
standard kpasswd port (464). New in release 1.15.
|
||||
|
||||
**kpasswd_port**
|
||||
(Port number.) Specifies the port on which the :ref:`kadmind(8)`
|
||||
daemon is to listen for password change requests for this realm.
|
||||
Port numbers specified in **kpasswd_listen** entries will override
|
||||
this port number. The assigned port for password change requests
|
||||
is 464, which is used by default.
|
||||
|
||||
**master_key_name**
|
||||
(String.) Specifies the name of the principal associated with the
|
||||
master key. The default is ``K/M``.
|
||||
|
||||
**master_key_type**
|
||||
(Key type string.) Specifies the master key's key type. The
|
||||
default value for this is |defmkey|. For a list of all possible
|
||||
values, see :ref:`Encryption_types`.
|
||||
|
||||
**max_life**
|
||||
(:ref:`duration` string.) Specifies the maximum time period for
|
||||
which a ticket may be valid in this realm. The default value is
|
||||
24 hours.
|
||||
|
||||
**max_renewable_life**
|
||||
(:ref:`duration` string.) Specifies the maximum time period
|
||||
during which a valid ticket may be renewed in this realm.
|
||||
The default value is 0.
|
||||
|
||||
**no_host_referral**
|
||||
(Whitespace- or comma-separated list.) Lists services to block
|
||||
from getting host-based referral processing, even if the client
|
||||
marks the server principal as host-based or the service is also
|
||||
listed in **host_based_services**. ``no_host_referral = *`` will
|
||||
disable referral processing altogether.
|
||||
|
||||
**reject_bad_transit**
|
||||
(Boolean value.) If set to true, the KDC will check the list of
|
||||
transited realms for cross-realm tickets against the transit path
|
||||
computed from the realm names and the capaths section of its
|
||||
:ref:`krb5.conf(5)` file; if the path in the ticket to be issued
|
||||
contains any realms not in the computed path, the ticket will not
|
||||
be issued, and an error will be returned to the client instead.
|
||||
If this value is set to false, such tickets will be issued
|
||||
anyways, and it will be left up to the application server to
|
||||
validate the realm transit path.
|
||||
|
||||
If the disable-transited-check flag is set in the incoming
|
||||
request, this check is not performed at all. Having the
|
||||
**reject_bad_transit** option will cause such ticket requests to
|
||||
be rejected always.
|
||||
|
||||
This transit path checking and config file option currently apply
|
||||
only to TGS requests.
|
||||
|
||||
The default value is true.
|
||||
|
||||
**restrict_anonymous_to_tgt**
|
||||
(Boolean value.) If set to true, the KDC will reject ticket
|
||||
requests from anonymous principals to service principals other
|
||||
than the realm's ticket-granting service. This option allows
|
||||
anonymous PKINIT to be enabled for use as FAST armor tickets
|
||||
without allowing anonymous authentication to services. The
|
||||
default value is false. New in release 1.9.
|
||||
|
||||
**spake_preauth_indicator**
|
||||
(String.) Specifies an authentication indicator value that the
|
||||
KDC asserts into tickets obtained using SPAKE pre-authentication.
|
||||
The default is not to add any indicators. This option may be
|
||||
specified multiple times. New in release 1.17.
|
||||
|
||||
**supported_enctypes**
|
||||
(List of *key*:*salt* strings.) Specifies the default key/salt
|
||||
combinations of principals for this realm. Any principals created
|
||||
through :ref:`kadmin(1)` will have keys of these types. The
|
||||
default value for this tag is |defkeysalts|. For lists of
|
||||
possible values, see :ref:`Keysalt_lists`.
|
||||
|
||||
|
||||
.. _dbdefaults:
|
||||
|
||||
[dbdefaults]
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The [dbdefaults] section specifies default values for some database
|
||||
parameters, to be used if the [dbmodules] subsection does not contain
|
||||
a relation for the tag. See the :ref:`dbmodules` section for the
|
||||
definitions of these relations.
|
||||
|
||||
* **ldap_kerberos_container_dn**
|
||||
* **ldap_kdc_dn**
|
||||
* **ldap_kdc_sasl_authcid**
|
||||
* **ldap_kdc_sasl_authzid**
|
||||
* **ldap_kdc_sasl_mech**
|
||||
* **ldap_kdc_sasl_realm**
|
||||
* **ldap_kadmind_dn**
|
||||
* **ldap_kadmind_sasl_authcid**
|
||||
* **ldap_kadmind_sasl_authzid**
|
||||
* **ldap_kadmind_sasl_mech**
|
||||
* **ldap_kadmind_sasl_realm**
|
||||
* **ldap_service_password_file**
|
||||
* **ldap_conns_per_server**
|
||||
|
||||
|
||||
.. _dbmodules:
|
||||
|
||||
[dbmodules]
|
||||
~~~~~~~~~~~
|
||||
|
||||
The [dbmodules] section contains parameters used by the KDC database
|
||||
library and database modules. Each tag in the [dbmodules] section is
|
||||
the name of a Kerberos realm or a section name specified by a realm's
|
||||
**database_module** parameter. The following example shows how to
|
||||
define one database parameter for the ATHENA.MIT.EDU realm::
|
||||
|
||||
[dbmodules]
|
||||
ATHENA.MIT.EDU = {
|
||||
disable_last_success = true
|
||||
}
|
||||
|
||||
The following tags may be specified in a [dbmodules] subsection:
|
||||
|
||||
**database_name**
|
||||
This DB2-specific tag indicates the location of the database in
|
||||
the filesystem. The default is |kdcdir|\ ``/principal``.
|
||||
|
||||
**db_library**
|
||||
This tag indicates the name of the loadable database module. The
|
||||
value should be ``db2`` for the DB2 module, ``klmdb`` for the LMDB
|
||||
module, or ``kldap`` for the LDAP module.
|
||||
|
||||
**disable_last_success**
|
||||
If set to ``true``, suppresses KDC updates to the "Last successful
|
||||
authentication" field of principal entries requiring
|
||||
preauthentication. Setting this flag may improve performance.
|
||||
(Principal entries which do not require preauthentication never
|
||||
update the "Last successful authentication" field.). First
|
||||
introduced in release 1.9.
|
||||
|
||||
**disable_lockout**
|
||||
If set to ``true``, suppresses KDC updates to the "Last failed
|
||||
authentication" and "Failed password attempts" fields of principal
|
||||
entries requiring preauthentication. Setting this flag may
|
||||
improve performance, but also disables account lockout. First
|
||||
introduced in release 1.9.
|
||||
|
||||
**ldap_conns_per_server**
|
||||
This LDAP-specific tag indicates the number of connections to be
|
||||
maintained per LDAP server.
|
||||
|
||||
**ldap_kdc_dn** and **ldap_kadmind_dn**
|
||||
These LDAP-specific tags indicate the default DN for binding to
|
||||
the LDAP server. The :ref:`krb5kdc(8)` daemon uses
|
||||
**ldap_kdc_dn**, while the :ref:`kadmind(8)` daemon and other
|
||||
administrative programs use **ldap_kadmind_dn**. The kadmind DN
|
||||
must have the rights to read and write the Kerberos data in the
|
||||
LDAP database. The KDC DN must have the same rights, unless
|
||||
**disable_lockout** and **disable_last_success** are true, in
|
||||
which case it only needs to have rights to read the Kerberos data.
|
||||
These tags are ignored if a SASL mechanism is set with
|
||||
**ldap_kdc_sasl_mech** or **ldap_kadmind_sasl_mech**.
|
||||
|
||||
**ldap_kdc_sasl_mech** and **ldap_kadmind_sasl_mech**
|
||||
These LDAP-specific tags specify the SASL mechanism (such as
|
||||
``EXTERNAL``) to use when binding to the LDAP server. New in
|
||||
release 1.13.
|
||||
|
||||
**ldap_kdc_sasl_authcid** and **ldap_kadmind_sasl_authcid**
|
||||
These LDAP-specific tags specify the SASL authentication identity
|
||||
to use when binding to the LDAP server. Not all SASL mechanisms
|
||||
require an authentication identity. If the SASL mechanism
|
||||
requires a secret (such as the password for ``DIGEST-MD5``), these
|
||||
tags also determine the name within the
|
||||
**ldap_service_password_file** where the secret is stashed. New
|
||||
in release 1.13.
|
||||
|
||||
**ldap_kdc_sasl_authzid** and **ldap_kadmind_sasl_authzid**
|
||||
These LDAP-specific tags specify the SASL authorization identity
|
||||
to use when binding to the LDAP server. In most circumstances
|
||||
they do not need to be specified. New in release 1.13.
|
||||
|
||||
**ldap_kdc_sasl_realm** and **ldap_kadmind_sasl_realm**
|
||||
These LDAP-specific tags specify the SASL realm to use when
|
||||
binding to the LDAP server. In most circumstances they do not
|
||||
need to be set. New in release 1.13.
|
||||
|
||||
**ldap_kerberos_container_dn**
|
||||
This LDAP-specific tag indicates the DN of the container object
|
||||
where the realm objects will be located.
|
||||
|
||||
**ldap_servers**
|
||||
This LDAP-specific tag indicates the list of LDAP servers that the
|
||||
Kerberos servers can connect to. The list of LDAP servers is
|
||||
whitespace-separated. The LDAP server is specified by a LDAP URI.
|
||||
It is recommended to use ``ldapi:`` or ``ldaps:`` URLs to connect
|
||||
to the LDAP server.
|
||||
|
||||
**ldap_service_password_file**
|
||||
This LDAP-specific tag indicates the file containing the stashed
|
||||
passwords (created by ``kdb5_ldap_util stashsrvpw``) for the
|
||||
**ldap_kdc_dn** and **ldap_kadmind_dn** objects, or for the
|
||||
**ldap_kdc_sasl_authcid** or **ldap_kadmind_sasl_authcid** names
|
||||
for SASL authentication. This file must be kept secure.
|
||||
|
||||
**mapsize**
|
||||
This LMDB-specific tag indicates the maximum size of the two
|
||||
database environments in megabytes. The default value is 128.
|
||||
Increase this value to address "Environment mapsize limit reached"
|
||||
errors. New in release 1.17.
|
||||
|
||||
**max_readers**
|
||||
This LMDB-specific tag indicates the maximum number of concurrent
|
||||
reading processes for the databases. The default value is 128.
|
||||
New in release 1.17.
|
||||
|
||||
**nosync**
|
||||
This LMDB-specific tag can be set to improve the throughput of
|
||||
kadmind and other administrative agents, at the expense of
|
||||
durability (recent database changes may not survive a power outage
|
||||
or other sudden reboot). It does not affect the throughput of the
|
||||
KDC. The default value is false. New in release 1.17.
|
||||
|
||||
**unlockiter**
|
||||
If set to ``true``, this DB2-specific tag causes iteration
|
||||
operations to release the database lock while processing each
|
||||
principal. Setting this flag to ``true`` can prevent extended
|
||||
blocking of KDC or kadmin operations when dumps of large databases
|
||||
are in progress. First introduced in release 1.13.
|
||||
|
||||
The following tag may be specified directly in the [dbmodules]
|
||||
section to control where database modules are loaded from:
|
||||
|
||||
**db_module_dir**
|
||||
This tag controls where the plugin system looks for database
|
||||
modules. The value should be an absolute path.
|
||||
|
||||
.. _logging:
|
||||
|
||||
[logging]
|
||||
~~~~~~~~~
|
||||
|
||||
The [logging] section indicates how :ref:`krb5kdc(8)` and
|
||||
:ref:`kadmind(8)` perform logging. It may contain the following
|
||||
relations:
|
||||
|
||||
**admin_server**
|
||||
Specifies how :ref:`kadmind(8)` performs logging.
|
||||
|
||||
**kdc**
|
||||
Specifies how :ref:`krb5kdc(8)` performs logging.
|
||||
|
||||
**default**
|
||||
Specifies how either daemon performs logging in the absence of
|
||||
relations specific to the daemon.
|
||||
|
||||
**debug**
|
||||
(Boolean value.) Specifies whether debugging messages are
|
||||
included in log outputs other than SYSLOG. Debugging messages are
|
||||
always included in the system log output because syslog performs
|
||||
its own priority filtering. The default value is false. New in
|
||||
release 1.15.
|
||||
|
||||
Logging specifications may have the following forms:
|
||||
|
||||
**FILE=**\ *filename* or **FILE:**\ *filename*
|
||||
This value causes the daemon's logging messages to go to the
|
||||
*filename*. If the ``=`` form is used, the file is overwritten.
|
||||
If the ``:`` form is used, the file is appended to.
|
||||
|
||||
**STDERR**
|
||||
This value causes the daemon's logging messages to go to its
|
||||
standard error stream.
|
||||
|
||||
**CONSOLE**
|
||||
This value causes the daemon's logging messages to go to the
|
||||
console, if the system supports it.
|
||||
|
||||
**DEVICE=**\ *<devicename>*
|
||||
This causes the daemon's logging messages to go to the specified
|
||||
device.
|
||||
|
||||
**SYSLOG**\ [\ **:**\ *severity*\ [\ **:**\ *facility*\ ]]
|
||||
This causes the daemon's logging messages to go to the system log.
|
||||
|
||||
For backward compatibility, a severity argument may be specified,
|
||||
and must be specified in order to specify a facility. This
|
||||
argument will be ignored.
|
||||
|
||||
The facility argument specifies the facility under which the
|
||||
messages are logged. This may be any of the following facilities
|
||||
supported by the syslog(3) call minus the LOG\_ prefix: **KERN**,
|
||||
**USER**, **MAIL**, **DAEMON**, **AUTH**, **LPR**, **NEWS**,
|
||||
**UUCP**, **CRON**, and **LOCAL0** through **LOCAL7**. If no
|
||||
facility is specified, the default is **AUTH**.
|
||||
|
||||
In the following example, the logging messages from the KDC will go to
|
||||
the console and to the system log under the facility LOG_DAEMON, and
|
||||
the logging messages from the administrative server will be appended
|
||||
to the file ``/var/adm/kadmin.log`` and sent to the device
|
||||
``/dev/tty04``. ::
|
||||
|
||||
[logging]
|
||||
kdc = CONSOLE
|
||||
kdc = SYSLOG:INFO:DAEMON
|
||||
admin_server = FILE:/var/adm/kadmin.log
|
||||
admin_server = DEVICE=/dev/tty04
|
||||
|
||||
If no logging specification is given, the default is to use syslog.
|
||||
To disable logging entirely, specify ``default = DEVICE=/dev/null``.
|
||||
|
||||
|
||||
.. _otp:
|
||||
|
||||
[otp]
|
||||
~~~~~
|
||||
|
||||
Each subsection of [otp] is the name of an OTP token type. The tags
|
||||
within the subsection define the configuration required to forward a
|
||||
One Time Password request to a RADIUS server.
|
||||
|
||||
For each token type, the following tags may be specified:
|
||||
|
||||
**server**
|
||||
This is the server to send the RADIUS request to. It can be a
|
||||
hostname with optional port, an ip address with optional port, or
|
||||
a Unix domain socket address. The default is
|
||||
|kdcdir|\ ``/<name>.socket``.
|
||||
|
||||
**secret**
|
||||
This tag indicates a filename (which may be relative to |kdcdir|)
|
||||
containing the secret used to encrypt the RADIUS packets. The
|
||||
secret should appear in the first line of the file by itself;
|
||||
leading and trailing whitespace on the line will be removed. If
|
||||
the value of **server** is a Unix domain socket address, this tag
|
||||
is optional, and an empty secret will be used if it is not
|
||||
specified. Otherwise, this tag is required.
|
||||
|
||||
**timeout**
|
||||
An integer which specifies the time in seconds during which the
|
||||
KDC should attempt to contact the RADIUS server. This tag is the
|
||||
total time across all retries and should be less than the time
|
||||
which an OTP value remains valid for. The default is 5 seconds.
|
||||
|
||||
**retries**
|
||||
This tag specifies the number of retries to make to the RADIUS
|
||||
server. The default is 3 retries (4 tries).
|
||||
|
||||
**strip_realm**
|
||||
If this tag is ``true``, the principal without the realm will be
|
||||
passed to the RADIUS server. Otherwise, the realm will be
|
||||
included. The default value is ``true``.
|
||||
|
||||
**indicator**
|
||||
This tag specifies an authentication indicator to be included in
|
||||
the ticket if this token type is used to authenticate. This
|
||||
option may be specified multiple times. (New in release 1.14.)
|
||||
|
||||
In the following example, requests are sent to a remote server via UDP::
|
||||
|
||||
[otp]
|
||||
MyRemoteTokenType = {
|
||||
server = radius.mydomain.com:1812
|
||||
secret = SEmfiajf42$
|
||||
timeout = 15
|
||||
retries = 5
|
||||
strip_realm = true
|
||||
}
|
||||
|
||||
An implicit default token type named ``DEFAULT`` is defined for when
|
||||
the per-principal configuration does not specify a token type. Its
|
||||
configuration is shown below. You may override this token type to
|
||||
something applicable for your situation::
|
||||
|
||||
[otp]
|
||||
DEFAULT = {
|
||||
strip_realm = false
|
||||
}
|
||||
|
||||
PKINIT options
|
||||
--------------
|
||||
|
||||
.. note::
|
||||
|
||||
The following are pkinit-specific options. These values may
|
||||
be specified in [kdcdefaults] as global defaults, or within
|
||||
a realm-specific subsection of [realms]. Also note that a
|
||||
realm-specific value over-rides, does not add to, a generic
|
||||
[kdcdefaults] specification. The search order is:
|
||||
|
||||
1. realm-specific subsection of [realms]::
|
||||
|
||||
[realms]
|
||||
EXAMPLE.COM = {
|
||||
pkinit_anchors = FILE:/usr/local/example.com.crt
|
||||
}
|
||||
|
||||
2. generic value in the [kdcdefaults] section::
|
||||
|
||||
[kdcdefaults]
|
||||
pkinit_anchors = DIR:/usr/local/generic_trusted_cas/
|
||||
|
||||
For information about the syntax of some of these options, see
|
||||
:ref:`Specifying PKINIT identity information <pkinit_identity>` in
|
||||
:ref:`krb5.conf(5)`.
|
||||
|
||||
**pkinit_anchors**
|
||||
Specifies the location of trusted anchor (root) certificates which
|
||||
the KDC trusts to sign client certificates. This option is
|
||||
required if pkinit is to be supported by the KDC. This option may
|
||||
be specified multiple times.
|
||||
|
||||
**pkinit_dh_min_bits**
|
||||
Specifies the minimum number of bits the KDC is willing to accept
|
||||
for a client's Diffie-Hellman key. The default is 2048.
|
||||
|
||||
**pkinit_allow_upn**
|
||||
Specifies that the KDC is willing to accept client certificates
|
||||
with the Microsoft UserPrincipalName (UPN) Subject Alternative
|
||||
Name (SAN). This means the KDC accepts the binding of the UPN in
|
||||
the certificate to the Kerberos principal name. The default value
|
||||
is false.
|
||||
|
||||
Without this option, the KDC will only accept certificates with
|
||||
the id-pkinit-san as defined in :rfc:`4556`. There is currently
|
||||
no option to disable SAN checking in the KDC.
|
||||
|
||||
**pkinit_eku_checking**
|
||||
This option specifies what Extended Key Usage (EKU) values the KDC
|
||||
is willing to accept in client certificates. The values
|
||||
recognized in the kdc.conf file are:
|
||||
|
||||
**kpClientAuth**
|
||||
This is the default value and specifies that client
|
||||
certificates must have the id-pkinit-KPClientAuth EKU as
|
||||
defined in :rfc:`4556`.
|
||||
|
||||
**scLogin**
|
||||
If scLogin is specified, client certificates with the
|
||||
Microsoft Smart Card Login EKU (id-ms-kp-sc-logon) will be
|
||||
accepted.
|
||||
|
||||
**none**
|
||||
If none is specified, then client certificates will not be
|
||||
checked to verify they have an acceptable EKU. The use of
|
||||
this option is not recommended.
|
||||
|
||||
**pkinit_identity**
|
||||
Specifies the location of the KDC's X.509 identity information.
|
||||
This option is required if pkinit is to be supported by the KDC.
|
||||
|
||||
**pkinit_indicator**
|
||||
Specifies an authentication indicator to include in the ticket if
|
||||
pkinit is used to authenticate. This option may be specified
|
||||
multiple times. (New in release 1.14.)
|
||||
|
||||
**pkinit_pool**
|
||||
Specifies the location of intermediate certificates which may be
|
||||
used by the KDC to complete the trust chain between a client's
|
||||
certificate and a trusted anchor. This option may be specified
|
||||
multiple times.
|
||||
|
||||
**pkinit_revoke**
|
||||
Specifies the location of Certificate Revocation List (CRL)
|
||||
information to be used by the KDC when verifying the validity of
|
||||
client certificates. This option may be specified multiple times.
|
||||
|
||||
**pkinit_require_crl_checking**
|
||||
The default certificate verification process will always check the
|
||||
available revocation information to see if a certificate has been
|
||||
revoked. If a match is found for the certificate in a CRL,
|
||||
verification fails. If the certificate being verified is not
|
||||
listed in a CRL, or there is no CRL present for its issuing CA,
|
||||
and **pkinit_require_crl_checking** is false, then verification
|
||||
succeeds.
|
||||
|
||||
However, if **pkinit_require_crl_checking** is true and there is
|
||||
no CRL information available for the issuing CA, then verification
|
||||
fails.
|
||||
|
||||
**pkinit_require_crl_checking** should be set to true if the
|
||||
policy is such that up-to-date CRLs must be present for every CA.
|
||||
|
||||
**pkinit_require_freshness**
|
||||
Specifies whether to require clients to include a freshness token
|
||||
in PKINIT requests. The default value is false. (New in release
|
||||
1.17.)
|
||||
|
||||
.. _Encryption_types:
|
||||
|
||||
Encryption types
|
||||
----------------
|
||||
|
||||
Any tag in the configuration files which requires a list of encryption
|
||||
types can be set to some combination of the following strings.
|
||||
Encryption types marked as "weak" and "deprecated" are available for
|
||||
compatibility but not recommended for use.
|
||||
|
||||
==================================================== =========================================================
|
||||
des3-cbc-raw Triple DES cbc mode raw (weak)
|
||||
des3-cbc-sha1 des3-hmac-sha1 des3-cbc-sha1-kd Triple DES cbc mode with HMAC/sha1 (deprecated)
|
||||
aes256-cts-hmac-sha1-96 aes256-cts aes256-sha1 AES-256 CTS mode with 96-bit SHA-1 HMAC
|
||||
aes128-cts-hmac-sha1-96 aes128-cts aes128-sha1 AES-128 CTS mode with 96-bit SHA-1 HMAC
|
||||
aes256-cts-hmac-sha384-192 aes256-sha2 AES-256 CTS mode with 192-bit SHA-384 HMAC
|
||||
aes128-cts-hmac-sha256-128 aes128-sha2 AES-128 CTS mode with 128-bit SHA-256 HMAC
|
||||
arcfour-hmac rc4-hmac arcfour-hmac-md5 RC4 with HMAC/MD5 (deprecated)
|
||||
arcfour-hmac-exp rc4-hmac-exp arcfour-hmac-md5-exp Exportable RC4 with HMAC/MD5 (weak)
|
||||
camellia256-cts-cmac camellia256-cts Camellia-256 CTS mode with CMAC
|
||||
camellia128-cts-cmac camellia128-cts Camellia-128 CTS mode with CMAC
|
||||
des3 The triple DES family: des3-cbc-sha1
|
||||
aes The AES family: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, aes256-cts-hmac-sha384-192, and aes128-cts-hmac-sha256-128
|
||||
rc4 The RC4 family: arcfour-hmac
|
||||
camellia The Camellia family: camellia256-cts-cmac and camellia128-cts-cmac
|
||||
==================================================== =========================================================
|
||||
|
||||
The string **DEFAULT** can be used to refer to the default set of
|
||||
types for the variable in question. Types or families can be removed
|
||||
from the current list by prefixing them with a minus sign ("-").
|
||||
Types or families can be prefixed with a plus sign ("+") for symmetry;
|
||||
it has the same meaning as just listing the type or family. For
|
||||
example, "``DEFAULT -rc4``" would be the default set of encryption
|
||||
types with RC4 types removed, and "``des3 DEFAULT``" would be the
|
||||
default set of encryption types with triple DES types moved to the
|
||||
front.
|
||||
|
||||
While **aes128-cts** and **aes256-cts** are supported for all Kerberos
|
||||
operations, they are not supported by very old versions of our GSSAPI
|
||||
implementation (krb5-1.3.1 and earlier). Services running versions of
|
||||
krb5 without AES support must not be given keys of these encryption
|
||||
types in the KDC database.
|
||||
|
||||
The **aes128-sha2** and **aes256-sha2** encryption types are new in
|
||||
release 1.15. Services running versions of krb5 without support for
|
||||
these newer encryption types must not be given keys of these
|
||||
encryption types in the KDC database.
|
||||
|
||||
|
||||
.. _Keysalt_lists:
|
||||
|
||||
Keysalt lists
|
||||
-------------
|
||||
|
||||
Kerberos keys for users are usually derived from passwords. Kerberos
|
||||
commands and configuration parameters that affect generation of keys
|
||||
take lists of enctype-salttype ("keysalt") pairs, known as *keysalt
|
||||
lists*. Each keysalt pair is an enctype name followed by a salttype
|
||||
name, in the format *enc*:*salt*. Individual keysalt list members are
|
||||
separated by comma (",") characters or space characters. For example::
|
||||
|
||||
kadmin -e aes256-cts:normal,aes128-cts:normal
|
||||
|
||||
would start up kadmin so that by default it would generate
|
||||
password-derived keys for the **aes256-cts** and **aes128-cts**
|
||||
encryption types, using a **normal** salt.
|
||||
|
||||
To ensure that people who happen to pick the same password do not have
|
||||
the same key, Kerberos 5 incorporates more information into the key
|
||||
using something called a salt. The supported salt types are as
|
||||
follows:
|
||||
|
||||
================= ============================================
|
||||
normal default for Kerberos Version 5
|
||||
norealm same as the default, without using realm information
|
||||
onlyrealm uses only realm information as the salt
|
||||
special generate a random salt
|
||||
================= ============================================
|
||||
|
||||
|
||||
Sample kdc.conf File
|
||||
--------------------
|
||||
|
||||
Here's an example of a kdc.conf file::
|
||||
|
||||
[kdcdefaults]
|
||||
kdc_listen = 88
|
||||
kdc_tcp_listen = 88
|
||||
[realms]
|
||||
ATHENA.MIT.EDU = {
|
||||
kadmind_port = 749
|
||||
max_life = 12h 0m 0s
|
||||
max_renewable_life = 7d 0h 0m 0s
|
||||
master_key_type = aes256-cts-hmac-sha1-96
|
||||
supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal
|
||||
database_module = openldap_ldapconf
|
||||
}
|
||||
|
||||
[logging]
|
||||
kdc = FILE:/usr/local/var/krb5kdc/kdc.log
|
||||
admin_server = FILE:/usr/local/var/krb5kdc/kadmin.log
|
||||
|
||||
[dbdefaults]
|
||||
ldap_kerberos_container_dn = cn=krbcontainer,dc=mit,dc=edu
|
||||
|
||||
[dbmodules]
|
||||
openldap_ldapconf = {
|
||||
db_library = kldap
|
||||
disable_last_success = true
|
||||
ldap_kdc_dn = "cn=krbadmin,dc=mit,dc=edu"
|
||||
# this object needs to have read rights on
|
||||
# the realm container and principal subtrees
|
||||
ldap_kadmind_dn = "cn=krbadmin,dc=mit,dc=edu"
|
||||
# this object needs to have read and write rights on
|
||||
# the realm container and principal subtrees
|
||||
ldap_service_password_file = /etc/kerberos/service.keyfile
|
||||
ldap_servers = ldaps://kerberos.mit.edu
|
||||
ldap_conns_per_server = 5
|
||||
}
|
||||
|
||||
|
||||
FILES
|
||||
------
|
||||
|
||||
|kdcdir|\ ``/kdc.conf``
|
||||
|
||||
|
||||
SEE ALSO
|
||||
---------
|
||||
|
||||
:ref:`krb5.conf(5)`, :ref:`krb5kdc(8)`, :ref:`kadm5.acl(5)`
|
||||
1251
crypto/krb5/doc/admin/conf_files/krb5_conf.rst
Normal file
1251
crypto/krb5/doc/admin/conf_files/krb5_conf.rst
Normal file
File diff suppressed because it is too large
Load diff
132
crypto/krb5/doc/admin/conf_ldap.rst
Normal file
132
crypto/krb5/doc/admin/conf_ldap.rst
Normal file
|
|
@ -0,0 +1,132 @@
|
|||
.. _conf_ldap:
|
||||
|
||||
Configuring Kerberos with OpenLDAP back-end
|
||||
===========================================
|
||||
|
||||
|
||||
1. Make sure the LDAP server is using local authentication
|
||||
(``ldapi://``) or TLS (``ldaps``). See
|
||||
https://www.openldap.org/doc/admin/tls.html for instructions on
|
||||
configuring TLS support in OpenLDAP.
|
||||
|
||||
2. Add the Kerberos schema file to the LDAP Server using the OpenLDAP
|
||||
LDIF file from the krb5 source directory
|
||||
(``src/plugins/kdb/ldap/libkdb_ldap/kerberos.openldap.ldif``).
|
||||
The following example uses local authentication::
|
||||
|
||||
ldapadd -Y EXTERNAL -H ldapi:/// -f /path/to/kerberos.openldap.ldif
|
||||
|
||||
3. Choose DNs for the :ref:`krb5kdc(8)` and :ref:`kadmind(8)` servers
|
||||
to bind to the LDAP server, and create them if necessary. Specify
|
||||
these DNs with the **ldap_kdc_dn** and **ldap_kadmind_dn**
|
||||
directives in :ref:`kdc.conf(5)`. The kadmind DN will also be
|
||||
used for administrative commands such as :ref:`kdb5_util(8)`.
|
||||
|
||||
Alternatively, you may configure krb5kdc and kadmind to use SASL
|
||||
authentication to access the LDAP server; see the :ref:`dbmodules`
|
||||
relations **ldap_kdc_sasl_mech** and similar.
|
||||
|
||||
4. Specify a location for the LDAP service password file by setting
|
||||
**ldap_service_password_file**. Use ``kdb5_ldap_util stashsrvpw``
|
||||
to stash passwords for the KDC and kadmind DNs chosen above. For
|
||||
example::
|
||||
|
||||
kdb5_ldap_util stashsrvpw -f /path/to/service.keyfile cn=krbadmin,dc=example,dc=com
|
||||
|
||||
Skip this step if you are using SASL authentication and the
|
||||
mechanism does not require a password.
|
||||
|
||||
5. Choose a DN for the global Kerberos container entry (but do not
|
||||
create the entry at this time). Specify this DN with the
|
||||
**ldap_kerberos_container_dn** directive in :ref:`kdc.conf(5)`.
|
||||
Realm container entries will be created underneath this DN.
|
||||
Principal entries may exist either underneath the realm container
|
||||
(the default) or in separate trees referenced from the realm
|
||||
container.
|
||||
|
||||
6. Configure the LDAP server ACLs to enable the KDC and kadmin server
|
||||
DNs to read and write the Kerberos data. If
|
||||
**disable_last_success** and **disable_lockout** are both set to
|
||||
true in the :ref:`dbmodules` subsection for the realm, then the
|
||||
KDC DN only requires read access to the Kerberos data.
|
||||
|
||||
Sample access control information::
|
||||
|
||||
access to dn.base=""
|
||||
by * read
|
||||
|
||||
access to dn.base="cn=Subschema"
|
||||
by * read
|
||||
|
||||
# Provide access to the realm container.
|
||||
access to dn.subtree= "cn=EXAMPLE.COM,cn=krbcontainer,dc=example,dc=com"
|
||||
by dn.exact="cn=kdc-service,dc=example,dc=com" write
|
||||
by dn.exact="cn=adm-service,dc=example,dc=com" write
|
||||
by * none
|
||||
|
||||
# Provide access to principals, if not underneath the realm container.
|
||||
access to dn.subtree= "ou=users,dc=example,dc=com"
|
||||
by dn.exact="cn=kdc-service,dc=example,dc=com" write
|
||||
by dn.exact="cn=adm-service,dc=example,dc=com" write
|
||||
by * none
|
||||
|
||||
access to *
|
||||
by * read
|
||||
|
||||
If the locations of the container and principals or the DNs of the
|
||||
service objects for a realm are changed then this information
|
||||
should be updated.
|
||||
|
||||
7. In :ref:`kdc.conf(5)`, make sure the following relations are set
|
||||
in the :ref:`dbmodules` subsection for the realm::
|
||||
|
||||
db_library (set to ``kldap``)
|
||||
ldap_kerberos_container_dn
|
||||
ldap_kdc_dn
|
||||
ldap_kadmind_dn
|
||||
ldap_service_password_file
|
||||
ldap_servers
|
||||
|
||||
8. Create the realm using :ref:`kdb5_ldap_util(8)`:
|
||||
|
||||
kdb5_ldap_util create -subtrees ou=users,dc=example,dc=com -s
|
||||
|
||||
Use the **-subtrees** option if the principals are to exist in a
|
||||
separate subtree from the realm container. Before executing the
|
||||
command, make sure that the subtree mentioned above
|
||||
``(ou=users,dc=example,dc=com)`` exists. If the principals will
|
||||
exist underneath the realm container, omit the **-subtrees** option
|
||||
and do not worry about creating the principal subtree.
|
||||
|
||||
For more information, refer to the section :ref:`ops_on_ldap`.
|
||||
|
||||
The realm object is created under the
|
||||
**ldap_kerberos_container_dn** specified in the configuration
|
||||
file. This operation will also create the Kerberos container, if
|
||||
not present already. This container can be used to store
|
||||
information related to multiple realms.
|
||||
|
||||
9. Add an ``eq`` index for ``krbPrincipalName`` to speed up principal
|
||||
lookup operations. See
|
||||
https://www.openldap.org/doc/admin/tuning.html#Indexes for
|
||||
details.
|
||||
|
||||
With the LDAP back end it is possible to provide aliases for principal
|
||||
entries. Currently we provide no administrative utilities for
|
||||
creating aliases, so it must be done by direct manipulation of the
|
||||
LDAP entries.
|
||||
|
||||
An entry with aliases contains multiple values of the
|
||||
*krbPrincipalName* attribute. Since LDAP attribute values are not
|
||||
ordered, it is necessary to specify which principal name is canonical,
|
||||
by using the *krbCanonicalName* attribute. Therefore, to create
|
||||
aliases for an entry, first set the *krbCanonicalName* attribute of
|
||||
the entry to the canonical principal name (which should be identical
|
||||
to the pre-existing *krbPrincipalName* value), and then add additional
|
||||
*krbPrincipalName* attributes for the aliases.
|
||||
|
||||
Principal aliases are only returned by the KDC when the client
|
||||
requests canonicalization. Canonicalization is normally requested for
|
||||
service principals; for client principals, an explicit flag is often
|
||||
required (e.g., ``kinit -C``) and canonicalization is only performed
|
||||
for initial ticket requests.
|
||||
587
crypto/krb5/doc/admin/database.rst
Normal file
587
crypto/krb5/doc/admin/database.rst
Normal file
|
|
@ -0,0 +1,587 @@
|
|||
Database administration
|
||||
=======================
|
||||
|
||||
A Kerberos database contains all of a realm's Kerberos principals,
|
||||
their passwords, and other administrative information about each
|
||||
principal. For the most part, you will use the :ref:`kdb5_util(8)`
|
||||
program to manipulate the Kerberos database as a whole, and the
|
||||
:ref:`kadmin(1)` program to make changes to the entries in the
|
||||
database. (One notable exception is that users will use the
|
||||
:ref:`kpasswd(1)` program to change their own passwords.) The kadmin
|
||||
program has its own command-line interface, to which you type the
|
||||
database administrating commands.
|
||||
|
||||
:ref:`kdb5_util(8)` provides a means to create, delete, load, or dump
|
||||
a Kerberos database. It also contains commands to roll over the
|
||||
database master key, and to stash a copy of the key so that the
|
||||
:ref:`kadmind(8)` and :ref:`krb5kdc(8)` daemons can use the database
|
||||
without manual input.
|
||||
|
||||
:ref:`kadmin(1)` provides for the maintenance of Kerberos principals,
|
||||
password policies, and service key tables (keytabs). Normally it
|
||||
operates as a network client using Kerberos authentication to
|
||||
communicate with :ref:`kadmind(8)`, but there is also a variant, named
|
||||
kadmin.local, which directly accesses the Kerberos database on the
|
||||
local filesystem (or through LDAP). kadmin.local is necessary to set
|
||||
up enough of the database to be able to use the remote version.
|
||||
|
||||
kadmin can authenticate to the admin server using the service
|
||||
principal ``kadmin/admin`` or ``kadmin/HOST`` (where *HOST* is the
|
||||
hostname of the admin server). If the credentials cache contains a
|
||||
ticket for either service principal and the **-c** ccache option is
|
||||
specified, that ticket is used to authenticate to KADM5. Otherwise,
|
||||
the **-p** and **-k** options are used to specify the client Kerberos
|
||||
principal name used to authenticate. Once kadmin has determined the
|
||||
principal name, it requests a ``kadmin/admin`` Kerberos service ticket
|
||||
from the KDC, and uses that service ticket to authenticate to KADM5.
|
||||
|
||||
See :ref:`kadmin(1)` for the available kadmin and kadmin.local
|
||||
commands and options.
|
||||
|
||||
|
||||
.. _principals:
|
||||
|
||||
Principals
|
||||
----------
|
||||
|
||||
Each entry in the Kerberos database contains a Kerberos principal and
|
||||
the attributes and policies associated with that principal.
|
||||
|
||||
To add a principal to the database, use the :ref:`kadmin(1)`
|
||||
**add_principal** command. User principals should usually be created
|
||||
with the ``+requires_preauth -allow_svr`` options to help mitigate
|
||||
dictionary attacks (see :ref:`dictionary`)::
|
||||
|
||||
kadmin: addprinc +requires_preauth -allow_svr alice
|
||||
Enter password for principal "alice@KRBTEST.COM":
|
||||
Re-enter password for principal "alice@KRBTEST.COM":
|
||||
|
||||
User principals which will authenticate with :ref:`pkinit` should
|
||||
instead by created with the ``-nokey`` option:
|
||||
|
||||
kadmin: addprinc -nokey alice
|
||||
|
||||
Service principals can be created with the ``-nokey`` option;
|
||||
long-term keys will be added when a keytab is generated::
|
||||
|
||||
kadmin: addprinc -nokey host/foo.mit.edu
|
||||
kadmin: ktadd -k foo.keytab host/foo.mit.edu
|
||||
Entry for principal host/foo.mit.edu with kvno 1, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:foo.keytab.
|
||||
Entry for principal host/foo.mit.edu with kvno 1, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:foo.keytab.
|
||||
|
||||
To modify attributes of an existing principal, use the kadmin
|
||||
**modify_principal** command::
|
||||
|
||||
kadmin: modprinc -expire tomorrow alice
|
||||
Principal "alice@KRBTEST.COM" modified.
|
||||
|
||||
To delete a principal, use the kadmin **delete_principal** command::
|
||||
|
||||
kadmin: delprinc alice
|
||||
Are you sure you want to delete the principal "alice@KRBTEST.COM"? (yes/no): yes
|
||||
Principal "alice@KRBTEST.COM" deleted.
|
||||
Make sure that you have removed this principal from all ACLs before reusing.
|
||||
|
||||
To change a principal's password, use the kadmin **change_password**
|
||||
command. Password changes made through kadmin are subject to the same
|
||||
password policies as would apply to password changes made through
|
||||
:ref:`kpasswd(1)`.
|
||||
|
||||
To view the attributes of a principal, use the kadmin`
|
||||
**get_principal** command.
|
||||
|
||||
To generate a listing of principals, use the kadmin
|
||||
**list_principals** command.
|
||||
|
||||
|
||||
.. _policies:
|
||||
|
||||
Policies
|
||||
--------
|
||||
|
||||
A policy is a set of rules governing passwords. Policies can dictate
|
||||
minimum and maximum password lifetimes, minimum number of characters
|
||||
and character classes a password must contain, and the number of old
|
||||
passwords kept in the database.
|
||||
|
||||
To add a new policy, use the :ref:`kadmin(1)` **add_policy** command::
|
||||
|
||||
kadmin: addpol -maxlife "1 year" -history 3 stduser
|
||||
|
||||
To modify attributes of a principal, use the kadmin **modify_policy**
|
||||
command. To delete a policy, use the kadmin **delete_policy**
|
||||
command.
|
||||
|
||||
To associate a policy with a principal, use the kadmin
|
||||
**modify_principal** command with the **-policy** option:
|
||||
|
||||
kadmin: modprinc -policy stduser alice
|
||||
Principal "alice@KRBTEST.COM" modified.
|
||||
|
||||
A principal entry may be associated with a nonexistent policy, either
|
||||
because the policy did not exist at the time of associated or was
|
||||
deleted afterwards. kadmin will warn when associated a principal with
|
||||
a nonexistent policy, and will annotate the policy name with "[does
|
||||
not exist]" in the **get_principal** output.
|
||||
|
||||
|
||||
.. _updating_history_key:
|
||||
|
||||
Updating the history key
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If a policy specifies a number of old keys kept of two or more, the
|
||||
stored old keys are encrypted in a history key, which is found in the
|
||||
key data of the ``kadmin/history`` principal.
|
||||
|
||||
Currently there is no support for proper rollover of the history key,
|
||||
but you can change the history key (for example, to use a better
|
||||
encryption type) at the cost of invalidating currently stored old
|
||||
keys. To change the history key, run::
|
||||
|
||||
kadmin: change_password -randkey kadmin/history
|
||||
|
||||
This command will fail if you specify the **-keepold** flag. Only one
|
||||
new history key will be created, even if you specify multiple key/salt
|
||||
combinations.
|
||||
|
||||
In the future, we plan to migrate towards encrypting old keys in the
|
||||
master key instead of the history key, and implementing proper
|
||||
rollover support for stored old keys.
|
||||
|
||||
|
||||
.. _privileges:
|
||||
|
||||
Privileges
|
||||
----------
|
||||
|
||||
Administrative privileges for the Kerberos database are stored in the
|
||||
file :ref:`kadm5.acl(5)`.
|
||||
|
||||
.. note::
|
||||
|
||||
A common use of an admin instance is so you can grant
|
||||
separate permissions (such as administrator access to the
|
||||
Kerberos database) to a separate Kerberos principal. For
|
||||
example, the user ``joeadmin`` might have a principal for
|
||||
his administrative use, called ``joeadmin/admin``. This
|
||||
way, ``joeadmin`` would obtain ``joeadmin/admin`` tickets
|
||||
only when he actually needs to use those permissions.
|
||||
|
||||
|
||||
.. _db_operations:
|
||||
|
||||
Operations on the Kerberos database
|
||||
-----------------------------------
|
||||
|
||||
The :ref:`kdb5_util(8)` command is the primary tool for administrating
|
||||
the Kerberos database when using the DB2 or LMDB modules (see
|
||||
:ref:`dbtypes`). Creating a database is described in
|
||||
:ref:`create_db`.
|
||||
|
||||
To create a stash file using the master password (because the database
|
||||
was not created with one using the ``create -s`` flag, or after
|
||||
restoring from a backup which did not contain the stash file), use the
|
||||
kdb5_util **stash** command::
|
||||
|
||||
$ kdb5_util stash
|
||||
kdb5_util: Cannot find/read stored master key while reading master key
|
||||
kdb5_util: Warning: proceeding without master key
|
||||
Enter KDC database master key: <= Type the KDC database master password.
|
||||
|
||||
To destroy a database, use the kdb5_util destroy command::
|
||||
|
||||
$ kdb5_util destroy
|
||||
Deleting KDC database stored in '/var/krb5kdc/principal', are you sure?
|
||||
(type 'yes' to confirm)? yes
|
||||
OK, deleting database '/var/krb5kdc/principal'...
|
||||
** Database '/var/krb5kdc/principal' destroyed.
|
||||
|
||||
|
||||
.. _restore_from_dump:
|
||||
|
||||
Dumping and loading a Kerberos database
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To dump a Kerberos database into a text file for backup or transfer
|
||||
purposes, use the :ref:`kdb5_util(8)` **dump** command on one of the
|
||||
KDCs::
|
||||
|
||||
$ kdb5_util dump dumpfile
|
||||
|
||||
$ kbd5_util dump -verbose dumpfile
|
||||
kadmin/admin@ATHENA.MIT.EDU
|
||||
krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
|
||||
kadmin/history@ATHENA.MIT.EDU
|
||||
K/M@ATHENA.MIT.EDU
|
||||
kadmin/changepw@ATHENA.MIT.EDU
|
||||
|
||||
You may specify which principals to dump, using full principal names
|
||||
including realm::
|
||||
|
||||
$ kdb5_util dump -verbose someprincs K/M@ATHENA.MIT.EDU kadmin/admin@ATHENA.MIT.EDU
|
||||
kadmin/admin@ATHENA.MIT.EDU
|
||||
K/M@ATHENA.MIT.EDU
|
||||
|
||||
To restore a Kerberos database dump from a file, use the
|
||||
:ref:`kdb5_util(8)` **load** command::
|
||||
|
||||
$ kdb5_util load dumpfile
|
||||
|
||||
To update an existing database with a partial dump file containing
|
||||
only some principals, use the ``-update`` flag::
|
||||
|
||||
$ kdb5_util load -update someprincs
|
||||
|
||||
.. note::
|
||||
|
||||
If the database file exists, and the *-update* flag was not
|
||||
given, *kdb5_util* will overwrite the existing database.
|
||||
|
||||
|
||||
.. _updating_master_key:
|
||||
|
||||
Updating the master key
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Starting with release 1.7, :ref:`kdb5_util(8)` allows the master key
|
||||
to be changed using a rollover process, with minimal loss of
|
||||
availability. To roll over the master key, follow these steps:
|
||||
|
||||
#. On the primary KDC, run ``kdb5_util list_mkeys`` to view the
|
||||
current master key version number (KVNO). If you have never rolled
|
||||
over the master key before, this will likely be version 1::
|
||||
|
||||
$ kdb5_util list_mkeys
|
||||
Master keys for Principal: K/M@KRBTEST.COM
|
||||
KVNO: 1, Enctype: aes256-cts-hmac-sha384-192, Active on: Thu Jan 01 00:00:00 UTC 1970 *
|
||||
|
||||
#. On the primary KDC, run ``kdb5_util use_mkey 1`` to ensure that a
|
||||
master key activation list is present in the database. This step
|
||||
is unnecessary in release 1.11.4 or later, or if the database was
|
||||
initially created with release 1.7 or later.
|
||||
|
||||
#. On the primary KDC, run ``kdb5_util add_mkey -s`` to create a new
|
||||
master key and write it to the stash file. Enter a secure password
|
||||
when prompted. If this is the first time you are changing the
|
||||
master key, the new key will have version 2. The new master key
|
||||
will not be used until you make it active.
|
||||
|
||||
#. Propagate the database to all replica KDCs, either manually or by
|
||||
waiting until the next scheduled propagation. If you do not have
|
||||
any replica KDCs, you can skip this and the next step.
|
||||
|
||||
#. On each replica KDC, run ``kdb5_util list_mkeys`` to verify that
|
||||
the new master key is present, and then ``kdb5_util stash`` to
|
||||
write the new master key to the replica KDC's stash file.
|
||||
|
||||
#. On the primary KDC, run ``kdb5_util use_mkey 2`` to begin using the
|
||||
new master key. Replace ``2`` with the version of the new master
|
||||
key, as appropriate. You can optionally specify a date for the new
|
||||
master key to become active; by default, it will become active
|
||||
immediately. Prior to release 1.12, :ref:`kadmind(8)` must be
|
||||
restarted for this change to take full effect.
|
||||
|
||||
#. On the primary KDC, run ``kdb5_util update_princ_encryption``.
|
||||
This command will iterate over the database and re-encrypt all keys
|
||||
in the new master key. If the database is large and uses DB2, the
|
||||
primary KDC will become unavailable while this command runs, but
|
||||
clients should fail over to replica KDCs (if any are present)
|
||||
during this time period. In release 1.13 and later, you can
|
||||
instead run ``kdb5_util -x unlockiter update_princ_encryption`` to
|
||||
use unlocked iteration; this variant will take longer, but will
|
||||
keep the database available to the KDC and kadmind while it runs.
|
||||
|
||||
#. Wait until the above changes have propagated to all replica KDCs
|
||||
and until all running KDC and kadmind processes have serviced
|
||||
requests using updated principal entries.
|
||||
|
||||
#. On the primary KDC, run ``kdb5_util purge_mkeys`` to clean up the
|
||||
old master key.
|
||||
|
||||
|
||||
.. _ops_on_ldap:
|
||||
|
||||
Operations on the LDAP database
|
||||
-------------------------------
|
||||
|
||||
The :ref:`kdb5_ldap_util(8)` command is the primary tool for
|
||||
administrating the Kerberos database when using the LDAP module.
|
||||
Creating an LDAP Kerberos database is describe in :ref:`conf_ldap`.
|
||||
|
||||
To view a list of realms in the LDAP database, use the kdb5_ldap_util
|
||||
**list** command::
|
||||
|
||||
$ kdb5_ldap_util list
|
||||
KRBTEST.COM
|
||||
|
||||
To modify the attributes of a realm, use the kdb5_ldap_util **modify**
|
||||
command. For example, to change the default realm's maximum ticket
|
||||
life::
|
||||
|
||||
$ kdb5_ldap_util modify -maxtktlife "10 hours"
|
||||
|
||||
To display the attributes of a realm, use the kdb5_ldap_util **view**
|
||||
command::
|
||||
|
||||
$ kdb5_ldap_util view
|
||||
Realm Name: KRBTEST.COM
|
||||
Maximum Ticket Life: 0 days 00:10:00
|
||||
|
||||
To remove a realm from the LDAP database, destroying its contents, use
|
||||
the kdb5_ldap_util **destroy** command::
|
||||
|
||||
$ kdb5_ldap_util destroy
|
||||
Deleting KDC database of 'KRBTEST.COM', are you sure?
|
||||
(type 'yes' to confirm)? yes
|
||||
OK, deleting database of 'KRBTEST.COM'...
|
||||
** Database of 'KRBTEST.COM' destroyed.
|
||||
|
||||
|
||||
Ticket Policy operations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Unlike the DB2 and LMDB modules, the LDAP module supports ticket
|
||||
policy objects, which can be associated with principals to restrict
|
||||
maximum ticket lifetimes and set mandatory principal flags. Ticket
|
||||
policy objects are distinct from the password policies described
|
||||
earlier on this page, and are chiefly managed through kdb5_ldap_util
|
||||
rather than kadmin. To create a new ticket policy, use the
|
||||
kdb5_ldap_util **create_policy** command::
|
||||
|
||||
$ kdb5_ldap_util create_policy -maxrenewlife "2 days" users
|
||||
|
||||
To associate a ticket policy with a principal, use the
|
||||
:ref:`kadmin(1)` **modify_principal** (or **add_principal**) command
|
||||
with the **-x tktpolicy=**\ *policy* option::
|
||||
|
||||
$ kadmin.local modprinc -x tktpolicy=users alice
|
||||
|
||||
To remove a ticket policy reference from a principal, use the same
|
||||
command with an empty *policy*::
|
||||
|
||||
$ kadmin.local modprinc -x tktpolicy= alice
|
||||
|
||||
To list the existing ticket policy objects, use the kdb5_ldap_util
|
||||
**list_policy** command::
|
||||
|
||||
$ kdb5_ldap_util list_policy
|
||||
users
|
||||
|
||||
To modify the attributes of a ticket policy object, use the
|
||||
kdb5_ldap_util **modify_policy** command::
|
||||
|
||||
$ kdb5_ldap_util modify_policy -allow_svr +requires_preauth users
|
||||
|
||||
To view the attributes of a ticket policy object, use the
|
||||
kdb5_ldap_util **view_policy** command::
|
||||
|
||||
$ kdb5_ldap_util view_policy users
|
||||
Ticket policy: users
|
||||
Maximum renewable life: 2 days 00:00:00
|
||||
Ticket flags: REQUIRES_PRE_AUTH DISALLOW_SVR
|
||||
|
||||
To destroy an ticket policy object, use the kdb5_ldap_util
|
||||
**destroy_policy** command::
|
||||
|
||||
$ kdb5_ldap_util destroy_policy users
|
||||
This will delete the policy object 'users', are you sure?
|
||||
(type 'yes' to confirm)? yes
|
||||
** policy object 'users' deleted.
|
||||
|
||||
|
||||
.. _xrealm_authn:
|
||||
|
||||
Cross-realm authentication
|
||||
--------------------------
|
||||
|
||||
In order for a KDC in one realm to authenticate Kerberos users in a
|
||||
different realm, it must share a key with the KDC in the other realm.
|
||||
In both databases, there must be krbtgt service principals for both realms.
|
||||
For example, if you need to do cross-realm authentication between the realms
|
||||
``ATHENA.MIT.EDU`` and ``EXAMPLE.COM``, you would need to add the
|
||||
principals ``krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU`` and
|
||||
``krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM`` to both databases.
|
||||
These principals must all have the same passwords, key version
|
||||
numbers, and encryption types; this may require explicitly setting
|
||||
the key version number with the **-kvno** option.
|
||||
|
||||
In the ATHENA.MIT.EDU and EXAMPLE.COM cross-realm case, the administrators
|
||||
would run the following commands on the KDCs in both realms::
|
||||
|
||||
shell%: kadmin.local -e "aes256-cts:normal"
|
||||
kadmin: addprinc -requires_preauth krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM
|
||||
Enter password for principal krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM:
|
||||
Re-enter password for principal krbtgt/ATHENA.MIT.EDU@EXAMPLE.COM:
|
||||
kadmin: addprinc -requires_preauth krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU
|
||||
Enter password for principal krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU:
|
||||
Enter password for principal krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU:
|
||||
kadmin:
|
||||
|
||||
.. note::
|
||||
|
||||
Even if most principals in a realm are generally created
|
||||
with the **requires_preauth** flag enabled, this flag is not
|
||||
desirable on cross-realm authentication keys because doing
|
||||
so makes it impossible to disable preauthentication on a
|
||||
service-by-service basis. Disabling it as in the example
|
||||
above is recommended.
|
||||
|
||||
.. note::
|
||||
|
||||
It is very important that these principals have good
|
||||
passwords. MIT recommends that TGT principal passwords be
|
||||
at least 26 characters of random ASCII text.
|
||||
|
||||
|
||||
.. _changing_krbtgt_key:
|
||||
|
||||
Changing the krbtgt key
|
||||
-----------------------
|
||||
|
||||
A Kerberos Ticket Granting Ticket (TGT) is a service ticket for the
|
||||
principal ``krbtgt/REALM``. The key for this principal is created
|
||||
when the Kerberos database is initialized and need not be changed.
|
||||
However, it will only have the encryption types supported by the KDC
|
||||
at the time of the initial database creation. To allow use of newer
|
||||
encryption types for the TGT, this key has to be changed.
|
||||
|
||||
Changing this key using the normal :ref:`kadmin(1)`
|
||||
**change_password** command would invalidate any previously issued
|
||||
TGTs. Therefore, when changing this key, normally one should use the
|
||||
**-keepold** flag to change_password to retain the previous key in the
|
||||
database as well as the new key. For example::
|
||||
|
||||
kadmin: change_password -randkey -keepold krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
|
||||
|
||||
.. warning::
|
||||
|
||||
After issuing this command, the old key is still valid
|
||||
and is still vulnerable to (for instance) brute force
|
||||
attacks. To completely retire an old key or encryption
|
||||
type, run the kadmin **purgekeys** command to delete keys
|
||||
with older kvnos, ideally first making sure that all
|
||||
tickets issued with the old keys have expired.
|
||||
|
||||
Only the first krbtgt key of the newest key version is used to encrypt
|
||||
ticket-granting tickets. However, the set of encryption types present
|
||||
in the krbtgt keys is used by default to determine the session key
|
||||
types supported by the krbtgt service (see
|
||||
:ref:`session_key_selection`). Because non-MIT Kerberos clients
|
||||
sometimes send a limited set of encryption types when making AS
|
||||
requests, it can be important for the krbtgt service to support
|
||||
multiple encryption types. This can be accomplished by giving the
|
||||
krbtgt principal multiple keys, which is usually as simple as not
|
||||
specifying any **-e** option when changing the krbtgt key, or by
|
||||
setting the **session_enctypes** string attribute on the krbtgt
|
||||
principal (see :ref:`set_string`).
|
||||
|
||||
Due to a bug in releases 1.8 through 1.13, renewed and forwarded
|
||||
tickets may not work if the original ticket was obtained prior to a
|
||||
krbtgt key change and the modified ticket is obtained afterwards.
|
||||
Upgrading the KDC to release 1.14 or later will correct this bug.
|
||||
|
||||
|
||||
.. _incr_db_prop:
|
||||
|
||||
Incremental database propagation
|
||||
--------------------------------
|
||||
|
||||
Overview
|
||||
~~~~~~~~
|
||||
|
||||
At some very large sites, dumping and transmitting the database can
|
||||
take more time than is desirable for changes to propagate from the
|
||||
primary KDC to the replica KDCs. The incremental propagation support
|
||||
added in the 1.7 release is intended to address this.
|
||||
|
||||
With incremental propagation enabled, all programs on the primary KDC
|
||||
that change the database also write information about the changes to
|
||||
an "update log" file, maintained as a circular buffer of a certain
|
||||
size. A process on each replica KDC connects to a service on the
|
||||
primary KDC (currently implemented in the :ref:`kadmind(8)` server) and
|
||||
periodically requests the changes that have been made since the last
|
||||
check. By default, this check is done every two minutes.
|
||||
|
||||
Incremental propagation uses the following entries in the per-realm
|
||||
data in the KDC config file (See :ref:`kdc.conf(5)`):
|
||||
|
||||
====================== =============== ===========================================
|
||||
iprop_enable *boolean* If *true*, then incremental propagation is enabled, and (as noted below) normal kprop propagation is disabled. The default is *false*.
|
||||
iprop_master_ulogsize *integer* Indicates the number of entries that should be retained in the update log. The default is 1000; the maximum number is 2500.
|
||||
iprop_replica_poll *time interval* Indicates how often the replica should poll the primary KDC for changes to the database. The default is two minutes.
|
||||
iprop_port *integer* Specifies the port number to be used for incremental propagation. This is required in both primary and replica configuration files.
|
||||
iprop_resync_timeout *integer* Specifies the number of seconds to wait for a full propagation to complete. This is optional on replica configurations. Defaults to 300 seconds (5 minutes).
|
||||
iprop_logfile *file name* Specifies where the update log file for the realm database is to be stored. The default is to use the *database_name* entry from the realms section of the config file :ref:`kdc.conf(5)`, with *.ulog* appended. (NOTE: If database_name isn't specified in the realms section, perhaps because the LDAP database back end is being used, or the file name is specified in the *dbmodules* section, then the hard-coded default for *database_name* is used. Determination of the *iprop_logfile* default value will not use values from the *dbmodules* section.)
|
||||
====================== =============== ===========================================
|
||||
|
||||
Both primary and replica sides must have a principal named
|
||||
``kiprop/hostname`` (where *hostname* is the lowercase,
|
||||
fully-qualified, canonical name for the host) registered in the
|
||||
Kerberos database, and have keys for that principal stored in the
|
||||
default keytab file (|keytab|). The ``kiprop/hostname`` principal may
|
||||
have been created automatically for the primary KDC, but it must
|
||||
always be created for replica KDCs.
|
||||
|
||||
On the primary KDC side, the ``kiprop/hostname`` principal must be
|
||||
listed in the kadmind ACL file :ref:`kadm5.acl(5)`, and given the
|
||||
**p** privilege (see :ref:`privileges`).
|
||||
|
||||
On the replica KDC side, :ref:`kpropd(8)` should be run. When
|
||||
incremental propagation is enabled, it will connect to the kadmind on
|
||||
the primary KDC and start requesting updates.
|
||||
|
||||
The normal kprop mechanism is disabled by the incremental propagation
|
||||
support. However, if the replica has been unable to fetch changes
|
||||
from the primary KDC for too long (network problems, perhaps), the log
|
||||
on the primary may wrap around and overwrite some of the updates that
|
||||
the replica has not yet retrieved. In this case, the replica will
|
||||
instruct the primary KDC to dump the current database out to a file
|
||||
and invoke a one-time kprop propagation, with special options to also
|
||||
convey the point in the update log at which the replica should resume
|
||||
fetching incremental updates. Thus, all the keytab and ACL setup
|
||||
previously described for kprop propagation is still needed.
|
||||
|
||||
If an environment has a large number of replicas, it may be desirable
|
||||
to arrange them in a hierarchy instead of having the primary serve
|
||||
updates to every replica. To do this, run ``kadmind -proponly`` on
|
||||
each intermediate replica, and ``kpropd -A upstreamhostname`` on
|
||||
downstream replicas to direct each one to the appropriate upstream
|
||||
replica.
|
||||
|
||||
There are several known restrictions in the current implementation:
|
||||
|
||||
- The incremental update protocol does not transport changes to policy
|
||||
objects. Any policy changes on the primary will result in full
|
||||
resyncs to all replicas.
|
||||
- The replica's KDB module must support locking; it cannot be using the
|
||||
LDAP KDB module.
|
||||
- The primary and replica must be able to initiate TCP connections in
|
||||
both directions, without an intervening NAT.
|
||||
|
||||
|
||||
Sun/MIT incremental propagation differences
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Sun donated the original code for supporting incremental database
|
||||
propagation to MIT. Some changes have been made in the MIT source
|
||||
tree that will be visible to administrators. (These notes are based
|
||||
on Sun's patches. Changes to Sun's implementation since then may not
|
||||
be reflected here.)
|
||||
|
||||
The Sun config file support looks for ``sunw_dbprop_enable``,
|
||||
``sunw_dbprop_master_ulogsize``, and ``sunw_dbprop_slave_poll``.
|
||||
|
||||
The incremental propagation service is implemented as an ONC RPC
|
||||
service. In the Sun implementation, the service is registered with
|
||||
rpcbind (also known as portmapper) and the client looks up the port
|
||||
number to contact. In the MIT implementation, where interaction with
|
||||
some modern versions of rpcbind doesn't always work well, the port
|
||||
number must be specified in the config file on both the primary and
|
||||
replica sides.
|
||||
|
||||
The Sun implementation hard-codes pathnames in ``/var/krb5`` for the
|
||||
update log and the per-replica kprop dump files. In the MIT
|
||||
implementation, the pathname for the update log is specified in the
|
||||
config file, and the per-replica dump files are stored in
|
||||
|kdcdir|\ ``/replica_datatrans_hostname``.
|
||||
149
crypto/krb5/doc/admin/dbtypes.rst
Normal file
149
crypto/krb5/doc/admin/dbtypes.rst
Normal file
|
|
@ -0,0 +1,149 @@
|
|||
.. _dbtypes:
|
||||
|
||||
Database types
|
||||
==============
|
||||
|
||||
A Kerberos database can be implemented with one of three built-in
|
||||
database providers, called KDB modules. Software which incorporates
|
||||
the MIT krb5 KDC may also provide its own KDB module. The following
|
||||
subsections describe the three built-in KDB modules and the
|
||||
configuration specific to them.
|
||||
|
||||
The database type can be configured with the **db_library** variable
|
||||
in the :ref:`dbmodules` subsection for the realm. For example::
|
||||
|
||||
[dbmodules]
|
||||
ATHENA.MIT.EDU = {
|
||||
db_library = db2
|
||||
}
|
||||
|
||||
If the ``ATHENA.MIT.EDU`` realm subsection contains a
|
||||
**database_module** setting, then the subsection within
|
||||
``[dbmodules]`` should use that name instead of ``ATHENA.MIT.EDU``.
|
||||
|
||||
To transition from one database type to another, stop the
|
||||
:ref:`kadmind(8)` service, use ``kdb5_util dump`` to create a dump
|
||||
file, change the **db_library** value and set any appropriate
|
||||
configuration for the new database type, and use ``kdb5_util load`` to
|
||||
create and populate the new database. If the new database type is
|
||||
LDAP, create the new database using ``kdb5_ldap_util`` and populate it
|
||||
from the dump file using ``kdb5_util load -update``. Then restart the
|
||||
:ref:`krb5kdc(8)` and :ref:`kadmind(8)` services.
|
||||
|
||||
|
||||
Berkeley database module (db2)
|
||||
------------------------------
|
||||
|
||||
The default KDB module is ``db2``, which uses a version of the
|
||||
Berkeley DB library. It creates four files based on the database
|
||||
pathname. If the pathname ends with ``principal`` then the four files
|
||||
are:
|
||||
|
||||
* ``principal``, containing principal entry data
|
||||
* ``principal.ok``, a lock file for the principal database
|
||||
* ``principal.kadm5``, containing policy object data
|
||||
* ``principal.kadm5.lock``, a lock file for the policy database
|
||||
|
||||
For large databases, the :ref:`kdb5_util(8)` **dump** command (perhaps
|
||||
invoked by :ref:`kprop(8)` or by :ref:`kadmind(8)` for incremental
|
||||
propagation) may cause :ref:`krb5kdc(8)` to stop for a noticeable
|
||||
period of time while it iterates over the database. This delay can be
|
||||
avoided by disabling account lockout features so that the KDC does not
|
||||
perform database writes (see :ref:`disable_lockout`). Alternatively,
|
||||
a slower form of iteration can be enabled by setting the
|
||||
**unlockiter** variable to ``true``. For example::
|
||||
|
||||
[dbmodules]
|
||||
ATHENA.MIT.EDU = {
|
||||
db_library = db2
|
||||
unlockiter = true
|
||||
}
|
||||
|
||||
In rare cases, a power failure or other unclean system shutdown may
|
||||
cause inconsistencies in the internal pointers within a database file,
|
||||
such that ``kdb5_util dump`` cannot retrieve all principal entries in
|
||||
the database. In this situation, it may be possible to retrieve all
|
||||
of the principal data by running ``kdb5_util dump -recurse`` to
|
||||
iterate over the database using the tree pointers instead of the
|
||||
iteration pointers. Running ``kdb5_util dump -rev`` to iterate over
|
||||
the database backwards may also retrieve some of the data which is not
|
||||
retrieved by a normal dump operation.
|
||||
|
||||
|
||||
Lightning Memory-Mapped Database module (klmdb)
|
||||
-----------------------------------------------
|
||||
|
||||
The klmdb module was added in release 1.17. It uses the LMDB library,
|
||||
and may offer better performance and reliability than the db2 module.
|
||||
It creates four files based on the database pathname. If the pathname
|
||||
ends with ``principal``, then the four files are:
|
||||
|
||||
* ``principal.mdb``, containing policy object data and most principal
|
||||
entry data
|
||||
* ``principal.mdb-lock``, a lock file for the primary database
|
||||
* ``principal.lockout.mdb``, containing the account lockout attributes
|
||||
(last successful authentication time, last failed authentication
|
||||
time, and number of failed attempts) for each principal entry
|
||||
* ``principal.lockout.mdb-lock``, a lock file for the lockout database
|
||||
|
||||
Separating out the lockout attributes ensures that the KDC will never
|
||||
block on an administrative operation such as a database dump or load.
|
||||
It also allows the KDC to operate without write access to the primary
|
||||
database. If both account lockout features are disabled (see
|
||||
:ref:`disable_lockout`), the lockout database files will be created
|
||||
but will not subsequently be opened, and the account lockout
|
||||
attributes will always have zero values.
|
||||
|
||||
Because LMDB creates a memory map to the database files, it requires a
|
||||
configured memory map size which also determines the maximum size of
|
||||
the database. This size is applied equally to the two databases, so
|
||||
twice the configured size will be consumed in the process address
|
||||
space; this is primarily a limitation on 32-bit platforms. The
|
||||
default value of 128 megabytes should be sufficient for several
|
||||
hundred thousand principal entries. If the limit is reached, kadmin
|
||||
operations will fail and the error message "Environment mapsize limit
|
||||
reached" will appear in the kadmind log file. In this case, the
|
||||
**mapsize** variable can be used to increase the map size. The
|
||||
following example sets the map size to 512 megabytes::
|
||||
|
||||
[dbmodules]
|
||||
ATHENA.MIT.EDU = {
|
||||
db_library = klmdb
|
||||
mapsize = 512
|
||||
}
|
||||
|
||||
LMDB has a configurable maximum number of readers. The default value
|
||||
of 128 should be sufficient for most deployments. If you are going to
|
||||
use a large number of KDC worker processes, it may be necessary to set
|
||||
the **max_readers** variable to a larger number.
|
||||
|
||||
By default, LMDB synchronizes database files to disk after each write
|
||||
transaction to ensure durability in the case of an unclean system
|
||||
shutdown. The klmdb module always turns synchronization off for the
|
||||
lockout database to ensure reasonable KDC performance, but leaves it
|
||||
on for the primary database. If high throughput for administrative
|
||||
operations (including password changes) is required, the **nosync**
|
||||
variable can be set to "true" to disable synchronization for the
|
||||
primary database.
|
||||
|
||||
The klmdb module does not support explicit locking with the
|
||||
:ref:`kadmin(1)` **lock** command.
|
||||
|
||||
|
||||
LDAP module (kldap)
|
||||
-------------------
|
||||
|
||||
The kldap module stores principal and policy data using an LDAP
|
||||
server. To use it you must configure an LDAP server to use the
|
||||
Kerberos schema. See :ref:`conf_ldap` for details.
|
||||
|
||||
Because :ref:`krb5kdc(8)` is single-threaded, latency in LDAP database
|
||||
accesses may limit KDC operation throughput. If the LDAP server is
|
||||
located on the same server host as the KDC and accessed through an
|
||||
``ldapi://`` URL, latency should be minimal. If this is not possible,
|
||||
consider starting multiple KDC worker processes with the
|
||||
:ref:`krb5kdc(8)` **-w** option to enable concurrent processing of KDC
|
||||
requests.
|
||||
|
||||
The kldap module does not support explicit locking with the
|
||||
:ref:`kadmin(1)` **lock** command.
|
||||
88
crypto/krb5/doc/admin/dictionary.rst
Normal file
88
crypto/krb5/doc/admin/dictionary.rst
Normal file
|
|
@ -0,0 +1,88 @@
|
|||
.. _dictionary:
|
||||
|
||||
Addressing dictionary attack risks
|
||||
==================================
|
||||
|
||||
Kerberos initial authentication is normally secured using the client
|
||||
principal's long-term key, which for users is generally derived from a
|
||||
password. Using a pasword-derived long-term key carries the risk of a
|
||||
dictionary attack, where an attacker tries a sequence of possible
|
||||
passwords, possibly requiring much less effort than would be required
|
||||
to try all possible values of the key. Even if :ref:`password policy
|
||||
objects <policies>` are used to force users not to pick trivial
|
||||
passwords, dictionary attacks can sometimes be successful against a
|
||||
significant fraction of the users in a realm. Dictionary attacks are
|
||||
not a concern for principals using random keys.
|
||||
|
||||
A dictionary attack may be online or offline. An online dictionary
|
||||
attack is performed by trying each password in a separate request to
|
||||
the KDC, and is therefore visible to the KDC and also limited in speed
|
||||
by the KDC's processing power and the network capacity between the
|
||||
client and the KDC. Online dictionary attacks can be mitigated using
|
||||
:ref:`account lockout <lockout>`. This measure is not totally
|
||||
satisfactory, as it makes it easy for an attacker to deny access to a
|
||||
client principal.
|
||||
|
||||
An offline dictionary attack is performed by obtaining a ciphertext
|
||||
generated using the password-derived key, and trying each password
|
||||
against the ciphertext. This category of attack is invisible to the
|
||||
KDC and can be performed much faster than an online attack. The
|
||||
attack will generally take much longer with more recent encryption
|
||||
types (particularly the ones based on AES), because those encryption
|
||||
types use a much more expensive string-to-key function. However, the
|
||||
best defense is to deny the attacker access to a useful ciphertext.
|
||||
The required defensive measures depend on the attacker's level of
|
||||
network access.
|
||||
|
||||
An off-path attacker has no access to packets sent between legitimate
|
||||
users and the KDC. An off-path attacker could gain access to an
|
||||
attackable ciphertext either by making an AS request for a client
|
||||
principal which does not have the **+requires_preauth** flag, or by
|
||||
making a TGS request (after authenticating as a different user) for a
|
||||
server principal which does not have the **-allow_svr** flag. To
|
||||
address off-path attackers, a KDC administrator should set those flags
|
||||
on principals with password-derived keys::
|
||||
|
||||
kadmin: add_principal +requires_preauth -allow_svr princname
|
||||
|
||||
An attacker with passive network access (one who can monitor packets
|
||||
sent between legitimate users and the KDC, but cannot change them or
|
||||
insert their own packets) can gain access to an attackable ciphertext
|
||||
by observing an authentication by a user using the most common form of
|
||||
preauthentication, encrypted timestamp. Any of the following methods
|
||||
can prevent dictionary attacks by attackers with passive network
|
||||
access:
|
||||
|
||||
* Enabling :ref:`SPAKE preauthentication <spake>` (added in release
|
||||
1.17) on the KDC, and ensuring that all clients are able to support
|
||||
it.
|
||||
|
||||
* Using an :ref:`HTTPS proxy <https>` for communication with the KDC,
|
||||
if the attacker cannot monitor communication between the proxy
|
||||
server and the KDC.
|
||||
|
||||
* Using FAST, protecting the initial authentication with either a
|
||||
random key (such as a host key) or with :ref:`anonymous PKINIT
|
||||
<anonymous_pkinit>`.
|
||||
|
||||
An attacker with active network access (one who can inject or modify
|
||||
packets sent between legitimate users and the KDC) can try to fool the
|
||||
client software into sending an attackable ciphertext using an
|
||||
encryption type and salt string of the attacker's choosing. Any of the
|
||||
following methods can prevent dictionary attacks by active attackers:
|
||||
|
||||
* Enabling SPAKE preauthentication and setting the
|
||||
**disable_encrypted_timestamp** variable to ``true`` in the
|
||||
:ref:`realms` subsection of the client configuration.
|
||||
|
||||
* Using an HTTPS proxy as described above, configured in the client's
|
||||
krb5.conf realm configuration. If :ref:`KDC discovery
|
||||
<kdc_discovery>` is used to locate a proxy server, an active
|
||||
attacker may be able to use DNS spoofing to cause the client to use
|
||||
a different HTTPS server or to not use HTTPS.
|
||||
|
||||
* Using FAST as described above.
|
||||
|
||||
If :ref:`PKINIT <pkinit>` or :ref:`OTP <otp_preauth>` are used for
|
||||
initial authentication, the principal's long-term keys are not used
|
||||
and dictionary attacks are usually not a concern.
|
||||
222
crypto/krb5/doc/admin/enctypes.rst
Normal file
222
crypto/krb5/doc/admin/enctypes.rst
Normal file
|
|
@ -0,0 +1,222 @@
|
|||
.. _enctypes:
|
||||
|
||||
Encryption types
|
||||
================
|
||||
|
||||
Kerberos can use a variety of cipher algorithms to protect data. A
|
||||
Kerberos **encryption type** (also known as an **enctype**) is a
|
||||
specific combination of a cipher algorithm with an integrity algorithm
|
||||
to provide both confidentiality and integrity to data.
|
||||
|
||||
|
||||
Enctypes in requests
|
||||
--------------------
|
||||
|
||||
Clients make two types of requests (KDC-REQ) to the KDC: AS-REQs and
|
||||
TGS-REQs. The client uses the AS-REQ to obtain initial tickets
|
||||
(typically a Ticket-Granting Ticket (TGT)), and uses the TGS-REQ to
|
||||
obtain service tickets.
|
||||
|
||||
The KDC uses three different keys when issuing a ticket to a client:
|
||||
|
||||
* The long-term key of the service: the KDC uses this to encrypt the
|
||||
actual service ticket. The KDC only uses the first long-term key in
|
||||
the most recent kvno for this purpose.
|
||||
|
||||
* The session key: the KDC randomly chooses this key and places one
|
||||
copy inside the ticket and the other copy inside the encrypted part
|
||||
of the reply.
|
||||
|
||||
* The reply-encrypting key: the KDC uses this to encrypt the reply it
|
||||
sends to the client. For AS replies, this is a long-term key of the
|
||||
client principal. For TGS replies, this is either the session key of the
|
||||
authenticating ticket, or a subsession key.
|
||||
|
||||
Each of these keys is of a specific enctype.
|
||||
|
||||
Each request type allows the client to submit a list of enctypes that
|
||||
it is willing to accept. For the AS-REQ, this list affects both the
|
||||
session key selection and the reply-encrypting key selection. For the
|
||||
TGS-REQ, this list only affects the session key selection.
|
||||
|
||||
|
||||
.. _session_key_selection:
|
||||
|
||||
Session key selection
|
||||
---------------------
|
||||
|
||||
The KDC chooses the session key enctype by taking the intersection of
|
||||
its **permitted_enctypes** list, the list of long-term keys for the
|
||||
most recent kvno of the service, and the client's requested list of
|
||||
enctypes. Starting in krb5-1.21, all services are assumed to support
|
||||
aes256-cts-hmac-sha1-96; also, des3-cbc-sha1 and arcfour-hmac session
|
||||
keys will not be issued by default.
|
||||
|
||||
Starting in krb5-1.11, it is possible to set a string attribute on a
|
||||
service principal to control what session key enctypes the KDC may
|
||||
issue for service tickets for that principal, overriding the service's
|
||||
long-term keys and the assumption of aes256-cts-hmac-sha1-96 support.
|
||||
See :ref:`set_string` in :ref:`kadmin(1)` for details.
|
||||
|
||||
|
||||
Choosing enctypes for a service
|
||||
-------------------------------
|
||||
|
||||
Generally, a service should have a key of the strongest
|
||||
enctype that both it and the KDC support. If the KDC is running a
|
||||
release earlier than krb5-1.11, it is also useful to generate an
|
||||
additional key for each enctype that the service can support. The KDC
|
||||
will only use the first key in the list of long-term keys for encrypting
|
||||
the service ticket, but the additional long-term keys indicate the
|
||||
other enctypes that the service supports.
|
||||
|
||||
As noted above, starting with release krb5-1.11, there are additional
|
||||
configuration settings that control session key enctype selection
|
||||
independently of the set of long-term keys that the KDC has stored for
|
||||
a service principal.
|
||||
|
||||
|
||||
Configuration variables
|
||||
-----------------------
|
||||
|
||||
The following ``[libdefaults]`` settings in :ref:`krb5.conf(5)` will
|
||||
affect how enctypes are chosen.
|
||||
|
||||
**allow_weak_crypto**
|
||||
defaults to *false* starting with krb5-1.8. When *false*, removes
|
||||
weak enctypes from **permitted_enctypes**,
|
||||
**default_tkt_enctypes**, and **default_tgs_enctypes**. Do not
|
||||
set this to *true* unless the use of weak enctypes is an
|
||||
acceptable risk for your environment and the weak enctypes are
|
||||
required for backward compatibility.
|
||||
|
||||
**allow_des3**
|
||||
was added in release 1.21 and defaults to *false*. Unless this
|
||||
flag is set to *true*, the KDC will not issue tickets with
|
||||
des3-cbc-sha1 session keys. In a future release, this flag will
|
||||
control whether des3-cbc-sha1 is permitted in similar fashion to
|
||||
weak enctypes.
|
||||
|
||||
**allow_rc4**
|
||||
was added in release 1.21 and defaults to *false*. Unless this
|
||||
flag is set to *true*, the KDC will not issue tickets with
|
||||
arcfour-hmac session keys. In a future release, this flag will
|
||||
control whether arcfour-hmac is permitted in similar fashion to
|
||||
weak enctypes.
|
||||
|
||||
**permitted_enctypes**
|
||||
controls the set of enctypes that a service will permit for
|
||||
session keys and for ticket and authenticator encryption. The KDC
|
||||
and other programs that access the Kerberos database will ignore
|
||||
keys of non-permitted enctypes. Starting in release 1.18, this
|
||||
setting also acts as the default for **default_tkt_enctypes** and
|
||||
**default_tgs_enctypes**.
|
||||
|
||||
**default_tkt_enctypes**
|
||||
controls the default set of enctypes that the Kerberos client
|
||||
library requests when making an AS-REQ. Do not set this unless
|
||||
required for specific backward compatibility purposes; stale
|
||||
values of this setting can prevent clients from taking advantage
|
||||
of new stronger enctypes when the libraries are upgraded.
|
||||
|
||||
**default_tgs_enctypes**
|
||||
controls the default set of enctypes that the Kerberos client
|
||||
library requests when making a TGS-REQ. Do not set this unless
|
||||
required for specific backward compatibility purposes; stale
|
||||
values of this setting can prevent clients from taking advantage
|
||||
of new stronger enctypes when the libraries are upgraded.
|
||||
|
||||
The following per-realm setting in :ref:`kdc.conf(5)` affects the
|
||||
generation of long-term keys.
|
||||
|
||||
**supported_enctypes**
|
||||
controls the default set of enctype-salttype pairs that :ref:`kadmind(8)`
|
||||
will use for generating long-term keys, either randomly or from
|
||||
passwords
|
||||
|
||||
|
||||
Enctype compatibility
|
||||
---------------------
|
||||
|
||||
See :ref:`Encryption_types` for additional information about enctypes.
|
||||
|
||||
========================== ========== ======== =======
|
||||
enctype weak? krb5 Windows
|
||||
========================== ========== ======== =======
|
||||
des-cbc-crc weak <1.18 >=2000
|
||||
des-cbc-md4 weak <1.18 ?
|
||||
des-cbc-md5 weak <1.18 >=2000
|
||||
des3-cbc-sha1 deprecated >=1.1 none
|
||||
arcfour-hmac deprecated >=1.3 >=2000
|
||||
arcfour-hmac-exp weak >=1.3 >=2000
|
||||
aes128-cts-hmac-sha1-96 >=1.3 >=Vista
|
||||
aes256-cts-hmac-sha1-96 >=1.3 >=Vista
|
||||
aes128-cts-hmac-sha256-128 >=1.15 none
|
||||
aes256-cts-hmac-sha384-192 >=1.15 none
|
||||
camellia128-cts-cmac >=1.9 none
|
||||
camellia256-cts-cmac >=1.9 none
|
||||
========================== ========== ======== =======
|
||||
|
||||
krb5 releases 1.18 and later do not support single-DES. krb5 releases
|
||||
1.8 and later disable the single-DES enctypes by default. Microsoft
|
||||
Windows releases Windows 7 and later disable single-DES enctypes by
|
||||
default.
|
||||
|
||||
krb5 releases 1.17 and later flag deprecated encryption types
|
||||
(including ``des3-cbc-sha1`` and ``arcfour-hmac``) in KDC logs and
|
||||
kadmin output. krb5 release 1.19 issues a warning during initial
|
||||
authentication if ``des3-cbc-sha1`` is used. Future releases will
|
||||
disable ``des3-cbc-sha1`` by default and eventually remove support for
|
||||
it.
|
||||
|
||||
|
||||
Migrating away from older encryption types
|
||||
------------------------------------------
|
||||
|
||||
Administrator intervention may be required to migrate a realm away
|
||||
from legacy encryption types, especially if the realm was created
|
||||
using krb5 release 1.2 or earlier. This migration should be performed
|
||||
before upgrading to krb5 versions which disable or remove support for
|
||||
legacy encryption types.
|
||||
|
||||
If there is a **supported_enctypes** setting in :ref:`kdc.conf(5)` on
|
||||
the KDC, make sure that it does not include weak or deprecated
|
||||
encryption types. This will ensure that newly created keys do not use
|
||||
those encryption types by default.
|
||||
|
||||
Check the ``krbtgt/REALM`` principal using the :ref:`kadmin(1)`
|
||||
**getprinc** command. If it lists a weak or deprecated encryption
|
||||
type as the first key, it must be migrated using the procedure in
|
||||
:ref:`changing_krbtgt_key`.
|
||||
|
||||
Check the ``kadmin/history`` principal, which should have only one key
|
||||
entry. If it uses a weak or deprecated encryption type, it should be
|
||||
upgraded following the notes in :ref:`updating_history_key`.
|
||||
|
||||
Check the other kadmin principals: kadmin/changepw, kadmin/admin, and
|
||||
any kadmin/hostname principals that may exist. These principals can
|
||||
be upgraded with **change_password -randkey** in kadmin.
|
||||
|
||||
Check the ``K/M`` entry. If it uses a weak or deprecated encryption
|
||||
type, it should be upgraded following the procedure in
|
||||
:ref:`updating_master_key`.
|
||||
|
||||
User and service principals using legacy encryption types can be
|
||||
enumerated with the :ref:`kdb5_util(8)` **tabdump keyinfo** command.
|
||||
|
||||
Service principals can be migrated with a keytab rotation on the
|
||||
service host, which can be accomplished using the :ref:`k5srvutil(1)`
|
||||
**change** and **delold** commands. Allow enough time for existing
|
||||
tickets to expire between the change and delold operations.
|
||||
|
||||
User principals with password-based keys can be migrated with a
|
||||
password change. The realm administrator can set a password
|
||||
expiration date using the :ref:`kadmin(1)` **modify_principal
|
||||
-pwexpire** command to force a password change.
|
||||
|
||||
If a legacy encryption type has not yet been disabled by default in
|
||||
the version of krb5 running on the KDC, it can be disabled
|
||||
administratively with the **permitted_enctypes** variable. For
|
||||
example, setting **permitted_enctypes** to ``DEFAULT -des3 -rc4`` will
|
||||
cause any database keys of the triple-DES and RC4 encryption types to
|
||||
be ignored.
|
||||
4
crypto/krb5/doc/admin/env_variables.rst
Normal file
4
crypto/krb5/doc/admin/env_variables.rst
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
Environment variables
|
||||
=====================
|
||||
|
||||
This content has moved to :ref:`kerberos(7)`.
|
||||
235
crypto/krb5/doc/admin/host_config.rst
Normal file
235
crypto/krb5/doc/admin/host_config.rst
Normal file
|
|
@ -0,0 +1,235 @@
|
|||
Host configuration
|
||||
==================
|
||||
|
||||
All hosts running Kerberos software, whether they are clients,
|
||||
application servers, or KDCs, can be configured using
|
||||
:ref:`krb5.conf(5)`. Here we describe some of the behavior changes
|
||||
you might want to make.
|
||||
|
||||
|
||||
Default realm
|
||||
-------------
|
||||
|
||||
In the :ref:`libdefaults` section, the **default_realm** realm
|
||||
relation sets the default Kerberos realm. For example::
|
||||
|
||||
[libdefaults]
|
||||
default_realm = ATHENA.MIT.EDU
|
||||
|
||||
The default realm affects Kerberos behavior in the following ways:
|
||||
|
||||
* When a principal name is parsed from text, the default realm is used
|
||||
if no ``@REALM`` component is specified.
|
||||
|
||||
* The default realm affects login authorization as described below.
|
||||
|
||||
* For programs which operate on a Kerberos database, the default realm
|
||||
is used to determine which database to operate on, unless the **-r**
|
||||
parameter is given to specify a realm.
|
||||
|
||||
* A server program may use the default realm when looking up its key
|
||||
in a :ref:`keytab file <keytab_file>`, if its realm is not
|
||||
determined by :ref:`domain_realm` configuration or by the server
|
||||
program itself.
|
||||
|
||||
* If :ref:`kinit(1)` is passed the **-n** flag, it requests anonymous
|
||||
tickets from the default realm.
|
||||
|
||||
In some situations, these uses of the default realm might conflict.
|
||||
For example, it might be desirable for principal name parsing to use
|
||||
one realm by default, but for login authorization to use a second
|
||||
realm. In this situation, the first realm can be configured as the
|
||||
default realm, and **auth_to_local** relations can be used as
|
||||
described below to use the second realm for login authorization.
|
||||
|
||||
|
||||
.. _login_authorization:
|
||||
|
||||
Login authorization
|
||||
-------------------
|
||||
|
||||
If a host runs a Kerberos-enabled login service such as OpenSSH with
|
||||
GSSAPIAuthentication enabled, login authorization rules determine
|
||||
whether a Kerberos principal is allowed to access a local account.
|
||||
|
||||
By default, a Kerberos principal is allowed access to an account if
|
||||
its realm matches the default realm and its name matches the account
|
||||
name. (For historical reasons, access is also granted by default if
|
||||
the name has two components and the second component matches the
|
||||
default realm; for instance, ``alice/ATHENA.MIT.EDU@ATHENA.MIT.EDU``
|
||||
is granted access to the ``alice`` account if ``ATHENA.MIT.EDU`` is
|
||||
the default realm.)
|
||||
|
||||
The simplest way to control local access is using :ref:`.k5login(5)`
|
||||
files. To use these, place a ``.k5login`` file in the home directory
|
||||
of each account listing the principal names which should have login
|
||||
access to that account. If it is not desirable to use ``.k5login``
|
||||
files located in account home directories, the **k5login_directory**
|
||||
relation in the :ref:`libdefaults` section can specify a directory
|
||||
containing one file per account uname.
|
||||
|
||||
By default, if a ``.k5login`` file is present, it controls
|
||||
authorization both positively and negatively--any principal name
|
||||
contained in the file is granted access and any other principal name
|
||||
is denied access, even if it would have had access if the ``.k5login``
|
||||
file didn't exist. The **k5login_authoritative** relation in the
|
||||
:ref:`libdefaults` section can be set to false to make ``.k5login``
|
||||
files provide positive authorization only.
|
||||
|
||||
The **auth_to_local** relation in the :ref:`realms` section for the
|
||||
default realm can specify pattern-matching rules to control login
|
||||
authorization. For example, the following configuration allows access
|
||||
to principals from a different realm than the default realm::
|
||||
|
||||
[realms]
|
||||
DEFAULT.REALM = {
|
||||
# Allow access to principals from OTHER.REALM.
|
||||
#
|
||||
# [1:$1@$0] matches single-component principal names and creates
|
||||
# a selection string containing the principal name and realm.
|
||||
#
|
||||
# (.*@OTHER\.REALM) matches against the selection string, so that
|
||||
# only principals in OTHER.REALM are matched.
|
||||
#
|
||||
# s/@OTHER\.REALM$// removes the realm name, leaving behind the
|
||||
# principal name as the account name.
|
||||
auth_to_local = RULE:[1:$1@$0](.*@OTHER\.REALM)s/@OTHER\.REALM$//
|
||||
|
||||
# Also allow principals from the default realm. Omit this line
|
||||
# to only allow access to principals in OTHER.REALM.
|
||||
auth_to_local = DEFAULT
|
||||
}
|
||||
|
||||
The **auth_to_local_names** subsection of the :ref:`realms` section
|
||||
for the default realm can specify explicit mappings from principal
|
||||
names to local accounts. The key used in this subsection is the
|
||||
principal name without realm, so it is only safe to use in a Kerberos
|
||||
environment with a single realm or a tightly controlled set of realms.
|
||||
An example use of **auth_to_local_names** might be::
|
||||
|
||||
[realms]
|
||||
ATHENA.MIT.EDU = {
|
||||
auth_to_local_names = {
|
||||
# Careful, these match principals in any realm!
|
||||
host/example.com = hostaccount
|
||||
fred = localfred
|
||||
}
|
||||
}
|
||||
|
||||
Local authorization behavior can also be modified using plugin
|
||||
modules; see :ref:`hostrealm_plugin` for details.
|
||||
|
||||
|
||||
.. _plugin_config:
|
||||
|
||||
Plugin module configuration
|
||||
---------------------------
|
||||
|
||||
Many aspects of Kerberos behavior, such as client preauthentication
|
||||
and KDC service location, can be modified through the use of plugin
|
||||
modules. For most of these behaviors, you can use the :ref:`plugins`
|
||||
section of krb5.conf to register third-party modules, and to switch
|
||||
off registered or built-in modules.
|
||||
|
||||
A plugin module takes the form of a Unix shared object
|
||||
(``modname.so``) or Windows DLL (``modname.dll``). If you have
|
||||
installed a third-party plugin module and want to register it, you do
|
||||
so using the **module** relation in the appropriate subsection of the
|
||||
[plugins] section. The value for **module** must give the module name
|
||||
and the path to the module, separated by a colon. The module name
|
||||
will often be the same as the shared object's name, but in unusual
|
||||
cases (such as a shared object which implements multiple modules for
|
||||
the same interface) it might not be. For example, to register a
|
||||
client preauthentication module named ``mypreauth`` installed at
|
||||
``/path/to/mypreauth.so``, you could write::
|
||||
|
||||
[plugins]
|
||||
clpreauth = {
|
||||
module = mypreauth:/path/to/mypreauth.so
|
||||
}
|
||||
|
||||
Many of the pluggable behaviors in MIT krb5 contain built-in modules
|
||||
which can be switched off. You can disable a built-in module (or one
|
||||
you have registered) using the **disable** directive in the
|
||||
appropriate subsection of the [plugins] section. For example, to
|
||||
disable the use of .k5identity files to select credential caches, you
|
||||
could write::
|
||||
|
||||
[plugins]
|
||||
ccselect = {
|
||||
disable = k5identity
|
||||
}
|
||||
|
||||
If you want to disable multiple modules, specify the **disable**
|
||||
directive multiple times, giving one module to disable each time.
|
||||
|
||||
Alternatively, you can explicitly specify which modules you want to be
|
||||
enabled for that behavior using the **enable_only** directive. For
|
||||
example, to make :ref:`kadmind(8)` check password quality using only a
|
||||
module you have registered, and no other mechanism, you could write::
|
||||
|
||||
[plugins]
|
||||
pwqual = {
|
||||
module = mymodule:/path/to/mymodule.so
|
||||
enable_only = mymodule
|
||||
}
|
||||
|
||||
Again, if you want to specify multiple modules, specify the
|
||||
**enable_only** directive multiple times, giving one module to enable
|
||||
each time.
|
||||
|
||||
Some Kerberos interfaces use different mechanisms to register plugin
|
||||
modules.
|
||||
|
||||
|
||||
KDC location modules
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For historical reasons, modules to control how KDC servers are located
|
||||
are registered simply by placing the shared object or DLL into the
|
||||
"libkrb5" subdirectory of the krb5 plugin directory, which defaults to
|
||||
|libdir|\ ``/krb5/plugins``. For example, Samba's winbind krb5
|
||||
locator plugin would be registered by placing its shared object in
|
||||
|libdir|\ ``/krb5/plugins/libkrb5/winbind_krb5_locator.so``.
|
||||
|
||||
|
||||
.. _gssapi_plugin_config:
|
||||
|
||||
GSSAPI mechanism modules
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
GSSAPI mechanism modules are registered using the file
|
||||
|sysconfdir|\ ``/gss/mech`` or configuration files in the
|
||||
|sysconfdir|\ ``/gss/mech.d`` directory with a ``.conf``
|
||||
suffix. Each line in these files has the form::
|
||||
|
||||
name oid pathname [options] <type>
|
||||
|
||||
Only the name, oid, and pathname are required. *name* is the
|
||||
mechanism name, which may be used for debugging or logging purposes.
|
||||
*oid* is the object identifier of the GSSAPI mechanism to be
|
||||
registered. *pathname* is a path to the module shared object or DLL.
|
||||
*options* (if present) are options provided to the plugin module,
|
||||
surrounded in square brackets. *type* (if present) can be used to
|
||||
indicate a special type of module. Currently the only special module
|
||||
type is "interposer", for a module designed to intercept calls to
|
||||
other mechanisms.
|
||||
|
||||
If the environment variable **GSS_MECH_CONFIG** is set, its value is
|
||||
used as the sole mechanism configuration filename.
|
||||
|
||||
|
||||
.. _profile_plugin_config:
|
||||
|
||||
Configuration profile modules
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A configuration profile module replaces the information source for
|
||||
:ref:`krb5.conf(5)` itself. To use a profile module, begin krb5.conf
|
||||
with the line::
|
||||
|
||||
module PATHNAME:STRING
|
||||
|
||||
where *PATHNAME* is a path to the module shared object or DLL, and
|
||||
*STRING* is a string to provide to the module. The module will then
|
||||
take over, and the rest of krb5.conf will be ignored.
|
||||
48
crypto/krb5/doc/admin/https.rst
Normal file
48
crypto/krb5/doc/admin/https.rst
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
.. _https:
|
||||
|
||||
HTTPS proxy configuration
|
||||
=========================
|
||||
|
||||
In addition to being able to use UDP or TCP to communicate directly
|
||||
with a KDC as is outlined in RFC4120, and with kpasswd services in a
|
||||
similar fashion, the client libraries can attempt to use an HTTPS
|
||||
proxy server to communicate with a KDC or kpasswd service, using the
|
||||
protocol outlined in [MS-KKDCP].
|
||||
|
||||
Communicating with a KDC through an HTTPS proxy allows clients to
|
||||
contact servers when network firewalls might otherwise prevent them
|
||||
from doing so. The use of TLS also encrypts all traffic between the
|
||||
clients and the KDC, preventing observers from conducting password
|
||||
dictionary attacks or from observing the client and server principals
|
||||
being authenticated, at additional computational cost to both clients
|
||||
and servers.
|
||||
|
||||
An HTTPS proxy server is provided as a feature in some versions of
|
||||
Microsoft Windows Server, and a WSGI implementation named `kdcproxy`
|
||||
is available in the python package index.
|
||||
|
||||
|
||||
Configuring the clients
|
||||
-----------------------
|
||||
|
||||
To use an HTTPS proxy, a client host must trust the CA which issued
|
||||
that proxy's SSL certificate. If that CA's certificate is not in the
|
||||
system-wide default set of trusted certificates, configure the
|
||||
following relation in the client host's :ref:`krb5.conf(5)` file in
|
||||
the appropriate :ref:`realms` subsection::
|
||||
|
||||
http_anchors = FILE:/etc/krb5/cacert.pem
|
||||
|
||||
Adjust the pathname to match the path of the file which contains a
|
||||
copy of the CA's certificate. The `http_anchors` option is documented
|
||||
more fully in :ref:`krb5.conf(5)`.
|
||||
|
||||
Configure the client to access the KDC and kpasswd service by
|
||||
specifying their locations in its :ref:`krb5.conf(5)` file in the form
|
||||
of HTTPS URLs for the proxy server::
|
||||
|
||||
kdc = https://server.fqdn/KdcProxy
|
||||
kpasswd_server = https://server.fqdn/KdcProxy
|
||||
|
||||
If the proxy and client are properly configured, client commands such
|
||||
as ``kinit``, ``kvno``, and ``kpasswd`` should all function normally.
|
||||
34
crypto/krb5/doc/admin/index.rst
Normal file
34
crypto/krb5/doc/admin/index.rst
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
For administrators
|
||||
==================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
install.rst
|
||||
conf_files/index.rst
|
||||
realm_config.rst
|
||||
database.rst
|
||||
dbtypes.rst
|
||||
lockout.rst
|
||||
conf_ldap.rst
|
||||
appl_servers.rst
|
||||
host_config.rst
|
||||
backup_host.rst
|
||||
pkinit.rst
|
||||
otp.rst
|
||||
spake.rst
|
||||
dictionary.rst
|
||||
princ_dns.rst
|
||||
enctypes.rst
|
||||
https.rst
|
||||
auth_indicator.rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
admin_commands/index.rst
|
||||
../mitK5defaults.rst
|
||||
env_variables.rst
|
||||
troubleshoot.rst
|
||||
advanced/index.rst
|
||||
various_envs.rst
|
||||
21
crypto/krb5/doc/admin/install.rst
Normal file
21
crypto/krb5/doc/admin/install.rst
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
Installation guide
|
||||
==================
|
||||
|
||||
Contents
|
||||
--------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
install_kdc.rst
|
||||
install_clients.rst
|
||||
install_appl_srv.rst
|
||||
|
||||
|
||||
Additional references
|
||||
---------------------
|
||||
|
||||
#. Debian: `Setting up MIT Kerberos 5
|
||||
<http://techpubs.spinlocksolutions.com/dklar/kerberos.html>`_
|
||||
#. Solaris: `Configuring the Kerberos Service
|
||||
<https://docs.oracle.com/cd/E19253-01/816-4557/6maosrjv2/index.html>`_
|
||||
78
crypto/krb5/doc/admin/install_appl_srv.rst
Normal file
78
crypto/krb5/doc/admin/install_appl_srv.rst
Normal file
|
|
@ -0,0 +1,78 @@
|
|||
UNIX Application Servers
|
||||
========================
|
||||
|
||||
An application server is a host that provides one or more services
|
||||
over the network. Application servers can be "secure" or "insecure."
|
||||
A "secure" host is set up to require authentication from every client
|
||||
connecting to it. An "insecure" host will still provide Kerberos
|
||||
authentication, but will also allow unauthenticated clients to
|
||||
connect.
|
||||
|
||||
If you have Kerberos V5 installed on all of your client machines, MIT
|
||||
recommends that you make your hosts secure, to take advantage of the
|
||||
security that Kerberos authentication affords. However, if you have
|
||||
some clients that do not have Kerberos V5 installed, you can run an
|
||||
insecure server, and still take advantage of Kerberos V5's single
|
||||
sign-on capability.
|
||||
|
||||
|
||||
.. _keytab_file:
|
||||
|
||||
The keytab file
|
||||
---------------
|
||||
|
||||
All Kerberos server machines need a keytab file to authenticate to the
|
||||
KDC. By default on UNIX-like systems this file is named |keytab|.
|
||||
The keytab file is an local copy of the host's key. The keytab file
|
||||
is a potential point of entry for a break-in, and if compromised,
|
||||
would allow unrestricted access to its host. The keytab file should
|
||||
be readable only by root, and should exist only on the machine's local
|
||||
disk. The file should not be part of any backup of the machine,
|
||||
unless access to the backup data is secured as tightly as access to
|
||||
the machine's root password.
|
||||
|
||||
In order to generate a keytab for a host, the host must have a
|
||||
principal in the Kerberos database. The procedure for adding hosts to
|
||||
the database is described fully in :ref:`principals`. (See
|
||||
:ref:`replica_host_key` for a brief description.) The keytab is
|
||||
generated by running :ref:`kadmin(1)` and issuing the :ref:`ktadd`
|
||||
command.
|
||||
|
||||
For example, to generate a keytab file to allow the host
|
||||
``trillium.mit.edu`` to authenticate for the services host, ftp, and
|
||||
pop, the administrator ``joeadmin`` would issue the command (on
|
||||
``trillium.mit.edu``)::
|
||||
|
||||
trillium% kadmin
|
||||
Authenticating as principal root/admin@ATHENA.MIT.EDU with password.
|
||||
Password for root/admin@ATHENA.MIT.EDU:
|
||||
kadmin: ktadd host/trillium.mit.edu ftp/trillium.mit.edu pop/trillium.mit.edu
|
||||
Entry for principal host/trillium.mit.edu@ATHENA.MIT.EDU with kvno 3, encryption type aes256-cts-hmac-sha384-192 added to keytab FILE:/etc/krb5.keytab.
|
||||
kadmin: Entry for principal ftp/trillium.mit.edu@ATHENA.MIT.EDU with kvno 3, encryption type aes256-cts-hmac-sha384-192 added to keytab FILE:/etc/krb5.keytab.
|
||||
kadmin: Entry for principal pop/trillium.mit.edu@ATHENA.MIT.EDU with kvno 3, encryption type aes256-cts-hmac-sha384-192 added to keytab FILE:/etc/krb5.keytab.
|
||||
kadmin: quit
|
||||
trillium%
|
||||
|
||||
If you generate the keytab file on another host, you need to get a
|
||||
copy of the keytab file onto the destination host (``trillium``, in
|
||||
the above example) without sending it unencrypted over the network.
|
||||
|
||||
|
||||
Some advice about secure hosts
|
||||
------------------------------
|
||||
|
||||
Kerberos V5 can protect your host from certain types of break-ins, but
|
||||
it is possible to install Kerberos V5 and still leave your host
|
||||
vulnerable to attack. Obviously an installation guide is not the
|
||||
place to try to include an exhaustive list of countermeasures for
|
||||
every possible attack, but it is worth noting some of the larger holes
|
||||
and how to close them.
|
||||
|
||||
We recommend that backups of secure machines exclude the keytab file
|
||||
(|keytab|). If this is not possible, the backups should at least be
|
||||
done locally, rather than over a network, and the backup tapes should
|
||||
be physically secured.
|
||||
|
||||
The keytab file and any programs run by root, including the Kerberos
|
||||
V5 binaries, should be kept on local disk. The keytab file should be
|
||||
readable only by root.
|
||||
58
crypto/krb5/doc/admin/install_clients.rst
Normal file
58
crypto/krb5/doc/admin/install_clients.rst
Normal file
|
|
@ -0,0 +1,58 @@
|
|||
Installing and configuring UNIX client machines
|
||||
===============================================
|
||||
|
||||
The Kerberized client programs include :ref:`kinit(1)`,
|
||||
:ref:`klist(1)`, :ref:`kdestroy(1)`, and :ref:`kpasswd(1)`. All of
|
||||
these programs are in the directory |bindir|.
|
||||
|
||||
You can often integrate Kerberos with the login system on client
|
||||
machines, typically through the use of PAM. The details vary by
|
||||
operating system, and should be covered in your operating system's
|
||||
documentation. If you do this, you will need to make sure your users
|
||||
know to use their Kerberos passwords when they log in.
|
||||
|
||||
You will also need to educate your users to use the ticket management
|
||||
programs kinit, klist, and kdestroy. If you do not have Kerberos
|
||||
password changing integrated into the native password program (again,
|
||||
typically through PAM), you will need to educate users to use kpasswd
|
||||
in place of its non-Kerberos counterparts passwd.
|
||||
|
||||
|
||||
Client machine configuration files
|
||||
----------------------------------
|
||||
|
||||
Each machine running Kerberos should have a :ref:`krb5.conf(5)` file.
|
||||
At a minimum, it should define a **default_realm** setting in
|
||||
:ref:`libdefaults`. If you are not using DNS SRV records
|
||||
(:ref:`kdc_hostnames`) or URI records (:ref:`kdc_discovery`), it must
|
||||
also contain a :ref:`realms` section containing information for your
|
||||
realm's KDCs.
|
||||
|
||||
Consider setting **rdns** to false in order to reduce your dependence
|
||||
on precisely correct DNS information for service hostnames. Turning
|
||||
this flag off means that service hostnames will be canonicalized
|
||||
through forward name resolution (which adds your domain name to
|
||||
unqualified hostnames, and resolves CNAME records in DNS), but not
|
||||
through reverse address lookup. The default value of this flag is
|
||||
true for historical reasons only.
|
||||
|
||||
If you anticipate users frequently logging into remote hosts
|
||||
(e.g., using ssh) using forwardable credentials, consider setting
|
||||
**forwardable** to true so that users obtain forwardable tickets by
|
||||
default. Otherwise users will need to use ``kinit -f`` to get
|
||||
forwardable tickets.
|
||||
|
||||
Consider adjusting the **ticket_lifetime** setting to match the likely
|
||||
length of sessions for your users. For instance, if most of your
|
||||
users will be logging in for an eight-hour workday, you could set the
|
||||
default to ten hours so that tickets obtained in the morning expire
|
||||
shortly after the end of the workday. Users can still manually
|
||||
request longer tickets when necessary, up to the maximum allowed by
|
||||
each user's principal record on the KDC.
|
||||
|
||||
If a client host may access services in different realms, it may be
|
||||
useful to define a :ref:`domain_realm` mapping so that clients know
|
||||
which hosts belong to which realms. However, if your clients and KDC
|
||||
are running release 1.7 or later, it is also reasonable to leave this
|
||||
section out on client machines and just define it in the KDC's
|
||||
krb5.conf.
|
||||
536
crypto/krb5/doc/admin/install_kdc.rst
Normal file
536
crypto/krb5/doc/admin/install_kdc.rst
Normal file
|
|
@ -0,0 +1,536 @@
|
|||
Installing KDCs
|
||||
===============
|
||||
|
||||
When setting up Kerberos in a production environment, it is best to
|
||||
have multiple replica KDCs alongside with a primary KDC to ensure the
|
||||
continued availability of the Kerberized services. Each KDC contains
|
||||
a copy of the Kerberos database. The primary KDC contains the
|
||||
writable copy of the realm database, which it replicates to the
|
||||
replica KDCs at regular intervals. All database changes (such as
|
||||
password changes) are made on the primary KDC. Replica KDCs provide
|
||||
Kerberos ticket-granting services, but not database administration,
|
||||
when the primary KDC is unavailable. MIT recommends that you install
|
||||
all of your KDCs to be able to function as either the primary or one
|
||||
of the replicas. This will enable you to easily switch your primary
|
||||
KDC with one of the replicas if necessary (see
|
||||
:ref:`switch_primary_replica`). This installation procedure is based
|
||||
on that recommendation.
|
||||
|
||||
.. warning::
|
||||
|
||||
- The Kerberos system relies on the availability of correct time
|
||||
information. Ensure that the primary and all replica KDCs have
|
||||
properly synchronized clocks.
|
||||
|
||||
- It is best to install and run KDCs on secured and dedicated
|
||||
hardware with limited access. If your KDC is also a file
|
||||
server, FTP server, Web server, or even just a client machine,
|
||||
someone who obtained root access through a security hole in any
|
||||
of those areas could potentially gain access to the Kerberos
|
||||
database.
|
||||
|
||||
|
||||
Install and configure the primary KDC
|
||||
-------------------------------------
|
||||
|
||||
Install Kerberos either from the OS-provided packages or from the
|
||||
source (See :ref:`do_build`).
|
||||
|
||||
.. note::
|
||||
|
||||
For the purpose of this document we will use the following
|
||||
names::
|
||||
|
||||
kerberos.mit.edu - primary KDC
|
||||
kerberos-1.mit.edu - replica KDC
|
||||
ATHENA.MIT.EDU - realm name
|
||||
.k5.ATHENA.MIT.EDU - stash file
|
||||
admin/admin - admin principal
|
||||
|
||||
See :ref:`mitK5defaults` for the default names and locations
|
||||
of the relevant to this topic files. Adjust the names and
|
||||
paths to your system environment.
|
||||
|
||||
|
||||
Edit KDC configuration files
|
||||
----------------------------
|
||||
|
||||
Modify the configuration files, :ref:`krb5.conf(5)` and
|
||||
:ref:`kdc.conf(5)`, to reflect the correct information (such as
|
||||
domain-realm mappings and Kerberos servers names) for your realm.
|
||||
(See :ref:`mitK5defaults` for the recommended default locations for
|
||||
these files).
|
||||
|
||||
Most of the tags in the configuration have default values that will
|
||||
work well for most sites. There are some tags in the
|
||||
:ref:`krb5.conf(5)` file whose values must be specified, and this
|
||||
section will explain those.
|
||||
|
||||
If the locations for these configuration files differs from the
|
||||
default ones, set **KRB5_CONFIG** and **KRB5_KDC_PROFILE** environment
|
||||
variables to point to the krb5.conf and kdc.conf respectively. For
|
||||
example::
|
||||
|
||||
export KRB5_CONFIG=/yourdir/krb5.conf
|
||||
export KRB5_KDC_PROFILE=/yourdir/kdc.conf
|
||||
|
||||
|
||||
krb5.conf
|
||||
~~~~~~~~~
|
||||
|
||||
If you are not using DNS TXT records (see :ref:`mapping_hostnames`),
|
||||
you must specify the **default_realm** in the :ref:`libdefaults`
|
||||
section. If you are not using DNS URI or SRV records (see
|
||||
:ref:`kdc_hostnames` and :ref:`kdc_discovery`), you must include the
|
||||
**kdc** tag for each *realm* in the :ref:`realms` section. To
|
||||
communicate with the kadmin server in each realm, the **admin_server**
|
||||
tag must be set in the
|
||||
:ref:`realms` section.
|
||||
|
||||
An example krb5.conf file::
|
||||
|
||||
[libdefaults]
|
||||
default_realm = ATHENA.MIT.EDU
|
||||
|
||||
[realms]
|
||||
ATHENA.MIT.EDU = {
|
||||
kdc = kerberos.mit.edu
|
||||
kdc = kerberos-1.mit.edu
|
||||
admin_server = kerberos.mit.edu
|
||||
}
|
||||
|
||||
|
||||
kdc.conf
|
||||
~~~~~~~~
|
||||
|
||||
The kdc.conf file can be used to control the listening ports of the
|
||||
KDC and kadmind, as well as realm-specific defaults, the database type
|
||||
and location, and logging.
|
||||
|
||||
An example kdc.conf file::
|
||||
|
||||
[kdcdefaults]
|
||||
kdc_listen = 88
|
||||
kdc_tcp_listen = 88
|
||||
|
||||
[realms]
|
||||
ATHENA.MIT.EDU = {
|
||||
kadmind_port = 749
|
||||
max_life = 12h 0m 0s
|
||||
max_renewable_life = 7d 0h 0m 0s
|
||||
master_key_type = aes256-cts
|
||||
supported_enctypes = aes256-cts:normal aes128-cts:normal
|
||||
# If the default location does not suit your setup,
|
||||
# explicitly configure the following values:
|
||||
# database_name = /var/krb5kdc/principal
|
||||
# key_stash_file = /var/krb5kdc/.k5.ATHENA.MIT.EDU
|
||||
# acl_file = /var/krb5kdc/kadm5.acl
|
||||
}
|
||||
|
||||
[logging]
|
||||
# By default, the KDC and kadmind will log output using
|
||||
# syslog. You can instead send log output to files like this:
|
||||
kdc = FILE:/var/log/krb5kdc.log
|
||||
admin_server = FILE:/var/log/kadmin.log
|
||||
default = FILE:/var/log/krb5lib.log
|
||||
|
||||
Replace ``ATHENA.MIT.EDU`` and ``kerberos.mit.edu`` with the name of
|
||||
your Kerberos realm and server respectively.
|
||||
|
||||
.. note::
|
||||
|
||||
You have to have write permission on the target directories
|
||||
(these directories must exist) used by **database_name**,
|
||||
**key_stash_file**, and **acl_file**.
|
||||
|
||||
|
||||
.. _create_db:
|
||||
|
||||
Create the KDC database
|
||||
-----------------------
|
||||
|
||||
You will use the :ref:`kdb5_util(8)` command on the primary KDC to
|
||||
create the Kerberos database and the optional :ref:`stash_definition`.
|
||||
|
||||
.. note::
|
||||
|
||||
If you choose not to install a stash file, the KDC will
|
||||
prompt you for the master key each time it starts up. This
|
||||
means that the KDC will not be able to start automatically,
|
||||
such as after a system reboot.
|
||||
|
||||
:ref:`kdb5_util(8)` will prompt you for the master password for the
|
||||
Kerberos database. This password can be any string. A good password
|
||||
is one you can remember, but that no one else can guess. Examples of
|
||||
bad passwords are words that can be found in a dictionary, any common
|
||||
or popular name, especially a famous person (or cartoon character),
|
||||
your username in any form (e.g., forward, backward, repeated twice,
|
||||
etc.), and any of the sample passwords that appear in this manual.
|
||||
One example of a password which might be good if it did not appear in
|
||||
this manual is "MITiys4K5!", which represents the sentence "MIT is
|
||||
your source for Kerberos 5!" (It's the first letter of each word,
|
||||
substituting the numeral "4" for the word "for", and includes the
|
||||
punctuation mark at the end.)
|
||||
|
||||
The following is an example of how to create a Kerberos database and
|
||||
stash file on the primary KDC, using the :ref:`kdb5_util(8)` command.
|
||||
Replace ``ATHENA.MIT.EDU`` with the name of your Kerberos realm::
|
||||
|
||||
shell% kdb5_util create -r ATHENA.MIT.EDU -s
|
||||
|
||||
Initializing database '/usr/local/var/krb5kdc/principal' for realm 'ATHENA.MIT.EDU',
|
||||
master key name 'K/M@ATHENA.MIT.EDU'
|
||||
You will be prompted for the database Master Password.
|
||||
It is important that you NOT FORGET this password.
|
||||
Enter KDC database master key: <= Type the master password.
|
||||
Re-enter KDC database master key to verify: <= Type it again.
|
||||
shell%
|
||||
|
||||
This will create five files in |kdcdir| (or at the locations specified
|
||||
in :ref:`kdc.conf(5)`):
|
||||
|
||||
* two Kerberos database files, ``principal``, and ``principal.ok``
|
||||
* the Kerberos administrative database file, ``principal.kadm5``
|
||||
* the administrative database lock file, ``principal.kadm5.lock``
|
||||
* the stash file, in this example ``.k5.ATHENA.MIT.EDU``. If you do
|
||||
not want a stash file, run the above command without the **-s**
|
||||
option.
|
||||
|
||||
For more information on administrating Kerberos database see
|
||||
:ref:`db_operations`.
|
||||
|
||||
|
||||
.. _admin_acl:
|
||||
|
||||
Add administrators to the ACL file
|
||||
----------------------------------
|
||||
|
||||
Next, you need create an Access Control List (ACL) file and put the
|
||||
Kerberos principal of at least one of the administrators into it.
|
||||
This file is used by the :ref:`kadmind(8)` daemon to control which
|
||||
principals may view and make privileged modifications to the Kerberos
|
||||
database files. The ACL filename is determined by the **acl_file**
|
||||
variable in :ref:`kdc.conf(5)`; the default is |kdcdir|\
|
||||
``/kadm5.acl``.
|
||||
|
||||
For more information on Kerberos ACL file see :ref:`kadm5.acl(5)`.
|
||||
|
||||
.. _addadmin_kdb:
|
||||
|
||||
Add administrators to the Kerberos database
|
||||
-------------------------------------------
|
||||
|
||||
Next you need to add administrative principals (i.e., principals who
|
||||
are allowed to administer Kerberos database) to the Kerberos database.
|
||||
You *must* add at least one principal now to allow communication
|
||||
between the Kerberos administration daemon kadmind and the kadmin
|
||||
program over the network for further administration. To do this, use
|
||||
the kadmin.local utility on the primary KDC. kadmin.local is designed
|
||||
to be run on the primary KDC host without using Kerberos
|
||||
authentication to an admin server; instead, it must have read and
|
||||
write access to the Kerberos database on the local filesystem.
|
||||
|
||||
The administrative principals you create should be the ones you added
|
||||
to the ACL file (see :ref:`admin_acl`).
|
||||
|
||||
In the following example, the administrative principal ``admin/admin``
|
||||
is created::
|
||||
|
||||
shell% kadmin.local
|
||||
|
||||
kadmin.local: addprinc admin/admin@ATHENA.MIT.EDU
|
||||
|
||||
No policy specified for "admin/admin@ATHENA.MIT.EDU";
|
||||
assigning "default".
|
||||
Enter password for principal admin/admin@ATHENA.MIT.EDU: <= Enter a password.
|
||||
Re-enter password for principal admin/admin@ATHENA.MIT.EDU: <= Type it again.
|
||||
Principal "admin/admin@ATHENA.MIT.EDU" created.
|
||||
kadmin.local:
|
||||
|
||||
.. _start_kdc_daemons:
|
||||
|
||||
Start the Kerberos daemons on the primary KDC
|
||||
---------------------------------------------
|
||||
|
||||
At this point, you are ready to start the Kerberos KDC
|
||||
(:ref:`krb5kdc(8)`) and administrative daemons on the primary KDC. To
|
||||
do so, type::
|
||||
|
||||
shell% krb5kdc
|
||||
shell% kadmind
|
||||
|
||||
Each server daemon will fork and run in the background.
|
||||
|
||||
.. note::
|
||||
|
||||
Assuming you want these daemons to start up automatically at
|
||||
boot time, you can add them to the KDC's ``/etc/rc`` or
|
||||
``/etc/inittab`` file. You need to have a
|
||||
:ref:`stash_definition` in order to do this.
|
||||
|
||||
You can verify that they started properly by checking for their
|
||||
startup messages in the logging locations you defined in
|
||||
:ref:`krb5.conf(5)` (see :ref:`logging`). For example::
|
||||
|
||||
shell% tail /var/log/krb5kdc.log
|
||||
Dec 02 12:35:47 beeblebrox krb5kdc[3187](info): commencing operation
|
||||
shell% tail /var/log/kadmin.log
|
||||
Dec 02 12:35:52 beeblebrox kadmind[3189](info): starting
|
||||
|
||||
Any errors the daemons encounter while starting will also be listed in
|
||||
the logging output.
|
||||
|
||||
As an additional verification, check if :ref:`kinit(1)` succeeds
|
||||
against the principals that you have created on the previous step
|
||||
(:ref:`addadmin_kdb`). Run::
|
||||
|
||||
shell% kinit admin/admin@ATHENA.MIT.EDU
|
||||
|
||||
|
||||
Install the replica KDCs
|
||||
------------------------
|
||||
|
||||
You are now ready to start configuring the replica KDCs.
|
||||
|
||||
.. note::
|
||||
|
||||
Assuming you are setting the KDCs up so that you can easily
|
||||
switch the primary KDC with one of the replicas, you should
|
||||
perform each of these steps on the primary KDC as well as
|
||||
the replica KDCs, unless these instructions specify
|
||||
otherwise.
|
||||
|
||||
|
||||
.. _replica_host_key:
|
||||
|
||||
Create host keytabs for replica KDCs
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Each KDC needs a ``host`` key in the Kerberos database. These keys
|
||||
are used for mutual authentication when propagating the database dump
|
||||
file from the primary KDC to the secondary KDC servers.
|
||||
|
||||
On the primary KDC, connect to administrative interface and create the
|
||||
host principal for each of the KDCs' ``host`` services. For example,
|
||||
if the primary KDC were called ``kerberos.mit.edu``, and you had a
|
||||
replica KDC named ``kerberos-1.mit.edu``, you would type the
|
||||
following::
|
||||
|
||||
shell% kadmin
|
||||
kadmin: addprinc -randkey host/kerberos.mit.edu
|
||||
No policy specified for "host/kerberos.mit.edu@ATHENA.MIT.EDU"; assigning "default"
|
||||
Principal "host/kerberos.mit.edu@ATHENA.MIT.EDU" created.
|
||||
|
||||
kadmin: addprinc -randkey host/kerberos-1.mit.edu
|
||||
No policy specified for "host/kerberos-1.mit.edu@ATHENA.MIT.EDU"; assigning "default"
|
||||
Principal "host/kerberos-1.mit.edu@ATHENA.MIT.EDU" created.
|
||||
|
||||
It is not strictly necessary to have the primary KDC server in the
|
||||
Kerberos database, but it can be handy if you want to be able to swap
|
||||
the primary KDC with one of the replicas.
|
||||
|
||||
Next, extract ``host`` random keys for all participating KDCs and
|
||||
store them in each host's default keytab file. Ideally, you should
|
||||
extract each keytab locally on its own KDC. If this is not feasible,
|
||||
you should use an encrypted session to send them across the network.
|
||||
To extract a keytab directly on a replica KDC called
|
||||
``kerberos-1.mit.edu``, you would execute the following command::
|
||||
|
||||
kadmin: ktadd host/kerberos-1.mit.edu
|
||||
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
|
||||
type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
|
||||
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
|
||||
type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
|
||||
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
|
||||
type aes256-cts-hmac-sha384-192 added to keytab FILE:/etc/krb5.keytab.
|
||||
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
|
||||
type arcfour-hmac added to keytab FILE:/etc/krb5.keytab.
|
||||
|
||||
If you are instead extracting a keytab for the replica KDC called
|
||||
``kerberos-1.mit.edu`` on the primary KDC, you should use a dedicated
|
||||
temporary keytab file for that machine's keytab::
|
||||
|
||||
kadmin: ktadd -k /tmp/kerberos-1.keytab host/kerberos-1.mit.edu
|
||||
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
|
||||
type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
|
||||
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
|
||||
type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
|
||||
|
||||
The file ``/tmp/kerberos-1.keytab`` can then be installed as
|
||||
``/etc/krb5.keytab`` on the host ``kerberos-1.mit.edu``.
|
||||
|
||||
|
||||
Configure replica KDCs
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Database propagation copies the contents of the primary's database,
|
||||
but does not propagate configuration files, stash files, or the kadm5
|
||||
ACL file. The following files must be copied by hand to each replica
|
||||
(see :ref:`mitK5defaults` for the default locations for these files):
|
||||
|
||||
* krb5.conf
|
||||
* kdc.conf
|
||||
* kadm5.acl
|
||||
* master key stash file
|
||||
|
||||
Move the copied files into their appropriate directories, exactly as
|
||||
on the primary KDC. kadm5.acl is only needed to allow a replica to
|
||||
swap with the primary KDC.
|
||||
|
||||
The database is propagated from the primary KDC to the replica KDCs
|
||||
via the :ref:`kpropd(8)` daemon. You must explicitly specify the
|
||||
principals which are allowed to provide Kerberos dump updates on the
|
||||
replica machine with a new database. Create a file named kpropd.acl
|
||||
in the KDC state directory containing the ``host`` principals for each
|
||||
of the KDCs::
|
||||
|
||||
host/kerberos.mit.edu@ATHENA.MIT.EDU
|
||||
host/kerberos-1.mit.edu@ATHENA.MIT.EDU
|
||||
|
||||
.. note::
|
||||
|
||||
If you expect that the primary and replica KDCs will be
|
||||
switched at some point of time, list the host principals
|
||||
from all participating KDC servers in kpropd.acl files on
|
||||
all of the KDCs. Otherwise, you only need to list the
|
||||
primary KDC's host principal in the kpropd.acl files of the
|
||||
replica KDCs.
|
||||
|
||||
Then, add the following line to ``/etc/inetd.conf`` on each KDC
|
||||
(adjust the path to kpropd)::
|
||||
|
||||
krb5_prop stream tcp nowait root /usr/local/sbin/kpropd kpropd
|
||||
|
||||
You also need to add the following line to ``/etc/services`` on each
|
||||
KDC, if it is not already present (assuming that the default port is
|
||||
used)::
|
||||
|
||||
krb5_prop 754/tcp # Kerberos replica propagation
|
||||
|
||||
Restart inetd daemon.
|
||||
|
||||
Alternatively, start :ref:`kpropd(8)` as a stand-alone daemon. This is
|
||||
required when incremental propagation is enabled.
|
||||
|
||||
Now that the replica KDC is able to accept database propagation,
|
||||
you’ll need to propagate the database from the primary server.
|
||||
|
||||
NOTE: Do not start the replica KDC yet; you still do not have a copy
|
||||
of the primary's database.
|
||||
|
||||
|
||||
.. _kprop_to_replicas:
|
||||
|
||||
Propagate the database to each replica KDC
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
First, create a dump file of the database on the primary KDC, as
|
||||
follows::
|
||||
|
||||
shell% kdb5_util dump /usr/local/var/krb5kdc/replica_datatrans
|
||||
|
||||
Then, manually propagate the database to each replica KDC, as in the
|
||||
following example::
|
||||
|
||||
shell% kprop -f /usr/local/var/krb5kdc/replica_datatrans kerberos-1.mit.edu
|
||||
|
||||
Database propagation to kerberos-1.mit.edu: SUCCEEDED
|
||||
|
||||
You will need a script to dump and propagate the database. The
|
||||
following is an example of a Bourne shell script that will do this.
|
||||
|
||||
.. note::
|
||||
|
||||
Remember that you need to replace ``/usr/local/var/krb5kdc``
|
||||
with the name of the KDC state directory.
|
||||
|
||||
::
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
kdclist = "kerberos-1.mit.edu kerberos-2.mit.edu"
|
||||
|
||||
kdb5_util dump /usr/local/var/krb5kdc/replica_datatrans
|
||||
|
||||
for kdc in $kdclist
|
||||
do
|
||||
kprop -f /usr/local/var/krb5kdc/replica_datatrans $kdc
|
||||
done
|
||||
|
||||
You will need to set up a cron job to run this script at the intervals
|
||||
you decided on earlier (see :ref:`db_prop`).
|
||||
|
||||
Now that the replica KDC has a copy of the Kerberos database, you can
|
||||
start the krb5kdc daemon::
|
||||
|
||||
shell% krb5kdc
|
||||
|
||||
As with the primary KDC, you will probably want to add this command to
|
||||
the KDCs' ``/etc/rc`` or ``/etc/inittab`` files, so they will start
|
||||
the krb5kdc daemon automatically at boot time.
|
||||
|
||||
|
||||
Propagation failed?
|
||||
###################
|
||||
|
||||
You may encounter the following error messages. For a more detailed
|
||||
discussion on possible causes and solutions click on the error link
|
||||
to be redirected to :ref:`troubleshoot` section.
|
||||
|
||||
.. include:: ./troubleshoot.rst
|
||||
:start-after: _prop_failed_start:
|
||||
:end-before: _prop_failed_end:
|
||||
|
||||
|
||||
Add Kerberos principals to the database
|
||||
---------------------------------------
|
||||
|
||||
Once your KDCs are set up and running, you are ready to use
|
||||
:ref:`kadmin(1)` to load principals for your users, hosts, and other
|
||||
services into the Kerberos database. This procedure is described
|
||||
fully in :ref:`principals`.
|
||||
|
||||
You may occasionally want to use one of your replica KDCs as the
|
||||
primary. This might happen if you are upgrading the primary KDC, or
|
||||
if your primary KDC has a disk crash. See the following section for
|
||||
the instructions.
|
||||
|
||||
|
||||
.. _switch_primary_replica:
|
||||
|
||||
Switching primary and replica KDCs
|
||||
----------------------------------
|
||||
|
||||
You may occasionally want to use one of your replica KDCs as the
|
||||
primary. This might happen if you are upgrading the primary KDC, or
|
||||
if your primary KDC has a disk crash.
|
||||
|
||||
Assuming you have configured all of your KDCs to be able to function
|
||||
as either the primary KDC or a replica KDC (as this document
|
||||
recommends), all you need to do to make the changeover is:
|
||||
|
||||
If the primary KDC is still running, do the following on the *old*
|
||||
primary KDC:
|
||||
|
||||
#. Kill the kadmind process.
|
||||
#. Disable the cron job that propagates the database.
|
||||
#. Run your database propagation script manually, to ensure that the
|
||||
replicas all have the latest copy of the database (see
|
||||
:ref:`kprop_to_replicas`).
|
||||
|
||||
On the *new* primary KDC:
|
||||
|
||||
#. Start the :ref:`kadmind(8)` daemon (see :ref:`start_kdc_daemons`).
|
||||
#. Set up the cron job to propagate the database (see
|
||||
:ref:`kprop_to_replicas`).
|
||||
#. Switch the CNAMEs of the old and new primary KDCs. If you can't do
|
||||
this, you'll need to change the :ref:`krb5.conf(5)` file on every
|
||||
client machine in your Kerberos realm.
|
||||
|
||||
|
||||
Incremental database propagation
|
||||
--------------------------------
|
||||
|
||||
If you expect your Kerberos database to become large, you may wish to
|
||||
set up incremental propagation to replica KDCs. See
|
||||
:ref:`incr_db_prop` for details.
|
||||
154
crypto/krb5/doc/admin/lockout.rst
Normal file
154
crypto/krb5/doc/admin/lockout.rst
Normal file
|
|
@ -0,0 +1,154 @@
|
|||
.. _lockout:
|
||||
|
||||
Account lockout
|
||||
===============
|
||||
|
||||
As of release 1.8, the KDC can be configured to lock out principals
|
||||
after a number of failed authentication attempts within a period of
|
||||
time. Account lockout can make it more difficult to attack a
|
||||
principal's password by brute force, but also makes it easy for an
|
||||
attacker to deny access to a principal.
|
||||
|
||||
|
||||
Configuring account lockout
|
||||
---------------------------
|
||||
|
||||
Account lockout only works for principals with the
|
||||
**+requires_preauth** flag set. Without this flag, the KDC cannot
|
||||
know whether or not a client successfully decrypted the ticket it
|
||||
issued. It is also important to set the **-allow_svr** flag on a
|
||||
principal to protect its password from an off-line dictionary attack
|
||||
through a TGS request. You can set these flags on a principal with
|
||||
:ref:`kadmin(1)` as follows::
|
||||
|
||||
kadmin: modprinc +requires_preauth -allow_svr PRINCNAME
|
||||
|
||||
Account lockout parameters are configured via :ref:`policy objects
|
||||
<policies>`. There may be an existing policy associated with user
|
||||
principals (such as the "default" policy), or you may need to create a
|
||||
new one and associate it with each user principal.
|
||||
|
||||
The policy parameters related to account lockout are:
|
||||
|
||||
* :ref:`maxfailure <policy_maxfailure>`: the number of failed attempts
|
||||
before the principal is locked out
|
||||
* :ref:`failurecountinterval <policy_failurecountinterval>`: the
|
||||
allowable interval between failed attempts
|
||||
* :ref:`lockoutduration <policy_lockoutduration>`: the amount of time
|
||||
a principal is locked out for
|
||||
|
||||
Here is an example of setting these parameters on a new policy and
|
||||
associating it with a principal::
|
||||
|
||||
kadmin: addpol -maxfailure 10 -failurecountinterval 180
|
||||
-lockoutduration 60 lockout_policy
|
||||
kadmin: modprinc -policy lockout_policy PRINCNAME
|
||||
|
||||
|
||||
Testing account lockout
|
||||
-----------------------
|
||||
|
||||
To test that account lockout is working, try authenticating as the
|
||||
principal (hopefully not one that might be in use) multiple times with
|
||||
the wrong password. For instance, if **maxfailure** is set to 2, you
|
||||
might see::
|
||||
|
||||
$ kinit user
|
||||
Password for user@KRBTEST.COM:
|
||||
kinit: Password incorrect while getting initial credentials
|
||||
$ kinit user
|
||||
Password for user@KRBTEST.COM:
|
||||
kinit: Password incorrect while getting initial credentials
|
||||
$ kinit user
|
||||
kinit: Client's credentials have been revoked while getting initial credentials
|
||||
|
||||
|
||||
Account lockout principal state
|
||||
-------------------------------
|
||||
|
||||
A principal entry keeps three pieces of state related to account
|
||||
lockout:
|
||||
|
||||
* The time of last successful authentication
|
||||
* The time of last failed authentication
|
||||
* A counter of failed attempts
|
||||
|
||||
The time of last successful authentication is not actually needed for
|
||||
the account lockout system to function, but may be of administrative
|
||||
interest. These fields can be observed with the **getprinc** kadmin
|
||||
command. For example::
|
||||
|
||||
kadmin: getprinc user
|
||||
Principal: user@KRBTEST.COM
|
||||
...
|
||||
Last successful authentication: [never]
|
||||
Last failed authentication: Mon Dec 03 12:30:33 EST 2012
|
||||
Failed password attempts: 2
|
||||
...
|
||||
|
||||
A principal which has been locked out can be administratively unlocked
|
||||
with the **-unlock** option to the **modprinc** kadmin command::
|
||||
|
||||
kadmin: modprinc -unlock PRINCNAME
|
||||
|
||||
This command will reset the number of failed attempts to 0.
|
||||
|
||||
|
||||
KDC replication and account lockout
|
||||
-----------------------------------
|
||||
|
||||
The account lockout state of a principal is not replicated by either
|
||||
traditional :ref:`kprop(8)` or incremental propagation. Because of
|
||||
this, the number of attempts an attacker can make within a time period
|
||||
is multiplied by the number of KDCs. For instance, if the
|
||||
**maxfailure** parameter on a policy is 10 and there are four KDCs in
|
||||
the environment (a primary and three replicas), an attacker could make
|
||||
as many as 40 attempts before the principal is locked out on all four
|
||||
KDCs.
|
||||
|
||||
An administrative unlock is propagated from the primary to the replica
|
||||
KDCs during the next propagation. Propagation of an administrative
|
||||
unlock will cause the counter of failed attempts on each replica to
|
||||
reset to 1 on the next failure.
|
||||
|
||||
If a KDC environment uses a replication strategy other than kprop or
|
||||
incremental propagation, such as the LDAP KDB module with multi-master
|
||||
LDAP replication, then account lockout state may be replicated between
|
||||
KDCs and the concerns of this section may not apply.
|
||||
|
||||
|
||||
.. _disable_lockout:
|
||||
|
||||
KDC performance and account lockout
|
||||
-----------------------------------
|
||||
|
||||
In order to fully track account lockout state, the KDC must write to
|
||||
the the database on each successful and failed authentication.
|
||||
Writing to the database is generally more expensive than reading from
|
||||
it, so these writes may have a significant impact on KDC performance.
|
||||
As of release 1.9, it is possible to turn off account lockout state
|
||||
tracking in order to improve performance, by setting the
|
||||
**disable_last_success** and **disable_lockout** variables in the
|
||||
database module subsection of :ref:`kdc.conf(5)`. For example::
|
||||
|
||||
[dbmodules]
|
||||
DB = {
|
||||
disable_last_success = true
|
||||
disable_lockout = true
|
||||
}
|
||||
|
||||
Of the two variables, setting **disable_last_success** will usually
|
||||
have the largest positive impact on performance, and will still allow
|
||||
account lockout policies to operate. However, it will make it
|
||||
impossible to observe the last successful authentication time with
|
||||
kadmin.
|
||||
|
||||
|
||||
KDC setup and account lockout
|
||||
-----------------------------
|
||||
|
||||
To update the account lockout state on principals, the KDC must be
|
||||
able to write to the principal database. For the DB2 module, no
|
||||
special setup is required. For the LDAP module, the KDC DN must be
|
||||
granted write access to the principal objects. If the KDC DN has only
|
||||
read access, account lockout will not function.
|
||||
100
crypto/krb5/doc/admin/otp.rst
Normal file
100
crypto/krb5/doc/admin/otp.rst
Normal file
|
|
@ -0,0 +1,100 @@
|
|||
.. _otp_preauth:
|
||||
|
||||
OTP Preauthentication
|
||||
=====================
|
||||
|
||||
OTP is a preauthentication mechanism for Kerberos 5 which uses One
|
||||
Time Passwords (OTP) to authenticate the client to the KDC. The OTP
|
||||
is passed to the KDC over an encrypted FAST channel in clear-text.
|
||||
The KDC uses the password along with per-user configuration to proxy
|
||||
the request to a third-party RADIUS system. This enables
|
||||
out-of-the-box compatibility with a large number of already widely
|
||||
deployed proprietary systems.
|
||||
|
||||
Additionally, our implementation of the OTP system allows for the
|
||||
passing of RADIUS requests over a UNIX domain stream socket. This
|
||||
permits the use of a local companion daemon which can handle the
|
||||
details of authentication.
|
||||
|
||||
|
||||
Defining token types
|
||||
--------------------
|
||||
|
||||
Token types are defined in either :ref:`krb5.conf(5)` or
|
||||
:ref:`kdc.conf(5)` according to the following format::
|
||||
|
||||
[otp]
|
||||
<name> = {
|
||||
server = <host:port or filename> (default: see below)
|
||||
secret = <filename>
|
||||
timeout = <integer> (default: 5 [seconds])
|
||||
retries = <integer> (default: 3)
|
||||
strip_realm = <boolean> (default: true)
|
||||
indicator = <string> (default: none)
|
||||
}
|
||||
|
||||
If the server field begins with '/', it will be interpreted as a UNIX
|
||||
socket. Otherwise, it is assumed to be in the format host:port. When
|
||||
a UNIX domain socket is specified, the secret field is optional and an
|
||||
empty secret is used by default. If the server field is not
|
||||
specified, it defaults to |kdcrundir|\ ``/<name>.socket``.
|
||||
|
||||
When forwarding the request over RADIUS, by default the principal is
|
||||
used in the User-Name attribute of the RADIUS packet. The strip_realm
|
||||
parameter controls whether the principal is forwarded with or without
|
||||
the realm portion.
|
||||
|
||||
If an indicator field is present, tickets issued using this token type
|
||||
will be annotated with the specified authentication indicator (see
|
||||
:ref:`auth_indicator`). This key may be specified multiple times to
|
||||
add multiple indicators.
|
||||
|
||||
|
||||
The default token type
|
||||
----------------------
|
||||
|
||||
A default token type is used internally when no token type is specified for a
|
||||
given user. It is defined as follows::
|
||||
|
||||
[otp]
|
||||
DEFAULT = {
|
||||
strip_realm = false
|
||||
}
|
||||
|
||||
The administrator may override the internal ``DEFAULT`` token type
|
||||
simply by defining a configuration with the same name.
|
||||
|
||||
|
||||
Token instance configuration
|
||||
----------------------------
|
||||
|
||||
To enable OTP for a client principal, the administrator must define
|
||||
the **otp** string attribute for that principal. (See
|
||||
:ref:`set_string`.) The **otp** user string is a JSON string of the
|
||||
format:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
[{
|
||||
"type": <string>,
|
||||
"username": <string>,
|
||||
"indicators": [<string>, ...]
|
||||
}, ...]
|
||||
|
||||
This is an array of token objects. Both fields of token objects are
|
||||
optional. The **type** field names the token type of this token; if
|
||||
not specified, it defaults to ``DEFAULT``. The **username** field
|
||||
specifies the value to be sent in the User-Name RADIUS attribute. If
|
||||
not specified, the principal name is sent, with or without realm as
|
||||
defined in the token type. The **indicators** field specifies a list
|
||||
of authentication indicators to annotate tickets with, overriding any
|
||||
indicators specified in the token type.
|
||||
|
||||
For ease of configuration, an empty array (``[]``) is treated as
|
||||
equivalent to one DEFAULT token (``[{}]``).
|
||||
|
||||
|
||||
Other considerations
|
||||
--------------------
|
||||
|
||||
#. FAST is required for OTP to work.
|
||||
354
crypto/krb5/doc/admin/pkinit.rst
Normal file
354
crypto/krb5/doc/admin/pkinit.rst
Normal file
|
|
@ -0,0 +1,354 @@
|
|||
.. _pkinit:
|
||||
|
||||
PKINIT configuration
|
||||
====================
|
||||
|
||||
PKINIT is a preauthentication mechanism for Kerberos 5 which uses
|
||||
X.509 certificates to authenticate the KDC to clients and vice versa.
|
||||
PKINIT can also be used to enable anonymity support, allowing clients
|
||||
to communicate securely with the KDC or with application servers
|
||||
without authenticating as a particular client principal.
|
||||
|
||||
|
||||
Creating certificates
|
||||
---------------------
|
||||
|
||||
PKINIT requires an X.509 certificate for the KDC and one for each
|
||||
client principal which will authenticate using PKINIT. For anonymous
|
||||
PKINIT, a KDC certificate is required, but client certificates are
|
||||
not. A commercially issued server certificate can be used for the KDC
|
||||
certificate, but generally cannot be used for client certificates.
|
||||
|
||||
The instruction in this section describe how to establish a
|
||||
certificate authority and create standard PKINIT certificates. Skip
|
||||
this section if you are using a commercially issued server certificate
|
||||
as the KDC certificate for anonymous PKINIT, or if you are configuring
|
||||
a client to use an Active Directory KDC.
|
||||
|
||||
|
||||
Generating a certificate authority certificate
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can establish a new certificate authority (CA) for use with a
|
||||
PKINIT deployment with the commands::
|
||||
|
||||
openssl genrsa -out cakey.pem 2048
|
||||
openssl req -key cakey.pem -new -x509 -out cacert.pem -days 3650
|
||||
|
||||
The second command will ask for the values of several certificate
|
||||
fields. These fields can be set to any values. You can adjust the
|
||||
expiration time of the CA certificate by changing the number after
|
||||
``-days``. Since the CA certificate must be deployed to client
|
||||
machines each time it changes, it should normally have an expiration
|
||||
time far in the future; however, expiration times after 2037 may cause
|
||||
interoperability issues in rare circumstances.
|
||||
|
||||
The result of these commands will be two files, cakey.pem and
|
||||
cacert.pem. cakey.pem will contain a 2048-bit RSA private key, which
|
||||
must be carefully protected. cacert.pem will contain the CA
|
||||
certificate, which must be placed in the filesystems of the KDC and
|
||||
each client host. cakey.pem will be required to create KDC and client
|
||||
certificates.
|
||||
|
||||
|
||||
Generating a KDC certificate
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A KDC certificate for use with PKINIT is required to have some unusual
|
||||
fields, which makes generating them with OpenSSL somewhat complicated.
|
||||
First, you will need a file containing the following::
|
||||
|
||||
[kdc_cert]
|
||||
basicConstraints=CA:FALSE
|
||||
keyUsage=nonRepudiation,digitalSignature,keyEncipherment,keyAgreement
|
||||
extendedKeyUsage=1.3.6.1.5.2.3.5
|
||||
subjectKeyIdentifier=hash
|
||||
authorityKeyIdentifier=keyid,issuer
|
||||
issuerAltName=issuer:copy
|
||||
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name
|
||||
|
||||
[kdc_princ_name]
|
||||
realm=EXP:0,GeneralString:${ENV::REALM}
|
||||
principal_name=EXP:1,SEQUENCE:kdc_principal_seq
|
||||
|
||||
[kdc_principal_seq]
|
||||
name_type=EXP:0,INTEGER:2
|
||||
name_string=EXP:1,SEQUENCE:kdc_principals
|
||||
|
||||
[kdc_principals]
|
||||
princ1=GeneralString:krbtgt
|
||||
princ2=GeneralString:${ENV::REALM}
|
||||
|
||||
If the above contents are placed in extensions.kdc, you can generate
|
||||
and sign a KDC certificate with the following commands::
|
||||
|
||||
openssl genrsa -out kdckey.pem 2048
|
||||
openssl req -new -out kdc.req -key kdckey.pem
|
||||
env REALM=YOUR_REALMNAME openssl x509 -req -in kdc.req \
|
||||
-CAkey cakey.pem -CA cacert.pem -out kdc.pem -days 365 \
|
||||
-extfile extensions.kdc -extensions kdc_cert -CAcreateserial
|
||||
rm kdc.req
|
||||
|
||||
The second command will ask for the values of certificate fields,
|
||||
which can be set to any values. In the third command, substitute your
|
||||
KDC's realm name for YOUR_REALMNAME. You can adjust the certificate's
|
||||
expiration date by changing the number after ``-days``. Remember to
|
||||
create a new KDC certificate before the old one expires.
|
||||
|
||||
The result of this operation will be in two files, kdckey.pem and
|
||||
kdc.pem. Both files must be placed in the KDC's filesystem.
|
||||
kdckey.pem, which contains the KDC's private key, must be carefully
|
||||
protected.
|
||||
|
||||
If you examine the KDC certificate with ``openssl x509 -in kdc.pem
|
||||
-text -noout``, OpenSSL will not know how to display the KDC principal
|
||||
name in the Subject Alternative Name extension, so it will appear as
|
||||
``othername:<unsupported>``. This is normal and does not mean
|
||||
anything is wrong with the KDC certificate.
|
||||
|
||||
|
||||
Generating client certificates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
PKINIT client certificates also must have some unusual certificate
|
||||
fields. To generate a client certificate with OpenSSL for a
|
||||
single-component principal name, you will need an extensions file
|
||||
(different from the KDC extensions file above) containing::
|
||||
|
||||
[client_cert]
|
||||
basicConstraints=CA:FALSE
|
||||
keyUsage=digitalSignature,keyEncipherment,keyAgreement
|
||||
extendedKeyUsage=1.3.6.1.5.2.3.4
|
||||
subjectKeyIdentifier=hash
|
||||
authorityKeyIdentifier=keyid,issuer
|
||||
issuerAltName=issuer:copy
|
||||
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name
|
||||
|
||||
[princ_name]
|
||||
realm=EXP:0,GeneralString:${ENV::REALM}
|
||||
principal_name=EXP:1,SEQUENCE:principal_seq
|
||||
|
||||
[principal_seq]
|
||||
name_type=EXP:0,INTEGER:1
|
||||
name_string=EXP:1,SEQUENCE:principals
|
||||
|
||||
[principals]
|
||||
princ1=GeneralString:${ENV::CLIENT}
|
||||
|
||||
If the above contents are placed in extensions.client, you can
|
||||
generate and sign a client certificate with the following commands::
|
||||
|
||||
openssl genrsa -out clientkey.pem 2048
|
||||
openssl req -new -key clientkey.pem -out client.req
|
||||
env REALM=YOUR_REALMNAME CLIENT=YOUR_PRINCNAME openssl x509 \
|
||||
-CAkey cakey.pem -CA cacert.pem -req -in client.req \
|
||||
-extensions client_cert -extfile extensions.client \
|
||||
-days 365 -out client.pem
|
||||
rm client.req
|
||||
|
||||
Normally, the first two commands should be run on the client host, and
|
||||
the resulting client.req file transferred to the certificate authority
|
||||
host for the third command. As in the previous steps, the second
|
||||
command will ask for the values of certificate fields, which can be
|
||||
set to any values. In the third command, substitute your realm's name
|
||||
for YOUR_REALMNAME and the client's principal name (without realm) for
|
||||
YOUR_PRINCNAME. You can adjust the certificate's expiration date by
|
||||
changing the number after ``-days``.
|
||||
|
||||
The result of this operation will be two files, clientkey.pem and
|
||||
client.pem. Both files must be present on the client's host;
|
||||
clientkey.pem, which contains the client's private key, must be
|
||||
protected from access by others.
|
||||
|
||||
As in the KDC certificate, OpenSSL will display the client principal
|
||||
name as ``othername:<unsupported>`` in the Subject Alternative Name
|
||||
extension of a PKINIT client certificate.
|
||||
|
||||
If the client principal name contains more than one component
|
||||
(e.g. ``host/example.com@REALM``), the ``[principals]`` section of
|
||||
``extensions.client`` must be altered to contain multiple entries.
|
||||
(Simply setting ``CLIENT`` to ``host/example.com`` would generate a
|
||||
certificate for ``host\/example.com@REALM`` which would not match the
|
||||
multi-component principal name.) For a two-component principal, the
|
||||
section should read::
|
||||
|
||||
[principals]
|
||||
princ1=GeneralString:${ENV::CLIENT1}
|
||||
princ2=GeneralString:${ENV::CLIENT2}
|
||||
|
||||
The environment variables ``CLIENT1`` and ``CLIENT2`` must then be set
|
||||
to the first and second components when running ``openssl x509``.
|
||||
|
||||
|
||||
Configuring the KDC
|
||||
-------------------
|
||||
|
||||
The KDC must have filesystem access to the KDC certificate (kdc.pem)
|
||||
and the KDC private key (kdckey.pem). Configure the following
|
||||
relation in the KDC's :ref:`kdc.conf(5)` file, either in the
|
||||
:ref:`kdcdefaults` section or in a :ref:`kdc_realms` subsection (with
|
||||
appropriate pathnames)::
|
||||
|
||||
pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem
|
||||
|
||||
If any clients will authenticate using regular (as opposed to
|
||||
anonymous) PKINIT, the KDC must also have filesystem access to the CA
|
||||
certificate (cacert.pem), and the following configuration (with the
|
||||
appropriate pathname)::
|
||||
|
||||
pkinit_anchors = FILE:/var/lib/krb5kdc/cacert.pem
|
||||
|
||||
Because of the larger size of requests and responses using PKINIT, you
|
||||
may also need to allow TCP access to the KDC::
|
||||
|
||||
kdc_tcp_listen = 88
|
||||
|
||||
Restart the :ref:`krb5kdc(8)` daemon to pick up the configuration
|
||||
changes.
|
||||
|
||||
The principal entry for each PKINIT-using client must be configured to
|
||||
require preauthentication. Ensure this with the command::
|
||||
|
||||
kadmin -q 'modprinc +requires_preauth YOUR_PRINCNAME'
|
||||
|
||||
Starting with release 1.12, it is possible to remove the long-term
|
||||
keys of a principal entry, which can save some space in the database
|
||||
and help to clarify some PKINIT-related error conditions by not asking
|
||||
for a password::
|
||||
|
||||
kadmin -q 'purgekeys -all YOUR_PRINCNAME'
|
||||
|
||||
These principal options can also be specified at principal creation
|
||||
time as follows::
|
||||
|
||||
kadmin -q 'add_principal +requires_preauth -nokey YOUR_PRINCNAME'
|
||||
|
||||
By default, the KDC requires PKINIT client certificates to have the
|
||||
standard Extended Key Usage and Subject Alternative Name attributes
|
||||
for PKINIT. Starting in release 1.16, it is possible to authorize
|
||||
client certificates based on the subject or other criteria instead of
|
||||
the standard PKINIT Subject Alternative Name, by setting the
|
||||
**pkinit_cert_match** string attribute on each client principal entry.
|
||||
For example::
|
||||
|
||||
kadmin set_string user@REALM pkinit_cert_match "<SUBJECT>CN=user@REALM$"
|
||||
|
||||
The **pkinit_cert_match** string attribute follows the syntax used by
|
||||
the :ref:`krb5.conf(5)` **pkinit_cert_match** relation. To allow the
|
||||
use of non-PKINIT client certificates, it will also be necessary to
|
||||
disable key usage checking using the **pkinit_eku_checking** relation;
|
||||
for example::
|
||||
|
||||
[kdcdefaults]
|
||||
pkinit_eku_checking = none
|
||||
|
||||
|
||||
|
||||
Configuring the clients
|
||||
-----------------------
|
||||
|
||||
Client hosts must be configured to trust the issuing authority for the
|
||||
KDC certificate. For a newly established certificate authority, the
|
||||
client host must have filesystem access to the CA certificate
|
||||
(cacert.pem) and the following relation in :ref:`krb5.conf(5)` in the
|
||||
appropriate :ref:`realms` subsection (with appropriate pathnames)::
|
||||
|
||||
pkinit_anchors = FILE:/etc/krb5/cacert.pem
|
||||
|
||||
If the KDC certificate is a commercially issued server certificate,
|
||||
the issuing certificate is most likely included in a system directory.
|
||||
You can specify it by filename as above, or specify the whole
|
||||
directory like so::
|
||||
|
||||
pkinit_anchors = DIR:/etc/ssl/certs
|
||||
|
||||
A commercially issued server certificate will usually not have the
|
||||
standard PKINIT principal name or Extended Key Usage extensions, so
|
||||
the following additional configuration is required::
|
||||
|
||||
pkinit_eku_checking = kpServerAuth
|
||||
pkinit_kdc_hostname = hostname.of.kdc.certificate
|
||||
|
||||
Multiple **pkinit_kdc_hostname** relations can be configured to
|
||||
recognize multiple KDC certificates. If the KDC is an Active
|
||||
Directory domain controller, setting **pkinit_kdc_hostname** is
|
||||
necessary, but it should not be necessary to set
|
||||
**pkinit_eku_checking**.
|
||||
|
||||
To perform regular (as opposed to anonymous) PKINIT authentication, a
|
||||
client host must have filesystem access to a client certificate
|
||||
(client.pem), and the corresponding private key (clientkey.pem).
|
||||
Configure the following relations in the client host's
|
||||
:ref:`krb5.conf(5)` file in the appropriate :ref:`realms` subsection
|
||||
(with appropriate pathnames)::
|
||||
|
||||
pkinit_identities = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem
|
||||
|
||||
If the KDC and client are properly configured, it should now be
|
||||
possible to run ``kinit username`` without entering a password.
|
||||
|
||||
|
||||
.. _anonymous_pkinit:
|
||||
|
||||
Anonymous PKINIT
|
||||
----------------
|
||||
|
||||
Anonymity support in Kerberos allows a client to obtain a ticket
|
||||
without authenticating as any particular principal. Such a ticket can
|
||||
be used as a FAST armor ticket, or to securely communicate with an
|
||||
application server anonymously.
|
||||
|
||||
To configure anonymity support, you must generate or otherwise procure
|
||||
a KDC certificate and configure the KDC host, but you do not need to
|
||||
generate any client certificates. On the KDC, you must set the
|
||||
**pkinit_identity** variable to provide the KDC certificate, but do
|
||||
not need to set the **pkinit_anchors** variable or store the issuing
|
||||
certificate if you won't have any client certificates to verify. On
|
||||
client hosts, you must set the **pkinit_anchors** variable (and
|
||||
possibly **pkinit_kdc_hostname** and **pkinit_eku_checking**) in order
|
||||
to trust the issuing authority for the KDC certificate, but do not
|
||||
need to set the **pkinit_identities** variable.
|
||||
|
||||
Anonymity support is not enabled by default. To enable it, you must
|
||||
create the principal ``WELLKNOWN/ANONYMOUS`` using the command::
|
||||
|
||||
kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS'
|
||||
|
||||
Some Kerberos deployments include application servers which lack
|
||||
proper access control, and grant some level of access to any user who
|
||||
can authenticate. In such an environment, enabling anonymity support
|
||||
on the KDC would present a security issue. If you need to enable
|
||||
anonymity support for TGTs (for use as FAST armor tickets) without
|
||||
enabling anonymous authentication to application servers, you can set
|
||||
the variable **restrict_anonymous_to_tgt** to ``true`` in the
|
||||
appropriate :ref:`kdc_realms` subsection of the KDC's
|
||||
:ref:`kdc.conf(5)` file.
|
||||
|
||||
To obtain anonymous credentials on a client, run ``kinit -n``, or
|
||||
``kinit -n @REALMNAME`` to specify a realm. The resulting tickets
|
||||
will have the client name ``WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS``.
|
||||
|
||||
|
||||
Freshness tokens
|
||||
----------------
|
||||
|
||||
Freshness tokens can ensure that the client has recently had access to
|
||||
its certificate private key. If freshness tokens are not required by
|
||||
the KDC, a client program with temporary possession of the private key
|
||||
can compose requests for future timestamps and use them later.
|
||||
|
||||
In release 1.17 and later, freshness tokens are supported by the
|
||||
client and are sent by the KDC when the client indicates support for
|
||||
them. Because not all clients support freshness tokens yet, they are
|
||||
not required by default. To check if freshness tokens are supported
|
||||
by a realm's clients, look in the KDC logs for the lines::
|
||||
|
||||
PKINIT: freshness token received from <client principal>
|
||||
PKINIT: no freshness token received from <client principal>
|
||||
|
||||
To require freshness tokens for all clients in a realm (except for
|
||||
clients authenticating anonymously), set the
|
||||
**pkinit_require_freshness** variable to ``true`` in the appropriate
|
||||
:ref:`kdc_realms` subsection of the KDC's :ref:`kdc.conf(5)` file. To
|
||||
test that this option is in effect, run ``kinit -X disable_freshness``
|
||||
and verify that authentication is unsuccessful.
|
||||
126
crypto/krb5/doc/admin/princ_dns.rst
Normal file
126
crypto/krb5/doc/admin/princ_dns.rst
Normal file
|
|
@ -0,0 +1,126 @@
|
|||
Principal names and DNS
|
||||
=======================
|
||||
|
||||
Kerberos clients can do DNS lookups to canonicalize service principal
|
||||
names. This can cause difficulties when setting up Kerberos
|
||||
application servers, especially when the client's name for the service
|
||||
is different from what the service thinks its name is.
|
||||
|
||||
|
||||
Service principal names
|
||||
-----------------------
|
||||
|
||||
A frequently used kind of principal name is the host-based service
|
||||
principal name. This kind of principal name has two components: a
|
||||
service name and a hostname. For example, ``imap/imap.example.com``
|
||||
is the principal name of the "imap" service on the host
|
||||
"imap.example.com". Other possible service names for the first
|
||||
component include "host" (remote login services such as ssh), "HTTP",
|
||||
and "nfs" (Network File System).
|
||||
|
||||
Service administrators often publish well-known hostname aliases that
|
||||
they would prefer users to use instead of the canonical name of the
|
||||
service host. This gives service administrators more flexibility in
|
||||
deploying services. For example, a shell login server might be named
|
||||
"long-vanity-hostname.example.com", but users will naturally prefer to
|
||||
type something like "login.example.com". Hostname aliases also allow
|
||||
for administrators to set up load balancing for some sorts of services
|
||||
based on rotating ``CNAME`` records in DNS.
|
||||
|
||||
|
||||
Service principal canonicalization
|
||||
----------------------------------
|
||||
|
||||
In the MIT krb5 client library, canonicalization of host-based service
|
||||
principals is controlled by the **dns_canonicalize_hostname**,
|
||||
**rnds**, and **qualify_shortname** variables in :ref:`libdefaults`.
|
||||
|
||||
If **dns_canonicalize_hostname** is set to ``true`` (the default
|
||||
value), the client performs forward resolution by looking up the IPv4
|
||||
and/or IPv6 addresses of the hostname using ``getaddrinfo()``. This
|
||||
process will typically add a domain suffix to the hostname if needed,
|
||||
and follow CNAME records in the DNS. If **rdns** is also set to
|
||||
``true`` (the default), the client will then perform a reverse lookup
|
||||
of the first returned Internet address using ``getnameinfo()``,
|
||||
finding the name associated with the PTR record.
|
||||
|
||||
If **dns_canonicalize_hostname** is set to ``false``, the hostname is
|
||||
not canonicalized using DNS. If the hostname has only one component
|
||||
(i.e. it contains no "." characters), the host's primary DNS search
|
||||
domain will be appended, if there is one. The **qualify_shortname**
|
||||
variable can be used to override or disable this suffix.
|
||||
|
||||
If **dns_canonicalize_hostname** is set to ``fallback`` (added in
|
||||
release 1.18), the hostname is initially treated according to the
|
||||
rules for ``dns_canonicalize_hostname=false``. If a ticket request
|
||||
fails because the service principal is unknown, the hostname will be
|
||||
canonicalized according to the rules for
|
||||
``dns_canonicalize_hostname=true`` and the request will be retried.
|
||||
|
||||
In all cases, the hostname is converted to lowercase, and any trailing
|
||||
dot is removed.
|
||||
|
||||
|
||||
|
||||
Reverse DNS mismatches
|
||||
----------------------
|
||||
|
||||
Sometimes, an enterprise will have control over its forward DNS but
|
||||
not its reverse DNS. The reverse DNS is sometimes under the control
|
||||
of the Internet service provider of the enterprise, and the enterprise
|
||||
may not have much influence in setting up reverse DNS records for its
|
||||
address space. If there are difficulties with getting forward and
|
||||
reverse DNS to match, it is best to set ``rdns = false`` on client
|
||||
machines.
|
||||
|
||||
|
||||
Overriding application behavior
|
||||
-------------------------------
|
||||
|
||||
Applications can choose to use a default hostname component in their
|
||||
service principal name when accepting authentication, which avoids
|
||||
some sorts of hostname mismatches. Because not all relevant
|
||||
applications do this yet, using the :ref:`krb5.conf(5)` setting::
|
||||
|
||||
[libdefaults]
|
||||
ignore_acceptor_hostname = true
|
||||
|
||||
will allow the Kerberos library to override the application's choice
|
||||
of service principal hostname and will allow a server program to
|
||||
accept incoming authentications using any key in its keytab that
|
||||
matches the service name and realm name (if given). This setting
|
||||
defaults to "false" and is available in releases krb5-1.10 and later.
|
||||
|
||||
|
||||
Provisioning keytabs
|
||||
--------------------
|
||||
|
||||
One service principal entry that should be in the keytab is a
|
||||
principal whose hostname component is the canonical hostname that
|
||||
``getaddrinfo()`` reports for all known aliases for the host. If the
|
||||
reverse DNS information does not match this canonical hostname, an
|
||||
additional service principal entry should be in the keytab for this
|
||||
different hostname.
|
||||
|
||||
|
||||
Specific application advice
|
||||
---------------------------
|
||||
|
||||
Secure shell (ssh)
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Setting ``GSSAPIStrictAcceptorCheck = no`` in the configuration file
|
||||
of modern versions of the openssh daemon will allow the daemon to try
|
||||
any key in its keytab when accepting a connection, rather than looking
|
||||
for the keytab entry that matches the host's own idea of its name
|
||||
(typically the name that ``gethostname()`` returns). This requires
|
||||
krb5-1.10 or later.
|
||||
|
||||
OpenLDAP (ldapsearch, etc.)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
OpenLDAP's SASL implementation performs reverse DNS lookup in order to
|
||||
canonicalize service principal names, even if **rdns** is set to
|
||||
``false`` in the Kerberos configuration. To disable this behavior,
|
||||
add ``SASL_NOCANON on`` to ``ldap.conf``, or set the
|
||||
``LDAPSASL_NOCANON`` environment variable.
|
||||
268
crypto/krb5/doc/admin/realm_config.rst
Normal file
268
crypto/krb5/doc/admin/realm_config.rst
Normal file
|
|
@ -0,0 +1,268 @@
|
|||
Realm configuration decisions
|
||||
=============================
|
||||
|
||||
Before installing Kerberos V5, it is necessary to consider the
|
||||
following issues:
|
||||
|
||||
* The name of your Kerberos realm (or the name of each realm, if you
|
||||
need more than one).
|
||||
* How you will assign your hostnames to Kerberos realms.
|
||||
* Which ports your KDC and and kadmind services will use, if they will
|
||||
not be using the default ports.
|
||||
* How many replica KDCs you need and where they should be located.
|
||||
* The hostnames of your primary and replica KDCs.
|
||||
* How frequently you will propagate the database from the primary KDC
|
||||
to the replica KDCs.
|
||||
|
||||
|
||||
Realm name
|
||||
----------
|
||||
|
||||
Although your Kerberos realm can be any ASCII string, convention is to
|
||||
make it the same as your domain name, in upper-case letters.
|
||||
|
||||
For example, hosts in the domain ``example.com`` would be in the
|
||||
Kerberos realm::
|
||||
|
||||
EXAMPLE.COM
|
||||
|
||||
If you need multiple Kerberos realms, MIT recommends that you use
|
||||
descriptive names which end with your domain name, such as::
|
||||
|
||||
BOSTON.EXAMPLE.COM
|
||||
HOUSTON.EXAMPLE.COM
|
||||
|
||||
|
||||
.. _mapping_hostnames:
|
||||
|
||||
Mapping hostnames onto Kerberos realms
|
||||
--------------------------------------
|
||||
|
||||
Mapping hostnames onto Kerberos realms is done in one of three ways.
|
||||
|
||||
The first mechanism works through a set of rules in the
|
||||
:ref:`domain_realm` section of :ref:`krb5.conf(5)`. You can specify
|
||||
mappings for an entire domain or on a per-hostname basis. Typically
|
||||
you would do this by specifying the mappings for a given domain or
|
||||
subdomain and listing the exceptions.
|
||||
|
||||
The second mechanism is to use KDC host-based service referrals. With
|
||||
this method, the KDC's krb5.conf has a full [domain_realm] mapping for
|
||||
hosts, but the clients do not, or have mappings for only a subset of
|
||||
the hosts they might contact. When a client needs to contact a server
|
||||
host for which it has no mapping, it will ask the client realm's KDC
|
||||
for the service ticket, and will receive a referral to the appropriate
|
||||
service realm.
|
||||
|
||||
To use referrals, clients must be running MIT krb5 1.6 or later, and
|
||||
the KDC must be running MIT krb5 1.7 or later. The
|
||||
**host_based_services** and **no_host_referral** variables in the
|
||||
:ref:`kdc_realms` section of :ref:`kdc.conf(5)` can be used to
|
||||
fine-tune referral behavior on the KDC.
|
||||
|
||||
It is also possible for clients to use DNS TXT records, if
|
||||
**dns_lookup_realm** is enabled in :ref:`krb5.conf(5)`. Such lookups
|
||||
are disabled by default because DNS is an insecure protocol and security
|
||||
holes could result if DNS records are spoofed. If enabled, the client
|
||||
will try to look up a TXT record formed by prepending the prefix
|
||||
``_kerberos`` to the hostname in question. If that record is not
|
||||
found, the client will attempt a lookup by prepending ``_kerberos`` to the
|
||||
host's domain name, then its parent domain, up to the top-level domain.
|
||||
For the hostname ``boston.engineering.example.com``, the names looked up
|
||||
would be::
|
||||
|
||||
_kerberos.boston.engineering.example.com
|
||||
_kerberos.engineering.example.com
|
||||
_kerberos.example.com
|
||||
_kerberos.com
|
||||
|
||||
The value of the first TXT record found is taken as the realm name.
|
||||
|
||||
Even if you do not choose to use this mechanism within your site,
|
||||
you may wish to set it up anyway, for use when interacting with other sites.
|
||||
|
||||
|
||||
Ports for the KDC and admin services
|
||||
------------------------------------
|
||||
|
||||
The default ports used by Kerberos are port 88 for the KDC and port
|
||||
749 for the admin server. You can, however, choose to run on other
|
||||
ports, as long as they are specified in each host's
|
||||
:ref:`krb5.conf(5)` files or in DNS SRV records, and the
|
||||
:ref:`kdc.conf(5)` file on each KDC. For a more thorough treatment of
|
||||
port numbers used by the Kerberos V5 programs, refer to the
|
||||
:ref:`conf_firewall`.
|
||||
|
||||
|
||||
Replica KDCs
|
||||
------------
|
||||
|
||||
Replica KDCs provide an additional source of Kerberos ticket-granting
|
||||
services in the event of inaccessibility of the primary KDC. The
|
||||
number of replica KDCs you need and the decision of where to place them,
|
||||
both physically and logically, depends on the specifics of your
|
||||
network.
|
||||
|
||||
Kerberos authentication requires that each client be able to contact a
|
||||
KDC. Therefore, you need to anticipate any likely reason a KDC might
|
||||
be unavailable and have a replica KDC to take up the slack.
|
||||
|
||||
Some considerations include:
|
||||
|
||||
* Have at least one replica KDC as a backup, for when the primary KDC
|
||||
is down, is being upgraded, or is otherwise unavailable.
|
||||
* If your network is split such that a network outage is likely to
|
||||
cause a network partition (some segment or segments of the network
|
||||
to become cut off or isolated from other segments), have a replica
|
||||
KDC accessible to each segment.
|
||||
* If possible, have at least one replica KDC in a different building
|
||||
from the primary, in case of power outages, fires, or other
|
||||
localized disasters.
|
||||
|
||||
|
||||
.. _kdc_hostnames:
|
||||
|
||||
Hostnames for KDCs
|
||||
------------------
|
||||
|
||||
MIT recommends that your KDCs have a predefined set of CNAME records
|
||||
(DNS hostname aliases), such as ``kerberos`` for the primary KDC and
|
||||
``kerberos-1``, ``kerberos-2``, ... for the replica KDCs. This way,
|
||||
if you need to swap a machine, you only need to change a DNS entry,
|
||||
rather than having to change hostnames.
|
||||
|
||||
As of MIT krb5 1.4, clients can locate a realm's KDCs through DNS
|
||||
using SRV records (:rfc:`2782`), assuming the Kerberos realm name is
|
||||
also a DNS domain name. These records indicate the hostname and port
|
||||
number to contact for that service, optionally with weighting and
|
||||
prioritization. The domain name used in the SRV record name is the
|
||||
realm name. Several different Kerberos-related service names are
|
||||
used:
|
||||
|
||||
_kerberos._udp
|
||||
This is for contacting any KDC by UDP. This entry will be used
|
||||
the most often. Normally you should list port 88 on each of your
|
||||
KDCs.
|
||||
_kerberos._tcp
|
||||
This is for contacting any KDC by TCP. Normally you should use
|
||||
port 88. This entry should be omitted if the KDC does not listen
|
||||
on TCP ports, as was the default prior to release 1.13.
|
||||
_kerberos-master._udp
|
||||
This entry should refer to those KDCs, if any, that will
|
||||
immediately see password changes to the Kerberos database. If a
|
||||
user is logging in and the password appears to be incorrect, the
|
||||
client will retry with the primary KDC before failing with an
|
||||
"incorrect password" error given.
|
||||
|
||||
If you have only one KDC, or for whatever reason there is no
|
||||
accessible KDC that would get database changes faster than the
|
||||
others, you do not need to define this entry.
|
||||
_kerberos-adm._tcp
|
||||
This should list port 749 on your primary KDC. Support for it is
|
||||
not complete at this time, but it will eventually be used by the
|
||||
:ref:`kadmin(1)` program and related utilities. For now, you will
|
||||
also need the **admin_server** variable in :ref:`krb5.conf(5)`.
|
||||
_kerberos-master._tcp
|
||||
The corresponding TCP port for _kerberos-master._udp, assuming the
|
||||
primary KDC listens on a TCP port.
|
||||
_kpasswd._udp
|
||||
This entry should list port 464 on your primary KDC. It is used
|
||||
when a user changes her password. If this entry is not defined
|
||||
but a _kerberos-adm._tcp entry is defined, the client will use the
|
||||
_kerberos-adm._tcp entry with the port number changed to 464.
|
||||
_kpasswd._tcp
|
||||
The corresponding TCP port for _kpasswd._udp.
|
||||
|
||||
The DNS SRV specification requires that the hostnames listed be the
|
||||
canonical names, not aliases. So, for example, you might include the
|
||||
following records in your (BIND-style) zone file::
|
||||
|
||||
$ORIGIN foobar.com.
|
||||
_kerberos TXT "FOOBAR.COM"
|
||||
kerberos CNAME daisy
|
||||
kerberos-1 CNAME use-the-force-luke
|
||||
kerberos-2 CNAME bunny-rabbit
|
||||
_kerberos._udp SRV 0 0 88 daisy
|
||||
SRV 0 0 88 use-the-force-luke
|
||||
SRV 0 0 88 bunny-rabbit
|
||||
_kerberos-master._udp SRV 0 0 88 daisy
|
||||
_kerberos-adm._tcp SRV 0 0 749 daisy
|
||||
_kpasswd._udp SRV 0 0 464 daisy
|
||||
|
||||
Clients can also be configured with the explicit location of services
|
||||
using the **kdc**, **master_kdc**, **admin_server**, and
|
||||
**kpasswd_server** variables in the :ref:`realms` section of
|
||||
:ref:`krb5.conf(5)`. Even if some clients will be configured with
|
||||
explicit server locations, providing SRV records will still benefit
|
||||
unconfigured clients, and be useful for other sites.
|
||||
|
||||
|
||||
.. _kdc_discovery:
|
||||
|
||||
KDC Discovery
|
||||
-------------
|
||||
|
||||
As of MIT krb5 1.15, clients can also locate KDCs in DNS through URI
|
||||
records (:rfc:`7553`). Limitations with the SRV record format may
|
||||
result in extra DNS queries in situations where a client must failover
|
||||
to other transport types, or find a primary server. The URI record
|
||||
can convey more information about a realm's KDCs with a single query.
|
||||
|
||||
The client performs a query for the following URI records:
|
||||
|
||||
* ``_kerberos.REALM`` for finding KDCs.
|
||||
* ``_kerberos-adm.REALM`` for finding kadmin services.
|
||||
* ``_kpasswd.REALM`` for finding password services.
|
||||
|
||||
The URI record includes a priority, weight, and a URI string that
|
||||
consists of case-insensitive colon separated fields, in the form
|
||||
``scheme:[flags]:transport:residual``.
|
||||
|
||||
* *scheme* defines the registered URI type. It should always be
|
||||
``krb5srv``.
|
||||
* *flags* contains zero or more flag characters. Currently the only
|
||||
valid flag is ``m``, which indicates that the record is for a
|
||||
primary server.
|
||||
* *transport* defines the transport type of the residual URL or
|
||||
address. Accepted values are ``tcp``, ``udp``, or ``kkdcp`` for the
|
||||
MS-KKDCP type.
|
||||
* *residual* contains the hostname, IP address, or URL to be
|
||||
contacted using the specified transport, with an optional port
|
||||
extension. The MS-KKDCP transport type uses a HTTPS URL, and can
|
||||
include a port and/or path extension.
|
||||
|
||||
An example of URI records in a zone file::
|
||||
|
||||
_kerberos.EXAMPLE.COM URI 10 1 krb5srv:m:tcp:kdc1.example.com
|
||||
URI 20 1 krb5srv:m:udp:kdc2.example.com:89
|
||||
URI 40 1 krb5srv::udp:10.10.0.23
|
||||
URI 30 1 krb5srv::kkdcp:https://proxy:89/auth
|
||||
|
||||
URI lookups are enabled by default, and can be disabled by setting
|
||||
**dns_uri_lookup** in the :ref:`libdefaults` section of
|
||||
:ref:`krb5.conf(5)` to False. When enabled, URI lookups take
|
||||
precedence over SRV lookups, falling back to SRV lookups if no URI
|
||||
records are found.
|
||||
|
||||
|
||||
.. _db_prop:
|
||||
|
||||
Database propagation
|
||||
--------------------
|
||||
|
||||
The Kerberos database resides on the primary KDC, and must be
|
||||
propagated regularly (usually by a cron job) to the replica KDCs. In
|
||||
deciding how frequently the propagation should happen, you will need
|
||||
to balance the amount of time the propagation takes against the
|
||||
maximum reasonable amount of time a user should have to wait for a
|
||||
password change to take effect.
|
||||
|
||||
If the propagation time is longer than this maximum reasonable time
|
||||
(e.g., you have a particularly large database, you have a lot of
|
||||
replicas, or you experience frequent network delays), you may wish to
|
||||
cut down on your propagation delay by performing the propagation in
|
||||
parallel. To do this, have the primary KDC propagate the database to
|
||||
one set of replicas, and then have each of these replicas propagate
|
||||
the database to additional replicas.
|
||||
|
||||
See also :ref:`incr_db_prop`
|
||||
56
crypto/krb5/doc/admin/spake.rst
Normal file
56
crypto/krb5/doc/admin/spake.rst
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
.. _spake:
|
||||
|
||||
SPAKE Preauthentication
|
||||
=======================
|
||||
|
||||
SPAKE preauthentication (added in release 1.17) uses public key
|
||||
cryptography techniques to protect against :ref:`password dictionary
|
||||
attacks <dictionary>`. Unlike :ref:`PKINIT <pkinit>`, it does not
|
||||
require any additional infrastructure such as certificates; it simply
|
||||
needs to be turned on. Using SPAKE preauthentication may modestly
|
||||
increase the CPU and network load on the KDC.
|
||||
|
||||
SPAKE preauthentication can use one of four elliptic curve groups for
|
||||
its password-authenticated key exchange. The recommended group is
|
||||
``edwards25519``; three NIST curves (``P-256``, ``P-384``, and
|
||||
``P-521``) are also supported.
|
||||
|
||||
By default, SPAKE with the ``edwards25519`` group is enabled on
|
||||
clients, but the KDC does not offer SPAKE by default. To turn it on,
|
||||
set the **spake_preauth_groups** variable in :ref:`libdefaults` to a
|
||||
list of allowed groups. This variable affects both the client and the
|
||||
KDC. Simply setting it to ``edwards25519`` is recommended::
|
||||
|
||||
[libdefaults]
|
||||
spake_preauth_groups = edwards25519
|
||||
|
||||
Set the **+requires_preauth** and **-allow_svr** flags on client
|
||||
principal entries, as you would for any preauthentication mechanism::
|
||||
|
||||
kadmin: modprinc +requires_preauth -allow_svr PRINCNAME
|
||||
|
||||
Clients which do not implement SPAKE preauthentication will fall back
|
||||
to encrypted timestamp.
|
||||
|
||||
An active attacker can force a fallback to encrypted timestamp by
|
||||
modifying the initial KDC response, defeating the protection against
|
||||
dictionary attacks. To prevent this fallback on clients which do
|
||||
implement SPAKE preauthentication, set the
|
||||
**disable_encrypted_timestamp** variable to ``true`` in the
|
||||
:ref:`realms` subsection for realms whose KDCs offer SPAKE
|
||||
preauthentication.
|
||||
|
||||
By default, SPAKE preauthentication requires an extra network round
|
||||
trip to the KDC during initial authentication. If most of the clients
|
||||
in a realm support SPAKE, this extra round trip can be eliminated
|
||||
using an optimistic challenge, by setting the
|
||||
**spake_preauth_kdc_challenge** variable in :ref:`kdcdefaults` to a
|
||||
single group name::
|
||||
|
||||
[kdcdefaults]
|
||||
spake_preauth_kdc_challenge = edwards25519
|
||||
|
||||
Using optimistic challenge will cause the KDC to do extra work for
|
||||
initial authentication requests that do not result in SPAKE
|
||||
preauthentication, but will save work when SPAKE preauthentication is
|
||||
used.
|
||||
135
crypto/krb5/doc/admin/troubleshoot.rst
Normal file
135
crypto/krb5/doc/admin/troubleshoot.rst
Normal file
|
|
@ -0,0 +1,135 @@
|
|||
.. _troubleshoot:
|
||||
|
||||
Troubleshooting
|
||||
===============
|
||||
|
||||
.. _trace_logging:
|
||||
|
||||
Trace logging
|
||||
-------------
|
||||
|
||||
Most programs using MIT krb5 1.9 or later can be made to provide
|
||||
information about internal krb5 library operations using trace
|
||||
logging. To enable this, set the **KRB5_TRACE** environment variable
|
||||
to a filename before running the program. On many operating systems,
|
||||
the filename ``/dev/stdout`` can be used to send trace logging output
|
||||
to standard output.
|
||||
|
||||
Some programs do not honor **KRB5_TRACE**, either because they use
|
||||
secure library contexts (this generally applies to setuid programs and
|
||||
parts of the login system) or because they take direct control of the
|
||||
trace logging system using the API.
|
||||
|
||||
Here is a short example showing trace logging output for an invocation
|
||||
of the :ref:`kvno(1)` command::
|
||||
|
||||
shell% env KRB5_TRACE=/dev/stdout kvno krbtgt/KRBTEST.COM
|
||||
[9138] 1332348778.823276: Getting credentials user@KRBTEST.COM ->
|
||||
krbtgt/KRBTEST.COM@KRBTEST.COM using ccache
|
||||
FILE:/me/krb5/build/testdir/ccache
|
||||
[9138] 1332348778.823381: Retrieving user@KRBTEST.COM ->
|
||||
krbtgt/KRBTEST.COM@KRBTEST.COM from
|
||||
FILE:/me/krb5/build/testdir/ccache with result: 0/Unknown code 0
|
||||
krbtgt/KRBTEST.COM@KRBTEST.COM: kvno = 1
|
||||
|
||||
|
||||
List of errors
|
||||
--------------
|
||||
|
||||
Frequently seen errors
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. :ref:`init_creds_ETYPE_NOSUPP`
|
||||
|
||||
#. :ref:`cert_chain_ETYPE_NOSUPP`
|
||||
|
||||
#. :ref:`err_cert_chain_cert_expired`
|
||||
|
||||
|
||||
Errors seen by admins
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. _prop_failed_start:
|
||||
|
||||
#. :ref:`kprop_no_route`
|
||||
|
||||
#. :ref:`kprop_con_refused`
|
||||
|
||||
#. :ref:`kprop_sendauth_exchange`
|
||||
|
||||
.. _prop_failed_end:
|
||||
|
||||
-----
|
||||
|
||||
.. _init_creds_etype_nosupp:
|
||||
|
||||
KDC has no support for encryption type while getting initial credentials
|
||||
........................................................................
|
||||
|
||||
.. _cert_chain_etype_nosupp:
|
||||
|
||||
|
||||
credential verification failed: KDC has no support for encryption type
|
||||
......................................................................
|
||||
|
||||
This most commonly happens when trying to use a principal with only
|
||||
DES keys, in a release (MIT krb5 1.7 or later) which disables DES by
|
||||
default. DES encryption is considered weak due to its inadequate key
|
||||
size. If you cannot migrate away from its use, you can re-enable DES
|
||||
by adding ``allow_weak_crypto = true`` to the :ref:`libdefaults`
|
||||
section of :ref:`krb5.conf(5)`.
|
||||
|
||||
|
||||
.. _err_cert_chain_cert_expired:
|
||||
|
||||
Cannot create cert chain: certificate has expired
|
||||
.................................................
|
||||
|
||||
This error message indicates that PKINIT authentication failed because
|
||||
the client certificate, KDC certificate, or one of the certificates in
|
||||
the signing chain above them has expired.
|
||||
|
||||
If the KDC certificate has expired, this message appears in the KDC
|
||||
log file, and the client will receive a "Preauthentication failed"
|
||||
error. (Prior to release 1.11, the KDC log file message erroneously
|
||||
appears as "Out of memory". Prior to release 1.12, the client will
|
||||
receive a "Generic error".)
|
||||
|
||||
If the client or a signing certificate has expired, this message may
|
||||
appear in trace_logging_ output from :ref:`kinit(1)` or, starting in
|
||||
release 1.12, as an error message from kinit or another program which
|
||||
gets initial tickets. The error message is more likely to appear
|
||||
properly on the client if the principal entry has no long-term keys.
|
||||
|
||||
.. _kprop_no_route:
|
||||
|
||||
kprop: No route to host while connecting to server
|
||||
..................................................
|
||||
|
||||
Make sure that the hostname of the replica KDC (as given to kprop) is
|
||||
correct, and that any firewalls between the primary and the replica
|
||||
allow a connection on port 754.
|
||||
|
||||
.. _kprop_con_refused:
|
||||
|
||||
kprop: Connection refused while connecting to server
|
||||
....................................................
|
||||
|
||||
If the replica KDC is intended to run kpropd out of inetd, make sure
|
||||
that inetd is configured to accept krb5_prop connections. inetd may
|
||||
need to be restarted or sent a SIGHUP to recognize the new
|
||||
configuration. If the replica is intended to run kpropd in standalone
|
||||
mode, make sure that it is running.
|
||||
|
||||
.. _kprop_sendauth_exchange:
|
||||
|
||||
kprop: Server rejected authentication (during sendauth exchange) while authenticating to server
|
||||
...............................................................................................
|
||||
|
||||
Make sure that:
|
||||
|
||||
#. The time is synchronized between the primary and replica KDCs.
|
||||
#. The master stash file was copied from the primary to the expected
|
||||
location on the replica.
|
||||
#. The replica has a keytab file in the default location containing a
|
||||
``host`` principal for the replica's hostname.
|
||||
27
crypto/krb5/doc/admin/various_envs.rst
Normal file
27
crypto/krb5/doc/admin/various_envs.rst
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
Various links
|
||||
=============
|
||||
|
||||
Whitepapers
|
||||
-----------
|
||||
|
||||
#. https://kerberos.org/software/whitepapers.html
|
||||
|
||||
|
||||
Tutorials
|
||||
---------
|
||||
|
||||
#. Fulvio Ricciardi <https://www.kerberos.org/software/tutorial.html>_
|
||||
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
#. https://wiki.ncsa.illinois.edu/display/ITS/Windows+Kerberos+Troubleshooting
|
||||
|
||||
#. https://www.shrubbery.net/solaris9ab/SUNWaadm/SYSADV6/p27.html
|
||||
|
||||
#. https://docs.oracle.com/cd/E19253-01/816-4557/trouble-1/index.html
|
||||
|
||||
#. https://docs.microsoft.com/en-us/previous-versions/tn-archive/bb463167(v=technet.10)#EBAA
|
||||
|
||||
#. https://bugs.launchpad.net/ubuntu/+source/libpam-heimdal/+bug/86528
|
||||
727
crypto/krb5/doc/appdev/gssapi.rst
Normal file
727
crypto/krb5/doc/appdev/gssapi.rst
Normal file
|
|
@ -0,0 +1,727 @@
|
|||
Developing with GSSAPI
|
||||
======================
|
||||
|
||||
The GSSAPI (Generic Security Services API) allows applications to
|
||||
communicate securely using Kerberos 5 or other security mechanisms.
|
||||
We recommend using the GSSAPI (or a higher-level framework which
|
||||
encompasses GSSAPI, such as SASL) for secure network communication
|
||||
over using the libkrb5 API directly.
|
||||
|
||||
GSSAPIv2 is specified in :rfc:`2743` and :rfc:`2744`. Also see
|
||||
:rfc:`7546` for a description of how to use the GSSAPI in a client or
|
||||
server program.
|
||||
|
||||
This documentation will describe how various ways of using the
|
||||
GSSAPI will behave with the krb5 mechanism as implemented in MIT krb5,
|
||||
as well as krb5-specific extensions to the GSSAPI.
|
||||
|
||||
|
||||
Name types
|
||||
----------
|
||||
|
||||
A GSSAPI application can name a local or remote entity by calling
|
||||
gss_import_name_, specifying a name type and a value. The following
|
||||
name types are supported by the krb5 mechanism:
|
||||
|
||||
* **GSS_C_NT_HOSTBASED_SERVICE**: The value should be a string of the
|
||||
form ``service`` or ``service@hostname``. This is the most common
|
||||
way to name target services when initiating a security context, and
|
||||
is the most likely name type to work across multiple mechanisms.
|
||||
|
||||
* **GSS_KRB5_NT_PRINCIPAL_NAME**: The value should be a principal name
|
||||
string. This name type only works with the krb5 mechanism, and is
|
||||
defined in the ``<gssapi/gssapi_krb5.h>`` header.
|
||||
|
||||
* **GSS_C_NT_USER_NAME** or **GSS_C_NULL_OID**: The value is treated
|
||||
as an unparsed principal name string, as above. These name types
|
||||
may work with mechanisms other than krb5, but will have different
|
||||
interpretations in those mechanisms. **GSS_C_NT_USER_NAME** is
|
||||
intended to be used with a local username, which will parse into a
|
||||
single-component principal in the default realm.
|
||||
|
||||
* **GSS_C_NT_ANONYMOUS**: The value is ignored. The anonymous
|
||||
principal is used, allowing a client to authenticate to a server
|
||||
without asserting a particular identity (which may or may not be
|
||||
allowed by a particular server or Kerberos realm).
|
||||
|
||||
* **GSS_C_NT_MACHINE_UID_NAME**: The value is uid_t object. On
|
||||
Unix-like systems, the username of the uid is looked up in the
|
||||
system user database and the resulting username is parsed as a
|
||||
principal name.
|
||||
|
||||
* **GSS_C_NT_STRING_UID_NAME**: As above, but the value is a decimal
|
||||
string representation of the uid.
|
||||
|
||||
* **GSS_C_NT_EXPORT_NAME**: The value must be the result of a
|
||||
gss_export_name_ call.
|
||||
|
||||
* **GSS_KRB5_NT_ENTERPRISE_NAME**: The value should be a krb5
|
||||
enterprise name string (see :rfc:`6806` section 5), in the form
|
||||
``user@suffix``. This name type is used to convey alias names, and
|
||||
is defined in the ``<gssapi/gssapi_krb5.h>`` header. (New in
|
||||
release 1.17.)
|
||||
|
||||
* **GSS_KRB5_NT_X509_CERT**: The value should be an X.509 certificate
|
||||
encoded according to :rfc:`5280`. This name form can be used for
|
||||
the desired_name parameter of gss_acquire_cred_impersonate_name(),
|
||||
to identify the S4U2Self user by certificate. (New in release
|
||||
1.19.)
|
||||
|
||||
|
||||
Initiator credentials
|
||||
---------------------
|
||||
|
||||
A GSSAPI client application uses gss_init_sec_context_ to establish a
|
||||
security context. The *initiator_cred_handle* parameter determines
|
||||
what tickets are used to establish the connection. An application can
|
||||
either pass **GSS_C_NO_CREDENTIAL** to use the default client
|
||||
credential, or it can use gss_acquire_cred_ beforehand to acquire an
|
||||
initiator credential. The call to gss_acquire_cred_ may include a
|
||||
*desired_name* parameter, or it may pass **GSS_C_NO_NAME** if it does
|
||||
not have a specific name preference.
|
||||
|
||||
If the desired name for a krb5 initiator credential is a host-based
|
||||
name, it is converted to a principal name of the form
|
||||
``service/hostname`` in the local realm, where *hostname* is the local
|
||||
hostname if not specified. The hostname will be canonicalized using
|
||||
forward name resolution, and possibly also using reverse name
|
||||
resolution depending on the value of the **rdns** variable in
|
||||
:ref:`libdefaults`.
|
||||
|
||||
If a desired name is specified in the call to gss_acquire_cred_, the
|
||||
krb5 mechanism will attempt to find existing tickets for that client
|
||||
principal name in the default credential cache or collection. If the
|
||||
default cache type does not support a collection, and the default
|
||||
cache contains credentials for a different principal than the desired
|
||||
name, a **GSS_S_CRED_UNAVAIL** error will be returned with a minor
|
||||
code indicating a mismatch.
|
||||
|
||||
If no existing tickets are available for the desired name, but the
|
||||
name has an entry in the default client :ref:`keytab_definition`, the
|
||||
krb5 mechanism will acquire initial tickets for the name using the
|
||||
default client keytab.
|
||||
|
||||
If no desired name is specified, credential acquisition will be
|
||||
deferred until the credential is used in a call to
|
||||
gss_init_sec_context_ or gss_inquire_cred_. If the call is to
|
||||
gss_init_sec_context_, the target name will be used to choose a client
|
||||
principal name using the credential cache selection facility. (This
|
||||
facility might, for instance, try to choose existing tickets for a
|
||||
client principal in the same realm as the target service). If there
|
||||
are no existing tickets for the chosen principal, but it is present in
|
||||
the default client keytab, the krb5 mechanism will acquire initial
|
||||
tickets using the keytab.
|
||||
|
||||
If the target name cannot be used to select a client principal
|
||||
(because the credentials are used in a call to gss_inquire_cred_), or
|
||||
if the credential cache selection facility cannot choose a principal
|
||||
for it, the default credential cache will be selected if it exists and
|
||||
contains tickets.
|
||||
|
||||
If the default credential cache does not exist, but the default client
|
||||
keytab does, the krb5 mechanism will try to acquire initial tickets
|
||||
for the first principal in the default client keytab.
|
||||
|
||||
If the krb5 mechanism acquires initial tickets using the default
|
||||
client keytab, the resulting tickets will be stored in the default
|
||||
cache or collection, and will be refreshed by future calls to
|
||||
gss_acquire_cred_ as they approach their expire time.
|
||||
|
||||
|
||||
Acceptor names
|
||||
--------------
|
||||
|
||||
A GSSAPI server application uses gss_accept_sec_context_ to establish
|
||||
a security context based on tokens provided by the client. The
|
||||
*acceptor_cred_handle* parameter determines what
|
||||
:ref:`keytab_definition` entries may be authenticated to by the
|
||||
client, if the krb5 mechanism is used.
|
||||
|
||||
The simplest choice is to pass **GSS_C_NO_CREDENTIAL** as the acceptor
|
||||
credential. In this case, clients may authenticate to any service
|
||||
principal in the default keytab (typically |keytab|, or the value of
|
||||
the **KRB5_KTNAME** environment variable). This is the recommended
|
||||
approach if the server application has no specific requirements to the
|
||||
contrary.
|
||||
|
||||
A server may acquire an acceptor credential with gss_acquire_cred_ and
|
||||
a *cred_usage* of **GSS_C_ACCEPT** or **GSS_C_BOTH**. If the
|
||||
*desired_name* parameter is **GSS_C_NO_NAME**, then clients will be
|
||||
allowed to authenticate to any service principal in the default
|
||||
keytab, just as if no acceptor credential was supplied.
|
||||
|
||||
If a server wishes to specify a *desired_name* to gss_acquire_cred_,
|
||||
the most common choice is a host-based name. If the host-based
|
||||
*desired_name* contains just a *service*, then clients will be allowed
|
||||
to authenticate to any host-based service principal (that is, a
|
||||
principal of the form ``service/hostname@REALM``) for the named
|
||||
service, regardless of hostname or realm, as long as it is present in
|
||||
the default keytab. If the input name contains both a *service* and a
|
||||
*hostname*, clients will be allowed to authenticate to any host-based
|
||||
principal for the named service and hostname, regardless of realm.
|
||||
|
||||
.. note::
|
||||
|
||||
If a *hostname* is specified, it will be canonicalized
|
||||
using forward name resolution, and possibly also using
|
||||
reverse name resolution depending on the value of the
|
||||
**rdns** variable in :ref:`libdefaults`.
|
||||
|
||||
.. note::
|
||||
|
||||
If the **ignore_acceptor_hostname** variable in
|
||||
:ref:`libdefaults` is enabled, then *hostname* will be
|
||||
ignored even if one is specified in the input name.
|
||||
|
||||
.. note::
|
||||
|
||||
In MIT krb5 versions prior to 1.10, and in Heimdal's
|
||||
implementation of the krb5 mechanism, an input name with
|
||||
just a *service* is treated like an input name of
|
||||
``service@localhostname``, where *localhostname* is the
|
||||
string returned by gethostname().
|
||||
|
||||
If the *desired_name* is a krb5 principal name or a local system name
|
||||
type which is mapped to a krb5 principal name, clients will only be
|
||||
allowed to authenticate to that principal in the default keytab.
|
||||
|
||||
|
||||
Name Attributes
|
||||
---------------
|
||||
|
||||
In release 1.8 or later, the gss_inquire_name_ and
|
||||
gss_get_name_attribute_ functions, specified in :rfc:`6680`, can be
|
||||
used to retrieve name attributes from the *src_name* returned by
|
||||
gss_accept_sec_context_. The following attributes are defined when
|
||||
the krb5 mechanism is used:
|
||||
|
||||
.. _gssapi_authind_attr:
|
||||
|
||||
* "auth-indicators" attribute:
|
||||
|
||||
This attribute will be included in the gss_inquire_name_ output if the
|
||||
ticket contains :ref:`authentication indicators <auth_indicator>`.
|
||||
One indicator is returned per invocation of gss_get_name_attribute_,
|
||||
so multiple invocations may be necessary to retrieve all of the
|
||||
indicators from the ticket. (New in release 1.15.)
|
||||
|
||||
|
||||
Credential store extensions
|
||||
---------------------------
|
||||
|
||||
Beginning with release 1.11, the following GSSAPI extensions declared
|
||||
in ``<gssapi/gssapi_ext.h>`` can be used to specify how credentials
|
||||
are acquired or stored::
|
||||
|
||||
struct gss_key_value_element_struct {
|
||||
const char *key;
|
||||
const char *value;
|
||||
};
|
||||
typedef struct gss_key_value_element_struct gss_key_value_element_desc;
|
||||
|
||||
struct gss_key_value_set_struct {
|
||||
OM_uint32 count;
|
||||
gss_key_value_element_desc *elements;
|
||||
};
|
||||
typedef const struct gss_key_value_set_struct gss_key_value_set_desc;
|
||||
typedef const gss_key_value_set_desc *gss_const_key_value_set_t;
|
||||
|
||||
OM_uint32 gss_acquire_cred_from(OM_uint32 *minor_status,
|
||||
const gss_name_t desired_name,
|
||||
OM_uint32 time_req,
|
||||
const gss_OID_set desired_mechs,
|
||||
gss_cred_usage_t cred_usage,
|
||||
gss_const_key_value_set_t cred_store,
|
||||
gss_cred_id_t *output_cred_handle,
|
||||
gss_OID_set *actual_mechs,
|
||||
OM_uint32 *time_rec);
|
||||
|
||||
OM_uint32 gss_store_cred_into(OM_uint32 *minor_status,
|
||||
gss_cred_id_t input_cred_handle,
|
||||
gss_cred_usage_t cred_usage,
|
||||
const gss_OID desired_mech,
|
||||
OM_uint32 overwrite_cred,
|
||||
OM_uint32 default_cred,
|
||||
gss_const_key_value_set_t cred_store,
|
||||
gss_OID_set *elements_stored,
|
||||
gss_cred_usage_t *cred_usage_stored);
|
||||
|
||||
The additional *cred_store* parameter allows the caller to specify
|
||||
information about how the credentials should be obtained and stored.
|
||||
The following options are supported by the krb5 mechanism:
|
||||
|
||||
* **ccache**: For acquiring initiator credentials, the name of the
|
||||
:ref:`credential cache <ccache_definition>` to which the handle will
|
||||
refer. For storing credentials, the name of the cache or collection
|
||||
where the credentials will be stored (see below).
|
||||
|
||||
* **client_keytab**: For acquiring initiator credentials, the name of
|
||||
the :ref:`keytab <keytab_definition>` which will be used, if
|
||||
necessary, to refresh the credentials in the cache.
|
||||
|
||||
* **keytab**: For acquiring acceptor credentials, the name of the
|
||||
:ref:`keytab <keytab_definition>` to which the handle will refer.
|
||||
In release 1.19 and later, this option also determines the keytab to
|
||||
be used for verification when initiator credentials are acquired
|
||||
using a password and verified.
|
||||
|
||||
* **password**: For acquiring initiator credentials, this option
|
||||
instructs the mechanism to acquire fresh credentials into a unique
|
||||
memory credential cache. This option may not be used with the
|
||||
**ccache** or **client_keytab** options, and a *desired_name* must
|
||||
be specified. (New in release 1.19.)
|
||||
|
||||
* **rcache**: For acquiring acceptor credentials, the name of the
|
||||
:ref:`replay cache <rcache_definition>` to be used when processing
|
||||
the initiator tokens. (New in release 1.13.)
|
||||
|
||||
* **verify**: For acquiring initiator credentials, this option
|
||||
instructs the mechanism to verify the credentials by obtaining a
|
||||
ticket to a service with a known key. The service key is obtained
|
||||
from the keytab specified with the **keytab** option or the default
|
||||
keytab. The value may be the name of a principal in the keytab, or
|
||||
the empty string. If the empty string is given, any ``host``
|
||||
service principal in the keytab may be used. (New in release 1.19.)
|
||||
|
||||
In release 1.20 or later, if a collection name is specified for
|
||||
**cache** in a call to gss_store_cred_into(), an existing cache for
|
||||
the client principal within the collection will be selected, or a new
|
||||
cache will be created within the collection. If *overwrite_cred* is
|
||||
false and the selected credential cache already exists, a
|
||||
**GSS_S_DUPLICATE_ELEMENT** error will be returned. If *default_cred*
|
||||
is true, the primary cache of the collection will be switched to the
|
||||
selected cache.
|
||||
|
||||
|
||||
Importing and exporting credentials
|
||||
-----------------------------------
|
||||
|
||||
The following GSSAPI extensions can be used to import and export
|
||||
credentials (declared in ``<gssapi/gssapi_ext.h>``)::
|
||||
|
||||
OM_uint32 gss_export_cred(OM_uint32 *minor_status,
|
||||
gss_cred_id_t cred_handle,
|
||||
gss_buffer_t token);
|
||||
|
||||
OM_uint32 gss_import_cred(OM_uint32 *minor_status,
|
||||
gss_buffer_t token,
|
||||
gss_cred_id_t *cred_handle);
|
||||
|
||||
The first function serializes a GSSAPI credential handle into a
|
||||
buffer; the second unseralizes a buffer into a GSSAPI credential
|
||||
handle. Serializing a credential does not destroy it. If any of the
|
||||
mechanisms used in *cred_handle* do not support serialization,
|
||||
gss_export_cred will return **GSS_S_UNAVAILABLE**. As with other
|
||||
GSSAPI serialization functions, these extensions are only intended to
|
||||
work with a matching implementation on the other side; they do not
|
||||
serialize credentials in a standardized format.
|
||||
|
||||
A serialized credential may contain secret information such as ticket
|
||||
session keys. The serialization format does not protect this
|
||||
information from eavesdropping or tampering. The calling application
|
||||
must take care to protect the serialized credential when communicating
|
||||
it over an insecure channel or to an untrusted party.
|
||||
|
||||
A krb5 GSSAPI credential may contain references to a credential cache,
|
||||
a client keytab, an acceptor keytab, and a replay cache. These
|
||||
resources are normally serialized as references to their external
|
||||
locations (such as the filename of the credential cache). Because of
|
||||
this, a serialized krb5 credential can only be imported by a process
|
||||
with similar privileges to the exporter. A serialized credential
|
||||
should not be trusted if it originates from a source with lower
|
||||
privileges than the importer, as it may contain references to external
|
||||
credential cache, keytab, or replay cache resources not accessible to
|
||||
the originator.
|
||||
|
||||
An exception to the above rule applies when a krb5 GSSAPI credential
|
||||
refers to a memory credential cache, as is normally the case for
|
||||
delegated credentials received by gss_accept_sec_context_. In this
|
||||
case, the contents of the credential cache are serialized, so that the
|
||||
resulting token may be imported even if the original memory credential
|
||||
cache no longer exists.
|
||||
|
||||
|
||||
Constrained delegation (S4U)
|
||||
----------------------------
|
||||
|
||||
The Microsoft S4U2Self and S4U2Proxy Kerberos protocol extensions
|
||||
allow an intermediate service to acquire credentials from a client to
|
||||
a target service without requiring the client to delegate a
|
||||
ticket-granting ticket, if the KDC is configured to allow it.
|
||||
|
||||
To perform a constrained delegation operation, the intermediate
|
||||
service must submit to the KDC an "evidence ticket" from the client to
|
||||
the intermediate service. An evidence ticket can be acquired when the
|
||||
client authenticates to the intermediate service with Kerberos, or
|
||||
with an S4U2Self request if the KDC allows it. The MIT krb5 GSSAPI
|
||||
library represents an evidence ticket using a "proxy credential",
|
||||
which is a special kind of gss_cred_id_t object whose underlying
|
||||
credential cache contains the evidence ticket and a krbtgt ticket for
|
||||
the intermediate service.
|
||||
|
||||
To acquire a proxy credential during client authentication, the
|
||||
service should first create an acceptor credential using the
|
||||
**GSS_C_BOTH** usage. The application should then pass this
|
||||
credential as the *acceptor_cred_handle* to gss_accept_sec_context_,
|
||||
and also pass a *delegated_cred_handle* output parameter to receive a
|
||||
proxy credential containing the evidence ticket. The output value of
|
||||
*delegated_cred_handle* may be a delegated ticket-granting ticket if
|
||||
the client sent one, or a proxy credential if not. If the library can
|
||||
determine that the client's ticket is not a valid evidence ticket, it
|
||||
will place **GSS_C_NO_CREDENTIAL** in *delegated_cred_handle*.
|
||||
|
||||
To acquire a proxy credential using an S4U2Self request, the service
|
||||
can use the following GSSAPI extension::
|
||||
|
||||
OM_uint32 gss_acquire_cred_impersonate_name(OM_uint32 *minor_status,
|
||||
gss_cred_id_t icred,
|
||||
gss_name_t desired_name,
|
||||
OM_uint32 time_req,
|
||||
gss_OID_set desired_mechs,
|
||||
gss_cred_usage_t cred_usage,
|
||||
gss_cred_id_t *output_cred,
|
||||
gss_OID_set *actual_mechs,
|
||||
OM_uint32 *time_rec);
|
||||
|
||||
The parameters to this function are similar to those of
|
||||
gss_acquire_cred_, except that *icred* is used to make an S4U2Self
|
||||
request to the KDC for a ticket from *desired_name* to the
|
||||
intermediate service. Both *icred* and *desired_name* are required
|
||||
for this function; passing **GSS_C_NO_CREDENTIAL** or
|
||||
**GSS_C_NO_NAME** will cause the call to fail. *icred* must contain a
|
||||
krbtgt ticket for the intermediate service. The result of this
|
||||
operation is a proxy credential. (Prior to release 1.18, the result
|
||||
of this operation may be a regular credential for *desired_name*, if
|
||||
the KDC issues a non-forwardable ticket.)
|
||||
|
||||
Once the intermediate service has a proxy credential, it can simply
|
||||
pass it to gss_init_sec_context_ as the *initiator_cred_handle*
|
||||
parameter, and the desired service as the *target_name* parameter.
|
||||
The GSSAPI library will present the krbtgt ticket and evidence ticket
|
||||
in the proxy credential to the KDC in an S4U2Proxy request; if the
|
||||
intermediate service has the appropriate permissions, the KDC will
|
||||
issue a ticket from the client to the target service. The GSSAPI
|
||||
library will then use this ticket to authenticate to the target
|
||||
service.
|
||||
|
||||
If an application needs to find out whether a credential it holds is a
|
||||
proxy credential and the name of the intermediate service, it can
|
||||
query the credential with the **GSS_KRB5_GET_CRED_IMPERSONATOR** OID
|
||||
(new in release 1.16, declared in ``<gssapi/gssapi_krb5.h>``) using
|
||||
the gss_inquire_cred_by_oid extension (declared in
|
||||
``<gssapi/gssapi_ext.h>``)::
|
||||
|
||||
OM_uint32 gss_inquire_cred_by_oid(OM_uint32 *minor_status,
|
||||
const gss_cred_id_t cred_handle,
|
||||
gss_OID desired_object,
|
||||
gss_buffer_set_t *data_set);
|
||||
|
||||
If the call succeeds and *cred_handle* is a proxy credential,
|
||||
*data_set* will be set to a single-element buffer set containing the
|
||||
unparsed principal name of the intermediate service. If *cred_handle*
|
||||
is not a proxy credential, *data_set* will be set to an empty buffer
|
||||
set. If the library does not support the query,
|
||||
gss_inquire_cred_by_oid will return **GSS_S_UNAVAILABLE**.
|
||||
|
||||
|
||||
AEAD message wrapping
|
||||
---------------------
|
||||
|
||||
The following GSSAPI extensions (declared in
|
||||
``<gssapi/gssapi_ext.h>``) can be used to wrap and unwrap messages
|
||||
with additional "associated data" which is integrity-checked but is
|
||||
not included in the output buffer::
|
||||
|
||||
OM_uint32 gss_wrap_aead(OM_uint32 *minor_status,
|
||||
gss_ctx_id_t context_handle,
|
||||
int conf_req_flag, gss_qop_t qop_req,
|
||||
gss_buffer_t input_assoc_buffer,
|
||||
gss_buffer_t input_payload_buffer,
|
||||
int *conf_state,
|
||||
gss_buffer_t output_message_buffer);
|
||||
|
||||
OM_uint32 gss_unwrap_aead(OM_uint32 *minor_status,
|
||||
gss_ctx_id_t context_handle,
|
||||
gss_buffer_t input_message_buffer,
|
||||
gss_buffer_t input_assoc_buffer,
|
||||
gss_buffer_t output_payload_buffer,
|
||||
int *conf_state,
|
||||
gss_qop_t *qop_state);
|
||||
|
||||
Wrap tokens created with gss_wrap_aead will successfully unwrap only
|
||||
if the same *input_assoc_buffer* contents are presented to
|
||||
gss_unwrap_aead.
|
||||
|
||||
|
||||
IOV message wrapping
|
||||
--------------------
|
||||
|
||||
The following extensions (declared in ``<gssapi/gssapi_ext.h>``) can
|
||||
be used for in-place encryption, fine-grained control over wrap token
|
||||
layout, and for constructing wrap tokens compatible with Microsoft DCE
|
||||
RPC::
|
||||
|
||||
typedef struct gss_iov_buffer_desc_struct {
|
||||
OM_uint32 type;
|
||||
gss_buffer_desc buffer;
|
||||
} gss_iov_buffer_desc, *gss_iov_buffer_t;
|
||||
|
||||
OM_uint32 gss_wrap_iov(OM_uint32 *minor_status,
|
||||
gss_ctx_id_t context_handle,
|
||||
int conf_req_flag, gss_qop_t qop_req,
|
||||
int *conf_state,
|
||||
gss_iov_buffer_desc *iov, int iov_count);
|
||||
|
||||
OM_uint32 gss_unwrap_iov(OM_uint32 *minor_status,
|
||||
gss_ctx_id_t context_handle,
|
||||
int *conf_state, gss_qop_t *qop_state,
|
||||
gss_iov_buffer_desc *iov, int iov_count);
|
||||
|
||||
OM_uint32 gss_wrap_iov_length(OM_uint32 *minor_status,
|
||||
gss_ctx_id_t context_handle,
|
||||
int conf_req_flag,
|
||||
gss_qop_t qop_req, int *conf_state,
|
||||
gss_iov_buffer_desc *iov,
|
||||
int iov_count);
|
||||
|
||||
OM_uint32 gss_release_iov_buffer(OM_uint32 *minor_status,
|
||||
gss_iov_buffer_desc *iov,
|
||||
int iov_count);
|
||||
|
||||
The caller of gss_wrap_iov provides an array of gss_iov_buffer_desc
|
||||
structures, each containing a type and a gss_buffer_desc structure.
|
||||
Valid types include:
|
||||
|
||||
* **GSS_C_BUFFER_TYPE_DATA**: A data buffer to be included in the
|
||||
token, and to be encrypted or decrypted in-place if the token is
|
||||
confidentiality-protected.
|
||||
|
||||
* **GSS_C_BUFFER_TYPE_HEADER**: The GSSAPI wrap token header and
|
||||
underlying cryptographic header.
|
||||
|
||||
* **GSS_C_BUFFER_TYPE_TRAILER**: The cryptographic trailer, if one is
|
||||
required.
|
||||
|
||||
* **GSS_C_BUFFER_TYPE_PADDING**: Padding to be combined with the data
|
||||
during encryption and decryption. (The implementation may choose to
|
||||
place padding in the trailer buffer, in which case it will set the
|
||||
padding buffer length to 0.)
|
||||
|
||||
* **GSS_C_BUFFER_TYPE_STREAM**: For unwrapping only, a buffer
|
||||
containing a complete wrap token in standard format to be unwrapped.
|
||||
|
||||
* **GSS_C_BUFFER_TYPE_SIGN_ONLY**: A buffer to be included in the
|
||||
token's integrity protection checksum, but not to be encrypted or
|
||||
included in the token itself.
|
||||
|
||||
For gss_wrap_iov, the IOV list should contain one HEADER buffer,
|
||||
followed by zero or more SIGN_ONLY buffers, followed by one or more
|
||||
DATA buffers, followed by a TRAILER buffer. The memory pointed to by
|
||||
the buffers is not required to be contiguous or in any particular
|
||||
order. If *conf_req_flag* is true, DATA buffers will be encrypted
|
||||
in-place, while SIGN_ONLY buffers will not be modified.
|
||||
|
||||
The type of an output buffer may be combined with
|
||||
**GSS_C_BUFFER_FLAG_ALLOCATE** to request that gss_wrap_iov allocate
|
||||
the buffer contents. If gss_wrap_iov allocates a buffer, it sets the
|
||||
**GSS_C_BUFFER_FLAG_ALLOCATED** flag on the buffer type.
|
||||
gss_release_iov_buffer can be used to release all allocated buffers
|
||||
within an iov list and unset their allocated flags. Here is an
|
||||
example of how gss_wrap_iov can be used with allocation requested
|
||||
(*ctx* is assumed to be a previously established gss_ctx_id_t)::
|
||||
|
||||
OM_uint32 major, minor;
|
||||
gss_iov_buffer_desc iov[4];
|
||||
char str[] = "message";
|
||||
|
||||
iov[0].type = GSS_IOV_BUFFER_TYPE_HEADER | GSS_IOV_BUFFER_FLAG_ALLOCATE;
|
||||
iov[1].type = GSS_IOV_BUFFER_TYPE_DATA;
|
||||
iov[1].buffer.value = str;
|
||||
iov[1].buffer.length = strlen(str);
|
||||
iov[2].type = GSS_IOV_BUFFER_TYPE_PADDING | GSS_IOV_BUFFER_FLAG_ALLOCATE;
|
||||
iov[3].type = GSS_IOV_BUFFER_TYPE_TRAILER | GSS_IOV_BUFFER_FLAG_ALLOCATE;
|
||||
|
||||
major = gss_wrap_iov(&minor, ctx, 1, GSS_C_QOP_DEFAULT, NULL,
|
||||
iov, 4);
|
||||
if (GSS_ERROR(major))
|
||||
handle_error(major, minor);
|
||||
|
||||
/* Transmit or otherwise use resulting buffers. */
|
||||
|
||||
(void)gss_release_iov_buffer(&minor, iov, 4);
|
||||
|
||||
If the caller does not choose to request buffer allocation by
|
||||
gss_wrap_iov, it should first call gss_wrap_iov_length to query the
|
||||
lengths of the HEADER, PADDING, and TRAILER buffers. DATA buffers
|
||||
must be provided in the iov list so that padding length can be
|
||||
computed correctly, but the output buffers need not be initialized.
|
||||
Here is an example of using gss_wrap_iov_length and gss_wrap_iov::
|
||||
|
||||
OM_uint32 major, minor;
|
||||
gss_iov_buffer_desc iov[4];
|
||||
char str[1024] = "message", *ptr;
|
||||
|
||||
iov[0].type = GSS_IOV_BUFFER_TYPE_HEADER;
|
||||
iov[1].type = GSS_IOV_BUFFER_TYPE_DATA;
|
||||
iov[1].buffer.value = str;
|
||||
iov[1].buffer.length = strlen(str);
|
||||
|
||||
iov[2].type = GSS_IOV_BUFFER_TYPE_PADDING;
|
||||
iov[3].type = GSS_IOV_BUFFER_TYPE_TRAILER;
|
||||
|
||||
major = gss_wrap_iov_length(&minor, ctx, 1, GSS_C_QOP_DEFAULT,
|
||||
NULL, iov, 4);
|
||||
if (GSS_ERROR(major))
|
||||
handle_error(major, minor);
|
||||
if (strlen(str) + iov[0].buffer.length + iov[2].buffer.length +
|
||||
iov[3].buffer.length > sizeof(str))
|
||||
handle_out_of_space_error();
|
||||
ptr = str + strlen(str);
|
||||
iov[0].buffer.value = ptr;
|
||||
ptr += iov[0].buffer.length;
|
||||
iov[2].buffer.value = ptr;
|
||||
ptr += iov[2].buffer.length;
|
||||
iov[3].buffer.value = ptr;
|
||||
|
||||
major = gss_wrap_iov(&minor, ctx, 1, GSS_C_QOP_DEFAULT, NULL,
|
||||
iov, 4);
|
||||
if (GSS_ERROR(major))
|
||||
handle_error(major, minor);
|
||||
|
||||
If the context was established using the **GSS_C_DCE_STYLE** flag
|
||||
(described in :rfc:`4757`), wrap tokens compatible with Microsoft DCE
|
||||
RPC can be constructed. In this case, the IOV list must include a
|
||||
SIGN_ONLY buffer, a DATA buffer, a second SIGN_ONLY buffer, and a
|
||||
HEADER buffer in that order (the order of the buffer contents remains
|
||||
arbitrary). The application must pad the DATA buffer to a multiple of
|
||||
16 bytes as no padding or trailer buffer is used.
|
||||
|
||||
gss_unwrap_iov may be called with an IOV list just like one which
|
||||
would be provided to gss_wrap_iov. DATA buffers will be decrypted
|
||||
in-place if they were encrypted, and SIGN_ONLY buffers will not be
|
||||
modified.
|
||||
|
||||
Alternatively, gss_unwrap_iov may be called with a single STREAM
|
||||
buffer, zero or more SIGN_ONLY buffers, and a single DATA buffer. The
|
||||
STREAM buffer is interpreted as a complete wrap token. The STREAM
|
||||
buffer will be modified in-place to decrypt its contents. The DATA
|
||||
buffer will be initialized to point to the decrypted data within the
|
||||
STREAM buffer, unless it has the **GSS_C_BUFFER_FLAG_ALLOCATE** flag
|
||||
set, in which case it will be initialized with a copy of the decrypted
|
||||
data. Here is an example (*token* and *token_len* are assumed to be a
|
||||
pre-existing pointer and length for a modifiable region of data)::
|
||||
|
||||
OM_uint32 major, minor;
|
||||
gss_iov_buffer_desc iov[2];
|
||||
|
||||
iov[0].type = GSS_IOV_BUFFER_TYPE_STREAM;
|
||||
iov[0].buffer.value = token;
|
||||
iov[0].buffer.length = token_len;
|
||||
iov[1].type = GSS_IOV_BUFFER_TYPE_DATA;
|
||||
major = gss_unwrap_iov(&minor, ctx, NULL, NULL, iov, 2);
|
||||
if (GSS_ERROR(major))
|
||||
handle_error(major, minor);
|
||||
|
||||
/* Decrypted data is in iov[1].buffer, pointing to a subregion of
|
||||
* token. */
|
||||
|
||||
.. _gssapi_mic_token:
|
||||
|
||||
IOV MIC tokens
|
||||
--------------
|
||||
|
||||
The following extensions (declared in ``<gssapi/gssapi_ext.h>``) can
|
||||
be used in release 1.12 or later to construct and verify MIC tokens
|
||||
using an IOV list::
|
||||
|
||||
OM_uint32 gss_get_mic_iov(OM_uint32 *minor_status,
|
||||
gss_ctx_id_t context_handle,
|
||||
gss_qop_t qop_req,
|
||||
gss_iov_buffer_desc *iov,
|
||||
int iov_count);
|
||||
|
||||
OM_uint32 gss_get_mic_iov_length(OM_uint32 *minor_status,
|
||||
gss_ctx_id_t context_handle,
|
||||
gss_qop_t qop_req,
|
||||
gss_iov_buffer_desc *iov,
|
||||
iov_count);
|
||||
|
||||
OM_uint32 gss_verify_mic_iov(OM_uint32 *minor_status,
|
||||
gss_ctx_id_t context_handle,
|
||||
gss_qop_t *qop_state,
|
||||
gss_iov_buffer_desc *iov,
|
||||
int iov_count);
|
||||
|
||||
The caller of gss_get_mic_iov provides an array of gss_iov_buffer_desc
|
||||
structures, each containing a type and a gss_buffer_desc structure.
|
||||
Valid types include:
|
||||
|
||||
* **GSS_C_BUFFER_TYPE_DATA** and **GSS_C_BUFFER_TYPE_SIGN_ONLY**: The
|
||||
corresponding buffer for each of these types will be signed for the
|
||||
MIC token, in the order provided.
|
||||
|
||||
* **GSS_C_BUFFER_TYPE_MIC_TOKEN**: The GSSAPI MIC token.
|
||||
|
||||
The type of the MIC_TOKEN buffer may be combined with
|
||||
**GSS_C_BUFFER_FLAG_ALLOCATE** to request that gss_get_mic_iov
|
||||
allocate the buffer contents. If gss_get_mic_iov allocates the
|
||||
buffer, it sets the **GSS_C_BUFFER_FLAG_ALLOCATED** flag on the buffer
|
||||
type. gss_release_iov_buffer can be used to release all allocated
|
||||
buffers within an iov list and unset their allocated flags. Here is
|
||||
an example of how gss_get_mic_iov can be used with allocation
|
||||
requested (*ctx* is assumed to be a previously established
|
||||
gss_ctx_id_t)::
|
||||
|
||||
OM_uint32 major, minor;
|
||||
gss_iov_buffer_desc iov[3];
|
||||
|
||||
iov[0].type = GSS_IOV_BUFFER_TYPE_DATA;
|
||||
iov[0].buffer.value = "sign1";
|
||||
iov[0].buffer.length = 5;
|
||||
iov[1].type = GSS_IOV_BUFFER_TYPE_SIGN_ONLY;
|
||||
iov[1].buffer.value = "sign2";
|
||||
iov[1].buffer.length = 5;
|
||||
iov[2].type = GSS_IOV_BUFFER_TYPE_MIC_TOKEN | GSS_IOV_BUFFER_FLAG_ALLOCATE;
|
||||
|
||||
major = gss_get_mic_iov(&minor, ctx, GSS_C_QOP_DEFAULT, iov, 3);
|
||||
if (GSS_ERROR(major))
|
||||
handle_error(major, minor);
|
||||
|
||||
/* Transmit or otherwise use iov[2].buffer. */
|
||||
|
||||
(void)gss_release_iov_buffer(&minor, iov, 3);
|
||||
|
||||
If the caller does not choose to request buffer allocation by
|
||||
gss_get_mic_iov, it should first call gss_get_mic_iov_length to query
|
||||
the length of the MIC_TOKEN buffer. Here is an example of using
|
||||
gss_get_mic_iov_length and gss_get_mic_iov::
|
||||
|
||||
OM_uint32 major, minor;
|
||||
gss_iov_buffer_desc iov[2];
|
||||
char data[1024];
|
||||
|
||||
iov[0].type = GSS_IOV_BUFFER_TYPE_MIC_TOKEN;
|
||||
iov[1].type = GSS_IOV_BUFFER_TYPE_DATA;
|
||||
iov[1].buffer.value = "message";
|
||||
iov[1].buffer.length = 7;
|
||||
|
||||
major = gss_get_mic_iov_length(&minor, ctx, GSS_C_QOP_DEFAULT, iov, 2);
|
||||
if (GSS_ERROR(major))
|
||||
handle_error(major, minor);
|
||||
if (iov[0].buffer.length > sizeof(data))
|
||||
handle_out_of_space_error();
|
||||
iov[0].buffer.value = data;
|
||||
|
||||
major = gss_get_mic_iov(&minor, ctx, GSS_C_QOP_DEFAULT, iov, 2);
|
||||
if (GSS_ERROR(major))
|
||||
handle_error(major, minor);
|
||||
|
||||
|
||||
.. _gss_accept_sec_context: https://tools.ietf.org/html/rfc2744.html#section-5.1
|
||||
.. _gss_acquire_cred: https://tools.ietf.org/html/rfc2744.html#section-5.2
|
||||
.. _gss_export_name: https://tools.ietf.org/html/rfc2744.html#section-5.13
|
||||
.. _gss_get_name_attribute: https://tools.ietf.org/html/6680.html#section-7.5
|
||||
.. _gss_import_name: https://tools.ietf.org/html/rfc2744.html#section-5.16
|
||||
.. _gss_init_sec_context: https://tools.ietf.org/html/rfc2744.html#section-5.19
|
||||
.. _gss_inquire_name: https://tools.ietf.org/html/rfc6680.txt#section-7.4
|
||||
.. _gss_inquire_cred: https://tools.ietf.org/html/rfc2744.html#section-5.21
|
||||
28
crypto/krb5/doc/appdev/h5l_mit_apidiff.rst
Normal file
28
crypto/krb5/doc/appdev/h5l_mit_apidiff.rst
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
Differences between Heimdal and MIT Kerberos API
|
||||
================================================
|
||||
|
||||
.. tabularcolumns:: |l|l|
|
||||
|
||||
.. table::
|
||||
|
||||
======================================== =================================================
|
||||
:c:func:`krb5_auth_con_getaddrs()` H5l: If either of the pointers to local_addr
|
||||
and remote_addr is not NULL, it is freed
|
||||
first and then reallocated before being
|
||||
populated with the content of corresponding
|
||||
address from authentication context.
|
||||
:c:func:`krb5_auth_con_setaddrs()` H5l: If either address is NULL, the previous
|
||||
address remains in place
|
||||
:c:func:`krb5_auth_con_setports()` H5l: Not implemented as of version 1.3.3
|
||||
:c:func:`krb5_auth_con_setrecvsubkey()` H5l: If either port is NULL, the previous
|
||||
port remains in place
|
||||
:c:func:`krb5_auth_con_setsendsubkey()` H5l: Not implemented as of version 1.3.3
|
||||
:c:func:`krb5_cc_set_config()` MIT: Before version 1.10 it was assumed that
|
||||
the last argument *data* is ALWAYS non-zero.
|
||||
:c:func:`krb5_cccol_last_change_time()` MIT: not implemented
|
||||
:c:func:`krb5_set_default_realm()` H5l: Caches the computed default realm context
|
||||
field. If the second argument is NULL,
|
||||
it tries to retrieve it from libdefaults or DNS.
|
||||
MIT: Computes the default realm each time
|
||||
if it wasn't explicitly set in the context
|
||||
======================================== =================================================
|
||||
16
crypto/krb5/doc/appdev/index.rst
Normal file
16
crypto/krb5/doc/appdev/index.rst
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
For application developers
|
||||
==========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
gssapi.rst
|
||||
y2038.rst
|
||||
h5l_mit_apidiff.rst
|
||||
init_creds.rst
|
||||
princ_handle.rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
refs/index.rst
|
||||
304
crypto/krb5/doc/appdev/init_creds.rst
Normal file
304
crypto/krb5/doc/appdev/init_creds.rst
Normal file
|
|
@ -0,0 +1,304 @@
|
|||
Initial credentials
|
||||
===================
|
||||
|
||||
Software that performs tasks such as logging users into a computer
|
||||
when they type their Kerberos password needs to get initial
|
||||
credentials (usually ticket granting tickets) from Kerberos. Such
|
||||
software shares some behavior with the :ref:`kinit(1)` program.
|
||||
|
||||
Whenever a program grants access to a resource (such as a local login
|
||||
session on a desktop computer) based on a user successfully getting
|
||||
initial Kerberos credentials, it must verify those credentials against
|
||||
a secure shared secret (e.g., a host keytab) to ensure that the user
|
||||
credentials actually originate from a legitimate KDC. Failure to
|
||||
perform this verification is a critical vulnerability, because a
|
||||
malicious user can execute the "Zanarotti attack": the user constructs
|
||||
a fake response that appears to come from the legitimate KDC, but
|
||||
whose contents come from an attacker-controlled KDC.
|
||||
|
||||
Some applications read a Kerberos password over the network (ideally
|
||||
over a secure channel), which they then verify against the KDC. While
|
||||
this technique may be the only practical way to integrate Kerberos
|
||||
into some existing legacy systems, its use is contrary to the original
|
||||
design goals of Kerberos.
|
||||
|
||||
The function :c:func:`krb5_get_init_creds_password` will get initial
|
||||
credentials for a client using a password. An application that needs
|
||||
to verify the credentials can call :c:func:`krb5_verify_init_creds`.
|
||||
Here is an example of code to obtain and verify TGT credentials, given
|
||||
strings *princname* and *password* for the client principal name and
|
||||
password::
|
||||
|
||||
krb5_error_code ret;
|
||||
krb5_creds creds;
|
||||
krb5_principal client_princ = NULL;
|
||||
|
||||
memset(&creds, 0, sizeof(creds));
|
||||
ret = krb5_parse_name(context, princname, &client_princ);
|
||||
if (ret)
|
||||
goto cleanup;
|
||||
ret = krb5_get_init_creds_password(context, &creds, client_princ,
|
||||
password, NULL, NULL, 0, NULL, NULL);
|
||||
if (ret)
|
||||
goto cleanup;
|
||||
ret = krb5_verify_init_creds(context, &creds, NULL, NULL, NULL, NULL);
|
||||
|
||||
cleanup:
|
||||
krb5_free_principal(context, client_princ);
|
||||
krb5_free_cred_contents(context, &creds);
|
||||
return ret;
|
||||
|
||||
Options for get_init_creds
|
||||
--------------------------
|
||||
|
||||
The function :c:func:`krb5_get_init_creds_password` takes an options
|
||||
parameter (which can be a null pointer). Use the function
|
||||
:c:func:`krb5_get_init_creds_opt_alloc` to allocate an options
|
||||
structure, and :c:func:`krb5_get_init_creds_opt_free` to free it. For
|
||||
example::
|
||||
|
||||
krb5_error_code ret;
|
||||
krb5_get_init_creds_opt *opt = NULL;
|
||||
krb5_creds creds;
|
||||
|
||||
memset(&creds, 0, sizeof(creds));
|
||||
ret = krb5_get_init_creds_opt_alloc(context, &opt);
|
||||
if (ret)
|
||||
goto cleanup;
|
||||
krb5_get_init_creds_opt_set_tkt_life(opt, 24 * 60 * 60);
|
||||
ret = krb5_get_init_creds_password(context, &creds, client_princ,
|
||||
password, NULL, NULL, 0, NULL, opt);
|
||||
if (ret)
|
||||
goto cleanup;
|
||||
|
||||
cleanup:
|
||||
krb5_get_init_creds_opt_free(context, opt);
|
||||
krb5_free_cred_contents(context, &creds);
|
||||
return ret;
|
||||
|
||||
Getting anonymous credentials
|
||||
-----------------------------
|
||||
|
||||
As of release 1.8, it is possible to obtain fully anonymous or
|
||||
partially anonymous (realm-exposed) credentials, if the KDC supports
|
||||
it. The MIT KDC supports issuing fully anonymous credentials as of
|
||||
release 1.8 if configured appropriately (see :ref:`anonymous_pkinit`),
|
||||
but does not support issuing realm-exposed anonymous credentials at
|
||||
this time.
|
||||
|
||||
To obtain fully anonymous credentials, call
|
||||
:c:func:`krb5_get_init_creds_opt_set_anonymous` on the options
|
||||
structure to set the anonymous flag, and specify a client principal
|
||||
with the KDC's realm and a single empty data component (the principal
|
||||
obtained by parsing ``@``\ *realmname*). Authentication will take
|
||||
place using anonymous PKINIT; if successful, the client principal of
|
||||
the resulting tickets will be
|
||||
``WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS``. Here is an example::
|
||||
|
||||
krb5_get_init_creds_opt_set_anonymous(opt, 1);
|
||||
ret = krb5_build_principal(context, &client_princ, strlen(myrealm),
|
||||
myrealm, "", (char *)NULL);
|
||||
if (ret)
|
||||
goto cleanup;
|
||||
ret = krb5_get_init_creds_password(context, &creds, client_princ,
|
||||
password, NULL, NULL, 0, NULL, opt);
|
||||
if (ret)
|
||||
goto cleanup;
|
||||
|
||||
To obtain realm-exposed anonymous credentials, set the anonymous flag
|
||||
on the options structure as above, but specify a normal client
|
||||
principal in order to prove membership in the realm. Authentication
|
||||
will take place as it normally does; if successful, the client
|
||||
principal of the resulting tickets will be ``WELLKNOWN/ANONYMOUS@``\
|
||||
*realmname*.
|
||||
|
||||
User interaction
|
||||
----------------
|
||||
|
||||
Authenticating a user usually requires the entry of secret
|
||||
information, such as a password. A password can be supplied directly
|
||||
to :c:func:`krb5_get_init_creds_password` via the *password*
|
||||
parameter, or the application can supply prompter and/or responder
|
||||
callbacks instead. If callbacks are used, the user can also be
|
||||
queried for other secret information such as a PIN, informed of
|
||||
impending password expiration, or prompted to change a password which
|
||||
has expired.
|
||||
|
||||
Prompter callback
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
A prompter callback can be specified via the *prompter* and *data*
|
||||
parameters to :c:func:`krb5_get_init_creds_password`. The prompter
|
||||
will be invoked each time the krb5 library has a question to ask or
|
||||
information to present. When the prompter callback is invoked, the
|
||||
*banner* argument (if not null) is intended to be displayed to the
|
||||
user, and the questions to be answered are specified in the *prompts*
|
||||
array. Each prompt contains a text question in the *prompt* field, a
|
||||
*hidden* bit to indicate whether the answer should be hidden from
|
||||
display, and a storage area for the answer in the *reply* field. The
|
||||
callback should fill in each question's ``reply->data`` with the
|
||||
answer, up to a maximum number of ``reply->length`` bytes, and then
|
||||
reset ``reply->length`` to the length of the answer.
|
||||
|
||||
A prompter callback can call :c:func:`krb5_get_prompt_types` to get an
|
||||
array of type constants corresponding to the prompts, to get
|
||||
programmatic information about the semantic meaning of the questions.
|
||||
:c:func:`krb5_get_prompt_types` may return a null pointer if no prompt
|
||||
type information is available.
|
||||
|
||||
Text-based applications can use a built-in text prompter
|
||||
implementation by supplying :c:func:`krb5_prompter_posix` as the
|
||||
*prompter* parameter and a null pointer as the *data* parameter. For
|
||||
example::
|
||||
|
||||
ret = krb5_get_init_creds_password(context, &creds, client_princ,
|
||||
NULL, krb5_prompter_posix, NULL, 0,
|
||||
NULL, NULL);
|
||||
|
||||
Responder callback
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A responder callback can be specified through the init_creds options
|
||||
using the :c:func:`krb5_get_init_creds_opt_set_responder` function.
|
||||
Responder callbacks can present a more sophisticated user interface
|
||||
for authentication secrets. The responder callback is usually invoked
|
||||
only once per authentication, with a list of questions produced by all
|
||||
of the allowed preauthentication mechanisms.
|
||||
|
||||
When the responder callback is invoked, the *rctx* argument can be
|
||||
accessed to obtain the list of questions and to answer them. The
|
||||
:c:func:`krb5_responder_list_questions` function retrieves an array of
|
||||
question types. For each question type, the
|
||||
:c:func:`krb5_responder_get_challenge` function retrieves additional
|
||||
information about the question, if applicable, and the
|
||||
:c:func:`krb5_responder_set_answer` function sets the answer.
|
||||
|
||||
Responder question types, challenges, and answers are UTF-8 strings.
|
||||
The question type is a well-known string; the meaning of the challenge
|
||||
and answer depend on the question type. If an application does not
|
||||
understand a question type, it cannot interpret the challenge or
|
||||
provide an answer. Failing to answer a question typically results in
|
||||
the prompter callback being used as a fallback.
|
||||
|
||||
Password question
|
||||
#################
|
||||
|
||||
The :c:macro:`KRB5_RESPONDER_QUESTION_PASSWORD` (or ``"password"``)
|
||||
question type requests the user's password. This question does not
|
||||
have a challenge, and the response is simply the password string.
|
||||
|
||||
One-time password question
|
||||
##########################
|
||||
|
||||
The :c:macro:`KRB5_RESPONDER_QUESTION_OTP` (or ``"otp"``) question
|
||||
type requests a choice among one-time password tokens and the PIN and
|
||||
value for the chosen token. The challenge and answer are JSON-encoded
|
||||
strings, but an application can use convenience functions to avoid
|
||||
doing any JSON processing itself.
|
||||
|
||||
The :c:func:`krb5_responder_otp_get_challenge` function decodes the
|
||||
challenge into a krb5_responder_otp_challenge structure. The
|
||||
:c:func:`krb5_responder_otp_set_answer` function selects one of the
|
||||
token information elements from the challenge and supplies the value
|
||||
and pin for that token.
|
||||
|
||||
PKINIT password or PIN question
|
||||
###############################
|
||||
|
||||
The :c:macro:`KRB5_RESPONDER_QUESTION_PKINIT` (or ``"pkinit"``) question
|
||||
type requests PINs for hardware devices and/or passwords for encrypted
|
||||
credentials which are stored on disk, potentially also supplying
|
||||
information about the state of the hardware devices. The challenge and
|
||||
answer are JSON-encoded strings, but an application can use convenience
|
||||
functions to avoid doing any JSON processing itself.
|
||||
|
||||
The :c:func:`krb5_responder_pkinit_get_challenge` function decodes the
|
||||
challenges into a krb5_responder_pkinit_challenge structure. The
|
||||
:c:func:`krb5_responder_pkinit_set_answer` function can be used to
|
||||
supply the PIN or password for a particular client credential, and can
|
||||
be called multiple times.
|
||||
|
||||
Example
|
||||
#######
|
||||
|
||||
Here is an example of using a responder callback::
|
||||
|
||||
static krb5_error_code
|
||||
my_responder(krb5_context context, void *data,
|
||||
krb5_responder_context rctx)
|
||||
{
|
||||
krb5_error_code ret;
|
||||
krb5_responder_otp_challenge *chl;
|
||||
|
||||
if (krb5_responder_get_challenge(context, rctx,
|
||||
KRB5_RESPONDER_QUESTION_PASSWORD)) {
|
||||
ret = krb5_responder_set_answer(context, rctx,
|
||||
KRB5_RESPONDER_QUESTION_PASSWORD,
|
||||
"open sesame");
|
||||
if (ret)
|
||||
return ret;
|
||||
}
|
||||
ret = krb5_responder_otp_get_challenge(context, rctx, &chl);
|
||||
if (ret == 0 && chl != NULL) {
|
||||
ret = krb5_responder_otp_set_answer(context, rctx, 0, "1234",
|
||||
NULL);
|
||||
krb5_responder_otp_challenge_free(context, rctx, chl);
|
||||
if (ret)
|
||||
return ret;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
static krb5_error_code
|
||||
get_creds(krb5_context context, krb5_principal client_princ)
|
||||
{
|
||||
krb5_error_code ret;
|
||||
krb5_get_init_creds_opt *opt = NULL;
|
||||
krb5_creds creds;
|
||||
|
||||
memset(&creds, 0, sizeof(creds));
|
||||
ret = krb5_get_init_creds_opt_alloc(context, &opt);
|
||||
if (ret)
|
||||
goto cleanup;
|
||||
ret = krb5_get_init_creds_opt_set_responder(context, opt, my_responder,
|
||||
NULL);
|
||||
if (ret)
|
||||
goto cleanup;
|
||||
ret = krb5_get_init_creds_password(context, &creds, client_princ,
|
||||
NULL, NULL, NULL, 0, NULL, opt);
|
||||
|
||||
cleanup:
|
||||
krb5_get_init_creds_opt_free(context, opt);
|
||||
krb5_free_cred_contents(context, &creds);
|
||||
return ret;
|
||||
}
|
||||
|
||||
Verifying initial credentials
|
||||
-----------------------------
|
||||
|
||||
Use the function :c:func:`krb5_verify_init_creds` to verify initial
|
||||
credentials. It takes an options structure (which can be a null
|
||||
pointer). Use :c:func:`krb5_verify_init_creds_opt_init` to initialize
|
||||
the caller-allocated options structure, and
|
||||
:c:func:`krb5_verify_init_creds_opt_set_ap_req_nofail` to set the
|
||||
"nofail" option. For example::
|
||||
|
||||
krb5_verify_init_creds_opt vopt;
|
||||
|
||||
krb5_verify_init_creds_opt_init(&vopt);
|
||||
krb5_verify_init_creds_opt_set_ap_req_nofail(&vopt, 1);
|
||||
ret = krb5_verify_init_creds(context, &creds, NULL, NULL, NULL, &vopt);
|
||||
|
||||
The confusingly named "nofail" option, when set, means that the
|
||||
verification must actually succeed in order for
|
||||
:c:func:`krb5_verify_init_creds` to indicate success. The default
|
||||
state of this option (cleared) means that if there is no key material
|
||||
available to verify the user credentials, the verification will
|
||||
succeed anyway. (The default can be changed by a configuration file
|
||||
setting.)
|
||||
|
||||
This accommodates a use case where a large number of unkeyed shared
|
||||
desktop workstations need to allow users to log in using Kerberos.
|
||||
The security risks from this practice are mitigated by the absence of
|
||||
valuable state on the shared workstations---any valuable resources
|
||||
that the users would access reside on networked servers.
|
||||
79
crypto/krb5/doc/appdev/princ_handle.rst
Normal file
79
crypto/krb5/doc/appdev/princ_handle.rst
Normal file
|
|
@ -0,0 +1,79 @@
|
|||
Principal manipulation and parsing
|
||||
==================================
|
||||
|
||||
Kerberos principal structure
|
||||
|
||||
..
|
||||
|
||||
:c:type:`krb5_principal_data`
|
||||
|
||||
:c:type:`krb5_principal`
|
||||
|
||||
..
|
||||
|
||||
Create and free principal
|
||||
|
||||
..
|
||||
|
||||
:c:func:`krb5_build_principal()`
|
||||
|
||||
:c:func:`krb5_build_principal_alloc_va()`
|
||||
|
||||
:c:func:`krb5_build_principal_ext()`
|
||||
|
||||
:c:func:`krb5_copy_principal()`
|
||||
|
||||
:c:func:`krb5_free_principal()`
|
||||
|
||||
:c:func:`krb5_cc_get_principal()`
|
||||
|
||||
..
|
||||
|
||||
Comparing
|
||||
|
||||
..
|
||||
|
||||
:c:func:`krb5_principal_compare()`
|
||||
|
||||
:c:func:`krb5_principal_compare_flags()`
|
||||
|
||||
:c:func:`krb5_principal_compare_any_realm()`
|
||||
|
||||
:c:func:`krb5_sname_match()`
|
||||
|
||||
:c:func:`krb5_sname_to_principal()`
|
||||
|
||||
..
|
||||
|
||||
|
||||
Parsing:
|
||||
|
||||
..
|
||||
|
||||
:c:func:`krb5_parse_name()`
|
||||
|
||||
:c:func:`krb5_parse_name_flags()`
|
||||
|
||||
:c:func:`krb5_unparse_name()`
|
||||
|
||||
:c:func:`krb5_unparse_name_flags()`
|
||||
|
||||
..
|
||||
|
||||
Utilities:
|
||||
|
||||
..
|
||||
|
||||
:c:func:`krb5_is_config_principal()`
|
||||
|
||||
:c:func:`krb5_kuserok()`
|
||||
|
||||
:c:func:`krb5_set_password()`
|
||||
|
||||
:c:func:`krb5_set_password_using_ccache()`
|
||||
|
||||
:c:func:`krb5_set_principal_realm()`
|
||||
|
||||
:c:func:`krb5_realm_compare()`
|
||||
|
||||
..
|
||||
413
crypto/krb5/doc/appdev/refs/api/index.rst
Normal file
413
crypto/krb5/doc/appdev/refs/api/index.rst
Normal file
|
|
@ -0,0 +1,413 @@
|
|||
krb5 API
|
||||
========
|
||||
|
||||
|
||||
Frequently used public interfaces
|
||||
----------------------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
krb5_build_principal.rst
|
||||
krb5_build_principal_alloc_va.rst
|
||||
krb5_build_principal_ext.rst
|
||||
krb5_cc_close.rst
|
||||
krb5_cc_default.rst
|
||||
krb5_cc_default_name.rst
|
||||
krb5_cc_destroy.rst
|
||||
krb5_cc_dup.rst
|
||||
krb5_cc_get_name.rst
|
||||
krb5_cc_get_principal.rst
|
||||
krb5_cc_get_type.rst
|
||||
krb5_cc_initialize.rst
|
||||
krb5_cc_new_unique.rst
|
||||
krb5_cc_resolve.rst
|
||||
krb5_change_password.rst
|
||||
krb5_chpw_message.rst
|
||||
krb5_expand_hostname.rst
|
||||
krb5_free_context.rst
|
||||
krb5_free_error_message.rst
|
||||
krb5_free_principal.rst
|
||||
krb5_fwd_tgt_creds.rst
|
||||
krb5_get_default_realm.rst
|
||||
krb5_get_error_message.rst
|
||||
krb5_get_host_realm.rst
|
||||
krb5_get_credentials.rst
|
||||
krb5_get_fallback_host_realm.rst
|
||||
krb5_get_init_creds_keytab.rst
|
||||
krb5_get_init_creds_opt_alloc.rst
|
||||
krb5_get_init_creds_opt_free.rst
|
||||
krb5_get_init_creds_opt_get_fast_flags.rst
|
||||
krb5_get_init_creds_opt_set_address_list.rst
|
||||
krb5_get_init_creds_opt_set_anonymous.rst
|
||||
krb5_get_init_creds_opt_set_canonicalize.rst
|
||||
krb5_get_init_creds_opt_set_change_password_prompt.rst
|
||||
krb5_get_init_creds_opt_set_etype_list.rst
|
||||
krb5_get_init_creds_opt_set_expire_callback.rst
|
||||
krb5_get_init_creds_opt_set_fast_ccache.rst
|
||||
krb5_get_init_creds_opt_set_fast_ccache_name.rst
|
||||
krb5_get_init_creds_opt_set_fast_flags.rst
|
||||
krb5_get_init_creds_opt_set_forwardable.rst
|
||||
krb5_get_init_creds_opt_set_in_ccache.rst
|
||||
krb5_get_init_creds_opt_set_out_ccache.rst
|
||||
krb5_get_init_creds_opt_set_pa.rst
|
||||
krb5_get_init_creds_opt_set_pac_request.rst
|
||||
krb5_get_init_creds_opt_set_preauth_list.rst
|
||||
krb5_get_init_creds_opt_set_proxiable.rst
|
||||
krb5_get_init_creds_opt_set_renew_life.rst
|
||||
krb5_get_init_creds_opt_set_responder.rst
|
||||
krb5_get_init_creds_opt_set_salt.rst
|
||||
krb5_get_init_creds_opt_set_tkt_life.rst
|
||||
krb5_get_init_creds_password.rst
|
||||
krb5_get_profile.rst
|
||||
krb5_get_prompt_types.rst
|
||||
krb5_get_renewed_creds.rst
|
||||
krb5_get_validated_creds.rst
|
||||
krb5_init_context.rst
|
||||
krb5_init_secure_context.rst
|
||||
krb5_is_config_principal.rst
|
||||
krb5_is_thread_safe.rst
|
||||
krb5_kt_close.rst
|
||||
krb5_kt_client_default.rst
|
||||
krb5_kt_default.rst
|
||||
krb5_kt_default_name.rst
|
||||
krb5_kt_dup.rst
|
||||
krb5_kt_get_name.rst
|
||||
krb5_kt_get_type.rst
|
||||
krb5_kt_resolve.rst
|
||||
krb5_kuserok.rst
|
||||
krb5_parse_name.rst
|
||||
krb5_parse_name_flags.rst
|
||||
krb5_principal_compare.rst
|
||||
krb5_principal_compare_any_realm.rst
|
||||
krb5_principal_compare_flags.rst
|
||||
krb5_prompter_posix.rst
|
||||
krb5_realm_compare.rst
|
||||
krb5_responder_get_challenge.rst
|
||||
krb5_responder_list_questions.rst
|
||||
krb5_responder_set_answer.rst
|
||||
krb5_responder_otp_get_challenge.rst
|
||||
krb5_responder_otp_set_answer.rst
|
||||
krb5_responder_otp_challenge_free.rst
|
||||
krb5_responder_pkinit_get_challenge.rst
|
||||
krb5_responder_pkinit_set_answer.rst
|
||||
krb5_responder_pkinit_challenge_free.rst
|
||||
krb5_set_default_realm.rst
|
||||
krb5_set_password.rst
|
||||
krb5_set_password_using_ccache.rst
|
||||
krb5_set_principal_realm.rst
|
||||
krb5_set_trace_callback.rst
|
||||
krb5_set_trace_filename.rst
|
||||
krb5_sname_match.rst
|
||||
krb5_sname_to_principal.rst
|
||||
krb5_unparse_name.rst
|
||||
krb5_unparse_name_ext.rst
|
||||
krb5_unparse_name_flags.rst
|
||||
krb5_unparse_name_flags_ext.rst
|
||||
krb5_us_timeofday.rst
|
||||
krb5_verify_authdata_kdc_issued.rst
|
||||
|
||||
Rarely used public interfaces
|
||||
--------------------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
krb5_425_conv_principal.rst
|
||||
krb5_524_conv_principal.rst
|
||||
krb5_address_compare.rst
|
||||
krb5_address_order.rst
|
||||
krb5_address_search.rst
|
||||
krb5_allow_weak_crypto.rst
|
||||
krb5_aname_to_localname.rst
|
||||
krb5_anonymous_principal.rst
|
||||
krb5_anonymous_realm.rst
|
||||
krb5_appdefault_boolean.rst
|
||||
krb5_appdefault_string.rst
|
||||
krb5_auth_con_free.rst
|
||||
krb5_auth_con_genaddrs.rst
|
||||
krb5_auth_con_get_checksum_func.rst
|
||||
krb5_auth_con_getaddrs.rst
|
||||
krb5_auth_con_getauthenticator.rst
|
||||
krb5_auth_con_getflags.rst
|
||||
krb5_auth_con_getkey.rst
|
||||
krb5_auth_con_getkey_k.rst
|
||||
krb5_auth_con_getlocalseqnumber.rst
|
||||
krb5_auth_con_getrcache.rst
|
||||
krb5_auth_con_getrecvsubkey.rst
|
||||
krb5_auth_con_getrecvsubkey_k.rst
|
||||
krb5_auth_con_getremoteseqnumber.rst
|
||||
krb5_auth_con_getsendsubkey.rst
|
||||
krb5_auth_con_getsendsubkey_k.rst
|
||||
krb5_auth_con_init.rst
|
||||
krb5_auth_con_set_checksum_func.rst
|
||||
krb5_auth_con_set_req_cksumtype.rst
|
||||
krb5_auth_con_setaddrs.rst
|
||||
krb5_auth_con_setflags.rst
|
||||
krb5_auth_con_setports.rst
|
||||
krb5_auth_con_setrcache.rst
|
||||
krb5_auth_con_setrecvsubkey.rst
|
||||
krb5_auth_con_setrecvsubkey_k.rst
|
||||
krb5_auth_con_setsendsubkey.rst
|
||||
krb5_auth_con_setsendsubkey_k.rst
|
||||
krb5_auth_con_setuseruserkey.rst
|
||||
krb5_cc_cache_match.rst
|
||||
krb5_cc_copy_creds.rst
|
||||
krb5_cc_end_seq_get.rst
|
||||
krb5_cc_get_config.rst
|
||||
krb5_cc_get_flags.rst
|
||||
krb5_cc_get_full_name.rst
|
||||
krb5_cc_move.rst
|
||||
krb5_cc_next_cred.rst
|
||||
krb5_cc_remove_cred.rst
|
||||
krb5_cc_retrieve_cred.rst
|
||||
krb5_cc_select.rst
|
||||
krb5_cc_set_config.rst
|
||||
krb5_cc_set_default_name.rst
|
||||
krb5_cc_set_flags.rst
|
||||
krb5_cc_start_seq_get.rst
|
||||
krb5_cc_store_cred.rst
|
||||
krb5_cc_support_switch.rst
|
||||
krb5_cc_switch.rst
|
||||
krb5_cccol_cursor_free.rst
|
||||
krb5_cccol_cursor_new.rst
|
||||
krb5_cccol_cursor_next.rst
|
||||
krb5_cccol_have_content.rst
|
||||
krb5_clear_error_message.rst
|
||||
krb5_check_clockskew.rst
|
||||
krb5_copy_addresses.rst
|
||||
krb5_copy_authdata.rst
|
||||
krb5_copy_authenticator.rst
|
||||
krb5_copy_checksum.rst
|
||||
krb5_copy_context.rst
|
||||
krb5_copy_creds.rst
|
||||
krb5_copy_data.rst
|
||||
krb5_copy_error_message.rst
|
||||
krb5_copy_keyblock.rst
|
||||
krb5_copy_keyblock_contents.rst
|
||||
krb5_copy_principal.rst
|
||||
krb5_copy_ticket.rst
|
||||
krb5_find_authdata.rst
|
||||
krb5_free_addresses.rst
|
||||
krb5_free_ap_rep_enc_part.rst
|
||||
krb5_free_authdata.rst
|
||||
krb5_free_authenticator.rst
|
||||
krb5_free_cred_contents.rst
|
||||
krb5_free_creds.rst
|
||||
krb5_free_data.rst
|
||||
krb5_free_data_contents.rst
|
||||
krb5_free_default_realm.rst
|
||||
krb5_free_enctypes.rst
|
||||
krb5_free_error.rst
|
||||
krb5_free_host_realm.rst
|
||||
krb5_free_keyblock.rst
|
||||
krb5_free_keyblock_contents.rst
|
||||
krb5_free_keytab_entry_contents.rst
|
||||
krb5_free_string.rst
|
||||
krb5_free_ticket.rst
|
||||
krb5_free_unparsed_name.rst
|
||||
krb5_get_etype_info.rst
|
||||
krb5_get_permitted_enctypes.rst
|
||||
krb5_get_server_rcache.rst
|
||||
krb5_get_time_offsets.rst
|
||||
krb5_init_context_profile.rst
|
||||
krb5_init_creds_free.rst
|
||||
krb5_init_creds_get.rst
|
||||
krb5_init_creds_get_creds.rst
|
||||
krb5_init_creds_get_error.rst
|
||||
krb5_init_creds_get_times.rst
|
||||
krb5_init_creds_init.rst
|
||||
krb5_init_creds_set_keytab.rst
|
||||
krb5_init_creds_set_password.rst
|
||||
krb5_init_creds_set_service.rst
|
||||
krb5_init_creds_step.rst
|
||||
krb5_init_keyblock.rst
|
||||
krb5_is_referral_realm.rst
|
||||
krb5_kdc_sign_ticket.rst
|
||||
krb5_kdc_verify_ticket.rst
|
||||
krb5_kt_add_entry.rst
|
||||
krb5_kt_end_seq_get.rst
|
||||
krb5_kt_get_entry.rst
|
||||
krb5_kt_have_content.rst
|
||||
krb5_kt_next_entry.rst
|
||||
krb5_kt_read_service_key.rst
|
||||
krb5_kt_remove_entry.rst
|
||||
krb5_kt_start_seq_get.rst
|
||||
krb5_make_authdata_kdc_issued.rst
|
||||
krb5_marshal_credentials.rst
|
||||
krb5_merge_authdata.rst
|
||||
krb5_mk_1cred.rst
|
||||
krb5_mk_error.rst
|
||||
krb5_mk_ncred.rst
|
||||
krb5_mk_priv.rst
|
||||
krb5_mk_rep.rst
|
||||
krb5_mk_rep_dce.rst
|
||||
krb5_mk_req.rst
|
||||
krb5_mk_req_extended.rst
|
||||
krb5_mk_safe.rst
|
||||
krb5_os_localaddr.rst
|
||||
krb5_pac_add_buffer.rst
|
||||
krb5_pac_free.rst
|
||||
krb5_pac_get_buffer.rst
|
||||
krb5_pac_get_types.rst
|
||||
krb5_pac_init.rst
|
||||
krb5_pac_parse.rst
|
||||
krb5_pac_sign.rst
|
||||
krb5_pac_sign_ext.rst
|
||||
krb5_pac_verify.rst
|
||||
krb5_pac_verify_ext.rst
|
||||
krb5_pac_get_client_info.rst
|
||||
krb5_prepend_error_message.rst
|
||||
krb5_principal2salt.rst
|
||||
krb5_rd_cred.rst
|
||||
krb5_rd_error.rst
|
||||
krb5_rd_priv.rst
|
||||
krb5_rd_rep.rst
|
||||
krb5_rd_rep_dce.rst
|
||||
krb5_rd_req.rst
|
||||
krb5_rd_safe.rst
|
||||
krb5_read_password.rst
|
||||
krb5_salttype_to_string.rst
|
||||
krb5_server_decrypt_ticket_keytab.rst
|
||||
krb5_set_default_tgs_enctypes.rst
|
||||
krb5_set_error_message.rst
|
||||
krb5_set_kdc_recv_hook.rst
|
||||
krb5_set_kdc_send_hook.rst
|
||||
krb5_set_real_time.rst
|
||||
krb5_string_to_cksumtype.rst
|
||||
krb5_string_to_deltat.rst
|
||||
krb5_string_to_enctype.rst
|
||||
krb5_string_to_salttype.rst
|
||||
krb5_string_to_timestamp.rst
|
||||
krb5_timeofday.rst
|
||||
krb5_timestamp_to_sfstring.rst
|
||||
krb5_timestamp_to_string.rst
|
||||
krb5_tkt_creds_free.rst
|
||||
krb5_tkt_creds_get.rst
|
||||
krb5_tkt_creds_get_creds.rst
|
||||
krb5_tkt_creds_get_times.rst
|
||||
krb5_tkt_creds_init.rst
|
||||
krb5_tkt_creds_step.rst
|
||||
krb5_unmarshal_credentials.rst
|
||||
krb5_verify_init_creds.rst
|
||||
krb5_verify_init_creds_opt_init.rst
|
||||
krb5_verify_init_creds_opt_set_ap_req_nofail.rst
|
||||
krb5_vprepend_error_message.rst
|
||||
krb5_vset_error_message.rst
|
||||
krb5_vwrap_error_message.rst
|
||||
krb5_wrap_error_message.rst
|
||||
|
||||
|
||||
Public interfaces that should not be called directly
|
||||
-------------------------------------------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
krb5_c_block_size.rst
|
||||
krb5_c_checksum_length.rst
|
||||
krb5_c_crypto_length.rst
|
||||
krb5_c_crypto_length_iov.rst
|
||||
krb5_c_decrypt.rst
|
||||
krb5_c_decrypt_iov.rst
|
||||
krb5_c_derive_prfplus.rst
|
||||
krb5_c_encrypt.rst
|
||||
krb5_c_encrypt_iov.rst
|
||||
krb5_c_encrypt_length.rst
|
||||
krb5_c_enctype_compare.rst
|
||||
krb5_c_free_state.rst
|
||||
krb5_c_fx_cf2_simple.rst
|
||||
krb5_c_init_state.rst
|
||||
krb5_c_is_coll_proof_cksum.rst
|
||||
krb5_c_is_keyed_cksum.rst
|
||||
krb5_c_keyed_checksum_types.rst
|
||||
krb5_c_keylengths.rst
|
||||
krb5_c_make_checksum.rst
|
||||
krb5_c_make_checksum_iov.rst
|
||||
krb5_c_make_random_key.rst
|
||||
krb5_c_padding_length.rst
|
||||
krb5_c_prf.rst
|
||||
krb5_c_prfplus.rst
|
||||
krb5_c_prf_length.rst
|
||||
krb5_c_random_add_entropy.rst
|
||||
krb5_c_random_make_octets.rst
|
||||
krb5_c_random_os_entropy.rst
|
||||
krb5_c_random_to_key.rst
|
||||
krb5_c_string_to_key.rst
|
||||
krb5_c_string_to_key_with_params.rst
|
||||
krb5_c_valid_cksumtype.rst
|
||||
krb5_c_valid_enctype.rst
|
||||
krb5_c_verify_checksum.rst
|
||||
krb5_c_verify_checksum_iov.rst
|
||||
krb5_cksumtype_to_string.rst
|
||||
krb5_decode_authdata_container.rst
|
||||
krb5_decode_ticket.rst
|
||||
krb5_deltat_to_string.rst
|
||||
krb5_encode_authdata_container.rst
|
||||
krb5_enctype_to_name.rst
|
||||
krb5_enctype_to_string.rst
|
||||
krb5_free_checksum.rst
|
||||
krb5_free_checksum_contents.rst
|
||||
krb5_free_cksumtypes.rst
|
||||
krb5_free_tgt_creds.rst
|
||||
krb5_k_create_key.rst
|
||||
krb5_k_decrypt.rst
|
||||
krb5_k_decrypt_iov.rst
|
||||
krb5_k_encrypt.rst
|
||||
krb5_k_encrypt_iov.rst
|
||||
krb5_k_free_key.rst
|
||||
krb5_k_key_enctype.rst
|
||||
krb5_k_key_keyblock.rst
|
||||
krb5_k_make_checksum.rst
|
||||
krb5_k_make_checksum_iov.rst
|
||||
krb5_k_prf.rst
|
||||
krb5_k_reference_key.rst
|
||||
krb5_k_verify_checksum.rst
|
||||
krb5_k_verify_checksum_iov.rst
|
||||
|
||||
|
||||
Legacy convenience interfaces
|
||||
------------------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
krb5_recvauth.rst
|
||||
krb5_recvauth_version.rst
|
||||
krb5_sendauth.rst
|
||||
|
||||
|
||||
Deprecated public interfaces
|
||||
------------------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
krb5_524_convert_creds.rst
|
||||
krb5_auth_con_getlocalsubkey.rst
|
||||
krb5_auth_con_getremotesubkey.rst
|
||||
krb5_auth_con_initivector.rst
|
||||
krb5_build_principal_va.rst
|
||||
krb5_c_random_seed.rst
|
||||
krb5_calculate_checksum.rst
|
||||
krb5_checksum_size.rst
|
||||
krb5_encrypt.rst
|
||||
krb5_decrypt.rst
|
||||
krb5_eblock_enctype.rst
|
||||
krb5_encrypt_size.rst
|
||||
krb5_finish_key.rst
|
||||
krb5_finish_random_key.rst
|
||||
krb5_cc_gen_new.rst
|
||||
krb5_get_credentials_renew.rst
|
||||
krb5_get_credentials_validate.rst
|
||||
krb5_get_in_tkt_with_password.rst
|
||||
krb5_get_in_tkt_with_skey.rst
|
||||
krb5_get_in_tkt_with_keytab.rst
|
||||
krb5_get_init_creds_opt_init.rst
|
||||
krb5_init_random_key.rst
|
||||
krb5_kt_free_entry.rst
|
||||
krb5_random_key.rst
|
||||
krb5_process_key.rst
|
||||
krb5_string_to_key.rst
|
||||
krb5_use_enctype.rst
|
||||
krb5_verify_checksum.rst
|
||||
9
crypto/krb5/doc/appdev/refs/index.rst
Normal file
9
crypto/krb5/doc/appdev/refs/index.rst
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
Complete reference - API and datatypes
|
||||
======================================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
api/index.rst
|
||||
types/index.rst
|
||||
macros/index.rst
|
||||
397
crypto/krb5/doc/appdev/refs/macros/index.rst
Normal file
397
crypto/krb5/doc/appdev/refs/macros/index.rst
Normal file
|
|
@ -0,0 +1,397 @@
|
|||
krb5 simple macros
|
||||
=========================
|
||||
|
||||
Public
|
||||
-------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
ADDRTYPE_ADDRPORT.rst
|
||||
ADDRTYPE_CHAOS.rst
|
||||
ADDRTYPE_DDP.rst
|
||||
ADDRTYPE_INET.rst
|
||||
ADDRTYPE_INET6.rst
|
||||
ADDRTYPE_IPPORT.rst
|
||||
ADDRTYPE_ISO.rst
|
||||
ADDRTYPE_IS_LOCAL.rst
|
||||
ADDRTYPE_NETBIOS.rst
|
||||
ADDRTYPE_XNS.rst
|
||||
AD_TYPE_EXTERNAL.rst
|
||||
AD_TYPE_FIELD_TYPE_MASK.rst
|
||||
AD_TYPE_REGISTERED.rst
|
||||
AD_TYPE_RESERVED.rst
|
||||
AP_OPTS_ETYPE_NEGOTIATION.rst
|
||||
AP_OPTS_MUTUAL_REQUIRED.rst
|
||||
AP_OPTS_RESERVED.rst
|
||||
AP_OPTS_USE_SESSION_KEY.rst
|
||||
AP_OPTS_USE_SUBKEY.rst
|
||||
AP_OPTS_WIRE_MASK.rst
|
||||
CKSUMTYPE_CMAC_CAMELLIA128.rst
|
||||
CKSUMTYPE_CMAC_CAMELLIA256.rst
|
||||
CKSUMTYPE_CRC32.rst
|
||||
CKSUMTYPE_DESCBC.rst
|
||||
CKSUMTYPE_HMAC_MD5_ARCFOUR.rst
|
||||
CKSUMTYPE_HMAC_SHA1_96_AES128.rst
|
||||
CKSUMTYPE_HMAC_SHA1_96_AES256.rst
|
||||
CKSUMTYPE_HMAC_SHA256_128_AES128.rst
|
||||
CKSUMTYPE_HMAC_SHA384_192_AES256.rst
|
||||
CKSUMTYPE_HMAC_SHA1_DES3.rst
|
||||
CKSUMTYPE_MD5_HMAC_ARCFOUR.rst
|
||||
CKSUMTYPE_NIST_SHA.rst
|
||||
CKSUMTYPE_RSA_MD4.rst
|
||||
CKSUMTYPE_RSA_MD4_DES.rst
|
||||
CKSUMTYPE_RSA_MD5.rst
|
||||
CKSUMTYPE_RSA_MD5_DES.rst
|
||||
CKSUMTYPE_SHA1.rst
|
||||
ENCTYPE_AES128_CTS_HMAC_SHA1_96.rst
|
||||
ENCTYPE_AES128_CTS_HMAC_SHA256_128.rst
|
||||
ENCTYPE_AES256_CTS_HMAC_SHA1_96.rst
|
||||
ENCTYPE_AES256_CTS_HMAC_SHA384_192.rst
|
||||
ENCTYPE_ARCFOUR_HMAC.rst
|
||||
ENCTYPE_ARCFOUR_HMAC_EXP.rst
|
||||
ENCTYPE_CAMELLIA128_CTS_CMAC.rst
|
||||
ENCTYPE_CAMELLIA256_CTS_CMAC.rst
|
||||
ENCTYPE_DES3_CBC_ENV.rst
|
||||
ENCTYPE_DES3_CBC_RAW.rst
|
||||
ENCTYPE_DES3_CBC_SHA.rst
|
||||
ENCTYPE_DES3_CBC_SHA1.rst
|
||||
ENCTYPE_DES_CBC_CRC.rst
|
||||
ENCTYPE_DES_CBC_MD4.rst
|
||||
ENCTYPE_DES_CBC_MD5.rst
|
||||
ENCTYPE_DES_CBC_RAW.rst
|
||||
ENCTYPE_DES_HMAC_SHA1.rst
|
||||
ENCTYPE_DSA_SHA1_CMS.rst
|
||||
ENCTYPE_MD5_RSA_CMS.rst
|
||||
ENCTYPE_NULL.rst
|
||||
ENCTYPE_RC2_CBC_ENV.rst
|
||||
ENCTYPE_RSA_ENV.rst
|
||||
ENCTYPE_RSA_ES_OAEP_ENV.rst
|
||||
ENCTYPE_SHA1_RSA_CMS.rst
|
||||
ENCTYPE_UNKNOWN.rst
|
||||
KDC_OPT_ALLOW_POSTDATE.rst
|
||||
KDC_OPT_CANONICALIZE.rst
|
||||
KDC_OPT_CNAME_IN_ADDL_TKT.rst
|
||||
KDC_OPT_DISABLE_TRANSITED_CHECK.rst
|
||||
KDC_OPT_ENC_TKT_IN_SKEY.rst
|
||||
KDC_OPT_FORWARDABLE.rst
|
||||
KDC_OPT_FORWARDED.rst
|
||||
KDC_OPT_POSTDATED.rst
|
||||
KDC_OPT_PROXIABLE.rst
|
||||
KDC_OPT_PROXY.rst
|
||||
KDC_OPT_RENEW.rst
|
||||
KDC_OPT_RENEWABLE.rst
|
||||
KDC_OPT_RENEWABLE_OK.rst
|
||||
KDC_OPT_REQUEST_ANONYMOUS.rst
|
||||
KDC_OPT_VALIDATE.rst
|
||||
KDC_TKT_COMMON_MASK.rst
|
||||
KRB5_ALTAUTH_ATT_CHALLENGE_RESPONSE.rst
|
||||
KRB5_ANONYMOUS_PRINCSTR.rst
|
||||
KRB5_ANONYMOUS_REALMSTR.rst
|
||||
KRB5_AP_REP.rst
|
||||
KRB5_AP_REQ.rst
|
||||
KRB5_AS_REP.rst
|
||||
KRB5_AS_REQ.rst
|
||||
KRB5_AUTHDATA_AND_OR.rst
|
||||
KRB5_AUTHDATA_AP_OPTIONS.rst
|
||||
KRB5_AUTHDATA_AUTH_INDICATOR.rst
|
||||
KRB5_AUTHDATA_CAMMAC.rst
|
||||
KRB5_AUTHDATA_ETYPE_NEGOTIATION.rst
|
||||
KRB5_AUTHDATA_FX_ARMOR.rst
|
||||
KRB5_AUTHDATA_IF_RELEVANT.rst
|
||||
KRB5_AUTHDATA_INITIAL_VERIFIED_CAS.rst
|
||||
KRB5_AUTHDATA_KDC_ISSUED.rst
|
||||
KRB5_AUTHDATA_MANDATORY_FOR_KDC.rst
|
||||
KRB5_AUTHDATA_OSF_DCE.rst
|
||||
KRB5_AUTHDATA_SESAME.rst
|
||||
KRB5_AUTHDATA_SIGNTICKET.rst
|
||||
KRB5_AUTHDATA_WIN2K_PAC.rst
|
||||
KRB5_AUTH_CONTEXT_DO_SEQUENCE.rst
|
||||
KRB5_AUTH_CONTEXT_DO_TIME.rst
|
||||
KRB5_AUTH_CONTEXT_GENERATE_LOCAL_ADDR.rst
|
||||
KRB5_AUTH_CONTEXT_GENERATE_LOCAL_FULL_ADDR.rst
|
||||
KRB5_AUTH_CONTEXT_GENERATE_REMOTE_ADDR.rst
|
||||
KRB5_AUTH_CONTEXT_GENERATE_REMOTE_FULL_ADDR.rst
|
||||
KRB5_AUTH_CONTEXT_PERMIT_ALL.rst
|
||||
KRB5_AUTH_CONTEXT_RET_SEQUENCE.rst
|
||||
KRB5_AUTH_CONTEXT_RET_TIME.rst
|
||||
KRB5_AUTH_CONTEXT_USE_SUBKEY.rst
|
||||
KRB5_CRED.rst
|
||||
KRB5_CRYPTO_TYPE_CHECKSUM.rst
|
||||
KRB5_CRYPTO_TYPE_DATA.rst
|
||||
KRB5_CRYPTO_TYPE_EMPTY.rst
|
||||
KRB5_CRYPTO_TYPE_HEADER.rst
|
||||
KRB5_CRYPTO_TYPE_PADDING.rst
|
||||
KRB5_CRYPTO_TYPE_SIGN_ONLY.rst
|
||||
KRB5_CRYPTO_TYPE_STREAM.rst
|
||||
KRB5_CRYPTO_TYPE_TRAILER.rst
|
||||
KRB5_CYBERSAFE_SECUREID.rst
|
||||
KRB5_DOMAIN_X500_COMPRESS.rst
|
||||
KRB5_ENCPADATA_REQ_ENC_PA_REP.rst
|
||||
KRB5_ERROR.rst
|
||||
KRB5_FAST_REQUIRED.rst
|
||||
KRB5_GC_CACHED.rst
|
||||
KRB5_GC_CANONICALIZE.rst
|
||||
KRB5_GC_CONSTRAINED_DELEGATION.rst
|
||||
KRB5_GC_FORWARDABLE.rst
|
||||
KRB5_GC_NO_STORE.rst
|
||||
KRB5_GC_NO_TRANSIT_CHECK.rst
|
||||
KRB5_GC_USER_USER.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_ADDRESS_LIST.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_ANONYMOUS.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_CANONICALIZE.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_CHG_PWD_PRMPT.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_ETYPE_LIST.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_FORWARDABLE.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_PREAUTH_LIST.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_PROXIABLE.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_RENEW_LIFE.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_SALT.rst
|
||||
KRB5_GET_INIT_CREDS_OPT_TKT_LIFE.rst
|
||||
KRB5_INIT_CONTEXT_SECURE.rst
|
||||
KRB5_INIT_CONTEXT_KDC.rst
|
||||
KRB5_INIT_CREDS_STEP_FLAG_CONTINUE.rst
|
||||
KRB5_INT16_MAX.rst
|
||||
KRB5_INT16_MIN.rst
|
||||
KRB5_INT32_MAX.rst
|
||||
KRB5_INT32_MIN.rst
|
||||
KRB5_KEYUSAGE_AD_ITE.rst
|
||||
KRB5_KEYUSAGE_AD_KDCISSUED_CKSUM.rst
|
||||
KRB5_KEYUSAGE_AD_MTE.rst
|
||||
KRB5_KEYUSAGE_AD_SIGNEDPATH.rst
|
||||
KRB5_KEYUSAGE_APP_DATA_CKSUM.rst
|
||||
KRB5_KEYUSAGE_APP_DATA_ENCRYPT.rst
|
||||
KRB5_KEYUSAGE_AP_REP_ENCPART.rst
|
||||
KRB5_KEYUSAGE_AP_REQ_AUTH.rst
|
||||
KRB5_KEYUSAGE_AP_REQ_AUTH_CKSUM.rst
|
||||
KRB5_KEYUSAGE_AS_REP_ENCPART.rst
|
||||
KRB5_KEYUSAGE_AS_REQ.rst
|
||||
KRB5_KEYUSAGE_AS_REQ_PA_ENC_TS.rst
|
||||
KRB5_KEYUSAGE_CAMMAC.rst
|
||||
KRB5_KEYUSAGE_ENC_CHALLENGE_CLIENT.rst
|
||||
KRB5_KEYUSAGE_ENC_CHALLENGE_KDC.rst
|
||||
KRB5_KEYUSAGE_FAST_ENC.rst
|
||||
KRB5_KEYUSAGE_FAST_FINISHED.rst
|
||||
KRB5_KEYUSAGE_FAST_REP.rst
|
||||
KRB5_KEYUSAGE_FAST_REQ_CHKSUM.rst
|
||||
KRB5_KEYUSAGE_GSS_TOK_MIC.rst
|
||||
KRB5_KEYUSAGE_GSS_TOK_WRAP_INTEG.rst
|
||||
KRB5_KEYUSAGE_GSS_TOK_WRAP_PRIV.rst
|
||||
KRB5_KEYUSAGE_IAKERB_FINISHED.rst
|
||||
KRB5_KEYUSAGE_KDC_REP_TICKET.rst
|
||||
KRB5_KEYUSAGE_KRB_CRED_ENCPART.rst
|
||||
KRB5_KEYUSAGE_KRB_ERROR_CKSUM.rst
|
||||
KRB5_KEYUSAGE_KRB_PRIV_ENCPART.rst
|
||||
KRB5_KEYUSAGE_KRB_SAFE_CKSUM.rst
|
||||
KRB5_KEYUSAGE_PA_AS_FRESHNESS.rst
|
||||
KRB5_KEYUSAGE_PA_FX_COOKIE.rst
|
||||
KRB5_KEYUSAGE_PA_OTP_REQUEST.rst
|
||||
KRB5_KEYUSAGE_PA_PKINIT_KX.rst
|
||||
KRB5_KEYUSAGE_PA_S4U_X509_USER_REPLY.rst
|
||||
KRB5_KEYUSAGE_PA_S4U_X509_USER_REQUEST.rst
|
||||
KRB5_KEYUSAGE_PA_SAM_CHALLENGE_CKSUM.rst
|
||||
KRB5_KEYUSAGE_PA_SAM_CHALLENGE_TRACKID.rst
|
||||
KRB5_KEYUSAGE_PA_SAM_RESPONSE.rst
|
||||
KRB5_KEYUSAGE_SPAKE.rst
|
||||
KRB5_KEYUSAGE_TGS_REP_ENCPART_SESSKEY.rst
|
||||
KRB5_KEYUSAGE_TGS_REP_ENCPART_SUBKEY.rst
|
||||
KRB5_KEYUSAGE_TGS_REQ_AD_SESSKEY.rst
|
||||
KRB5_KEYUSAGE_TGS_REQ_AD_SUBKEY.rst
|
||||
KRB5_KEYUSAGE_TGS_REQ_AUTH.rst
|
||||
KRB5_KEYUSAGE_TGS_REQ_AUTH_CKSUM.rst
|
||||
KRB5_KPASSWD_ACCESSDENIED.rst
|
||||
KRB5_KPASSWD_AUTHERROR.rst
|
||||
KRB5_KPASSWD_BAD_VERSION.rst
|
||||
KRB5_KPASSWD_HARDERROR.rst
|
||||
KRB5_KPASSWD_INITIAL_FLAG_NEEDED.rst
|
||||
KRB5_KPASSWD_MALFORMED.rst
|
||||
KRB5_KPASSWD_SOFTERROR.rst
|
||||
KRB5_KPASSWD_SUCCESS.rst
|
||||
KRB5_LRQ_ALL_ACCT_EXPTIME.rst
|
||||
KRB5_LRQ_ALL_LAST_INITIAL.rst
|
||||
KRB5_LRQ_ALL_LAST_RENEWAL.rst
|
||||
KRB5_LRQ_ALL_LAST_REQ.rst
|
||||
KRB5_LRQ_ALL_LAST_TGT.rst
|
||||
KRB5_LRQ_ALL_LAST_TGT_ISSUED.rst
|
||||
KRB5_LRQ_ALL_PW_EXPTIME.rst
|
||||
KRB5_LRQ_NONE.rst
|
||||
KRB5_LRQ_ONE_ACCT_EXPTIME.rst
|
||||
KRB5_LRQ_ONE_LAST_INITIAL.rst
|
||||
KRB5_LRQ_ONE_LAST_RENEWAL.rst
|
||||
KRB5_LRQ_ONE_LAST_REQ.rst
|
||||
KRB5_LRQ_ONE_LAST_TGT.rst
|
||||
KRB5_LRQ_ONE_LAST_TGT_ISSUED.rst
|
||||
KRB5_LRQ_ONE_PW_EXPTIME.rst
|
||||
KRB5_NT_ENTERPRISE_PRINCIPAL.rst
|
||||
KRB5_NT_ENT_PRINCIPAL_AND_ID.rst
|
||||
KRB5_NT_MS_PRINCIPAL.rst
|
||||
KRB5_NT_MS_PRINCIPAL_AND_ID.rst
|
||||
KRB5_NT_PRINCIPAL.rst
|
||||
KRB5_NT_SMTP_NAME.rst
|
||||
KRB5_NT_SRV_HST.rst
|
||||
KRB5_NT_SRV_INST.rst
|
||||
KRB5_NT_SRV_XHST.rst
|
||||
KRB5_NT_UID.rst
|
||||
KRB5_NT_UNKNOWN.rst
|
||||
KRB5_NT_WELLKNOWN.rst
|
||||
KRB5_NT_X500_PRINCIPAL.rst
|
||||
KRB5_PAC_ATTRIBUTES_INFO.rst
|
||||
KRB5_PAC_CLIENT_INFO.rst
|
||||
KRB5_PAC_CLIENT_CLAIMS.rst
|
||||
KRB5_PAC_CREDENTIALS_INFO.rst
|
||||
KRB5_PAC_DELEGATION_INFO.rst
|
||||
KRB5_PAC_DEVICE_CLAIMS.rst
|
||||
KRB5_PAC_DEVICE_INFO.rst
|
||||
KRB5_PAC_LOGON_INFO.rst
|
||||
KRB5_PAC_PRIVSVR_CHECKSUM.rst
|
||||
KRB5_PAC_REQUESTOR.rst
|
||||
KRB5_PAC_SERVER_CHECKSUM.rst
|
||||
KRB5_PAC_TICKET_CHECKSUM.rst
|
||||
KRB5_PAC_UPN_DNS_INFO.rst
|
||||
KRB5_PAC_FULL_CHECKSUM.rst
|
||||
KRB5_PADATA_AFS3_SALT.rst
|
||||
KRB5_PADATA_AP_REQ.rst
|
||||
KRB5_PADATA_AS_CHECKSUM.rst
|
||||
KRB5_PADATA_AS_FRESHNESS.rst
|
||||
KRB5_PADATA_ENCRYPTED_CHALLENGE.rst
|
||||
KRB5_PADATA_ENC_SANDIA_SECURID.rst
|
||||
KRB5_PADATA_ENC_TIMESTAMP.rst
|
||||
KRB5_PADATA_ENC_UNIX_TIME.rst
|
||||
KRB5_PADATA_ETYPE_INFO.rst
|
||||
KRB5_PADATA_ETYPE_INFO2.rst
|
||||
KRB5_PADATA_FOR_USER.rst
|
||||
KRB5_PADATA_FX_COOKIE.rst
|
||||
KRB5_PADATA_FX_ERROR.rst
|
||||
KRB5_PADATA_FX_FAST.rst
|
||||
KRB5_PADATA_GET_FROM_TYPED_DATA.rst
|
||||
KRB5_PADATA_NONE.rst
|
||||
KRB5_PADATA_OSF_DCE.rst
|
||||
KRB5_PADATA_OTP_CHALLENGE.rst
|
||||
KRB5_PADATA_OTP_PIN_CHANGE.rst
|
||||
KRB5_PADATA_OTP_REQUEST.rst
|
||||
KRB5_PADATA_PAC_OPTIONS.rst
|
||||
KRB5_PADATA_PAC_REQUEST.rst
|
||||
KRB5_PADATA_PKINIT_KX.rst
|
||||
KRB5_PADATA_PK_AS_REP.rst
|
||||
KRB5_PADATA_PK_AS_REP_OLD.rst
|
||||
KRB5_PADATA_PK_AS_REQ.rst
|
||||
KRB5_PADATA_PK_AS_REQ_OLD.rst
|
||||
KRB5_PADATA_PW_SALT.rst
|
||||
KRB5_PADATA_REFERRAL.rst
|
||||
KRB5_PADATA_S4U_X509_USER.rst
|
||||
KRB5_PADATA_SAM_CHALLENGE.rst
|
||||
KRB5_PADATA_SAM_CHALLENGE_2.rst
|
||||
KRB5_PADATA_SAM_REDIRECT.rst
|
||||
KRB5_PADATA_SAM_RESPONSE.rst
|
||||
KRB5_PADATA_SAM_RESPONSE_2.rst
|
||||
KRB5_PADATA_SESAME.rst
|
||||
KRB5_PADATA_SPAKE.rst
|
||||
KRB5_PADATA_REDHAT_IDP_OAUTH2.rst
|
||||
KRB5_PADATA_REDHAT_PASSKEY.rst
|
||||
KRB5_PADATA_SVR_REFERRAL_INFO.rst
|
||||
KRB5_PADATA_TGS_REQ.rst
|
||||
KRB5_PADATA_USE_SPECIFIED_KVNO.rst
|
||||
KRB5_PRINCIPAL_COMPARE_CASEFOLD.rst
|
||||
KRB5_PRINCIPAL_COMPARE_ENTERPRISE.rst
|
||||
KRB5_PRINCIPAL_COMPARE_IGNORE_REALM.rst
|
||||
KRB5_PRINCIPAL_COMPARE_UTF8.rst
|
||||
KRB5_PRINCIPAL_PARSE_ENTERPRISE.rst
|
||||
KRB5_PRINCIPAL_PARSE_IGNORE_REALM.rst
|
||||
KRB5_PRINCIPAL_PARSE_NO_DEF_REALM.rst
|
||||
KRB5_PRINCIPAL_PARSE_NO_REALM.rst
|
||||
KRB5_PRINCIPAL_PARSE_REQUIRE_REALM.rst
|
||||
KRB5_PRINCIPAL_UNPARSE_DISPLAY.rst
|
||||
KRB5_PRINCIPAL_UNPARSE_NO_REALM.rst
|
||||
KRB5_PRINCIPAL_UNPARSE_SHORT.rst
|
||||
KRB5_PRIV.rst
|
||||
KRB5_PROMPT_TYPE_NEW_PASSWORD.rst
|
||||
KRB5_PROMPT_TYPE_NEW_PASSWORD_AGAIN.rst
|
||||
KRB5_PROMPT_TYPE_PASSWORD.rst
|
||||
KRB5_PROMPT_TYPE_PREAUTH.rst
|
||||
KRB5_PVNO.rst
|
||||
KRB5_REALM_BRANCH_CHAR.rst
|
||||
KRB5_RECVAUTH_BADAUTHVERS.rst
|
||||
KRB5_RECVAUTH_SKIP_VERSION.rst
|
||||
KRB5_REFERRAL_REALM.rst
|
||||
KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_COUNT_LOW.rst
|
||||
KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_FINAL_TRY.rst
|
||||
KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_LOCKED.rst
|
||||
KRB5_RESPONDER_QUESTION_PKINIT.rst
|
||||
KRB5_RESPONDER_OTP_FLAGS_COLLECT_PIN.rst
|
||||
KRB5_RESPONDER_OTP_FLAGS_COLLECT_TOKEN.rst
|
||||
KRB5_RESPONDER_OTP_FLAGS_NEXTOTP.rst
|
||||
KRB5_RESPONDER_OTP_FLAGS_SEPARATE_PIN.rst
|
||||
KRB5_RESPONDER_OTP_FORMAT_ALPHANUMERIC.rst
|
||||
KRB5_RESPONDER_OTP_FORMAT_DECIMAL.rst
|
||||
KRB5_RESPONDER_OTP_FORMAT_HEXADECIMAL.rst
|
||||
KRB5_RESPONDER_QUESTION_OTP.rst
|
||||
KRB5_RESPONDER_QUESTION_PASSWORD.rst
|
||||
KRB5_SAFE.rst
|
||||
KRB5_SAM_MUST_PK_ENCRYPT_SAD.rst
|
||||
KRB5_SAM_SEND_ENCRYPTED_SAD.rst
|
||||
KRB5_SAM_USE_SAD_AS_KEY.rst
|
||||
KRB5_TC_MATCH_2ND_TKT.rst
|
||||
KRB5_TC_MATCH_AUTHDATA.rst
|
||||
KRB5_TC_MATCH_FLAGS.rst
|
||||
KRB5_TC_MATCH_FLAGS_EXACT.rst
|
||||
KRB5_TC_MATCH_IS_SKEY.rst
|
||||
KRB5_TC_MATCH_KTYPE.rst
|
||||
KRB5_TC_MATCH_SRV_NAMEONLY.rst
|
||||
KRB5_TC_MATCH_TIMES.rst
|
||||
KRB5_TC_MATCH_TIMES_EXACT.rst
|
||||
KRB5_TC_NOTICKET.rst
|
||||
KRB5_TC_OPENCLOSE.rst
|
||||
KRB5_TC_SUPPORTED_KTYPES.rst
|
||||
KRB5_TGS_NAME.rst
|
||||
KRB5_TGS_NAME_SIZE.rst
|
||||
KRB5_TGS_REP.rst
|
||||
KRB5_TGS_REQ.rst
|
||||
KRB5_TKT_CREDS_STEP_FLAG_CONTINUE.rst
|
||||
KRB5_VERIFY_INIT_CREDS_OPT_AP_REQ_NOFAIL.rst
|
||||
KRB5_WELLKNOWN_NAMESTR.rst
|
||||
LR_TYPE_INTERPRETATION_MASK.rst
|
||||
LR_TYPE_THIS_SERVER_ONLY.rst
|
||||
MAX_KEYTAB_NAME_LEN.rst
|
||||
MSEC_DIRBIT.rst
|
||||
MSEC_VAL_MASK.rst
|
||||
SALT_TYPE_AFS_LENGTH.rst
|
||||
SALT_TYPE_NO_LENGTH.rst
|
||||
THREEPARAMOPEN.rst
|
||||
TKT_FLG_ANONYMOUS.rst
|
||||
TKT_FLG_ENC_PA_REP.rst
|
||||
TKT_FLG_FORWARDABLE.rst
|
||||
TKT_FLG_FORWARDED.rst
|
||||
TKT_FLG_HW_AUTH.rst
|
||||
TKT_FLG_INITIAL.rst
|
||||
TKT_FLG_INVALID.rst
|
||||
TKT_FLG_MAY_POSTDATE.rst
|
||||
TKT_FLG_OK_AS_DELEGATE.rst
|
||||
TKT_FLG_POSTDATED.rst
|
||||
TKT_FLG_PRE_AUTH.rst
|
||||
TKT_FLG_PROXIABLE.rst
|
||||
TKT_FLG_PROXY.rst
|
||||
TKT_FLG_RENEWABLE.rst
|
||||
TKT_FLG_TRANSIT_POLICY_CHECKED.rst
|
||||
VALID_INT_BITS.rst
|
||||
VALID_UINT_BITS.rst
|
||||
krb5_const.rst
|
||||
krb5_princ_component.rst
|
||||
krb5_princ_name.rst
|
||||
krb5_princ_realm.rst
|
||||
krb5_princ_set_realm.rst
|
||||
krb5_princ_set_realm_data.rst
|
||||
krb5_princ_set_realm_length.rst
|
||||
krb5_princ_size.rst
|
||||
krb5_princ_type.rst
|
||||
krb5_roundup.rst
|
||||
krb5_x.rst
|
||||
krb5_xc.rst
|
||||
|
||||
Deprecated macros
|
||||
------------------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
krb524_convert_creds_kdc.rst
|
||||
krb524_init_ets.rst
|
||||
108
crypto/krb5/doc/appdev/refs/types/index.rst
Normal file
108
crypto/krb5/doc/appdev/refs/types/index.rst
Normal file
|
|
@ -0,0 +1,108 @@
|
|||
krb5 types and structures
|
||||
=========================
|
||||
|
||||
Public
|
||||
-------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
krb5_address.rst
|
||||
krb5_addrtype.rst
|
||||
krb5_ap_req.rst
|
||||
krb5_ap_rep.rst
|
||||
krb5_ap_rep_enc_part.rst
|
||||
krb5_authdata.rst
|
||||
krb5_authdatatype.rst
|
||||
krb5_authenticator.rst
|
||||
krb5_boolean.rst
|
||||
krb5_checksum.rst
|
||||
krb5_const_pointer.rst
|
||||
krb5_const_principal.rst
|
||||
krb5_cred.rst
|
||||
krb5_cred_enc_part.rst
|
||||
krb5_cred_info.rst
|
||||
krb5_creds.rst
|
||||
krb5_crypto_iov.rst
|
||||
krb5_cryptotype.rst
|
||||
krb5_data.rst
|
||||
krb5_deltat.rst
|
||||
krb5_enc_data.rst
|
||||
krb5_enc_kdc_rep_part.rst
|
||||
krb5_enc_tkt_part.rst
|
||||
krb5_encrypt_block.rst
|
||||
krb5_enctype.rst
|
||||
krb5_error.rst
|
||||
krb5_error_code.rst
|
||||
krb5_expire_callback_func.rst
|
||||
krb5_flags.rst
|
||||
krb5_get_init_creds_opt.rst
|
||||
krb5_gic_opt_pa_data.rst
|
||||
krb5_int16.rst
|
||||
krb5_int32.rst
|
||||
krb5_kdc_rep.rst
|
||||
krb5_kdc_req.rst
|
||||
krb5_keyblock.rst
|
||||
krb5_keytab_entry.rst
|
||||
krb5_keyusage.rst
|
||||
krb5_kt_cursor.rst
|
||||
krb5_kvno.rst
|
||||
krb5_last_req_entry.rst
|
||||
krb5_magic.rst
|
||||
krb5_mk_req_checksum_func.rst
|
||||
krb5_msgtype.rst
|
||||
krb5_octet.rst
|
||||
krb5_pa_pac_req.rst
|
||||
krb5_pa_server_referral_data.rst
|
||||
krb5_pa_svr_referral_data.rst
|
||||
krb5_pa_data.rst
|
||||
krb5_pointer.rst
|
||||
krb5_post_recv_fn.rst
|
||||
krb5_pre_send_fn.rst
|
||||
krb5_preauthtype.rst
|
||||
krb5_principal.rst
|
||||
krb5_principal_data.rst
|
||||
krb5_prompt.rst
|
||||
krb5_prompt_type.rst
|
||||
krb5_prompter_fct.rst
|
||||
krb5_pwd_data.rst
|
||||
krb5_responder_context.rst
|
||||
krb5_responder_fn.rst
|
||||
krb5_responder_otp_challenge.rst
|
||||
krb5_responder_otp_tokeninfo.rst
|
||||
krb5_responder_pkinit_challenge.rst
|
||||
krb5_responder_pkinit_identity.rst
|
||||
krb5_response.rst
|
||||
krb5_replay_data.rst
|
||||
krb5_ticket.rst
|
||||
krb5_ticket_times.rst
|
||||
krb5_timestamp.rst
|
||||
krb5_tkt_authent.rst
|
||||
krb5_trace_callback.rst
|
||||
krb5_trace_info.rst
|
||||
krb5_transited.rst
|
||||
krb5_typed_data.rst
|
||||
krb5_ui_2.rst
|
||||
krb5_ui_4.rst
|
||||
krb5_verify_init_creds_opt.rst
|
||||
passwd_phrase_element.rst
|
||||
|
||||
|
||||
Internal
|
||||
---------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
krb5_auth_context.rst
|
||||
krb5_cksumtype
|
||||
krb5_context.rst
|
||||
krb5_cc_cursor.rst
|
||||
krb5_ccache.rst
|
||||
krb5_cccol_cursor.rst
|
||||
krb5_init_creds_context.rst
|
||||
krb5_key.rst
|
||||
krb5_keytab.rst
|
||||
krb5_pac.rst
|
||||
krb5_rcache.rst
|
||||
krb5_tkt_creds_context.rst
|
||||
12
crypto/krb5/doc/appdev/refs/types/krb5_int32.rst
Normal file
12
crypto/krb5/doc/appdev/refs/types/krb5_int32.rst
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
.. highlight:: c
|
||||
|
||||
.. _krb5-int32-struct:
|
||||
|
||||
krb5_int32
|
||||
==========
|
||||
|
||||
..
|
||||
.. c:type:: krb5_int32
|
||||
..
|
||||
|
||||
krb5_int32 is a signed 32-bit integer type
|
||||
12
crypto/krb5/doc/appdev/refs/types/krb5_ui_4.rst
Normal file
12
crypto/krb5/doc/appdev/refs/types/krb5_ui_4.rst
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
.. highlight:: c
|
||||
|
||||
.. _krb5-ui4-struct:
|
||||
|
||||
krb5_ui_4
|
||||
==========
|
||||
|
||||
..
|
||||
.. c:type:: krb5_ui_4
|
||||
..
|
||||
|
||||
krb5_ui_4 is an unsigned 32-bit integer type.
|
||||
28
crypto/krb5/doc/appdev/y2038.rst
Normal file
28
crypto/krb5/doc/appdev/y2038.rst
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
Year 2038 considerations for uses of krb5_timestamp
|
||||
===================================================
|
||||
|
||||
POSIX time values, which measure the number of seconds since January 1
|
||||
1970, will exceed the maximum value representable in a signed 32-bit
|
||||
integer in January 2038. This documentation describes considerations
|
||||
for consumers of the MIT krb5 libraries.
|
||||
|
||||
Applications or libraries which use libkrb5 and consume the timestamps
|
||||
included in credentials or other structures make use of the
|
||||
:c:type:`krb5_timestamp` type. For historical reasons, krb5_timestamp
|
||||
is a signed 32-bit integer, even on platforms where a larger type is
|
||||
natively used to represent time values. To behave properly for time
|
||||
values after January 2038, calling code should cast krb5_timestamp
|
||||
values to uint32_t, and then to time_t::
|
||||
|
||||
(time_t)(uint32_t)timestamp
|
||||
|
||||
Used in this way, krb5_timestamp values can represent time values up
|
||||
until February 2106, provided that the platform uses a 64-bit or
|
||||
larger time_t type. This usage will also remain safe if a later
|
||||
version of MIT krb5 changes krb5_timestamp to an unsigned 32-bit
|
||||
integer.
|
||||
|
||||
The GSSAPI only uses representations of time intervals, not absolute
|
||||
times. Callers of the GSSAPI should require no changes to behave
|
||||
correctly after January 2038, provided that they use MIT krb5 release
|
||||
1.16 or later.
|
||||
160
crypto/krb5/doc/basic/ccache_def.rst
Normal file
160
crypto/krb5/doc/basic/ccache_def.rst
Normal file
|
|
@ -0,0 +1,160 @@
|
|||
.. _ccache_definition:
|
||||
|
||||
Credential cache
|
||||
================
|
||||
|
||||
A credential cache (or "ccache") holds Kerberos credentials while they
|
||||
remain valid and, generally, while the user's session lasts, so that
|
||||
authenticating to a service multiple times (e.g., connecting to a web
|
||||
or mail server more than once) doesn't require contacting the KDC
|
||||
every time.
|
||||
|
||||
A credential cache usually contains one initial ticket which is
|
||||
obtained using a password or another form of identity verification.
|
||||
If this ticket is a ticket-granting ticket, it can be used to obtain
|
||||
additional credentials without the password. Because the credential
|
||||
cache does not store the password, less long-term damage can be done
|
||||
to the user's account if the machine is compromised.
|
||||
|
||||
A credentials cache stores a default client principal name, set when
|
||||
the cache is created. This is the name shown at the top of the
|
||||
:ref:`klist(1)` *-A* output.
|
||||
|
||||
Each normal cache entry includes a service principal name, a client
|
||||
principal name (which, in some ccache types, need not be the same as
|
||||
the default), lifetime information, and flags, along with the
|
||||
credential itself. There are also other entries, indicated by special
|
||||
names, that store additional information.
|
||||
|
||||
|
||||
ccache types
|
||||
------------
|
||||
|
||||
The credential cache interface, like the :ref:`keytab_definition` and
|
||||
:ref:`rcache_definition` interfaces, uses `TYPE:value` strings to
|
||||
indicate the type of credential cache and any associated cache naming
|
||||
data to use.
|
||||
|
||||
There are several kinds of credentials cache supported in the MIT
|
||||
Kerberos library. Not all are supported on every platform. In most
|
||||
cases, it should be correct to use the default type built into the
|
||||
library.
|
||||
|
||||
#. **API** is only implemented on Windows. It communicates with a
|
||||
server process that holds the credentials in memory for the user,
|
||||
rather than writing them to disk.
|
||||
|
||||
#. **DIR** points to the storage location of the collection of the
|
||||
credential caches in *FILE:* format. It is most useful when dealing
|
||||
with multiple Kerberos realms and KDCs. For release 1.10 the
|
||||
directory must already exist. In post-1.10 releases the
|
||||
requirement is for parent directory to exist and the current
|
||||
process must have permissions to create the directory if it does
|
||||
not exist. See :ref:`col_ccache` for details. New in release 1.10.
|
||||
The following residual forms are supported:
|
||||
|
||||
* DIR:dirname
|
||||
* DIR::dirpath/filename - a single cache within the directory
|
||||
|
||||
Switching to a ccache of the latter type causes it to become the
|
||||
primary for the directory.
|
||||
|
||||
#. **FILE** caches are the simplest and most portable. A simple flat
|
||||
file format is used to store one credential after another. This is
|
||||
the default ccache type if no type is specified in a ccache name.
|
||||
|
||||
#. **KCM** caches work by contacting a daemon process called ``kcm``
|
||||
to perform cache operations. If the cache name is just ``KCM:``,
|
||||
the default cache as determined by the KCM daemon will be used.
|
||||
Newly created caches must generally be named ``KCM:uid:name``,
|
||||
where *uid* is the effective user ID of the running process.
|
||||
|
||||
KCM client support is new in release 1.13. A KCM daemon has not
|
||||
yet been implemented in MIT krb5, but the client will interoperate
|
||||
with the KCM daemon implemented by Heimdal. macOS 10.7 and higher
|
||||
provides a KCM daemon as part of the operating system, and the
|
||||
**KCM** cache type is used as the default cache on that platform in
|
||||
a default build.
|
||||
|
||||
#. **KEYRING** is Linux-specific, and uses the kernel keyring support
|
||||
to store credential data in unswappable kernel memory where only
|
||||
the current user should be able to access it. The following
|
||||
residual forms are supported:
|
||||
|
||||
* KEYRING:name
|
||||
* KEYRING:process:name - process keyring
|
||||
* KEYRING:thread:name - thread keyring
|
||||
|
||||
Starting with release 1.12 the *KEYRING* type supports collections.
|
||||
The following new residual forms were added:
|
||||
|
||||
* KEYRING:session:name - session keyring
|
||||
* KEYRING:user:name - user keyring
|
||||
* KEYRING:persistent:uidnumber - persistent per-UID collection.
|
||||
Unlike the user keyring, this collection survives after the user
|
||||
logs out, until the cache credentials expire. This type of
|
||||
ccache requires support from the kernel; otherwise, it will fall
|
||||
back to the user keyring.
|
||||
|
||||
See :ref:`col_ccache` for details.
|
||||
|
||||
#. **MEMORY** caches are for storage of credentials that don't need to
|
||||
be made available outside of the current process. For example, a
|
||||
memory ccache is used by :ref:`kadmin(1)` to store the
|
||||
administrative ticket used to contact the admin server. Memory
|
||||
ccaches are faster than file ccaches and are automatically
|
||||
destroyed when the process exits.
|
||||
|
||||
#. **MSLSA** is a Windows-specific cache type that accesses the
|
||||
Windows credential store.
|
||||
|
||||
|
||||
.. _col_ccache:
|
||||
|
||||
Collections of caches
|
||||
---------------------
|
||||
|
||||
Some credential cache types can support collections of multiple
|
||||
caches. One of the caches in the collection is designated as the
|
||||
*primary* and will be used when the collection is resolved as a cache.
|
||||
When a collection-enabled cache type is the default cache for a
|
||||
process, applications can search the specified collection for a
|
||||
specific client principal, and GSSAPI applications will automatically
|
||||
select between the caches in the collection based on criteria such as
|
||||
the target service realm.
|
||||
|
||||
Credential cache collections are new in release 1.10, with support
|
||||
from the **DIR** and **API** ccache types. Starting in release 1.12,
|
||||
collections are also supported by the **KEYRING** ccache type.
|
||||
Collections are supported by the **KCM** ccache type in release 1.13.
|
||||
|
||||
|
||||
Tool alterations to use cache collection
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* :ref:`kdestroy(1)` *-A* will destroy all caches in the collection.
|
||||
* If the default cache type supports switching, :ref:`kinit(1)`
|
||||
*princname* will search the collection for a matching cache and
|
||||
store credentials there, or will store credentials in a new unique
|
||||
cache of the default type if no existing cache for the principal
|
||||
exists. Either way, kinit will switch to the selected cache.
|
||||
* :ref:`klist(1)` *-l* will list the caches in the collection.
|
||||
* :ref:`klist(1)` *-A* will show the content of all caches in the
|
||||
collection.
|
||||
* :ref:`kswitch(1)` *-p princname* will search the collection for a
|
||||
matching cache and switch to it.
|
||||
* :ref:`kswitch(1)` *-c cachename* will switch to a specified cache.
|
||||
|
||||
|
||||
Default ccache name
|
||||
-------------------
|
||||
|
||||
The default credential cache name is determined by the following, in
|
||||
descending order of priority:
|
||||
|
||||
#. The **KRB5CCNAME** environment variable. For example,
|
||||
``KRB5CCNAME=DIR:/mydir/``.
|
||||
|
||||
#. The **default_ccache_name** profile variable in :ref:`libdefaults`.
|
||||
|
||||
#. The hardcoded default, |ccache|.
|
||||
140
crypto/krb5/doc/basic/date_format.rst
Normal file
140
crypto/krb5/doc/basic/date_format.rst
Normal file
|
|
@ -0,0 +1,140 @@
|
|||
.. _datetime:
|
||||
|
||||
Supported date and time formats
|
||||
===============================
|
||||
|
||||
.. _duration:
|
||||
|
||||
Time duration
|
||||
-------------
|
||||
|
||||
This format is used to express a time duration in the Kerberos
|
||||
configuration files and user commands. The allowed formats are:
|
||||
|
||||
====================== ============== ============
|
||||
Format Example Value
|
||||
---------------------- -------------- ------------
|
||||
h:m[:s] 36:00 36 hours
|
||||
NdNhNmNs 8h30s 8 hours 30 seconds
|
||||
N (number of seconds) 3600 1 hour
|
||||
====================== ============== ============
|
||||
|
||||
Here *N* denotes a number, *d* - days, *h* - hours, *m* - minutes,
|
||||
*s* - seconds.
|
||||
|
||||
.. note::
|
||||
|
||||
The time interval should not exceed 2147483647 seconds.
|
||||
|
||||
Examples::
|
||||
|
||||
Request a ticket valid for one hour, five hours, 30 minutes
|
||||
and 10 days respectively:
|
||||
|
||||
kinit -l 3600
|
||||
kinit -l 5:00
|
||||
kinit -l 30m
|
||||
kinit -l "10d 0h 0m 0s"
|
||||
|
||||
|
||||
.. _getdate:
|
||||
|
||||
getdate time
|
||||
------------
|
||||
|
||||
Some of the kadmin and kdb5_util commands take a date-time in a
|
||||
human-readable format. Some of the acceptable date-time
|
||||
strings are:
|
||||
|
||||
+-----------+------------------+-----------------+
|
||||
| | Format | Example |
|
||||
+===========+==================+=================+
|
||||
| Date | mm/dd/yy | 07/27/12 |
|
||||
| +------------------+-----------------+
|
||||
| | month dd, yyyy | Jul 27, 2012 |
|
||||
| +------------------+-----------------+
|
||||
| | yyyy-mm-dd | 2012-07-27 |
|
||||
+-----------+------------------+-----------------+
|
||||
| Absolute | HH:mm[:ss]pp | 08:30 PM |
|
||||
| time +------------------+-----------------+
|
||||
| | hh:mm[:ss] | 20:30 |
|
||||
+-----------+------------------+-----------------+
|
||||
| Relative | N tt | 30 sec |
|
||||
| time | | |
|
||||
+-----------+------------------+-----------------+
|
||||
| Time zone | Z | EST |
|
||||
| +------------------+-----------------+
|
||||
| | z | -0400 |
|
||||
+-----------+------------------+-----------------+
|
||||
|
||||
(See :ref:`abbreviation`.)
|
||||
|
||||
Examples::
|
||||
|
||||
Create a principal that expires on the date indicated:
|
||||
addprinc test1 -expire "3/27/12 10:00:07 EST"
|
||||
addprinc test2 -expire "January 23, 2015 10:05pm"
|
||||
addprinc test3 -expire "22:00 GMT"
|
||||
Add a principal that will expire in 30 minutes:
|
||||
addprinc test4 -expire "30 minutes"
|
||||
|
||||
|
||||
.. _abstime:
|
||||
|
||||
Absolute time
|
||||
-------------
|
||||
|
||||
This rarely used date-time format can be noted in one of the
|
||||
following ways:
|
||||
|
||||
|
||||
+------------------------+----------------------+--------------+
|
||||
| Format | Example | Value |
|
||||
+========================+======================+==============+
|
||||
| yyyymmddhhmmss | 20141231235900 | One minute |
|
||||
+------------------------+----------------------+ before 2015 |
|
||||
| yyyy.mm.dd.hh.mm.ss | 2014.12.31.23.59.00 | |
|
||||
+------------------------+----------------------+ |
|
||||
| yymmddhhmmss | 141231235900 | |
|
||||
+------------------------+----------------------+ |
|
||||
| yy.mm.dd.hh.mm.ss | 14.12.31.23.59.00 | |
|
||||
+------------------------+----------------------+ |
|
||||
| dd-month-yyyy:hh:mm:ss | 31-Dec-2014:23:59:00 | |
|
||||
+------------------------+----------------------+--------------+
|
||||
| hh:mm:ss | 20:00:00 | 8 o'clock in |
|
||||
+------------------------+----------------------+ the evening |
|
||||
| hhmmss | 200000 | |
|
||||
+------------------------+----------------------+--------------+
|
||||
|
||||
(See :ref:`abbreviation`.)
|
||||
|
||||
Example::
|
||||
|
||||
Set the default expiration date to July 27, 2012 at 20:30
|
||||
default_principal_expiration = 20120727203000
|
||||
|
||||
|
||||
.. _abbreviation:
|
||||
|
||||
Abbreviations used in this document
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
| *month* : locale’s month name or its abbreviation;
|
||||
| *dd* : day of month (01-31);
|
||||
| *HH* : hours (00-12);
|
||||
| *hh* : hours (00-23);
|
||||
| *mm* : in time - minutes (00-59); in date - month (01-12);
|
||||
| *N* : number;
|
||||
| *pp* : AM or PM;
|
||||
| *ss* : seconds (00-60);
|
||||
| *tt* : time units (hours, minutes, min, seconds, sec);
|
||||
| *yyyy* : year;
|
||||
| *yy* : last two digits of the year;
|
||||
| *Z* : alphabetic time zone abbreviation;
|
||||
| *z* : numeric time zone;
|
||||
|
||||
.. note::
|
||||
|
||||
- If the date specification contains spaces, you may need to
|
||||
enclose it in double quotes;
|
||||
- All keywords are case-insensitive.
|
||||
14
crypto/krb5/doc/basic/index.rst
Normal file
14
crypto/krb5/doc/basic/index.rst
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
.. _basic_concepts:
|
||||
|
||||
Kerberos V5 concepts
|
||||
====================
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
ccache_def
|
||||
keytab_def
|
||||
rcache_def
|
||||
stash_file_def
|
||||
date_format
|
||||
59
crypto/krb5/doc/basic/keytab_def.rst
Normal file
59
crypto/krb5/doc/basic/keytab_def.rst
Normal file
|
|
@ -0,0 +1,59 @@
|
|||
.. _keytab_definition:
|
||||
|
||||
keytab
|
||||
======
|
||||
|
||||
A keytab (short for "key table") stores long-term keys for one or more
|
||||
principals. Keytabs are normally represented by files in a standard
|
||||
format, although in rare cases they can be represented in other ways.
|
||||
Keytabs are used most often to allow server applications to accept
|
||||
authentications from clients, but can also be used to obtain initial
|
||||
credentials for client applications.
|
||||
|
||||
Keytabs are named using the format *type*\ ``:``\ *value*. Usually
|
||||
*type* is ``FILE`` and *value* is the absolute pathname of the file.
|
||||
The other possible value for *type* is ``MEMORY``, which indicates a
|
||||
temporary keytab stored in the memory of the current process.
|
||||
|
||||
A keytab contains one or more entries, where each entry consists of a
|
||||
timestamp (indicating when the entry was written to the keytab), a
|
||||
principal name, a key version number, an encryption type, and the
|
||||
encryption key itself.
|
||||
|
||||
A keytab can be displayed using the :ref:`klist(1)` command with the
|
||||
``-k`` option. Keytabs can be created or appended to by extracting
|
||||
keys from the KDC database using the :ref:`kadmin(1)` :ref:`ktadd`
|
||||
command. Keytabs can be manipulated using the :ref:`ktutil(1)` and
|
||||
:ref:`k5srvutil(1)` commands.
|
||||
|
||||
|
||||
Default keytab
|
||||
--------------
|
||||
|
||||
The default keytab is used by server applications if the application
|
||||
does not request a specific keytab. The name of the default keytab is
|
||||
determined by the following, in decreasing order of preference:
|
||||
|
||||
#. The **KRB5_KTNAME** environment variable.
|
||||
|
||||
#. The **default_keytab_name** profile variable in :ref:`libdefaults`.
|
||||
|
||||
#. The hardcoded default, |keytab|.
|
||||
|
||||
|
||||
Default client keytab
|
||||
---------------------
|
||||
|
||||
The default client keytab is used, if it is present and readable, to
|
||||
automatically obtain initial credentials for GSSAPI client
|
||||
applications. The principal name of the first entry in the client
|
||||
keytab is used by default when obtaining initial credentials. The
|
||||
name of the default client keytab is determined by the following, in
|
||||
decreasing order of preference:
|
||||
|
||||
#. The **KRB5_CLIENT_KTNAME** environment variable.
|
||||
|
||||
#. The **default_client_keytab_name** profile variable in
|
||||
:ref:`libdefaults`.
|
||||
|
||||
#. The hardcoded default, |ckeytab|.
|
||||
111
crypto/krb5/doc/basic/rcache_def.rst
Normal file
111
crypto/krb5/doc/basic/rcache_def.rst
Normal file
|
|
@ -0,0 +1,111 @@
|
|||
.. _rcache_definition:
|
||||
|
||||
replay cache
|
||||
============
|
||||
|
||||
A replay cache (or "rcache") keeps track of all authenticators
|
||||
recently presented to a service. If a duplicate authentication
|
||||
request is detected in the replay cache, an error message is sent to
|
||||
the application program.
|
||||
|
||||
The replay cache interface, like the credential cache and
|
||||
:ref:`keytab_definition` interfaces, uses `type:residual` strings to
|
||||
indicate the type of replay cache and any associated cache naming
|
||||
data to use.
|
||||
|
||||
Background information
|
||||
----------------------
|
||||
|
||||
Some Kerberos or GSSAPI services use a simple authentication mechanism
|
||||
where a message is sent containing an authenticator, which establishes
|
||||
the encryption key that the client will use for talking to the
|
||||
service. But nothing about that prevents an eavesdropper from
|
||||
recording the messages sent by the client, establishing a new
|
||||
connection, and re-sending or "replaying" the same messages; the
|
||||
replayed authenticator will establish the same encryption key for the
|
||||
new session, and the following messages will be decrypted and
|
||||
processed. The attacker may not know what the messages say, and can't
|
||||
generate new messages under the same encryption key, but in some
|
||||
instances it may be harmful to the user (or helpful to the attacker)
|
||||
to cause the server to see the same messages again a second time. For
|
||||
example, if the legitimate client sends "delete first message in
|
||||
mailbox", a replay from an attacker may delete another, different
|
||||
"first" message. (Protocol design to guard against such problems has
|
||||
been discussed in :rfc:`4120#section-10`.)
|
||||
|
||||
Even if one protocol uses further protection to verify that the client
|
||||
side of the connection actually knows the encryption keys (and thus is
|
||||
presumably a legitimate user), if another service uses the same
|
||||
service principal name, it may be possible to record an authenticator
|
||||
used with the first protocol and "replay" it against the second.
|
||||
|
||||
The replay cache mitigates these attacks somewhat, by keeping track of
|
||||
authenticators that have been seen until their five-minute window
|
||||
expires. Different authenticators generated by multiple connections
|
||||
from the same legitimate client will generally have different
|
||||
timestamps, and thus will not be considered the same.
|
||||
|
||||
This mechanism isn't perfect. If a message is sent to one application
|
||||
server but a man-in-the-middle attacker can prevent it from actually
|
||||
arriving at that server, the attacker could then use the authenticator
|
||||
(once!) against a different service on the same host. This could be a
|
||||
problem if the message from the client included something more than
|
||||
authentication in the first message that could be useful to the
|
||||
attacker (which is uncommon; in most protocols the server has to
|
||||
indicate a successful authentication before the client sends
|
||||
additional messages), or if the simple act of presenting the
|
||||
authenticator triggers some interesting action in the service being
|
||||
attacked.
|
||||
|
||||
Replay cache types
|
||||
------------------
|
||||
|
||||
Unlike the credential cache and keytab interfaces, replay cache types
|
||||
are in lowercase. The following types are defined:
|
||||
|
||||
#. **none** disables the replay cache. The residual value is ignored.
|
||||
|
||||
#. **file2** (new in release 1.18) uses a hash-based format to store
|
||||
replay records. The file may grow to accommodate hash collisions.
|
||||
The residual value is the filename.
|
||||
|
||||
#. **dfl** is the default type if no environment variable or
|
||||
configuration specifies a different type. It stores replay data in
|
||||
a file2 replay cache with a filename based on the effective uid.
|
||||
The residual value is ignored.
|
||||
|
||||
For the dfl type, the location of the replay cache file is determined
|
||||
as follows:
|
||||
|
||||
#. The directory is taken from the **KRB5RCACHEDIR** environment
|
||||
variable, or the **TMPDIR** environment variable, or a temporary
|
||||
directory determined at configuration time such as ``/var/tmp``, in
|
||||
descending order of preference.
|
||||
|
||||
#. The filename is ``krb5_EUID.rcache2`` where EUID is the effective
|
||||
uid of the process.
|
||||
|
||||
#. The file is opened without following symbolic links, and ownership
|
||||
of the file is verified to match the effective uid.
|
||||
|
||||
On Windows, the directory for the dfl type is the local appdata
|
||||
directory, unless overridden by the **KRB5RCACHEDIR** environment
|
||||
variable. The filename on Windows is ``krb5.rcache2``, and the file
|
||||
is opened normally.
|
||||
|
||||
Default replay cache name
|
||||
-------------------------
|
||||
|
||||
The default replay cache name is determined by the following, in
|
||||
descending order of priority:
|
||||
|
||||
#. The **KRB5RCACHENAME** environment variable (new in release 1.18).
|
||||
|
||||
#. The **KRB5RCACHETYPE** environment variable. If this variable is
|
||||
set, the residual value is empty.
|
||||
|
||||
#. The **default_rcache_name** profile variable in :ref:`libdefaults`
|
||||
(new in release 1.18).
|
||||
|
||||
#. If none of the above are set, the default replay cache name is
|
||||
``dfl:``.
|
||||
25
crypto/krb5/doc/basic/stash_file_def.rst
Normal file
25
crypto/krb5/doc/basic/stash_file_def.rst
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
.. _stash_definition:
|
||||
|
||||
|
||||
stash file
|
||||
============
|
||||
|
||||
The stash file is a local copy of the master key that resides in
|
||||
encrypted form on the KDC's local disk. The stash file is used to
|
||||
authenticate the KDC to itself automatically before starting the
|
||||
:ref:`kadmind(8)` and :ref:`krb5kdc(8)` daemons (e.g., as part of the
|
||||
machine's boot sequence). The stash file, like the keytab file (see
|
||||
:ref:`keytab_file`) is a potential point-of-entry for a break-in, and
|
||||
if compromised, would allow unrestricted access to the Kerberos
|
||||
database. If you choose to install a stash file, it should be
|
||||
readable only by root, and should exist only on the KDC's local disk.
|
||||
The file should not be part of any backup of the machine, unless
|
||||
access to the backup data is secured as tightly as access to the
|
||||
master password itself.
|
||||
|
||||
.. note::
|
||||
|
||||
If you choose not to install a stash file, the KDC will prompt you for the master key each time it starts up.
|
||||
This means that the KDC will not be able to start automatically, such as after a system reboot.
|
||||
|
||||
|
||||
75
crypto/krb5/doc/build/directory_org.rst
vendored
Normal file
75
crypto/krb5/doc/build/directory_org.rst
vendored
Normal file
|
|
@ -0,0 +1,75 @@
|
|||
Organization of the source directory
|
||||
====================================
|
||||
|
||||
Below is a brief overview of the organization of the complete source
|
||||
directory. More detailed descriptions follow.
|
||||
|
||||
=============== ==============================================
|
||||
appl Kerberos application client and server programs
|
||||
ccapi Credential cache services
|
||||
clients Kerberos V5 user programs (See :ref:`user_commands`)
|
||||
config Configure scripts
|
||||
config-files Sample Kerberos configuration files
|
||||
include include files needed to build the Kerberos system
|
||||
kadmin Administrative interface to the Kerberos database: :ref:`kadmin(1)`, :ref:`kdb5_util(8)`, :ref:`ktutil(1)`.
|
||||
kdc Kerberos V5 Authentication Service and Key Distribution Center
|
||||
lib_ Libraries for use with/by Kerberos V5
|
||||
plugins Kerberos plugins directory
|
||||
po Localization infrastructure
|
||||
prototype Templates files containing the MIT copyright message and a placeholder for the title and description of the file.
|
||||
kprop Utilities for propagating the database to replica KDCs :ref:`kprop(8)` and :ref:`kpropd(8)`
|
||||
tests Test suite
|
||||
util_ Various utilities for building/configuring the code, sending bug reports, etc.
|
||||
windows Source code for building Kerberos V5 on Windows (see windows/README)
|
||||
=============== ==============================================
|
||||
|
||||
|
||||
.. _lib:
|
||||
|
||||
lib
|
||||
---
|
||||
|
||||
The lib directory contain several subdirectories as well as some
|
||||
definition and glue files.
|
||||
|
||||
- The apputils directory contains the code for the generic network
|
||||
servicing.
|
||||
- The crypto subdirectory contains the Kerberos V5 encryption
|
||||
library.
|
||||
- The gssapi library contains the Generic Security Services API,
|
||||
which is a library of commands to be used in secure client-server
|
||||
communication.
|
||||
- The kadm5 directory contains the libraries for the KADM5
|
||||
administration utilities.
|
||||
- The Kerberos 5 database libraries are contained in kdb.
|
||||
- The krb5 directory contains Kerberos 5 API.
|
||||
- The rpc directory contains the API for the Kerberos Remote
|
||||
Procedure Call protocol.
|
||||
|
||||
|
||||
.. _util:
|
||||
|
||||
util
|
||||
----
|
||||
|
||||
The util directory contains several utility programs and libraries.
|
||||
- the programs used to configure and build the code, such as
|
||||
autoconf, lndir, kbuild, reconf, and makedepend, are in this
|
||||
directory.
|
||||
- the profile directory contains most of the functions which parse
|
||||
the Kerberos configuration files (krb5.conf and kdc.conf).
|
||||
- the Kerberos error table library and utilities (et);
|
||||
- the Sub-system library and utilities (ss);
|
||||
- database utilities (db2);
|
||||
- pseudo-terminal utilities (pty);
|
||||
- bug-reporting program send-pr;
|
||||
- a generic support library support used by several of our other
|
||||
libraries;
|
||||
- the build infrastructure for building lightweight Kerberos client
|
||||
(collected-client-lib)
|
||||
- the tool for validating Kerberos configuration files
|
||||
(confvalidator);
|
||||
- the toolkit for kernel integrators for building krb5 code subsets
|
||||
(gss-kernel-lib);
|
||||
- source code for building Kerberos V5 on MacOS (mac)
|
||||
- Windows getopt operations (windows)
|
||||
148
crypto/krb5/doc/build/doing_build.rst
vendored
Normal file
148
crypto/krb5/doc/build/doing_build.rst
vendored
Normal file
|
|
@ -0,0 +1,148 @@
|
|||
Doing the build
|
||||
===============
|
||||
|
||||
.. _do_build:
|
||||
|
||||
Building within a single tree
|
||||
-----------------------------
|
||||
|
||||
If you only need to build Kerberos for one platform, using a single
|
||||
directory tree which contains both the source files and the object
|
||||
files is the simplest. However, if you need to maintain Kerberos for
|
||||
a large number of platforms, you will probably want to use separate
|
||||
build trees for each platform. We recommend that you look at OS
|
||||
Incompatibilities, for notes that we have on particular operating
|
||||
systems.
|
||||
|
||||
If you don't want separate build trees for each architecture, then use
|
||||
the following abbreviated procedure::
|
||||
|
||||
cd /u1/krb5-VERSION/src
|
||||
./configure
|
||||
make
|
||||
|
||||
That's it!
|
||||
|
||||
Building with separate build directories
|
||||
----------------------------------------
|
||||
|
||||
If you wish to keep separate build directories for each platform, you
|
||||
can do so using the following procedure. (Note, this requires that
|
||||
your make program support VPATH. GNU's make will provide this
|
||||
functionality, for example.) If your make program does not support
|
||||
this, see the next section.
|
||||
|
||||
For example, if you wish to store the binaries in ``tmpbuild`` build
|
||||
directory you might use the following procedure::
|
||||
|
||||
mkdir /u1/tmpbuild
|
||||
cd /u1/tmpbuild
|
||||
/u1/krb5-VERSION/src/configure
|
||||
make
|
||||
|
||||
|
||||
Building using lndir
|
||||
--------------------
|
||||
|
||||
If you wish to keep separate build directories for each platform, and
|
||||
you do not have access to a make program which supports VPATH, all is
|
||||
not lost. You can use the lndir program to create symbolic link trees
|
||||
in your build directory.
|
||||
|
||||
For example, if you wish to create a build directory for solaris
|
||||
binaries you might use the following procedure::
|
||||
|
||||
mkdir /u1/krb5-VERSION/solaris
|
||||
cd /u1/krb5-VERSION/solaris
|
||||
/u1/krb5-VERSION/src/util/lndir `pwd`/../src
|
||||
./configure
|
||||
make
|
||||
|
||||
You must give an absolute pathname to lndir because it has a bug that
|
||||
makes it fail for relative pathnames. Note that this version differs
|
||||
from the latest version as distributed and installed by the
|
||||
XConsortium with X11R6. Either version should be acceptable.
|
||||
|
||||
|
||||
Installing the binaries
|
||||
-----------------------
|
||||
|
||||
Once you have built Kerberos, you should install the binaries. You can
|
||||
do this by running::
|
||||
|
||||
make install
|
||||
|
||||
If you want to install the binaries into a destination directory that
|
||||
is not their final destination, which may be convenient if you want to
|
||||
build a binary distribution to be deployed on multiple hosts, you may
|
||||
use::
|
||||
|
||||
make install DESTDIR=/path/to/destdir
|
||||
|
||||
This will install the binaries under *DESTDIR/PREFIX*, e.g., the user
|
||||
programs will install into *DESTDIR/PREFIX/bin*, the libraries into
|
||||
*DESTDIR/PREFIX/lib*, etc. *DESTDIR* must be an absolute path.
|
||||
|
||||
Some implementations of make allow multiple commands to be run in
|
||||
parallel, for faster builds. We test our Makefiles in parallel builds
|
||||
with GNU make only; they may not be compatible with other parallel
|
||||
build implementations.
|
||||
|
||||
|
||||
Testing the build
|
||||
-----------------
|
||||
|
||||
The Kerberos V5 distribution comes with built-in regression tests. To
|
||||
run them, simply type the following command while in the top-level
|
||||
build directory (i.e., the directory where you sent typed make to
|
||||
start building Kerberos; see :ref:`do_build`)::
|
||||
|
||||
make check
|
||||
|
||||
On some operating systems, you have to run ``make install`` before
|
||||
running ``make check``, or the test suite will pick up installed
|
||||
versions of Kerberos libraries rather than the newly built ones. You
|
||||
can install into a prefix that isn't in the system library search
|
||||
path, though. Alternatively, you can configure with
|
||||
**-**\ **-disable-rpath**, which renders the build tree less suitable
|
||||
for installation, but allows testing without interference from
|
||||
previously installed libraries.
|
||||
|
||||
There are additional regression tests available, which are not run
|
||||
by ``make check``. These tests require manual setup and teardown of
|
||||
support infrastructure which is not easily automated, or require
|
||||
excessive resources for ordinary use. The procedure for running
|
||||
the manual tests is documented at
|
||||
https://k5wiki.kerberos.org/wiki/Manual_Testing.
|
||||
|
||||
|
||||
Cleaning up the build
|
||||
---------------------
|
||||
|
||||
* Use ``make clean`` to remove all files generated by running make
|
||||
command.
|
||||
* Use ``make distclean`` to remove all files generated by running
|
||||
./configure script. After running ``make distclean`` your source
|
||||
tree (ideally) should look like the raw (just un-tarred) source
|
||||
tree.
|
||||
|
||||
Using autoconf
|
||||
--------------
|
||||
|
||||
(If you are not a developer, you can ignore this section.)
|
||||
|
||||
In the Kerberos V5 source directory, there is a configure script which
|
||||
automatically determines the compilation environment and creates the
|
||||
proper Makefiles for a particular platform. This configure script is
|
||||
generated using autoconf, which you should already have installed if
|
||||
you will be making changes to ``src/configure.in``.
|
||||
|
||||
Normal users will not need to worry about running autoconf; the
|
||||
distribution comes with the configure script already prebuilt.
|
||||
|
||||
The autoconf package comes with a script called ``autoreconf`` that
|
||||
will automatically run ``autoconf`` and ``autoheader`` as needed. You
|
||||
should run ``autoreconf`` from the top source directory, e.g.::
|
||||
|
||||
cd /u1/krb5-VERSION/src
|
||||
autoreconf --verbose
|
||||
63
crypto/krb5/doc/build/index.rst
vendored
Normal file
63
crypto/krb5/doc/build/index.rst
vendored
Normal file
|
|
@ -0,0 +1,63 @@
|
|||
.. _build_V5:
|
||||
|
||||
Building Kerberos V5
|
||||
====================
|
||||
|
||||
This section details how to build and install MIT Kerberos software
|
||||
from the source.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
In order to build Kerberos V5, you will need approximately 60-70
|
||||
megabytes of disk space. The exact amount will vary depending on the
|
||||
platform and whether the distribution is compiled with debugging
|
||||
symbol tables or not.
|
||||
|
||||
Your C compiler must conform to ANSI C (ISO/IEC 9899:1990, "c89").
|
||||
Some operating systems do not have an ANSI C compiler, or their
|
||||
default compiler requires extra command-line options to enable ANSI C
|
||||
conformance.
|
||||
|
||||
If you wish to keep a separate build tree, which contains the compiled
|
||||
\*.o file and executables, separate from your source tree, you will
|
||||
need a make program which supports **VPATH**, or you will need to use
|
||||
a tool such as lndir to produce a symbolic link tree for your build
|
||||
tree.
|
||||
|
||||
Obtaining the software
|
||||
----------------------
|
||||
|
||||
The source code can be obtained from MIT Kerberos Distribution page,
|
||||
at https://kerberos.org/dist/index.html.
|
||||
The MIT Kerberos distribution comes in an archive file, generally
|
||||
named krb5-VERSION-signed.tar, where *VERSION* is a placeholder for
|
||||
the major and minor versions of MIT Kerberos. (For example, MIT
|
||||
Kerberos 1.9 has major version "1" and minor version "9".)
|
||||
|
||||
The krb5-VERSION-signed.tar contains a compressed tar file consisting
|
||||
of the sources for all of Kerberos (generally named
|
||||
krb5-VERSION.tar.gz) and a PGP signature file for this source tree
|
||||
(generally named krb5-VERSION.tar.gz.asc). MIT highly recommends that
|
||||
you verify the integrity of the source code using this signature,
|
||||
e.g., by running::
|
||||
|
||||
tar xf krb5-VERSION-signed.tar
|
||||
gpg --verify krb5-VERSION.tar.gz.asc
|
||||
|
||||
Unpack krb5-VERSION.tar.gz in some directory. In this section we will assume
|
||||
that you have chosen the top directory of the distribution the directory
|
||||
``/u1/krb5-VERSION``.
|
||||
|
||||
Review the README file for the license, copyright and other sprecific to the
|
||||
distribution information.
|
||||
|
||||
Contents
|
||||
--------
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
directory_org.rst
|
||||
doing_build.rst
|
||||
options2configure.rst
|
||||
osconf.rst
|
||||
397
crypto/krb5/doc/build/options2configure.rst
vendored
Normal file
397
crypto/krb5/doc/build/options2configure.rst
vendored
Normal file
|
|
@ -0,0 +1,397 @@
|
|||
.. _options2configure:
|
||||
|
||||
Options to *configure*
|
||||
======================
|
||||
|
||||
There are a number of options to configure which you can use to
|
||||
control how the Kerberos distribution is built.
|
||||
|
||||
Most commonly used options
|
||||
--------------------------
|
||||
|
||||
**-**\ **-help**
|
||||
Provides help to configure. This will list the set of commonly
|
||||
used options for building Kerberos.
|
||||
|
||||
**-**\ **-prefix=**\ *PREFIX*
|
||||
By default, Kerberos will install the package's files rooted at
|
||||
``/usr/local``. If you desire to place the binaries into the
|
||||
directory *PREFIX*, use this option.
|
||||
|
||||
**-**\ **-exec-prefix=**\ *EXECPREFIX*
|
||||
This option allows one to separate the architecture independent
|
||||
programs from the host-dependent files (configuration files,
|
||||
manual pages). Use this option to install architecture-dependent
|
||||
programs in *EXECPREFIX*. The default location is the value of
|
||||
specified by **-**\ **-prefix** option.
|
||||
|
||||
**-**\ **-localstatedir=**\ *LOCALSTATEDIR*
|
||||
This option sets the directory for locally modifiable
|
||||
single-machine data. In Kerberos, this mostly is useful for
|
||||
setting a location for the KDC data files, as they will be
|
||||
installed in ``LOCALSTATEDIR/krb5kdc``, which is by default
|
||||
``PREFIX/var/krb5kdc``.
|
||||
|
||||
**-**\ **-with-netlib**\ [=\ *libs*]
|
||||
Allows for suppression of or replacement of network libraries. By
|
||||
default, Kerberos V5 configuration will look for ``-lnsl`` and
|
||||
``-lsocket``. If your operating system has a broken resolver
|
||||
library or fails to pass the tests in ``src/tests/resolv``, you
|
||||
will need to use this option.
|
||||
|
||||
**-**\ **-enable-dns-for-realm**
|
||||
Enable the use of DNS to look up a host's Kerberos realm,
|
||||
if the information is not provided in
|
||||
:ref:`krb5.conf(5)`. See :ref:`mapping_hostnames`
|
||||
for information about using DNS to determine the default realm.
|
||||
DNS lookups for realm names are disabled by default.
|
||||
|
||||
**-**\ **-with-system-et**
|
||||
Use an installed version of the error-table (et) support software,
|
||||
the compile_et program, the com_err.h header file and the com_err
|
||||
library. If these are not in the default locations, you may wish
|
||||
to specify ``CPPFLAGS=-I/some/dir`` and
|
||||
``LDFLAGS=-L/some/other/dir`` options at configuration time as
|
||||
well.
|
||||
|
||||
If this option is not given, a version supplied with the Kerberos
|
||||
sources will be built and installed along with the rest of the
|
||||
Kerberos tree, for Kerberos applications to link against.
|
||||
|
||||
**-**\ **-with-system-ss**
|
||||
Use an installed version of the subsystem command-line interface
|
||||
software, the mk_cmds program, the ``ss/ss.h`` header file and the
|
||||
ss library. If these are not in the default locations, you may
|
||||
wish to specify ``CPPFLAGS=-I/some/dir`` and
|
||||
``LDFLAGS=-L/some/other/dir`` options at configuration time as
|
||||
well. See also the **SS_LIB** option.
|
||||
|
||||
If this option is not given, the ss library supplied with the
|
||||
Kerberos sources will be compiled and linked into those programs
|
||||
that need it; it will not be installed separately.
|
||||
|
||||
**-**\ **-with-system-db**
|
||||
Use an installed version of the Berkeley DB package, which must
|
||||
provide an API compatible with version 1.85. This option is
|
||||
unsupported and untested. In particular, we do not know if the
|
||||
database-rename code used in the dumpfile load operation will
|
||||
behave properly.
|
||||
|
||||
If this option is not given, a version supplied with the Kerberos
|
||||
sources will be built and installed. (We are not updating this
|
||||
version at this time because of licensing issues with newer
|
||||
versions that we haven't investigated sufficiently yet.)
|
||||
|
||||
|
||||
Environment variables
|
||||
---------------------
|
||||
|
||||
**CC=**\ *COMPILER*
|
||||
Use *COMPILER* as the C compiler.
|
||||
|
||||
**CFLAGS=**\ *FLAGS*
|
||||
Use *FLAGS* as the default set of C compiler flags.
|
||||
|
||||
**CPP=**\ *CPP*
|
||||
C preprocessor to use. (e.g., ``CPP='gcc -E'``)
|
||||
|
||||
**CPPFLAGS=**\ *CPPOPTS*
|
||||
Use *CPPOPTS* as the default set of C preprocessor flags. The
|
||||
most common use of this option is to select certain #define's for
|
||||
use with the operating system's include files.
|
||||
|
||||
|
||||
**DB_HEADER=**\ *headername*
|
||||
If db.h is not the correct header file to include to compile
|
||||
against the Berkeley DB 1.85 API, specify the correct header file
|
||||
name with this option. For example, ``DB_HEADER=db3/db_185.h``.
|
||||
|
||||
**DB_LIB=**\ *libs*...
|
||||
If ``-ldb`` is not the correct library specification for the
|
||||
Berkeley DB library version to be used, override it with this
|
||||
option. For example, ``DB_LIB=-ldb-3.3``.
|
||||
|
||||
**DEFCCNAME=**\ *ccachename*
|
||||
Override the built-in default credential cache name.
|
||||
For example, ``DEFCCNAME=DIR:/var/run/user/%{USERID}/ccache``
|
||||
See :ref:`parameter_expansion` for information about supported
|
||||
parameter expansions.
|
||||
|
||||
**DEFCKTNAME=**\ *keytabname*
|
||||
Override the built-in default client keytab name.
|
||||
The format is the same as for *DEFCCNAME*.
|
||||
|
||||
**DEFKTNAME=**\ *keytabname*
|
||||
Override the built-in default keytab name.
|
||||
The format is the same as for *DEFCCNAME*.
|
||||
|
||||
**LD=**\ *LINKER*
|
||||
Use *LINKER* as the default loader if it should be different from
|
||||
C compiler as specified above.
|
||||
|
||||
**LDFLAGS=**\ *LDOPTS*
|
||||
This option informs the linker where to get additional libraries
|
||||
(e.g., ``-L<lib dir>``).
|
||||
|
||||
**LIBS=**\ *LDNAME*
|
||||
This option allows one to specify libraries to be passed to the
|
||||
linker (e.g., ``-l<library>``)
|
||||
|
||||
**PKCS11_MODNAME=**\ *library*
|
||||
Override the built-in default PKCS11 library name.
|
||||
|
||||
**SS_LIB=**\ *libs*...
|
||||
If ``-lss`` is not the correct way to link in your installed ss
|
||||
library, for example if additional support libraries are needed,
|
||||
specify the correct link options here. Some variants of this
|
||||
library are around which allow for Emacs-like line editing, but
|
||||
different versions require different support libraries to be
|
||||
explicitly specified.
|
||||
|
||||
This option is ignored if **-**\ **-with-system-ss** is not specified.
|
||||
|
||||
**YACC**
|
||||
The 'Yet Another C Compiler' implementation to use. Defaults to
|
||||
the first program found out of: '`bison -y`', '`byacc`',
|
||||
'`yacc`'.
|
||||
|
||||
**YFLAGS**
|
||||
The list of arguments that will be passed by default to $YACC.
|
||||
This script will default YFLAGS to the empty string to avoid a
|
||||
default value of ``-d`` given by some make applications.
|
||||
|
||||
|
||||
Fine tuning of the installation directories
|
||||
-------------------------------------------
|
||||
|
||||
**-**\ **-bindir=**\ *DIR*
|
||||
User executables. Defaults to ``EXECPREFIX/bin``, where
|
||||
*EXECPREFIX* is the path specified by **-**\ **-exec-prefix**
|
||||
configuration option.
|
||||
|
||||
**-**\ **-sbindir=**\ *DIR*
|
||||
System admin executables. Defaults to ``EXECPREFIX/sbin``, where
|
||||
*EXECPREFIX* is the path specified by **-**\ **-exec-prefix**
|
||||
configuration option.
|
||||
|
||||
**-**\ **-sysconfdir=**\ *DIR*
|
||||
Read-only single-machine data such as krb5.conf.
|
||||
Defaults to ``PREFIX/etc``, where
|
||||
*PREFIX* is the path specified by **-**\ **-prefix** configuration
|
||||
option.
|
||||
|
||||
**-**\ **-libdir=**\ *DIR*
|
||||
Object code libraries. Defaults to ``EXECPREFIX/lib``, where
|
||||
*EXECPREFIX* is the path specified by **-**\ **-exec-prefix**
|
||||
configuration option.
|
||||
|
||||
**-**\ **-includedir=**\ *DIR*
|
||||
C header files. Defaults to ``PREFIX/include``, where *PREFIX* is
|
||||
the path specified by **-**\ **-prefix** configuration option.
|
||||
|
||||
**-**\ **-datarootdir=**\ *DATAROOTDIR*
|
||||
Read-only architecture-independent data root. Defaults to
|
||||
``PREFIX/share``, where *PREFIX* is the path specified by
|
||||
**-**\ **-prefix** configuration option.
|
||||
|
||||
**-**\ **-datadir=**\ *DIR*
|
||||
Read-only architecture-independent data. Defaults to path
|
||||
specified by **-**\ **-datarootdir** configuration option.
|
||||
|
||||
**-**\ **-localedir=**\ *DIR*
|
||||
Locale-dependent data. Defaults to ``DATAROOTDIR/locale``, where
|
||||
*DATAROOTDIR* is the path specified by **-**\ **-datarootdir**
|
||||
configuration option.
|
||||
|
||||
**-**\ **-mandir=**\ *DIR*
|
||||
Man documentation. Defaults to ``DATAROOTDIR/man``, where
|
||||
*DATAROOTDIR* is the path specified by **-**\ **-datarootdir**
|
||||
configuration option.
|
||||
|
||||
|
||||
Program names
|
||||
-------------
|
||||
|
||||
**-**\ **-program-prefix=**\ *PREFIX*
|
||||
Prepend *PREFIX* to the names of the programs when installing
|
||||
them. For example, specifying ``--program-prefix=mit-`` at the
|
||||
configure time will cause the program named ``abc`` to be
|
||||
installed as ``mit-abc``.
|
||||
|
||||
**-**\ **-program-suffix=**\ *SUFFIX*
|
||||
Append *SUFFIX* to the names of the programs when installing them.
|
||||
For example, specifying ``--program-suffix=-mit`` at the configure
|
||||
time will cause the program named ``abc`` to be installed as
|
||||
``abc-mit``.
|
||||
|
||||
**-**\ **-program-transform-name=**\ *PROGRAM*
|
||||
Run ``sed -e PROGRAM`` on installed program names. (*PROGRAM* is a
|
||||
sed script).
|
||||
|
||||
|
||||
System types
|
||||
------------
|
||||
|
||||
**-**\ **-build=**\ *BUILD*
|
||||
Configure for building on *BUILD*
|
||||
(e.g., ``--build=x86_64-linux-gnu``).
|
||||
|
||||
**-**\ **-host=**\ *HOST*
|
||||
Cross-compile to build programs to run on *HOST*
|
||||
(e.g., ``--host=x86_64-linux-gnu``). By default, Kerberos V5
|
||||
configuration will look for "build" option.
|
||||
|
||||
|
||||
Optional features
|
||||
-----------------
|
||||
|
||||
**-**\ **-disable-option-checking**
|
||||
Ignore unrecognized --enable/--with options.
|
||||
|
||||
**-**\ **-disable-**\ *FEATURE*
|
||||
Do not include *FEATURE* (same as --enable-FEATURE=no).
|
||||
|
||||
**-**\ **-enable-**\ *FEATURE*\ [=\ *ARG*]
|
||||
Include *FEATURE* [ARG=yes].
|
||||
|
||||
**-**\ **-enable-maintainer-mode**
|
||||
Enable rebuilding of source files, Makefiles, etc.
|
||||
|
||||
**-**\ **-disable-delayed-initialization**
|
||||
Initialize library code when loaded. Defaults to delay until
|
||||
first use.
|
||||
|
||||
**-**\ **-disable-thread-support**
|
||||
Don't enable thread support. Defaults to enabled.
|
||||
|
||||
**-**\ **-disable-rpath**
|
||||
Suppress run path flags in link lines.
|
||||
|
||||
**-**\ **-enable-athena**
|
||||
Build with MIT Project Athena configuration.
|
||||
|
||||
**-**\ **-disable-kdc-lookaside-cache**
|
||||
Disable the cache which detects client retransmits.
|
||||
|
||||
**-**\ **-disable-pkinit**
|
||||
Disable PKINIT plugin support.
|
||||
|
||||
**-**\ **-disable-aesni**
|
||||
Disable support for using AES instructions on x86 platforms.
|
||||
|
||||
**-**\ **-enable-asan**\ [=\ *ARG*]
|
||||
Enable building with asan memory error checking. If *ARG* is
|
||||
given, it controls the -fsanitize compilation flag value (the
|
||||
default is "address").
|
||||
|
||||
|
||||
Optional packages
|
||||
-----------------
|
||||
|
||||
**-**\ **-with-**\ *PACKAGE*\ [=ARG\]
|
||||
Use *PACKAGE* (e.g., ``--with-imap``). The default value of *ARG*
|
||||
is ``yes``.
|
||||
|
||||
**-**\ **-without-**\ *PACKAGE*
|
||||
Do not use *PACKAGE* (same as ``--with-PACKAGE=no``)
|
||||
(e.g., ``--without-libedit``).
|
||||
|
||||
**-**\ **-with-size-optimizations**
|
||||
Enable a few optimizations to reduce code size possibly at some
|
||||
run-time cost.
|
||||
|
||||
**-**\ **-with-system-et**
|
||||
Use the com_err library and compile_et utility that are already
|
||||
installed on the system, instead of building and installing
|
||||
local versions.
|
||||
|
||||
**-**\ **-with-system-ss**
|
||||
Use the ss library and mk_cmds utility that are already installed
|
||||
on the system, instead of building and using private versions.
|
||||
|
||||
**-**\ **-with-system-db**
|
||||
Use the berkeley db utility already installed on the system,
|
||||
instead of using a private version. This option is not
|
||||
recommended; enabling it may result in incompatibility with key
|
||||
databases originating on other systems.
|
||||
|
||||
**-**\ **-with-netlib=**\ *LIBS*
|
||||
Use the resolver library specified in *LIBS*. Use this variable
|
||||
if the C library resolver is insufficient or broken.
|
||||
|
||||
**-**\ **-with-hesiod=**\ *path*
|
||||
Compile with Hesiod support. The *path* points to the Hesiod
|
||||
directory. By default Hesiod is unsupported.
|
||||
|
||||
**-**\ **-with-ldap**
|
||||
Compile OpenLDAP database backend module.
|
||||
|
||||
**-**\ **-with-lmdb**
|
||||
Compile LMDB database backend module.
|
||||
|
||||
**-**\ **-with-vague-errors**
|
||||
Do not send helpful errors to client. For example, if the KDC
|
||||
should return only vague error codes to clients.
|
||||
|
||||
**-**\ **-with-crypto-impl=**\ *IMPL*
|
||||
Use specified crypto implementation (e.g., **-**\
|
||||
**-with-crypto-impl=**\ *openssl*). The default is the native MIT
|
||||
Kerberos implementation ``builtin``. The other currently
|
||||
implemented crypto backend is ``openssl``. (See
|
||||
:ref:`mitK5features`)
|
||||
|
||||
**-**\ **-without-libedit**
|
||||
Do not compile and link against libedit. Some utilities will no
|
||||
longer offer command history or completion in interactive mode if
|
||||
libedit is disabled.
|
||||
|
||||
**-**\ **-with-readline**
|
||||
Compile and link against GNU readline, as an alternative to libedit.
|
||||
|
||||
**-**\ **-with-system-verto**
|
||||
Use an installed version of libverto. If the libverto header and
|
||||
library are not in default locations, you may wish to specify
|
||||
``CPPFLAGS=-I/some/dir`` and ``LDFLAGS=-L/some/other/dir`` options
|
||||
at configuration time as well.
|
||||
|
||||
If this option is not given, the build system will try to detect
|
||||
an installed version of libverto and use it if it is found.
|
||||
Otherwise, a version supplied with the Kerberos sources will be
|
||||
built and installed. The built-in version does not contain the
|
||||
full set of back-end modules and is not a suitable general
|
||||
replacement for the upstream version, but will work for the
|
||||
purposes of Kerberos.
|
||||
|
||||
Specifying **-**\ **-without-system-verto** will cause the built-in
|
||||
version of libverto to be used unconditionally.
|
||||
|
||||
**-**\ **-with-krb5-config=**\ *PATH*
|
||||
Use the krb5-config program at *PATH* to obtain the build-time
|
||||
default credential cache, keytab, and client keytab names. The
|
||||
default is to use ``krb5-config`` from the program path. Specify
|
||||
``--without-krb5-config`` to disable the use of krb5-config and
|
||||
use the usual built-in defaults.
|
||||
|
||||
**-**\ **-without-keyutils**
|
||||
Build without libkeyutils support. This disables the KEYRING
|
||||
credential cache type.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
For example, in order to configure Kerberos on a Solaris machine using
|
||||
the suncc compiler with the optimizer turned on, run the configure
|
||||
script with the following options::
|
||||
|
||||
% ./configure CC=suncc CFLAGS=-O
|
||||
|
||||
For a slightly more complicated example, consider a system where
|
||||
several packages to be used by Kerberos are installed in
|
||||
``/usr/foobar``, including Berkeley DB 3.3, and an ss library that
|
||||
needs to link against the curses library. The configuration of
|
||||
Kerberos might be done thus::
|
||||
|
||||
./configure CPPFLAGS=-I/usr/foobar/include LDFLAGS=-L/usr/foobar/lib \
|
||||
--with-system-et --with-system-ss --with-system-db \
|
||||
SS_LIB='-lss -lcurses' DB_HEADER=db3/db_185.h DB_LIB=-ldb-3.3
|
||||
26
crypto/krb5/doc/build/osconf.rst
vendored
Normal file
26
crypto/krb5/doc/build/osconf.rst
vendored
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
osconf.hin
|
||||
==========
|
||||
|
||||
There is one configuration file which you may wish to edit to control
|
||||
various compile-time parameters in the Kerberos distribution::
|
||||
|
||||
include/osconf.hin
|
||||
|
||||
The list that follows is by no means complete, just some of the more
|
||||
interesting variables.
|
||||
|
||||
**DEFAULT_PROFILE_PATH**
|
||||
The pathname to the file which contains the profiles for the known
|
||||
realms, their KDCs, etc. The default value is |krb5conf|.
|
||||
**DEFAULT_KEYTAB_NAME**
|
||||
The type and pathname to the default server keytab file. The
|
||||
default is |keytab|.
|
||||
**DEFAULT_KDC_ENCTYPE**
|
||||
The default encryption type for the KDC database master key. The
|
||||
default value is |defmkey|.
|
||||
**RCTMPDIR**
|
||||
The directory which stores replay caches. The default is
|
||||
``/var/tmp``.
|
||||
**DEFAULT_KDB_FILE**
|
||||
The location of the default database. The default value is
|
||||
|kdcdir|\ ``/principal``.
|
||||
82
crypto/krb5/doc/build_this.rst
Normal file
82
crypto/krb5/doc/build_this.rst
Normal file
|
|
@ -0,0 +1,82 @@
|
|||
How to build this documentation from the source
|
||||
===============================================
|
||||
|
||||
Pre-requisites for a simple build, or to update man pages:
|
||||
|
||||
* Sphinx 1.0.4 or higher (See https://www.sphinx-doc.org) with the
|
||||
autodoc extension installed.
|
||||
|
||||
Additional prerequisites to include the API reference based on Doxygen
|
||||
markup:
|
||||
|
||||
* Python 2.5 with the Cheetah, lxml, and xml modules
|
||||
* Doxygen
|
||||
|
||||
|
||||
Simple build without API reference
|
||||
----------------------------------
|
||||
|
||||
To test simple changes to the RST sources, you can build the
|
||||
documentation without the Doxygen reference by running, from the doc
|
||||
directory::
|
||||
|
||||
sphinx-build . test_html
|
||||
|
||||
You will see a number of warnings about missing files. This is
|
||||
expected. If there is not already a ``doc/version.py`` file, you will
|
||||
need to create one by first running ``make version.py`` in the
|
||||
``src/doc`` directory of a configured build tree.
|
||||
|
||||
|
||||
Updating man pages
|
||||
------------------
|
||||
|
||||
Man pages are generated from the RST sources and checked into the
|
||||
``src/man`` directory of the repository. This allows man pages to be
|
||||
installed without requiring Sphinx when using a source checkout. To
|
||||
regenerate these files, run ``make man`` from the man subdirectory
|
||||
of a configured build tree. You can also do this from an unconfigured
|
||||
source tree with::
|
||||
|
||||
cd src/man
|
||||
make -f Makefile.in top_srcdir=.. srcdir=. man
|
||||
make clean
|
||||
|
||||
As with the simple build, it is normal to see warnings about missing
|
||||
files when rebuilding the man pages.
|
||||
|
||||
|
||||
Building for a release tarball or web site
|
||||
------------------------------------------
|
||||
|
||||
To generate documentation in HTML format, run ``make html`` in the
|
||||
``doc`` subdirectory of a configured build tree (the build directory
|
||||
corresponding to ``src/doc``, not the top-level ``doc`` directory).
|
||||
The output will be placed in the top-level ``doc/html`` directory.
|
||||
This build will include the API reference generated from Doxygen
|
||||
markup in the source tree.
|
||||
|
||||
Documentation generated this way will use symbolic names for paths
|
||||
(like ``BINDIR`` for the directory containing user programs), with the
|
||||
symbolic names being links to a table showing typical values for those
|
||||
paths.
|
||||
|
||||
You can also do this from an unconfigured source tree with::
|
||||
|
||||
cd src/doc
|
||||
make -f Makefile.in SPHINX_ARGS= htmlsrc
|
||||
|
||||
|
||||
Building for an OS package or site documentation
|
||||
------------------------------------------------
|
||||
|
||||
To generate documentation specific to a build of MIT krb5 as you have
|
||||
configured it, run ``make substhtml`` in the ``doc`` subdirectory of a
|
||||
configured build tree (the build directory corresponding to
|
||||
``src/doc``, not the top-level ``doc`` directory). The output will be
|
||||
placed in the ``html_subst`` subdirectory of that build directory.
|
||||
This build will include the API reference.
|
||||
|
||||
Documentation generated this way will use concrete paths (like
|
||||
``/usr/local/bin`` for the directory containing user programs, for a
|
||||
default custom build).
|
||||
5
crypto/krb5/doc/coding-style
Normal file
5
crypto/krb5/doc/coding-style
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
Please see
|
||||
|
||||
https://k5wiki.kerberos.org/wiki/Coding_style
|
||||
|
||||
for the current coding style.
|
||||
320
crypto/krb5/doc/conf.py
Normal file
320
crypto/krb5/doc/conf.py
Normal file
|
|
@ -0,0 +1,320 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
#
|
||||
# MIT Kerberos documentation build configuration file, created by
|
||||
# sphinx-quickstart on Wed Oct 13 09:14:03 2010.
|
||||
#
|
||||
# This file is execfile()d with the current directory set to its containing dir.
|
||||
#
|
||||
# Note that not all possible configuration values are present in this
|
||||
# autogenerated file.
|
||||
#
|
||||
# All configuration values have a default; values that are commented out
|
||||
# serve to show the default.
|
||||
|
||||
import sys, os
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#sys.path.insert(0, os.path.abspath('.'))
|
||||
|
||||
# -- General configuration -----------------------------------------------------
|
||||
|
||||
# If your documentation needs a minimal Sphinx version, state it here.
|
||||
#needs_sphinx = '1.0'
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be extensions
|
||||
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
|
||||
#extensions = ['sphinx.ext.autodoc', 'sphinxcontrib.doxylink']
|
||||
extensions = ['sphinx.ext.autodoc']
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
||||
# The suffix of source filenames.
|
||||
source_suffix = '.rst'
|
||||
|
||||
# The encoding of source files.
|
||||
#source_encoding = 'utf-8-sig'
|
||||
|
||||
# The master toctree document.
|
||||
if 'notice' in tags:
|
||||
master_doc = 'notice'
|
||||
else:
|
||||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = u'MIT Kerberos'
|
||||
copyright = u'1985-2024, MIT'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
# built documents.
|
||||
exec(open("version.py").read())
|
||||
# The short X.Y version.
|
||||
r_list = [r_major, r_minor]
|
||||
if r_patch:
|
||||
r_list += [r_patch]
|
||||
version = '.'.join(map(str, r_list))
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = version
|
||||
if r_tail:
|
||||
release += '-' + r_tail
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
#language = None
|
||||
|
||||
# There are two options for replacing |today|: either, you set today to some
|
||||
# non-false value, then it is used:
|
||||
today = ' '
|
||||
# Else, today_fmt is used as the format for a strftime call.
|
||||
#today_fmt = '%B %d, %Y'
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
exclude_patterns = []
|
||||
|
||||
# The reST default role (used for this markup: `text`) to use for all documents.
|
||||
#default_role = None
|
||||
|
||||
# If true, '()' will be appended to :func: etc. cross-reference text.
|
||||
#add_function_parentheses = True
|
||||
|
||||
# If true, the current module name will be prepended to all description
|
||||
# unit titles (such as .. function::).
|
||||
#add_module_names = True
|
||||
|
||||
# If true, sectionauthor and moduleauthor directives will be shown in the
|
||||
# output. They are ignored by default.
|
||||
#show_authors = False
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
pygments_style = 'sphinx'
|
||||
|
||||
# A list of ignored prefixes for module index sorting.
|
||||
#modindex_common_prefix = []
|
||||
|
||||
|
||||
# -- Options for HTML output ---------------------------------------------------
|
||||
|
||||
# When we can rely on Sphinx 1.8 (released Sep 2018) we can just set:
|
||||
# html_css_files = ['kerb.css']
|
||||
# But in the meantime, we add this file using either a way that works
|
||||
# after 1.8 or a way that works before 4.0.
|
||||
def setup(app):
|
||||
if callable(getattr(app, 'add_css_file', None)):
|
||||
app.add_css_file('kerb.css')
|
||||
else:
|
||||
app.add_stylesheet('kerb.css')
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
# html_theme = 'default'
|
||||
html_theme = 'agogo'
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
# documentation.
|
||||
html_theme_options = { "linkcolor": "#881f0d", "footerbg": "#5d1509",
|
||||
"bgcolor": "#5d1509", "documentwidth": "80%",
|
||||
"pagewidth": "auto", "sidebarwidth": "20%" }
|
||||
|
||||
# Add any paths that contain custom themes here, relative to this directory.
|
||||
#html_theme_path = []
|
||||
|
||||
# The name for this set of Sphinx documents. If None, it defaults to
|
||||
# "<project> v<release> documentation".
|
||||
html_title = "MIT Kerberos Documentation"
|
||||
|
||||
# A shorter title for the navigation bar. Default is the same as html_title.
|
||||
#html_short_title = None
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top
|
||||
# of the sidebar.
|
||||
if os.environ.get('HTML_LOGO'):
|
||||
html_logo = os.environ['HTML_LOGO']
|
||||
|
||||
# The name of an image file (within the static path) to use as favicon of the
|
||||
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
|
||||
# pixels large.
|
||||
#html_favicon = None
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
|
||||
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
|
||||
# using the given strftime format.
|
||||
#html_last_updated_fmt = '%b %d, %Y'
|
||||
|
||||
# Custom sidebar templates, maps document names to template names.
|
||||
#html_sidebars = {}
|
||||
|
||||
# Additional templates that should be rendered to pages, maps page names to
|
||||
# template names.
|
||||
#html_additional_pages = {}
|
||||
|
||||
# If false, no module index is generated.
|
||||
#html_domain_indices = True
|
||||
|
||||
# If false, no index is generated.
|
||||
#html_use_index = True
|
||||
|
||||
# If true, the index is split into individual pages for each letter.
|
||||
html_split_index = True
|
||||
|
||||
# If true, links to the reST sources are added to the pages.
|
||||
html_show_sourcelink = False
|
||||
|
||||
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
|
||||
#html_show_sphinx = True
|
||||
|
||||
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
|
||||
#html_show_copyright = True
|
||||
|
||||
# If true, an OpenSearch description file will be output, and all pages will
|
||||
# contain a <link> tag referring to it. The value of this option must be the
|
||||
# base URL from which the finished HTML is served.
|
||||
#html_use_opensearch = ''
|
||||
|
||||
# This is the file name suffix for HTML files (e.g., ".xhtml").
|
||||
#html_file_suffix = None
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'MIT Kerberos'
|
||||
|
||||
pointsize = '10pt'
|
||||
|
||||
# -- Options for LaTeX output --------------------------------------------------
|
||||
|
||||
# The paper size ('letter' or 'a4').
|
||||
#latex_paper_size = 'letter'
|
||||
|
||||
# The font size ('10pt', '11pt' or '12pt').
|
||||
#latex_font_size = '10pt'
|
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title, author, documentclass [howto/manual]).
|
||||
latex_documents = [
|
||||
('admin/index', 'admin.tex', u"Kerberos Administration Guide", u'MIT',
|
||||
'manual'),
|
||||
('appdev/index', 'appdev.tex', u"Kerberos Application Developer Guide",
|
||||
u'MIT', 'manual'),
|
||||
('basic/index', 'basic.tex', u"Kerberos Concepts", u'MIT', 'manual'),
|
||||
('build/index', 'build.tex', u"Building MIT Kerberos", u'MIT', 'manual'),
|
||||
('plugindev/index', 'plugindev.tex', u"Kerberos Plugin Module Developer Guide",
|
||||
u'MIT', 'manual'),
|
||||
('user/index', 'user.tex', u"Kerberos User Guide", u'MIT', 'manual')
|
||||
]
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of
|
||||
# the title page.
|
||||
#latex_logo = None
|
||||
|
||||
# For "manual" documents, if this is true, then toplevel headings are parts,
|
||||
# not chapters.
|
||||
#latex_use_parts = False
|
||||
|
||||
# If true, show page references after internal links.
|
||||
#latex_show_pagerefs = False
|
||||
|
||||
# If true, show URL addresses after external links.
|
||||
#latex_show_urls = False
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
#latex_preamble = ''
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
#latex_appendices = []
|
||||
|
||||
# If false, no module index is generated.
|
||||
#latex_domain_indices = True
|
||||
|
||||
if 'mansubs' in tags:
|
||||
bindir = '``@BINDIR@``'
|
||||
sbindir = '``@SBINDIR@``'
|
||||
libdir = '``@LIBDIR@``'
|
||||
localstatedir = '``@LOCALSTATEDIR@``'
|
||||
runstatedir = '``@RUNSTATEDIR@``'
|
||||
sysconfdir = '``@SYSCONFDIR@``'
|
||||
ccache = '``@CCNAME@``'
|
||||
keytab = '``@KTNAME@``'
|
||||
ckeytab = '``@CKTNAME@``'
|
||||
pkcs11_modname = '``@PKCS11MOD@``'
|
||||
elif 'pathsubs' in tags:
|
||||
# Read configured paths from a file produced by the build system.
|
||||
exec(open("paths.py").read())
|
||||
else:
|
||||
bindir = ':ref:`BINDIR <paths>`'
|
||||
sbindir = ':ref:`SBINDIR <paths>`'
|
||||
libdir = ':ref:`LIBDIR <paths>`'
|
||||
localstatedir = ':ref:`LOCALSTATEDIR <paths>`'
|
||||
runstatedir = ':ref:`RUNSTATEDIR <paths>`'
|
||||
sysconfdir = ':ref:`SYSCONFDIR <paths>`'
|
||||
ccache = ':ref:`DEFCCNAME <paths>`'
|
||||
keytab = ':ref:`DEFKTNAME <paths>`'
|
||||
ckeytab = ':ref:`DEFCKTNAME <paths>`'
|
||||
pkcs11_modname = ':ref:`PKCS11_MODNAME <paths>`'
|
||||
|
||||
rst_epilog = '\n'
|
||||
|
||||
if 'notice' in tags:
|
||||
exclude_patterns = [ 'admin', 'appdev', 'basic', 'build',
|
||||
'plugindev', 'user' ]
|
||||
exclude_patterns += [ 'about.rst', 'build_this.rst', 'copyright.rst',
|
||||
'index.rst', 'mitK5*.rst', 'resources.rst' ]
|
||||
rst_epilog += '.. |copy| replace:: \(C\)'
|
||||
else:
|
||||
exclude_patterns += [ 'notice.rst' ]
|
||||
rst_epilog += '.. |bindir| replace:: %s\n' % bindir
|
||||
rst_epilog += '.. |sbindir| replace:: %s\n' % sbindir
|
||||
rst_epilog += '.. |libdir| replace:: %s\n' % libdir
|
||||
rst_epilog += '.. |kdcdir| replace:: %s\\ ``/krb5kdc``\n' % localstatedir
|
||||
rst_epilog += '.. |kdcrundir| replace:: %s\\ ``/krb5kdc``\n' % runstatedir
|
||||
rst_epilog += '.. |sysconfdir| replace:: %s\n' % sysconfdir
|
||||
rst_epilog += '.. |ccache| replace:: %s\n' % ccache
|
||||
rst_epilog += '.. |keytab| replace:: %s\n' % keytab
|
||||
rst_epilog += '.. |ckeytab| replace:: %s\n' % ckeytab
|
||||
rst_epilog += '.. |pkcs11_modname| replace:: %s\n' % pkcs11_modname
|
||||
rst_epilog += '''
|
||||
.. |krb5conf| replace:: ``/etc/krb5.conf``
|
||||
.. |defkeysalts| replace:: ``aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal``
|
||||
.. |defetypes| replace:: ``aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac``
|
||||
.. |defmkey| replace:: ``aes256-cts-hmac-sha1-96``
|
||||
.. |copy| unicode:: U+000A9
|
||||
'''
|
||||
|
||||
# -- Options for manual page output --------------------------------------------
|
||||
|
||||
# One entry per manual page. List of tuples
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
('user/user_commands/kinit', 'kinit', u'obtain and cache Kerberos ticket-granting ticket', [u'MIT'], 1),
|
||||
('user/user_commands/klist', 'klist', u'list cached Kerberos tickets', [u'MIT'], 1),
|
||||
('user/user_commands/kdestroy', 'kdestroy', u'destroy Kerberos tickets', [u'MIT'], 1),
|
||||
('user/user_commands/kswitch', 'kswitch', u'switch primary ticket cache', [u'MIT'], 1),
|
||||
('user/user_commands/kpasswd', 'kpasswd', u'change a user\'s Kerberos password', [u'MIT'], 1),
|
||||
('user/user_commands/kvno', 'kvno', u'print key version numbers of Kerberos principals', [u'MIT'], 1),
|
||||
('user/user_commands/ksu', 'ksu', u'Kerberized super-user', [u'MIT'], 1),
|
||||
('user/user_commands/krb5-config', 'krb5-config', u'tool for linking against MIT Kerberos libraries', [u'MIT'], 1),
|
||||
('user/user_config/k5login', 'k5login', u'Kerberos V5 acl file for host access', [u'MIT'], 5),
|
||||
('user/user_config/k5identity', 'k5identity', u'Kerberos V5 client principal selection rules', [u'MIT'], 5),
|
||||
('user/user_config/kerberos', 'kerberos', u'Overview of using Kerberos', [u'MIT'], 7),
|
||||
('admin/admin_commands/krb5kdc', 'krb5kdc', u'Kerberos V5 KDC', [u'MIT'], 8),
|
||||
('admin/admin_commands/kadmin_local', 'kadmin', u'Kerberos V5 database administration program', [u'MIT'], 1),
|
||||
('admin/admin_commands/kprop', 'kprop', u'propagate a Kerberos V5 principal database to a replica server', [u'MIT'], 8),
|
||||
('admin/admin_commands/kproplog', 'kproplog', u'display the contents of the Kerberos principal update log', [u'MIT'], 8),
|
||||
('admin/admin_commands/kpropd', 'kpropd', u'Kerberos V5 replica KDC update server', [u'MIT'], 8),
|
||||
('admin/admin_commands/kdb5_util', 'kdb5_util', u'Kerberos database maintenance utility', [u'MIT'], 8),
|
||||
('admin/admin_commands/ktutil', 'ktutil', u'Kerberos keytab file maintenance utility', [u'MIT'], 1),
|
||||
('admin/admin_commands/k5srvutil', 'k5srvutil', u'host key table (keytab) manipulation utility', [u'MIT'], 1),
|
||||
('admin/admin_commands/kadmind', 'kadmind', u'KADM5 administration server', [u'MIT'], 8),
|
||||
('admin/admin_commands/kdb5_ldap_util', 'kdb5_ldap_util', u'Kerberos configuration utility', [u'MIT'], 8),
|
||||
('admin/conf_files/krb5_conf', 'krb5.conf', u'Kerberos configuration file', [u'MIT'], 5),
|
||||
('admin/conf_files/kdc_conf', 'kdc.conf', u'Kerberos V5 KDC configuration file', [u'MIT'], 5),
|
||||
('admin/conf_files/kadm5_acl', 'kadm5.acl', u'Kerberos ACL file', [u'MIT'], 5),
|
||||
('user/user_commands/sclient', 'sclient', u'sample Kerberos version 5 client', [u'MIT'], 1),
|
||||
('admin/admin_commands/sserver', 'sserver', u'sample Kerberos version 5 server', [u'MIT'], 8),
|
||||
]
|
||||
70
crypto/krb5/doc/contributing.txt
Normal file
70
crypto/krb5/doc/contributing.txt
Normal file
|
|
@ -0,0 +1,70 @@
|
|||
Contributing to MIT Kerberos
|
||||
|
||||
DESIGN
|
||||
======
|
||||
|
||||
If you are planning to contribute a substantial amount of work, please
|
||||
ensure that you have a discussion about the design on the
|
||||
krbdev@mit.edu list. Some changes may require coordination with
|
||||
standards groups. For example, interface changes and extensions for
|
||||
the GSS-API should be discussed in the IETF KITTEN Working Group.
|
||||
|
||||
STYLE
|
||||
=====
|
||||
|
||||
Please follow the guidelines in doc/coding-style for new code. For
|
||||
existing code, please preserve its existing indentation and brace
|
||||
conventions. These existing conventions usually resemble the
|
||||
guidelines in doc/coding-style. Exceptions to the style in
|
||||
doc/coding-style are usually large past contributions or imports from
|
||||
other parties. These include (not an exhaustive list):
|
||||
|
||||
src/appl/bsd
|
||||
src/appl/gssftp
|
||||
src/appl/telnet
|
||||
src/kadmin
|
||||
src/lib/kadm5
|
||||
src/lib/gssapi/mechglue
|
||||
src/lib/rpc
|
||||
|
||||
PATCHES
|
||||
=======
|
||||
|
||||
We prefer patches in either unified or context diff format (diff -u or
|
||||
diff -c). As is usual practice, please specify the original file
|
||||
before the modified file on the diff command line. It's also useful
|
||||
to perform the diff from the top level of the tree, e.g.,
|
||||
|
||||
diff -ur src.orig src
|
||||
|
||||
It's even more useful if you use our anonymous Subversion repository
|
||||
at
|
||||
|
||||
svn://anonsvn.mit.edu/krb5
|
||||
|
||||
and use "svn diff" (or "svk diff" if you prefer to use SVK) to
|
||||
generate your patches.
|
||||
|
||||
It is much easier for us to integrate patches which are generated
|
||||
against current code on the trunk. Please ensure that your source
|
||||
tree is up-to-date before generating your patch.
|
||||
|
||||
COPYRIGHT
|
||||
=========
|
||||
|
||||
If you are submitting substantial quantities of new code, or are
|
||||
substantially modifying existing code, please be clear about the
|
||||
copyright status of your contributions. Note that if your
|
||||
contribution was created in the course of your employment, your
|
||||
employer may own copyright in your contribution.
|
||||
|
||||
We prefer that MIT receives the ownership of the contributions, but
|
||||
will generally accept contributed code with copyright owned by other
|
||||
parties provided that the license conditions are substantially
|
||||
identical to the existing license on the MIT krb5 code.
|
||||
|
||||
Appropriate copyright notices and license terms should be added to new
|
||||
or changed files, unless the contributed code is being assigned to the
|
||||
already-listed copyright holder in the file, or the contribution is
|
||||
being released to the public domain. Please make sure that the
|
||||
year in the copyright statement is kept up-to-date.
|
||||
8
crypto/krb5/doc/copyright.rst
Normal file
8
crypto/krb5/doc/copyright.rst
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
Copyright
|
||||
=========
|
||||
|
||||
Copyright |copy| 1985-2024 by the Massachusetts Institute of
|
||||
Technology and its contributors. All rights reserved.
|
||||
|
||||
See :ref:`mitK5license` for additional copyright and license
|
||||
information.
|
||||
33
crypto/krb5/doc/doxy_examples/cc_set_config.c
Normal file
33
crypto/krb5/doc/doxy_examples/cc_set_config.c
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
/** @example cc_set_config.c
|
||||
*
|
||||
* Usage examples for krb5_cc_set_config and krb5_cc_get_config functions
|
||||
*/
|
||||
#include <k5-int.h>
|
||||
|
||||
krb5_error_code
|
||||
func_set(krb5_context context, krb5_ccache id,
|
||||
krb5_const_principal principal, const char *key)
|
||||
{
|
||||
krb5_data config_data;
|
||||
|
||||
config_data.data = "yes";
|
||||
config_data.length = strlen(config_data.data);
|
||||
return krb5_cc_set_config(context, id, principal, key, &config_data);
|
||||
}
|
||||
|
||||
krb5_error_code
|
||||
func_get(krb5_context context, krb5_ccache id,
|
||||
krb5_const_principal principal, const char *key)
|
||||
{
|
||||
krb5_data config_data;
|
||||
krb5_error_code ret;
|
||||
|
||||
config_data.data = NULL;
|
||||
ret = krb5_cc_get_config(context, id, principal, key, &config_data);
|
||||
if (ret){
|
||||
return ret;
|
||||
}
|
||||
/* do something */
|
||||
krb5_free_data_contents(context, &config_data);
|
||||
return ret;
|
||||
}
|
||||
23
crypto/krb5/doc/doxy_examples/cc_unique.c
Normal file
23
crypto/krb5/doc/doxy_examples/cc_unique.c
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
/** @example cc_unique.c
|
||||
*
|
||||
* Usage example for krb5_cc_new_unique function
|
||||
*/
|
||||
#include "k5-int.h"
|
||||
|
||||
krb5_error_code
|
||||
func(krb5_context context)
|
||||
{
|
||||
krb5_error_code ret;
|
||||
krb5_ccache ccache = NULL;
|
||||
|
||||
ret = krb5_cc_new_unique(context, "MEMORY", NULL, &ccache);
|
||||
if (ret){
|
||||
ccache = NULL;
|
||||
return ret;
|
||||
}
|
||||
/* do something */
|
||||
if (ccache)
|
||||
(void)krb5_cc_destroy(context, ccache);
|
||||
return 0;
|
||||
}
|
||||
|
||||
20
crypto/krb5/doc/doxy_examples/error_message.c
Executable file
20
crypto/krb5/doc/doxy_examples/error_message.c
Executable file
|
|
@ -0,0 +1,20 @@
|
|||
/** @example error_message.c
|
||||
*
|
||||
* Demo for krb5_get/set/free_error_message function family
|
||||
*/
|
||||
#include <k5-int.h>
|
||||
|
||||
krb5_error_code
|
||||
func(krb5_context context)
|
||||
{
|
||||
krb5_error_code ret;
|
||||
|
||||
ret = krb5_func(context);
|
||||
if (ret) {
|
||||
const char *err_str = krb5_get_error_message(context, ret);
|
||||
krb5_set_error_message(context, ret,
|
||||
"Failed krb5_func: %s", err_str);
|
||||
krb5_free_error_message(context, err_str);
|
||||
}
|
||||
}
|
||||
|
||||
55
crypto/krb5/doc/doxy_examples/tkt_creds.c
Normal file
55
crypto/krb5/doc/doxy_examples/tkt_creds.c
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
/** @example tkt_creds.c
|
||||
*
|
||||
* Usage example for krb5_tkt_creds function family
|
||||
*/
|
||||
#include "krb5.h"
|
||||
|
||||
krb5_error_code
|
||||
func(krb5_context context, krb5_flags options,
|
||||
krb5_ccache ccache, krb5_creds *in_creds,
|
||||
krb5_creds **out_creds)
|
||||
{
|
||||
krb5_error_code code = KRB5_OK;
|
||||
krb5_creds *ncreds = NULL;
|
||||
krb5_tkt_creds_context ctx = NULL;
|
||||
|
||||
*out_creds = NULL;
|
||||
|
||||
/* Allocate a container. */
|
||||
ncreds = k5alloc(sizeof(*ncreds), &code);
|
||||
if (ncreds == NULL)
|
||||
goto cleanup;
|
||||
|
||||
/* Make and execute a krb5_tkt_creds context to get the credential. */
|
||||
code = krb5_tkt_creds_init(context, ccache, in_creds, options, &ctx);
|
||||
if (code != KRB5_OK)
|
||||
goto cleanup;
|
||||
code = krb5_tkt_creds_get(context, ctx);
|
||||
if (code != KRB5_OK)
|
||||
goto cleanup;
|
||||
code = krb5_tkt_creds_get_creds(context, ctx, ncreds);
|
||||
if (code != KRB5_OK)
|
||||
goto cleanup;
|
||||
|
||||
*out_creds = ncreds;
|
||||
ncreds = NULL;
|
||||
|
||||
cleanup:
|
||||
krb5_free_creds(context, ncreds);
|
||||
krb5_tkt_creds_free(context, ctx);
|
||||
return code;
|
||||
}
|
||||
|
||||
/* Allocate zeroed memory; set *code to 0 on success or ENOMEM on failure. */
|
||||
static inline void *
|
||||
k5alloc(size_t len, krb5_error_code *code)
|
||||
{
|
||||
void *ptr;
|
||||
|
||||
/* Allocate at least one byte since zero-byte allocs may return NULL. */
|
||||
ptr = calloc((len > 0) ? len : 1, 1);
|
||||
*code = (ptr == NULL) ? ENOMEM : 0;
|
||||
return ptr;
|
||||
}
|
||||
|
||||
|
||||
28
crypto/krb5/doc/doxy_examples/verify_init_creds.c
Normal file
28
crypto/krb5/doc/doxy_examples/verify_init_creds.c
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
/** @example verify_init_creds.c
|
||||
*
|
||||
* Usage example for krb5_verify_init_creds function family
|
||||
*/
|
||||
#include "k5-int.h"
|
||||
|
||||
krb5_error_code
|
||||
func(krb5_context context, krb5_creds *creds, krb5_principal server_principal)
|
||||
{
|
||||
krb5_error_code ret = KRB5_OK;
|
||||
krb5_verify_init_creds_opt options;
|
||||
|
||||
krb5_verify_init_creds_opt_init (&options);
|
||||
krb5_verify_init_creds_opt_set_ap_req_nofail (&options, 1);
|
||||
|
||||
ret = krb5_verify_init_creds(context,
|
||||
creds,
|
||||
server_principal,
|
||||
NULL /* use default keytab */,
|
||||
NULL /* don't store creds in ccache */,
|
||||
&options);
|
||||
if (ret) {
|
||||
/* error while verifying credentials for server */
|
||||
}
|
||||
|
||||
return ret;
|
||||
}
|
||||
|
||||
182
crypto/krb5/doc/formats/ccache_file_format.rst
Normal file
182
crypto/krb5/doc/formats/ccache_file_format.rst
Normal file
|
|
@ -0,0 +1,182 @@
|
|||
.. _ccache_file_format:
|
||||
|
||||
Credential cache file format
|
||||
============================
|
||||
|
||||
There are four versions of the file format used by the FILE credential
|
||||
cache type. The first byte of the file always has the value 5, and
|
||||
the value of the second byte contains the version number (1 through
|
||||
4). Versions 1 and 2 of the file format use native byte order for integer
|
||||
representations. Versions 3 and 4 always use big-endian byte order.
|
||||
|
||||
After the two-byte version indicator, the file has three parts: the
|
||||
header (in version 4 only), the default principal name, and a sequence
|
||||
of credentials.
|
||||
|
||||
|
||||
Header format
|
||||
-------------
|
||||
|
||||
The header appears only in format version 4. It begins with a 16-bit
|
||||
integer giving the length of the entire header, followed by a sequence
|
||||
of fields. Each field consists of a 16-bit tag, a 16-bit length, and
|
||||
a value of the given length. A file format implementation should
|
||||
ignore fields with unknown tags.
|
||||
|
||||
At this time there is only one defined header field. Its tag value is
|
||||
1, its length is always 8, and its contents are two 32-bit integers
|
||||
giving the seconds and microseconds of the time offset of the KDC
|
||||
relative to the client. Adding this offset to the current time on the
|
||||
client should give the current time on the KDC, if that offset has not
|
||||
changed since the initial authentication.
|
||||
|
||||
|
||||
.. _cache_principal_format:
|
||||
|
||||
Principal format
|
||||
----------------
|
||||
|
||||
The default principal is marshalled using the following informal
|
||||
grammar::
|
||||
|
||||
principal ::=
|
||||
name type (32 bits) [omitted in version 1]
|
||||
count of components (32 bits) [includes realm in version 1]
|
||||
realm (data)
|
||||
component1 (data)
|
||||
component2 (data)
|
||||
...
|
||||
|
||||
data ::=
|
||||
length (32 bits)
|
||||
value (length bytes)
|
||||
|
||||
There is no external framing on the default principal, so it must be
|
||||
parsed according to the above grammar in order to find the sequence of
|
||||
credentials which follows.
|
||||
|
||||
|
||||
.. _ccache_credential_format:
|
||||
|
||||
Credential format
|
||||
-----------------
|
||||
|
||||
The credential format uses the following informal grammar (referencing
|
||||
the ``principal`` and ``data`` types from the previous section)::
|
||||
|
||||
credential ::=
|
||||
client (principal)
|
||||
server (principal)
|
||||
keyblock (keyblock)
|
||||
authtime (32 bits)
|
||||
starttime (32 bits)
|
||||
endtime (32 bits)
|
||||
renew_till (32 bits)
|
||||
is_skey (1 byte, 0 or 1)
|
||||
ticket_flags (32 bits)
|
||||
addresses (addresses)
|
||||
authdata (authdata)
|
||||
ticket (data)
|
||||
second_ticket (data)
|
||||
|
||||
keyblock ::=
|
||||
enctype (16 bits) [repeated twice in version 3]
|
||||
data
|
||||
|
||||
addresses ::=
|
||||
count (32 bits)
|
||||
address1
|
||||
address2
|
||||
...
|
||||
|
||||
address ::=
|
||||
addrtype (16 bits)
|
||||
data
|
||||
|
||||
authdata ::=
|
||||
count (32 bits)
|
||||
authdata1
|
||||
authdata2
|
||||
...
|
||||
|
||||
authdata ::=
|
||||
ad_type (16 bits)
|
||||
data
|
||||
|
||||
There is no external framing on a marshalled credential, so it must be
|
||||
parsed according to the above grammar in order to find the next
|
||||
credential. There is also no count of credentials or marker at the
|
||||
end of the sequence of credentials; the sequence ends when the file
|
||||
ends.
|
||||
|
||||
|
||||
Credential cache configuration entries
|
||||
--------------------------------------
|
||||
|
||||
Configuration entries are encoded as credential entries. The client
|
||||
principal of the entry is the default principal of the cache. The
|
||||
server principal has the realm ``X-CACHECONF:`` and two or three
|
||||
components, the first of which is ``krb5_ccache_conf_data``. The
|
||||
server principal's second component is the configuration key. The
|
||||
third component, if it exists, is a principal to which the
|
||||
configuration key is associated. The configuration value is stored in
|
||||
the ticket field of the entry. All other entry fields are zeroed.
|
||||
|
||||
Programs using credential caches must be aware of configuration
|
||||
entries for several reasons:
|
||||
|
||||
* A program which displays the contents of a cache should not
|
||||
generally display configuration entries.
|
||||
|
||||
* The ticket field of a configuration entry is not (usually) a valid
|
||||
encoding of a Kerberos ticket. An implementation must not treat the
|
||||
cache file as malformed if it cannot decode the ticket field.
|
||||
|
||||
* Configuration entries have an endtime field of 0 and might therefore
|
||||
always be considered expired, but they should not be treated as
|
||||
unimportant as a result. For instance, a program which copies
|
||||
credentials from one cache to another should not omit configuration
|
||||
entries because of the endtime.
|
||||
|
||||
The following configuration keys are currently used in MIT krb5:
|
||||
|
||||
fast_avail
|
||||
The presence of this key with a non-empty value indicates that the
|
||||
KDC asserted support for FAST (see :rfc:`6113`) during the initial
|
||||
authentication, using the negotiation method described in
|
||||
:rfc:`6806` section 11. This key is not associated with any
|
||||
principal.
|
||||
|
||||
pa_config_data
|
||||
The value of this key contains a JSON object representation of
|
||||
parameters remembered by the preauthentication mechanism used
|
||||
during the initial authentication. These parameters may be used
|
||||
when refreshing credentials. This key is associated with the
|
||||
server principal of the initial authentication (usually the local
|
||||
krbtgt principal of the client realm).
|
||||
|
||||
pa_type
|
||||
The value of this key is the ASCII decimal representation of the
|
||||
preauth type number used during the initial authentication. This
|
||||
key is associated with the server principal of the initial
|
||||
authentication.
|
||||
|
||||
proxy_impersonator
|
||||
The presence of this key indicates that the cache is a synthetic
|
||||
delegated credential for use with S4U2Proxy. The value is the
|
||||
name of the intermediate service whose TGT can be used to make
|
||||
S4U2Proxy requests for target services. This key is not
|
||||
associated with any principal.
|
||||
|
||||
refresh_time
|
||||
The presence of this key indicates that the cache was acquired by
|
||||
the GSS mechanism using a client keytab. The value is the ASCII
|
||||
decimal representation of a timestamp at which the GSS mechanism
|
||||
should attempt to refresh the credential cache from the client
|
||||
keytab.
|
||||
|
||||
start_realm
|
||||
This key indicates the realm of the ticket-granting ticket to be
|
||||
used for TGS requests, when making a referrals request or
|
||||
beginning a cross-realm request. If it is not present, the client
|
||||
realm is used.
|
||||
97
crypto/krb5/doc/formats/cookie.rst
Normal file
97
crypto/krb5/doc/formats/cookie.rst
Normal file
|
|
@ -0,0 +1,97 @@
|
|||
KDC cookie format
|
||||
=================
|
||||
|
||||
:rfc:`6113` section 5.2 specifies a pa-data type PA-FX-COOKIE, which
|
||||
clients are required to reflect back to the KDC during
|
||||
pre-authentication. The MIT krb5 KDC uses the following formats for
|
||||
cookies.
|
||||
|
||||
|
||||
Trivial cookie (version 0)
|
||||
--------------------------
|
||||
|
||||
If there is no pre-authentication mechanism state information to save,
|
||||
a trivial cookie containing the value "MIT" is used. A trivial cookie
|
||||
is needed to indicate that the conversation can continue.
|
||||
|
||||
|
||||
Secure cookie (version 1)
|
||||
-------------------------
|
||||
|
||||
In release 1.14 and later, a secure cookie can be sent if there is any
|
||||
mechanism state to save for the next request. A secure cookie
|
||||
contains the concatenation of the following:
|
||||
|
||||
* the four bytes "MIT1"
|
||||
* a four-byte big-endian kvno value
|
||||
* an :rfc:`3961` ciphertext
|
||||
|
||||
The ciphertext is encrypted in the cookie key with key usage
|
||||
number 513. The cookie key is derived from a key in the local krbtgt
|
||||
principal entry for the realm (e.g. ``krbtgt/KRBTEST.COM@KRBTEST.COM``
|
||||
if the request is to the ``KRBTEST.COM`` realm). The first krbtgt key
|
||||
for the indicated kvno value is combined with the client principal as
|
||||
follows::
|
||||
|
||||
cookie-key <- random-to-key(PRF+(tgt-key, "COOKIE" | client-princ))
|
||||
|
||||
where **random-to-key** is the :rfc:`3961` random-to-key operation for
|
||||
the krbtgt key's encryption type, **PRF+** is defined in :rfc:`6113`,
|
||||
and ``|`` denotes concatenation. *client-princ* is the request client
|
||||
principal name with realm, marshalled according to :rfc:`1964` section
|
||||
2.1.1.
|
||||
|
||||
The plain text of the encrypted part of a cookie is the DER encoding
|
||||
of the following ASN.1 type::
|
||||
|
||||
SecureCookie ::= SEQUENCE {
|
||||
time INTEGER,
|
||||
data SEQUENCE OF PA-DATA,
|
||||
...
|
||||
}
|
||||
|
||||
The time field represents the cookie creation time; for brevity, it is
|
||||
encoded as an integer giving the POSIX timestamp rather than as an
|
||||
ASN.1 GeneralizedTime value. The data field contains one element for
|
||||
each pre-authentication type which requires saved state. For
|
||||
mechanisms which have separate request and reply types, the request
|
||||
type is used; this allows the KDC to determine whether a cookie is
|
||||
relevant to a request by comparing the request pa-data types to the
|
||||
cookie data types.
|
||||
|
||||
SPAKE cookie format (version 1)
|
||||
-------------------------------
|
||||
|
||||
Inside the SecureCookie wrapper, a data value of type 151 contains
|
||||
state for SPAKE pre-authentication. This data is the concatenation of
|
||||
the following:
|
||||
|
||||
* a two-byte big-endian version number with the value 1
|
||||
* a two-byte big-endian stage number
|
||||
* a four-byte big-endian group number
|
||||
* a four-byte big-endian length and data for the SPAKE value
|
||||
* a four-byte big-endian length and data for the transcript hash
|
||||
* zero or more second factor records, each consisting of:
|
||||
- a four-byte big-endian second-factor type
|
||||
- a four-byte big-endian length and data
|
||||
|
||||
The stage value is 0 if the cookie was sent with a challenge message.
|
||||
Otherwise it is 1 for the first encdata message sent by the KDC during
|
||||
an exchange, 2 for the second, etc..
|
||||
|
||||
The group value indicates the group number used in the SPAKE challenge.
|
||||
|
||||
For a stage-0 cookie, the SPAKE value is the KDC private key,
|
||||
represented in the scalar marshalling form of the group. For other
|
||||
cookies, the SPAKE value is the SPAKE result K, represented in the
|
||||
group element marshalling form.
|
||||
|
||||
For a stage-0 cookie, the transcript hash is the intermediate hash
|
||||
after updating with the client support message (if one was sent) and
|
||||
challenge. For other cookies it is the final hash.
|
||||
|
||||
For a stage-0 cookie, there may be any number of second-factor
|
||||
records, including none; a second-factor type need not create a state
|
||||
field if it does not need one, and no record is created for SF-NONE.
|
||||
For other cookies, there must be exactly one second-factor record
|
||||
corresponding to the factor type chosen by the client.
|
||||
19
crypto/krb5/doc/formats/freshness_token.rst
Normal file
19
crypto/krb5/doc/formats/freshness_token.rst
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
PKINIT freshness tokens
|
||||
=======================
|
||||
|
||||
:rfc:`8070` specifies a pa-data type PA_AS_FRESHNESS, which clients
|
||||
should reflect within signed PKINIT data to prove recent access to the
|
||||
client certificate private key. The contents of a freshness token are
|
||||
left to the KDC implementation. The MIT krb5 KDC uses the following
|
||||
format for freshness tokens (starting in release 1.17):
|
||||
|
||||
* a four-byte big-endian POSIX timestamp
|
||||
* a four-byte big-endian key version number
|
||||
* an :rfc:`3961` checksum, with no ASN.1 wrapper
|
||||
|
||||
The checksum is computed using the first key in the local krbtgt
|
||||
principal entry for the realm (e.g. ``krbtgt/KRBTEST.COM@KRBTEST.COM``
|
||||
if the request is to the ``KRBTEST.COM`` realm) of the indicated key
|
||||
version. The checksum type must be the mandatory checksum type for
|
||||
the encryption type of the krbtgt key. The key usage value for the
|
||||
checksum is 514.
|
||||
11
crypto/krb5/doc/formats/index.rst
Normal file
11
crypto/krb5/doc/formats/index.rst
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
Protocols and file formats
|
||||
==========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
ccache_file_format
|
||||
keytab_file_format
|
||||
rcache_file_format
|
||||
cookie
|
||||
freshness_token
|
||||
51
crypto/krb5/doc/formats/keytab_file_format.rst
Normal file
51
crypto/krb5/doc/formats/keytab_file_format.rst
Normal file
|
|
@ -0,0 +1,51 @@
|
|||
.. _keytab_file_format:
|
||||
|
||||
Keytab file format
|
||||
==================
|
||||
|
||||
There are two versions of the file format used by the FILE keytab
|
||||
type. The first byte of the file always has the value 5, and the
|
||||
value of the second byte contains the version number (1 or 2).
|
||||
Version 1 of the file format uses native byte order for integer
|
||||
representations. Version 2 always uses big-endian byte order.
|
||||
|
||||
After the two-byte version indicator, the file contains a sequence of
|
||||
signed 32-bit record lengths followed by key records or holes. A
|
||||
positive record length indicates a valid key entry whose size is equal
|
||||
to or less than the record length. A negative length indicates a
|
||||
zero-filled hole whose size is the inverse of the length. A length of
|
||||
0 indicates the end of the file.
|
||||
|
||||
|
||||
Key entry format
|
||||
----------------
|
||||
|
||||
A key entry may be smaller in size than the record length which
|
||||
precedes it, because it may have replaced a hole which is larger than
|
||||
the key entry. Key entries use the following informal grammar::
|
||||
|
||||
entry ::=
|
||||
principal
|
||||
timestamp (32 bits)
|
||||
key version (8 bits)
|
||||
enctype (16 bits)
|
||||
key length (16 bits)
|
||||
key contents
|
||||
key version (32 bits) [in release 1.14 and later]
|
||||
|
||||
principal ::=
|
||||
count of components (16 bits) [includes realm in version 1]
|
||||
realm (data)
|
||||
component1 (data)
|
||||
component2 (data)
|
||||
...
|
||||
name type (32 bits) [omitted in version 1]
|
||||
|
||||
data ::=
|
||||
length (16 bits)
|
||||
value (length bytes)
|
||||
|
||||
The 32-bit key version overrides the 8-bit key version. To determine
|
||||
if it is present, the implementation must check that at least 4 bytes
|
||||
remain in the record after the other fields are read, and that the
|
||||
value of the 32-bit integer contained in those bytes is non-zero.
|
||||
50
crypto/krb5/doc/formats/rcache_file_format.rst
Normal file
50
crypto/krb5/doc/formats/rcache_file_format.rst
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
Replay cache file format
|
||||
========================
|
||||
|
||||
This section documents the second version of the replay cache file
|
||||
format, used by the "file2" replay cache type (new in release 1.18).
|
||||
The first version of the file replay cache format is not documented.
|
||||
|
||||
All accesses to the replay cache file take place under an exclusive
|
||||
POSIX or Windows file lock, obtained when the file is opened and
|
||||
released when it is closed. Replay cache files are automatically
|
||||
created when first accessed.
|
||||
|
||||
For each store operation, a tag is derived from the checksum part of
|
||||
the :RFC:`3961` ciphertext of the authenticator. The checksum is
|
||||
coerced to a fixed length of 12 bytes, either through truncation or
|
||||
right-padding with zero bytes. A four-byte timestamp is appended to
|
||||
the tag to produce a total record length of 16 bytes.
|
||||
|
||||
Bytes 0 through 15 of the file contain a hash seed for the SipHash-2-4
|
||||
algorithm (siphash_); this field is populated with random bytes when
|
||||
the file is first created. All remaining bytes are divided into a
|
||||
series of expanding hash tables:
|
||||
|
||||
* Bytes 16-16383: hash table 1 (1023 slots)
|
||||
* Bytes 16384-49151: hash table 2 (2048 slots)
|
||||
* Bytes 49152-114687: hash table 3 (4096 slots)
|
||||
* ...
|
||||
|
||||
Only some hash tables will be present in the file at any specific
|
||||
time, and the final table may be only partially filled. Replay cache
|
||||
files may be sparse if the filesystem supports it.
|
||||
|
||||
For each table present in the file, the tag is hashed with SipHash-2-4
|
||||
using the seed recorded in the file. The first byte of the seed is
|
||||
incremented by one (modulo 256) for each table after the first. The
|
||||
resulting hash value is taken modulo one less than the table size
|
||||
(1022 for the first hash table, 2047 for the second) to produce the
|
||||
index. The record may be found at the slot given by the index or at
|
||||
the next slot.
|
||||
|
||||
All candidate locations for the record must be searched until a slot
|
||||
is found with a timestamp of zero (indicating a slot which has never
|
||||
been written to) or an offset is reached at or beyond the end of the
|
||||
file. Any candidate location with a timestamp value of zero, with a
|
||||
timestamp value less than the current time minus clockskew, or at or
|
||||
beyond the end of the file is available for writing. When all
|
||||
candidate locations have been searched without finding a match, the
|
||||
new entry is written to the earliest candidate available for writing.
|
||||
|
||||
.. _siphash: https://131002.net/siphash/siphash.pdf
|
||||
4
crypto/krb5/doc/html/.buildinfo
Normal file
4
crypto/krb5/doc/html/.buildinfo
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
# Sphinx build info version 1
|
||||
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
|
||||
config: 9ca503a4e24138fa47d4451ee9426bb5
|
||||
tags: 645f666f9bcd5a90fca523b33c5a78b7
|
||||
35
crypto/krb5/doc/html/_sources/about.rst.txt
Normal file
35
crypto/krb5/doc/html/_sources/about.rst.txt
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
Contributing to the MIT Kerberos Documentation
|
||||
==============================================
|
||||
|
||||
We are looking for documentation writers and editors who could contribute
|
||||
towards improving the MIT KC documentation content. If you are an experienced
|
||||
Kerberos developer and/or administrator, please consider sharing your knowledge
|
||||
and experience with the Kerberos Community. You can suggest your own topic or
|
||||
write about any of the topics listed
|
||||
`here <https://k5wiki.kerberos.org/wiki/Projects/Documentation_Tasks>`__.
|
||||
|
||||
If you have any questions, comments, or suggestions on the existing documents,
|
||||
please send your feedback via email to krb5-bugs@mit.edu. The HTML version of
|
||||
this documentation has a "FEEDBACK" link to the krb5-bugs@mit.edu email
|
||||
address with a pre-constructed subject line.
|
||||
|
||||
|
||||
Background
|
||||
----------
|
||||
|
||||
Starting with release 1.11, the Kerberos documentation set is
|
||||
unified in a central form. Man pages, HTML documentation, and PDF
|
||||
documents are compiled from reStructuredText sources, and the application
|
||||
developer documentation incorporates Doxygen markup from the source
|
||||
tree. This project was undertaken along the outline described
|
||||
`here <https://k5wiki.kerberos.org/wiki/Projects/Kerberos_Documentation>`__.
|
||||
|
||||
Previous versions of Kerberos 5 attempted to maintain separate documentation
|
||||
in the texinfo format, with separate groff manual pages. Having the API
|
||||
documentation disjoint from the source code implementing that API
|
||||
resulted in the documentation becoming stale, and over time the documentation
|
||||
ceased to match reality. With a fresh start and a source format that is
|
||||
easier to use and maintain, reStructuredText-based documents should provide
|
||||
an improved experience for the user. Consolidating all the documentation
|
||||
formats into a single source document makes the documentation set easier
|
||||
to maintain.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
Administration programs
|
||||
========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
kadmin_local.rst
|
||||
kadmind.rst
|
||||
kdb5_util.rst
|
||||
kdb5_ldap_util.rst
|
||||
krb5kdc.rst
|
||||
kprop.rst
|
||||
kpropd.rst
|
||||
kproplog.rst
|
||||
ktutil.rst
|
||||
k5srvutil.rst
|
||||
sserver.rst
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
.. _k5srvutil(1):
|
||||
|
||||
k5srvutil
|
||||
=========
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**k5srvutil** *operation*
|
||||
[**-i**]
|
||||
[**-f** *filename*]
|
||||
[**-e** *keysalts*]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
k5srvutil allows an administrator to list keys currently in
|
||||
a keytab, to obtain new keys for a principal currently in a keytab,
|
||||
or to delete non-current keys from a keytab.
|
||||
|
||||
*operation* must be one of the following:
|
||||
|
||||
**list**
|
||||
Lists the keys in a keytab, showing version number and principal
|
||||
name.
|
||||
|
||||
**change**
|
||||
Uses the kadmin protocol to update the keys in the Kerberos
|
||||
database to new randomly-generated keys, and updates the keys in
|
||||
the keytab to match. If a key's version number doesn't match the
|
||||
version number stored in the Kerberos server's database, then the
|
||||
operation will fail. If the **-i** flag is given, k5srvutil will
|
||||
prompt for confirmation before changing each key. If the **-k**
|
||||
option is given, the old and new keys will be displayed.
|
||||
Ordinarily, keys will be generated with the default encryption
|
||||
types and key salts. This can be overridden with the **-e**
|
||||
option. Old keys are retained in the keytab so that existing
|
||||
tickets continue to work, but **delold** should be used after
|
||||
such tickets expire, to prevent attacks against the old keys.
|
||||
|
||||
**delold**
|
||||
Deletes keys that are not the most recent version from the keytab.
|
||||
This operation should be used some time after a change operation
|
||||
to remove old keys, after existing tickets issued for the service
|
||||
have expired. If the **-i** flag is given, then k5srvutil will
|
||||
prompt for confirmation for each principal.
|
||||
|
||||
**delete**
|
||||
Deletes particular keys in the keytab, interactively prompting for
|
||||
each key.
|
||||
|
||||
In all cases, the default keytab is used unless this is overridden by
|
||||
the **-f** option.
|
||||
|
||||
k5srvutil uses the :ref:`kadmin(1)` program to edit the keytab in
|
||||
place.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kadmin(1)`, :ref:`ktutil(1)`, :ref:`kerberos(7)`
|
||||
|
|
@ -0,0 +1,985 @@
|
|||
.. _kadmin(1):
|
||||
|
||||
kadmin
|
||||
======
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
.. _kadmin_synopsis:
|
||||
|
||||
**kadmin**
|
||||
[**-O**\|\ **-N**]
|
||||
[**-r** *realm*]
|
||||
[**-p** *principal*]
|
||||
[**-q** *query*]
|
||||
[[**-c** *cache_name*]\|[**-k** [**-t** *keytab*]]\|\ **-n**]
|
||||
[**-w** *password*]
|
||||
[**-s** *admin_server*\ [:*port*]]
|
||||
[command args...]
|
||||
|
||||
**kadmin.local**
|
||||
[**-r** *realm*]
|
||||
[**-p** *principal*]
|
||||
[**-q** *query*]
|
||||
[**-d** *dbname*]
|
||||
[**-e** *enc*:*salt* ...]
|
||||
[**-m**]
|
||||
[**-x** *db_args*]
|
||||
[command args...]
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
kadmin and kadmin.local are command-line interfaces to the Kerberos V5
|
||||
administration system. They provide nearly identical functionalities;
|
||||
the difference is that kadmin.local directly accesses the KDC
|
||||
database, while kadmin performs operations using :ref:`kadmind(8)`.
|
||||
Except as explicitly noted otherwise, this man page will use "kadmin"
|
||||
to refer to both versions. kadmin provides for the maintenance of
|
||||
Kerberos principals, password policies, and service key tables
|
||||
(keytabs).
|
||||
|
||||
The remote kadmin client uses Kerberos to authenticate to kadmind
|
||||
using the service principal ``kadmin/admin`` or ``kadmin/ADMINHOST``
|
||||
(where *ADMINHOST* is the fully-qualified hostname of the admin
|
||||
server). If the credentials cache contains a ticket for one of these
|
||||
principals, and the **-c** credentials_cache option is specified, that
|
||||
ticket is used to authenticate to kadmind. Otherwise, the **-p** and
|
||||
**-k** options are used to specify the client Kerberos principal name
|
||||
used to authenticate. Once kadmin has determined the principal name,
|
||||
it requests a service ticket from the KDC, and uses that service
|
||||
ticket to authenticate to kadmind.
|
||||
|
||||
Since kadmin.local directly accesses the KDC database, it usually must
|
||||
be run directly on the primary KDC with sufficient permissions to read
|
||||
the KDC database. If the KDC database uses the LDAP database module,
|
||||
kadmin.local can be run on any host which can access the LDAP server.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
.. _kadmin_options:
|
||||
|
||||
**-r** *realm*
|
||||
Use *realm* as the default database realm.
|
||||
|
||||
**-p** *principal*
|
||||
Use *principal* to authenticate. Otherwise, kadmin will append
|
||||
``/admin`` to the primary principal name of the default ccache,
|
||||
the value of the **USER** environment variable, or the username as
|
||||
obtained with getpwuid, in order of preference.
|
||||
|
||||
**-k**
|
||||
Use a keytab to decrypt the KDC response instead of prompting for
|
||||
a password. In this case, the default principal will be
|
||||
``host/hostname``. If there is no keytab specified with the
|
||||
**-t** option, then the default keytab will be used.
|
||||
|
||||
**-t** *keytab*
|
||||
Use *keytab* to decrypt the KDC response. This can only be used
|
||||
with the **-k** option.
|
||||
|
||||
**-n**
|
||||
Requests anonymous processing. Two types of anonymous principals
|
||||
are supported. For fully anonymous Kerberos, configure PKINIT on
|
||||
the KDC and configure **pkinit_anchors** in the client's
|
||||
:ref:`krb5.conf(5)`. Then use the **-n** option with a principal
|
||||
of the form ``@REALM`` (an empty principal name followed by the
|
||||
at-sign and a realm name). If permitted by the KDC, an anonymous
|
||||
ticket will be returned. A second form of anonymous tickets is
|
||||
supported; these realm-exposed tickets hide the identity of the
|
||||
client but not the client's realm. For this mode, use ``kinit
|
||||
-n`` with a normal principal name. If supported by the KDC, the
|
||||
principal (but not realm) will be replaced by the anonymous
|
||||
principal. As of release 1.8, the MIT Kerberos KDC only supports
|
||||
fully anonymous operation.
|
||||
|
||||
**-c** *credentials_cache*
|
||||
Use *credentials_cache* as the credentials cache. The cache
|
||||
should contain a service ticket for the ``kadmin/admin`` or
|
||||
``kadmin/ADMINHOST`` (where *ADMINHOST* is the fully-qualified
|
||||
hostname of the admin server) service; it can be acquired with the
|
||||
:ref:`kinit(1)` program. If this option is not specified, kadmin
|
||||
requests a new service ticket from the KDC, and stores it in its
|
||||
own temporary ccache.
|
||||
|
||||
**-w** *password*
|
||||
Use *password* instead of prompting for one. Use this option with
|
||||
care, as it may expose the password to other users on the system
|
||||
via the process list.
|
||||
|
||||
**-q** *query*
|
||||
Perform the specified query and then exit.
|
||||
|
||||
**-d** *dbname*
|
||||
Specifies the name of the KDC database. This option does not
|
||||
apply to the LDAP database module.
|
||||
|
||||
**-s** *admin_server*\ [:*port*]
|
||||
Specifies the admin server which kadmin should contact.
|
||||
|
||||
**-m**
|
||||
If using kadmin.local, prompt for the database master password
|
||||
instead of reading it from a stash file.
|
||||
|
||||
**-e** "*enc*:*salt* ..."
|
||||
Sets the keysalt list to be used for any new keys created. See
|
||||
:ref:`Keysalt_lists` in :ref:`kdc.conf(5)` for a list of possible
|
||||
values.
|
||||
|
||||
**-O**
|
||||
Force use of old AUTH_GSSAPI authentication flavor.
|
||||
|
||||
**-N**
|
||||
Prevent fallback to AUTH_GSSAPI authentication flavor.
|
||||
|
||||
**-x** *db_args*
|
||||
Specifies the database specific arguments. See the next section
|
||||
for supported options.
|
||||
|
||||
Starting with release 1.14, if any command-line arguments remain after
|
||||
the options, they will be treated as a single query to be executed.
|
||||
This mode of operation is intended for scripts and behaves differently
|
||||
from the interactive mode in several respects:
|
||||
|
||||
* Query arguments are split by the shell, not by kadmin.
|
||||
* Informational and warning messages are suppressed. Error messages
|
||||
and query output (e.g. for **get_principal**) will still be
|
||||
displayed.
|
||||
* Confirmation prompts are disabled (as if **-force** was given).
|
||||
Password prompts will still be issued as required.
|
||||
* The exit status will be non-zero if the query fails.
|
||||
|
||||
The **-q** option does not carry these behavior differences; the query
|
||||
will be processed as if it was entered interactively. The **-q**
|
||||
option cannot be used in combination with a query in the remaining
|
||||
arguments.
|
||||
|
||||
.. _dboptions:
|
||||
|
||||
DATABASE OPTIONS
|
||||
----------------
|
||||
|
||||
Database options can be used to override database-specific defaults.
|
||||
Supported options for the DB2 module are:
|
||||
|
||||
**-x dbname=**\ \*filename*
|
||||
Specifies the base filename of the DB2 database.
|
||||
|
||||
**-x lockiter**
|
||||
Make iteration operations hold the lock for the duration of
|
||||
the entire operation, rather than temporarily releasing the
|
||||
lock while handling each principal. This is the default
|
||||
behavior, but this option exists to allow command line
|
||||
override of a [dbmodules] setting. First introduced in
|
||||
release 1.13.
|
||||
|
||||
**-x unlockiter**
|
||||
Make iteration operations unlock the database for each
|
||||
principal, instead of holding the lock for the duration of the
|
||||
entire operation. First introduced in release 1.13.
|
||||
|
||||
Supported options for the LDAP module are:
|
||||
|
||||
**-x host=**\ *ldapuri*
|
||||
Specifies the LDAP server to connect to by a LDAP URI.
|
||||
|
||||
**-x binddn=**\ *bind_dn*
|
||||
Specifies the DN used to bind to the LDAP server.
|
||||
|
||||
**-x bindpwd=**\ *password*
|
||||
Specifies the password or SASL secret used to bind to the LDAP
|
||||
server. Using this option may expose the password to other
|
||||
users on the system via the process list; to avoid this,
|
||||
instead stash the password using the **stashsrvpw** command of
|
||||
:ref:`kdb5_ldap_util(8)`.
|
||||
|
||||
**-x sasl_mech=**\ *mechanism*
|
||||
Specifies the SASL mechanism used to bind to the LDAP server.
|
||||
The bind DN is ignored if a SASL mechanism is used. New in
|
||||
release 1.13.
|
||||
|
||||
**-x sasl_authcid=**\ *name*
|
||||
Specifies the authentication name used when binding to the
|
||||
LDAP server with a SASL mechanism, if the mechanism requires
|
||||
one. New in release 1.13.
|
||||
|
||||
**-x sasl_authzid=**\ *name*
|
||||
Specifies the authorization name used when binding to the LDAP
|
||||
server with a SASL mechanism. New in release 1.13.
|
||||
|
||||
**-x sasl_realm=**\ *realm*
|
||||
Specifies the realm used when binding to the LDAP server with
|
||||
a SASL mechanism, if the mechanism uses one. New in release
|
||||
1.13.
|
||||
|
||||
**-x debug=**\ *level*
|
||||
sets the OpenLDAP client library debug level. *level* is an
|
||||
integer to be interpreted by the library. Debugging messages
|
||||
are printed to standard error. New in release 1.12.
|
||||
|
||||
|
||||
COMMANDS
|
||||
--------
|
||||
|
||||
When using the remote client, available commands may be restricted
|
||||
according to the privileges specified in the :ref:`kadm5.acl(5)` file
|
||||
on the admin server.
|
||||
|
||||
.. _add_principal:
|
||||
|
||||
add_principal
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**add_principal** [*options*] *newprinc*
|
||||
|
||||
Creates the principal *newprinc*, prompting twice for a password. If
|
||||
no password policy is specified with the **-policy** option, and the
|
||||
policy named ``default`` is assigned to the principal if it exists.
|
||||
However, creating a policy named ``default`` will not automatically
|
||||
assign this policy to previously existing principals. This policy
|
||||
assignment can be suppressed with the **-clearpolicy** option.
|
||||
|
||||
This command requires the **add** privilege.
|
||||
|
||||
Aliases: **addprinc**, **ank**
|
||||
|
||||
Options:
|
||||
|
||||
**-expire** *expdate*
|
||||
(:ref:`getdate` string) The expiration date of the principal.
|
||||
|
||||
**-pwexpire** *pwexpdate*
|
||||
(:ref:`getdate` string) The password expiration date.
|
||||
|
||||
**-maxlife** *maxlife*
|
||||
(:ref:`duration` or :ref:`getdate` string) The maximum ticket life
|
||||
for the principal.
|
||||
|
||||
**-maxrenewlife** *maxrenewlife*
|
||||
(:ref:`duration` or :ref:`getdate` string) The maximum renewable
|
||||
life of tickets for the principal.
|
||||
|
||||
**-kvno** *kvno*
|
||||
The initial key version number.
|
||||
|
||||
**-policy** *policy*
|
||||
The password policy used by this principal. If not specified, the
|
||||
policy ``default`` is used if it exists (unless **-clearpolicy**
|
||||
is specified).
|
||||
|
||||
**-clearpolicy**
|
||||
Prevents any policy from being assigned when **-policy** is not
|
||||
specified.
|
||||
|
||||
{-\|+}\ **allow_postdated**
|
||||
**-allow_postdated** prohibits this principal from obtaining
|
||||
postdated tickets. **+allow_postdated** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_forwardable**
|
||||
**-allow_forwardable** prohibits this principal from obtaining
|
||||
forwardable tickets. **+allow_forwardable** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_renewable**
|
||||
**-allow_renewable** prohibits this principal from obtaining
|
||||
renewable tickets. **+allow_renewable** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_proxiable**
|
||||
**-allow_proxiable** prohibits this principal from obtaining
|
||||
proxiable tickets. **+allow_proxiable** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_dup_skey**
|
||||
**-allow_dup_skey** disables user-to-user authentication for this
|
||||
principal by prohibiting others from obtaining a service ticket
|
||||
encrypted in this principal's TGT session key.
|
||||
**+allow_dup_skey** clears this flag.
|
||||
|
||||
{-\|+}\ **requires_preauth**
|
||||
**+requires_preauth** requires this principal to preauthenticate
|
||||
before being allowed to kinit. **-requires_preauth** clears this
|
||||
flag. When **+requires_preauth** is set on a service principal,
|
||||
the KDC will only issue service tickets for that service principal
|
||||
if the client's initial authentication was performed using
|
||||
preauthentication.
|
||||
|
||||
{-\|+}\ **requires_hwauth**
|
||||
**+requires_hwauth** requires this principal to preauthenticate
|
||||
using a hardware device before being allowed to kinit.
|
||||
**-requires_hwauth** clears this flag. When **+requires_hwauth** is
|
||||
set on a service principal, the KDC will only issue service tickets
|
||||
for that service principal if the client's initial authentication was
|
||||
performed using a hardware device to preauthenticate.
|
||||
|
||||
{-\|+}\ **ok_as_delegate**
|
||||
**+ok_as_delegate** sets the **okay as delegate** flag on tickets
|
||||
issued with this principal as the service. Clients may use this
|
||||
flag as a hint that credentials should be delegated when
|
||||
authenticating to the service. **-ok_as_delegate** clears this
|
||||
flag.
|
||||
|
||||
{-\|+}\ **allow_svr**
|
||||
**-allow_svr** prohibits the issuance of service tickets for this
|
||||
principal. In release 1.17 and later, user-to-user service
|
||||
tickets are still allowed unless the **-allow_dup_skey** flag is
|
||||
also set. **+allow_svr** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_tgs_req**
|
||||
**-allow_tgs_req** specifies that a Ticket-Granting Service (TGS)
|
||||
request for a service ticket for this principal is not permitted.
|
||||
**+allow_tgs_req** clears this flag.
|
||||
|
||||
{-\|+}\ **allow_tix**
|
||||
**-allow_tix** forbids the issuance of any tickets for this
|
||||
principal. **+allow_tix** clears this flag.
|
||||
|
||||
{-\|+}\ **needchange**
|
||||
**+needchange** forces a password change on the next initial
|
||||
authentication to this principal. **-needchange** clears this
|
||||
flag.
|
||||
|
||||
{-\|+}\ **password_changing_service**
|
||||
**+password_changing_service** marks this principal as a password
|
||||
change service principal.
|
||||
|
||||
{-\|+}\ **ok_to_auth_as_delegate**
|
||||
**+ok_to_auth_as_delegate** allows this principal to acquire
|
||||
forwardable tickets to itself from arbitrary users, for use with
|
||||
constrained delegation.
|
||||
|
||||
{-\|+}\ **no_auth_data_required**
|
||||
**+no_auth_data_required** prevents PAC or AD-SIGNEDPATH data from
|
||||
being added to service tickets for the principal.
|
||||
|
||||
{-\|+}\ **lockdown_keys**
|
||||
**+lockdown_keys** prevents keys for this principal from leaving
|
||||
the KDC via kadmind. The chpass and extract operations are denied
|
||||
for a principal with this attribute. The chrand operation is
|
||||
allowed, but will not return the new keys. The delete and rename
|
||||
operations are also denied if this attribute is set, in order to
|
||||
prevent a malicious administrator from replacing principals like
|
||||
krbtgt/* or kadmin/* with new principals without the attribute.
|
||||
This attribute can be set via the network protocol, but can only
|
||||
be removed using kadmin.local.
|
||||
|
||||
**-randkey**
|
||||
Sets the key of the principal to a random value.
|
||||
|
||||
**-nokey**
|
||||
Causes the principal to be created with no key. New in release
|
||||
1.12.
|
||||
|
||||
**-pw** *password*
|
||||
Sets the password of the principal to the specified string and
|
||||
does not prompt for a password. Note: using this option in a
|
||||
shell script may expose the password to other users on the system
|
||||
via the process list.
|
||||
|
||||
**-e** *enc*:*salt*,...
|
||||
Uses the specified keysalt list for setting the keys of the
|
||||
principal. See :ref:`Keysalt_lists` in :ref:`kdc.conf(5)` for a
|
||||
list of possible values.
|
||||
|
||||
**-x** *db_princ_args*
|
||||
Indicates database-specific options. The options for the LDAP
|
||||
database module are:
|
||||
|
||||
**-x dn=**\ *dn*
|
||||
Specifies the LDAP object that will contain the Kerberos
|
||||
principal being created.
|
||||
|
||||
**-x linkdn=**\ *dn*
|
||||
Specifies the LDAP object to which the newly created Kerberos
|
||||
principal object will point.
|
||||
|
||||
**-x containerdn=**\ *container_dn*
|
||||
Specifies the container object under which the Kerberos
|
||||
principal is to be created.
|
||||
|
||||
**-x tktpolicy=**\ *policy*
|
||||
Associates a ticket policy to the Kerberos principal.
|
||||
|
||||
.. note::
|
||||
|
||||
- The **containerdn** and **linkdn** options cannot be
|
||||
specified with the **dn** option.
|
||||
- If the *dn* or *containerdn* options are not specified while
|
||||
adding the principal, the principals are created under the
|
||||
principal container configured in the realm or the realm
|
||||
container.
|
||||
- *dn* and *containerdn* should be within the subtrees or
|
||||
principal container configured in the realm.
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: addprinc jennifer
|
||||
No policy specified for "jennifer@ATHENA.MIT.EDU";
|
||||
defaulting to no policy.
|
||||
Enter password for principal jennifer@ATHENA.MIT.EDU:
|
||||
Re-enter password for principal jennifer@ATHENA.MIT.EDU:
|
||||
Principal "jennifer@ATHENA.MIT.EDU" created.
|
||||
kadmin:
|
||||
|
||||
.. _modify_principal:
|
||||
|
||||
modify_principal
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
**modify_principal** [*options*] *principal*
|
||||
|
||||
Modifies the specified principal, changing the fields as specified.
|
||||
The options to **add_principal** also apply to this command, except
|
||||
for the **-randkey**, **-pw**, and **-e** options. In addition, the
|
||||
option **-clearpolicy** will clear the current policy of a principal.
|
||||
|
||||
This command requires the *modify* privilege.
|
||||
|
||||
Alias: **modprinc**
|
||||
|
||||
Options (in addition to the **addprinc** options):
|
||||
|
||||
**-unlock**
|
||||
Unlocks a locked principal (one which has received too many failed
|
||||
authentication attempts without enough time between them according
|
||||
to its password policy) so that it can successfully authenticate.
|
||||
|
||||
.. _rename_principal:
|
||||
|
||||
rename_principal
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
**rename_principal** [**-force**] *old_principal* *new_principal*
|
||||
|
||||
Renames the specified *old_principal* to *new_principal*. This
|
||||
command prompts for confirmation, unless the **-force** option is
|
||||
given.
|
||||
|
||||
This command requires the **add** and **delete** privileges.
|
||||
|
||||
Alias: **renprinc**
|
||||
|
||||
.. _delete_principal:
|
||||
|
||||
delete_principal
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
**delete_principal** [**-force**] *principal*
|
||||
|
||||
Deletes the specified *principal* from the database. This command
|
||||
prompts for deletion, unless the **-force** option is given.
|
||||
|
||||
This command requires the **delete** privilege.
|
||||
|
||||
Alias: **delprinc**
|
||||
|
||||
.. _change_password:
|
||||
|
||||
change_password
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
**change_password** [*options*] *principal*
|
||||
|
||||
Changes the password of *principal*. Prompts for a new password if
|
||||
neither **-randkey** or **-pw** is specified.
|
||||
|
||||
This command requires the **changepw** privilege, or that the
|
||||
principal running the program is the same as the principal being
|
||||
changed.
|
||||
|
||||
Alias: **cpw**
|
||||
|
||||
The following options are available:
|
||||
|
||||
**-randkey**
|
||||
Sets the key of the principal to a random value.
|
||||
|
||||
**-pw** *password*
|
||||
Set the password to the specified string. Using this option in a
|
||||
script may expose the password to other users on the system via
|
||||
the process list.
|
||||
|
||||
**-e** *enc*:*salt*,...
|
||||
Uses the specified keysalt list for setting the keys of the
|
||||
principal. See :ref:`Keysalt_lists` in :ref:`kdc.conf(5)` for a
|
||||
list of possible values.
|
||||
|
||||
**-keepold**
|
||||
Keeps the existing keys in the database. This flag is usually not
|
||||
necessary except perhaps for ``krbtgt`` principals.
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: cpw systest
|
||||
Enter password for principal systest@BLEEP.COM:
|
||||
Re-enter password for principal systest@BLEEP.COM:
|
||||
Password for systest@BLEEP.COM changed.
|
||||
kadmin:
|
||||
|
||||
.. _purgekeys:
|
||||
|
||||
purgekeys
|
||||
~~~~~~~~~
|
||||
|
||||
**purgekeys** [**-all**\|\ **-keepkvno** *oldest_kvno_to_keep*] *principal*
|
||||
|
||||
Purges previously retained old keys (e.g., from **change_password
|
||||
-keepold**) from *principal*. If **-keepkvno** is specified, then
|
||||
only purges keys with kvnos lower than *oldest_kvno_to_keep*. If
|
||||
**-all** is specified, then all keys are purged. The **-all** option
|
||||
is new in release 1.12.
|
||||
|
||||
This command requires the **modify** privilege.
|
||||
|
||||
.. _get_principal:
|
||||
|
||||
get_principal
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**get_principal** [**-terse**] *principal*
|
||||
|
||||
Gets the attributes of principal. With the **-terse** option, outputs
|
||||
fields as quoted tab-separated strings.
|
||||
|
||||
This command requires the **inquire** privilege, or that the principal
|
||||
running the the program to be the same as the one being listed.
|
||||
|
||||
Alias: **getprinc**
|
||||
|
||||
Examples::
|
||||
|
||||
kadmin: getprinc tlyu/admin
|
||||
Principal: tlyu/admin@BLEEP.COM
|
||||
Expiration date: [never]
|
||||
Last password change: Mon Aug 12 14:16:47 EDT 1996
|
||||
Password expiration date: [never]
|
||||
Maximum ticket life: 0 days 10:00:00
|
||||
Maximum renewable life: 7 days 00:00:00
|
||||
Last modified: Mon Aug 12 14:16:47 EDT 1996 (bjaspan/admin@BLEEP.COM)
|
||||
Last successful authentication: [never]
|
||||
Last failed authentication: [never]
|
||||
Failed password attempts: 0
|
||||
Number of keys: 1
|
||||
Key: vno 1, aes256-cts-hmac-sha384-192
|
||||
MKey: vno 1
|
||||
Attributes:
|
||||
Policy: [none]
|
||||
|
||||
kadmin: getprinc -terse systest
|
||||
systest@BLEEP.COM 3 86400 604800 1
|
||||
785926535 753241234 785900000
|
||||
tlyu/admin@BLEEP.COM 786100034 0 0
|
||||
kadmin:
|
||||
|
||||
.. _list_principals:
|
||||
|
||||
list_principals
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
**list_principals** [*expression*]
|
||||
|
||||
Retrieves all or some principal names. *expression* is a shell-style
|
||||
glob expression that can contain the wild-card characters ``?``,
|
||||
``*``, and ``[]``. All principal names matching the expression are
|
||||
printed. If no expression is provided, all principal names are
|
||||
printed. If the expression does not contain an ``@`` character, an
|
||||
``@`` character followed by the local realm is appended to the
|
||||
expression.
|
||||
|
||||
This command requires the **list** privilege.
|
||||
|
||||
Alias: **listprincs**, **get_principals**, **getprincs**
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: listprincs test*
|
||||
test3@SECURE-TEST.OV.COM
|
||||
test2@SECURE-TEST.OV.COM
|
||||
test1@SECURE-TEST.OV.COM
|
||||
testuser@SECURE-TEST.OV.COM
|
||||
kadmin:
|
||||
|
||||
.. _get_strings:
|
||||
|
||||
get_strings
|
||||
~~~~~~~~~~~
|
||||
|
||||
**get_strings** *principal*
|
||||
|
||||
Displays string attributes on *principal*.
|
||||
|
||||
This command requires the **inquire** privilege.
|
||||
|
||||
Alias: **getstrs**
|
||||
|
||||
.. _set_string:
|
||||
|
||||
set_string
|
||||
~~~~~~~~~~
|
||||
|
||||
**set_string** *principal* *name* *value*
|
||||
|
||||
Sets a string attribute on *principal*. String attributes are used to
|
||||
supply per-principal configuration to the KDC and some KDC plugin
|
||||
modules. The following string attribute names are recognized by the
|
||||
KDC:
|
||||
|
||||
**require_auth**
|
||||
Specifies an authentication indicator which is required to
|
||||
authenticate to the principal as a service. Multiple indicators
|
||||
can be specified, separated by spaces; in this case any of the
|
||||
specified indicators will be accepted. (New in release 1.14.)
|
||||
|
||||
**session_enctypes**
|
||||
Specifies the encryption types supported for session keys when the
|
||||
principal is authenticated to as a server. See
|
||||
:ref:`Encryption_types` in :ref:`kdc.conf(5)` for a list of the
|
||||
accepted values.
|
||||
|
||||
**otp**
|
||||
Enables One Time Passwords (OTP) preauthentication for a client
|
||||
*principal*. The *value* is a JSON string representing an array
|
||||
of objects, each having optional ``type`` and ``username`` fields.
|
||||
|
||||
**pkinit_cert_match**
|
||||
Specifies a matching expression that defines the certificate
|
||||
attributes required for the client certificate used by the
|
||||
principal during PKINIT authentication. The matching expression
|
||||
is in the same format as those used by the **pkinit_cert_match**
|
||||
option in :ref:`krb5.conf(5)`. (New in release 1.16.)
|
||||
|
||||
**pac_privsvr_enctype**
|
||||
Forces the encryption type of the PAC KDC checksum buffers to the
|
||||
specified encryption type for tickets issued to this server, by
|
||||
deriving a key from the local krbtgt key if it is of a different
|
||||
encryption type. It may be necessary to set this value to
|
||||
"aes256-sha1" on the cross-realm krbtgt entry for an Active
|
||||
Directory realm when using aes-sha2 keys on the local krbtgt
|
||||
entry.
|
||||
|
||||
This command requires the **modify** privilege.
|
||||
|
||||
Alias: **setstr**
|
||||
|
||||
Example::
|
||||
|
||||
set_string host/foo.mit.edu session_enctypes aes128-cts
|
||||
set_string user@FOO.COM otp "[{""type"":""hotp"",""username"":""al""}]"
|
||||
|
||||
.. _del_string:
|
||||
|
||||
del_string
|
||||
~~~~~~~~~~
|
||||
|
||||
**del_string** *principal* *key*
|
||||
|
||||
Deletes a string attribute from *principal*.
|
||||
|
||||
This command requires the **delete** privilege.
|
||||
|
||||
Alias: **delstr**
|
||||
|
||||
.. _add_policy:
|
||||
|
||||
add_policy
|
||||
~~~~~~~~~~
|
||||
|
||||
**add_policy** [*options*] *policy*
|
||||
|
||||
Adds a password policy named *policy* to the database.
|
||||
|
||||
This command requires the **add** privilege.
|
||||
|
||||
Alias: **addpol**
|
||||
|
||||
The following options are available:
|
||||
|
||||
**-maxlife** *time*
|
||||
(:ref:`duration` or :ref:`getdate` string) Sets the maximum
|
||||
lifetime of a password.
|
||||
|
||||
**-minlife** *time*
|
||||
(:ref:`duration` or :ref:`getdate` string) Sets the minimum
|
||||
lifetime of a password.
|
||||
|
||||
**-minlength** *length*
|
||||
Sets the minimum length of a password.
|
||||
|
||||
**-minclasses** *number*
|
||||
Sets the minimum number of character classes required in a
|
||||
password. The five character classes are lower case, upper case,
|
||||
numbers, punctuation, and whitespace/unprintable characters.
|
||||
|
||||
**-history** *number*
|
||||
Sets the number of past keys kept for a principal. This option is
|
||||
not supported with the LDAP KDC database module.
|
||||
|
||||
.. _policy_maxfailure:
|
||||
|
||||
**-maxfailure** *maxnumber*
|
||||
Sets the number of authentication failures before the principal is
|
||||
locked. Authentication failures are only tracked for principals
|
||||
which require preauthentication. The counter of failed attempts
|
||||
resets to 0 after a successful attempt to authenticate. A
|
||||
*maxnumber* value of 0 (the default) disables lockout.
|
||||
|
||||
.. _policy_failurecountinterval:
|
||||
|
||||
**-failurecountinterval** *failuretime*
|
||||
(:ref:`duration` or :ref:`getdate` string) Sets the allowable time
|
||||
between authentication failures. If an authentication failure
|
||||
happens after *failuretime* has elapsed since the previous
|
||||
failure, the number of authentication failures is reset to 1. A
|
||||
*failuretime* value of 0 (the default) means forever.
|
||||
|
||||
.. _policy_lockoutduration:
|
||||
|
||||
**-lockoutduration** *lockouttime*
|
||||
(:ref:`duration` or :ref:`getdate` string) Sets the duration for
|
||||
which the principal is locked from authenticating if too many
|
||||
authentication failures occur without the specified failure count
|
||||
interval elapsing. A duration of 0 (the default) means the
|
||||
principal remains locked out until it is administratively unlocked
|
||||
with ``modprinc -unlock``.
|
||||
|
||||
**-allowedkeysalts**
|
||||
Specifies the key/salt tuples supported for long-term keys when
|
||||
setting or changing a principal's password/keys. See
|
||||
:ref:`Keysalt_lists` in :ref:`kdc.conf(5)` for a list of the
|
||||
accepted values, but note that key/salt tuples must be separated
|
||||
with commas (',') only. To clear the allowed key/salt policy use
|
||||
a value of '-'.
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: add_policy -maxlife "2 days" -minlength 5 guests
|
||||
kadmin:
|
||||
|
||||
.. _modify_policy:
|
||||
|
||||
modify_policy
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**modify_policy** [*options*] *policy*
|
||||
|
||||
Modifies the password policy named *policy*. Options are as described
|
||||
for **add_policy**.
|
||||
|
||||
This command requires the **modify** privilege.
|
||||
|
||||
Alias: **modpol**
|
||||
|
||||
.. _delete_policy:
|
||||
|
||||
delete_policy
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**delete_policy** [**-force**] *policy*
|
||||
|
||||
Deletes the password policy named *policy*. Prompts for confirmation
|
||||
before deletion. The command will fail if the policy is in use by any
|
||||
principals.
|
||||
|
||||
This command requires the **delete** privilege.
|
||||
|
||||
Alias: **delpol**
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: del_policy guests
|
||||
Are you sure you want to delete the policy "guests"?
|
||||
(yes/no): yes
|
||||
kadmin:
|
||||
|
||||
.. _get_policy:
|
||||
|
||||
get_policy
|
||||
~~~~~~~~~~
|
||||
|
||||
**get_policy** [ **-terse** ] *policy*
|
||||
|
||||
Displays the values of the password policy named *policy*. With the
|
||||
**-terse** flag, outputs the fields as quoted strings separated by
|
||||
tabs.
|
||||
|
||||
This command requires the **inquire** privilege.
|
||||
|
||||
Alias: **getpol**
|
||||
|
||||
Examples::
|
||||
|
||||
kadmin: get_policy admin
|
||||
Policy: admin
|
||||
Maximum password life: 180 days 00:00:00
|
||||
Minimum password life: 00:00:00
|
||||
Minimum password length: 6
|
||||
Minimum number of password character classes: 2
|
||||
Number of old keys kept: 5
|
||||
Reference count: 17
|
||||
|
||||
kadmin: get_policy -terse admin
|
||||
admin 15552000 0 6 2 5 17
|
||||
kadmin:
|
||||
|
||||
The "Reference count" is the number of principals using that policy.
|
||||
With the LDAP KDC database module, the reference count field is not
|
||||
meaningful.
|
||||
|
||||
.. _list_policies:
|
||||
|
||||
list_policies
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
**list_policies** [*expression*]
|
||||
|
||||
Retrieves all or some policy names. *expression* is a shell-style
|
||||
glob expression that can contain the wild-card characters ``?``,
|
||||
``*``, and ``[]``. All policy names matching the expression are
|
||||
printed. If no expression is provided, all existing policy names are
|
||||
printed.
|
||||
|
||||
This command requires the **list** privilege.
|
||||
|
||||
Aliases: **listpols**, **get_policies**, **getpols**.
|
||||
|
||||
Examples::
|
||||
|
||||
kadmin: listpols
|
||||
test-pol
|
||||
dict-only
|
||||
once-a-min
|
||||
test-pol-nopw
|
||||
|
||||
kadmin: listpols t*
|
||||
test-pol
|
||||
test-pol-nopw
|
||||
kadmin:
|
||||
|
||||
.. _ktadd:
|
||||
|
||||
ktadd
|
||||
~~~~~
|
||||
|
||||
| **ktadd** [options] *principal*
|
||||
| **ktadd** [options] **-glob** *princ-exp*
|
||||
|
||||
Adds a *principal*, or all principals matching *princ-exp*, to a
|
||||
keytab file. Each principal's keys are randomized in the process.
|
||||
The rules for *princ-exp* are described in the **list_principals**
|
||||
command.
|
||||
|
||||
This command requires the **inquire** and **changepw** privileges.
|
||||
With the **-glob** form, it also requires the **list** privilege.
|
||||
|
||||
The options are:
|
||||
|
||||
**-k[eytab]** *keytab*
|
||||
Use *keytab* as the keytab file. Otherwise, the default keytab is
|
||||
used.
|
||||
|
||||
**-e** *enc*:*salt*,...
|
||||
Uses the specified keysalt list for setting the new keys of the
|
||||
principal. See :ref:`Keysalt_lists` in :ref:`kdc.conf(5)` for a
|
||||
list of possible values.
|
||||
|
||||
**-q**
|
||||
Display less verbose information.
|
||||
|
||||
**-norandkey**
|
||||
Do not randomize the keys. The keys and their version numbers stay
|
||||
unchanged. This option cannot be specified in combination with the
|
||||
**-e** option.
|
||||
|
||||
An entry for each of the principal's unique encryption types is added,
|
||||
ignoring multiple keys with the same encryption type but different
|
||||
salt types.
|
||||
|
||||
Alias: **xst**
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: ktadd -k /tmp/foo-new-keytab host/foo.mit.edu
|
||||
Entry for principal host/foo.mit.edu@ATHENA.MIT.EDU with kvno 3,
|
||||
encryption type aes256-cts-hmac-sha1-96 added to keytab
|
||||
FILE:/tmp/foo-new-keytab
|
||||
kadmin:
|
||||
|
||||
.. _ktremove:
|
||||
|
||||
ktremove
|
||||
~~~~~~~~
|
||||
|
||||
**ktremove** [options] *principal* [*kvno* | *all* | *old*]
|
||||
|
||||
Removes entries for the specified *principal* from a keytab. Requires
|
||||
no permissions, since this does not require database access.
|
||||
|
||||
If the string "all" is specified, all entries for that principal are
|
||||
removed; if the string "old" is specified, all entries for that
|
||||
principal except those with the highest kvno are removed. Otherwise,
|
||||
the value specified is parsed as an integer, and all entries whose
|
||||
kvno match that integer are removed.
|
||||
|
||||
The options are:
|
||||
|
||||
**-k[eytab]** *keytab*
|
||||
Use *keytab* as the keytab file. Otherwise, the default keytab is
|
||||
used.
|
||||
|
||||
**-q**
|
||||
Display less verbose information.
|
||||
|
||||
Alias: **ktrem**
|
||||
|
||||
Example::
|
||||
|
||||
kadmin: ktremove kadmin/admin all
|
||||
Entry for principal kadmin/admin with kvno 3 removed from keytab
|
||||
FILE:/etc/krb5.keytab
|
||||
kadmin:
|
||||
|
||||
lock
|
||||
~~~~
|
||||
|
||||
Lock database exclusively. Use with extreme caution! This command
|
||||
only works with the DB2 KDC database module.
|
||||
|
||||
unlock
|
||||
~~~~~~
|
||||
|
||||
Release the exclusive database lock.
|
||||
|
||||
list_requests
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Lists available for kadmin requests.
|
||||
|
||||
Aliases: **lr**, **?**
|
||||
|
||||
quit
|
||||
~~~~
|
||||
|
||||
Exit program. If the database was locked, the lock is released.
|
||||
|
||||
Aliases: **exit**, **q**
|
||||
|
||||
|
||||
HISTORY
|
||||
-------
|
||||
|
||||
The kadmin program was originally written by Tom Yu at MIT, as an
|
||||
interface to the OpenVision Kerberos administration program.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kpasswd(1)`, :ref:`kadmind(8)`, :ref:`kerberos(7)`
|
||||
|
|
@ -0,0 +1,129 @@
|
|||
.. _kadmind(8):
|
||||
|
||||
kadmind
|
||||
=======
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**kadmind**
|
||||
[**-x** *db_args*]
|
||||
[**-r** *realm*]
|
||||
[**-m**]
|
||||
[**-nofork**]
|
||||
[**-proponly**]
|
||||
[**-port** *port-number*]
|
||||
[**-P** *pid_file*]
|
||||
[**-p** *kdb5_util_path*]
|
||||
[**-K** *kprop_path*]
|
||||
[**-k** *kprop_port*]
|
||||
[**-F** *dump_file*]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
kadmind starts the Kerberos administration server. kadmind typically
|
||||
runs on the primary Kerberos server, which stores the KDC database.
|
||||
If the KDC database uses the LDAP module, the administration server
|
||||
and the KDC server need not run on the same machine. kadmind accepts
|
||||
remote requests from programs such as :ref:`kadmin(1)` and
|
||||
:ref:`kpasswd(1)` to administer the information in these database.
|
||||
|
||||
kadmind requires a number of configuration files to be set up in order
|
||||
for it to work:
|
||||
|
||||
:ref:`kdc.conf(5)`
|
||||
The KDC configuration file contains configuration information for
|
||||
the KDC and admin servers. kadmind uses settings in this file to
|
||||
locate the Kerberos database, and is also affected by the
|
||||
**acl_file**, **dict_file**, **kadmind_port**, and iprop-related
|
||||
settings.
|
||||
|
||||
:ref:`kadm5.acl(5)`
|
||||
kadmind's ACL (access control list) tells it which principals are
|
||||
allowed to perform administration actions. The pathname to the
|
||||
ACL file can be specified with the **acl_file** :ref:`kdc.conf(5)`
|
||||
variable; by default, it is |kdcdir|\ ``/kadm5.acl``.
|
||||
|
||||
After the server begins running, it puts itself in the background and
|
||||
disassociates itself from its controlling terminal.
|
||||
|
||||
kadmind can be configured for incremental database propagation.
|
||||
Incremental propagation allows replica KDC servers to receive
|
||||
principal and policy updates incrementally instead of receiving full
|
||||
dumps of the database. This facility can be enabled in the
|
||||
:ref:`kdc.conf(5)` file with the **iprop_enable** option. Incremental
|
||||
propagation requires the principal ``kiprop/PRIMARY\@REALM`` (where
|
||||
PRIMARY is the primary KDC's canonical host name, and REALM the realm
|
||||
name). In release 1.13, this principal is automatically created and
|
||||
registered into the datebase.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
**-r** *realm*
|
||||
specifies the realm that kadmind will serve; if it is not
|
||||
specified, the default realm of the host is used.
|
||||
|
||||
**-m**
|
||||
causes the master database password to be fetched from the
|
||||
keyboard (before the server puts itself in the background, if not
|
||||
invoked with the **-nofork** option) rather than from a file on
|
||||
disk.
|
||||
|
||||
**-nofork**
|
||||
causes the server to remain in the foreground and remain
|
||||
associated to the terminal.
|
||||
|
||||
**-proponly**
|
||||
causes the server to only listen and respond to Kerberos replica
|
||||
incremental propagation polling requests. This option can be used
|
||||
to set up a hierarchical propagation topology where a replica KDC
|
||||
provides incremental updates to other Kerberos replicas.
|
||||
|
||||
**-port** *port-number*
|
||||
specifies the port on which the administration server listens for
|
||||
connections. The default port is determined by the
|
||||
**kadmind_port** configuration variable in :ref:`kdc.conf(5)`.
|
||||
|
||||
**-P** *pid_file*
|
||||
specifies the file to which the PID of kadmind process should be
|
||||
written after it starts up. This file can be used to identify
|
||||
whether kadmind is still running and to allow init scripts to stop
|
||||
the correct process.
|
||||
|
||||
**-p** *kdb5_util_path*
|
||||
specifies the path to the kdb5_util command to use when dumping the
|
||||
KDB in response to full resync requests when iprop is enabled.
|
||||
|
||||
**-K** *kprop_path*
|
||||
specifies the path to the kprop command to use to send full dumps
|
||||
to replicas in response to full resync requests.
|
||||
|
||||
**-k** *kprop_port*
|
||||
specifies the port by which the kprop process that is spawned by
|
||||
kadmind connects to the replica kpropd, in order to transfer the
|
||||
dump file during an iprop full resync request.
|
||||
|
||||
**-F** *dump_file*
|
||||
specifies the file path to be used for dumping the KDB in response
|
||||
to full resync requests when iprop is enabled.
|
||||
|
||||
**-x** *db_args*
|
||||
specifies database-specific arguments. See :ref:`Database Options
|
||||
<dboptions>` in :ref:`kadmin(1)` for supported arguments.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kpasswd(1)`, :ref:`kadmin(1)`, :ref:`kdb5_util(8)`,
|
||||
:ref:`kdb5_ldap_util(8)`, :ref:`kadm5.acl(5)`, :ref:`kerberos(7)`
|
||||
|
|
@ -0,0 +1,449 @@
|
|||
.. _kdb5_ldap_util(8):
|
||||
|
||||
kdb5_ldap_util
|
||||
===============
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
.. _kdb5_ldap_util_synopsis:
|
||||
|
||||
**kdb5_ldap_util**
|
||||
[**-D** *user_dn* [**-w** *passwd*]]
|
||||
[**-H** *ldapuri*]
|
||||
**command**
|
||||
[*command_options*]
|
||||
|
||||
.. _kdb5_ldap_util_synopsis_end:
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
kdb5_ldap_util allows an administrator to manage realms, Kerberos
|
||||
services and ticket policies.
|
||||
|
||||
|
||||
COMMAND-LINE OPTIONS
|
||||
--------------------
|
||||
|
||||
.. _kdb5_ldap_util_options:
|
||||
|
||||
**-r** *realm*
|
||||
Specifies the realm to be operated on.
|
||||
|
||||
**-D** *user_dn*
|
||||
Specifies the Distinguished Name (DN) of the user who has
|
||||
sufficient rights to perform the operation on the LDAP server.
|
||||
|
||||
**-w** *passwd*
|
||||
Specifies the password of *user_dn*. This option is not
|
||||
recommended.
|
||||
|
||||
**-H** *ldapuri*
|
||||
Specifies the URI of the LDAP server.
|
||||
|
||||
By default, kdb5_ldap_util operates on the default realm (as specified
|
||||
in :ref:`krb5.conf(5)`) and connects and authenticates to the LDAP
|
||||
server in the same manner as :ref:kadmind(8)` would given the
|
||||
parameters in :ref:`dbdefaults` in :ref:`kdc.conf(5)`.
|
||||
|
||||
.. _kdb5_ldap_util_options_end:
|
||||
|
||||
|
||||
COMMANDS
|
||||
--------
|
||||
|
||||
create
|
||||
~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_create:
|
||||
|
||||
**create**
|
||||
[**-subtrees** *subtree_dn_list*]
|
||||
[**-sscope** *search_scope*]
|
||||
[**-containerref** *container_reference_dn*]
|
||||
[**-k** *mkeytype*]
|
||||
[**-kv** *mkeyVNO*]
|
||||
[**-M** *mkeyname*]
|
||||
[**-m|-P** *password*\|\ **-sf** *stashfilename*]
|
||||
[**-s**]
|
||||
[**-maxtktlife** *max_ticket_life*]
|
||||
[**-maxrenewlife** *max_renewable_ticket_life*]
|
||||
[*ticket_flags*]
|
||||
|
||||
Creates realm in directory. Options:
|
||||
|
||||
**-subtrees** *subtree_dn_list*
|
||||
Specifies the list of subtrees containing the principals of a
|
||||
realm. The list contains the DNs of the subtree objects separated
|
||||
by colon (``:``).
|
||||
|
||||
**-sscope** *search_scope*
|
||||
Specifies the scope for searching the principals under the
|
||||
subtree. The possible values are 1 or one (one level), 2 or sub
|
||||
(subtrees).
|
||||
|
||||
**-containerref** *container_reference_dn*
|
||||
Specifies the DN of the container object in which the principals
|
||||
of a realm will be created. If the container reference is not
|
||||
configured for a realm, the principals will be created in the
|
||||
realm container.
|
||||
|
||||
**-k** *mkeytype*
|
||||
Specifies the key type of the master key in the database. The
|
||||
default is given by the **master_key_type** variable in
|
||||
:ref:`kdc.conf(5)`.
|
||||
|
||||
**-kv** *mkeyVNO*
|
||||
Specifies the version number of the master key in the database;
|
||||
the default is 1. Note that 0 is not allowed.
|
||||
|
||||
**-M** *mkeyname*
|
||||
Specifies the principal name for the master key in the database.
|
||||
If not specified, the name is determined by the
|
||||
**master_key_name** variable in :ref:`kdc.conf(5)`.
|
||||
|
||||
**-m**
|
||||
Specifies that the master database password should be read from
|
||||
the TTY rather than fetched from a file on the disk.
|
||||
|
||||
**-P** *password*
|
||||
Specifies the master database password. This option is not
|
||||
recommended.
|
||||
|
||||
**-sf** *stashfilename*
|
||||
Specifies the stash file of the master database password.
|
||||
|
||||
**-s**
|
||||
Specifies that the stash file is to be created.
|
||||
|
||||
**-maxtktlife** *max_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum ticket life for
|
||||
principals in this realm.
|
||||
|
||||
**-maxrenewlife** *max_renewable_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum renewable life of
|
||||
tickets for principals in this realm.
|
||||
|
||||
*ticket_flags*
|
||||
Specifies global ticket flags for the realm. Allowable flags are
|
||||
documented in the description of the **add_principal** command in
|
||||
:ref:`kadmin(1)`.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU create -subtrees o=org -sscope SUB
|
||||
Password for "cn=admin,o=org":
|
||||
Initializing database for realm 'ATHENA.MIT.EDU'
|
||||
You will be prompted for the database Master Password.
|
||||
It is important that you NOT FORGET this password.
|
||||
Enter KDC database master key:
|
||||
Re-enter KDC database master key to verify:
|
||||
|
||||
.. _kdb5_ldap_util_create_end:
|
||||
|
||||
modify
|
||||
~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_modify:
|
||||
|
||||
**modify**
|
||||
[**-subtrees** *subtree_dn_list*]
|
||||
[**-sscope** *search_scope*]
|
||||
[**-containerref** *container_reference_dn*]
|
||||
[**-maxtktlife** *max_ticket_life*]
|
||||
[**-maxrenewlife** *max_renewable_ticket_life*]
|
||||
[*ticket_flags*]
|
||||
|
||||
Modifies the attributes of a realm. Options:
|
||||
|
||||
**-subtrees** *subtree_dn_list*
|
||||
Specifies the list of subtrees containing the principals of a
|
||||
realm. The list contains the DNs of the subtree objects separated
|
||||
by colon (``:``). This list replaces the existing list.
|
||||
|
||||
**-sscope** *search_scope*
|
||||
Specifies the scope for searching the principals under the
|
||||
subtrees. The possible values are 1 or one (one level), 2 or sub
|
||||
(subtrees).
|
||||
|
||||
**-containerref** *container_reference_dn* Specifies the DN of the
|
||||
container object in which the principals of a realm will be
|
||||
created.
|
||||
|
||||
**-maxtktlife** *max_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum ticket life for
|
||||
principals in this realm.
|
||||
|
||||
**-maxrenewlife** *max_renewable_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum renewable life of
|
||||
tickets for principals in this realm.
|
||||
|
||||
*ticket_flags*
|
||||
Specifies global ticket flags for the realm. Allowable flags are
|
||||
documented in the description of the **add_principal** command in
|
||||
:ref:`kadmin(1)`.
|
||||
|
||||
Example::
|
||||
|
||||
shell% kdb5_ldap_util -r ATHENA.MIT.EDU -D cn=admin,o=org -H
|
||||
ldaps://ldap-server1.mit.edu modify +requires_preauth
|
||||
Password for "cn=admin,o=org":
|
||||
shell%
|
||||
|
||||
.. _kdb5_ldap_util_modify_end:
|
||||
|
||||
view
|
||||
~~~~
|
||||
|
||||
.. _kdb5_ldap_util_view:
|
||||
|
||||
**view**
|
||||
|
||||
Displays the attributes of a realm.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU view
|
||||
Password for "cn=admin,o=org":
|
||||
Realm Name: ATHENA.MIT.EDU
|
||||
Subtree: ou=users,o=org
|
||||
Subtree: ou=servers,o=org
|
||||
SearchScope: ONE
|
||||
Maximum ticket life: 0 days 01:00:00
|
||||
Maximum renewable life: 0 days 10:00:00
|
||||
Ticket flags: DISALLOW_FORWARDABLE REQUIRES_PWCHANGE
|
||||
|
||||
.. _kdb5_ldap_util_view_end:
|
||||
|
||||
destroy
|
||||
~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_destroy:
|
||||
|
||||
**destroy** [**-f**]
|
||||
|
||||
Destroys an existing realm. Options:
|
||||
|
||||
**-f**
|
||||
If specified, will not prompt the user for confirmation.
|
||||
|
||||
Example::
|
||||
|
||||
shell% kdb5_ldap_util -r ATHENA.MIT.EDU -D cn=admin,o=org -H
|
||||
ldaps://ldap-server1.mit.edu destroy
|
||||
Password for "cn=admin,o=org":
|
||||
Deleting KDC database of 'ATHENA.MIT.EDU', are you sure?
|
||||
(type 'yes' to confirm)? yes
|
||||
OK, deleting database of 'ATHENA.MIT.EDU'...
|
||||
shell%
|
||||
|
||||
.. _kdb5_ldap_util_destroy_end:
|
||||
|
||||
list
|
||||
~~~~
|
||||
|
||||
.. _kdb5_ldap_util_list:
|
||||
|
||||
**list**
|
||||
|
||||
Lists the names of realms under the container.
|
||||
|
||||
Example::
|
||||
|
||||
shell% kdb5_ldap_util -D cn=admin,o=org -H
|
||||
ldaps://ldap-server1.mit.edu list
|
||||
Password for "cn=admin,o=org":
|
||||
ATHENA.MIT.EDU
|
||||
OPENLDAP.MIT.EDU
|
||||
MEDIA-LAB.MIT.EDU
|
||||
shell%
|
||||
|
||||
.. _kdb5_ldap_util_list_end:
|
||||
|
||||
stashsrvpw
|
||||
~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_stashsrvpw:
|
||||
|
||||
**stashsrvpw**
|
||||
[**-f** *filename*]
|
||||
*name*
|
||||
|
||||
Allows an administrator to store the password for service object in a
|
||||
file so that KDC and Administration server can use it to authenticate
|
||||
to the LDAP server. Options:
|
||||
|
||||
**-f** *filename*
|
||||
Specifies the complete path of the service password file. By
|
||||
default, ``/usr/local/var/service_passwd`` is used.
|
||||
|
||||
*name*
|
||||
Specifies the name of the object whose password is to be stored.
|
||||
If :ref:`krb5kdc(8)` or :ref:`kadmind(8)` are configured for
|
||||
simple binding, this should be the distinguished name it will
|
||||
use as given by the **ldap_kdc_dn** or **ldap_kadmind_dn**
|
||||
variable in :ref:`kdc.conf(5)`. If the KDC or kadmind is
|
||||
configured for SASL binding, this should be the authentication
|
||||
name it will use as given by the **ldap_kdc_sasl_authcid** or
|
||||
**ldap_kadmind_sasl_authcid** variable.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util stashsrvpw -f /home/andrew/conf_keyfile
|
||||
cn=service-kdc,o=org
|
||||
Password for "cn=service-kdc,o=org":
|
||||
Re-enter password for "cn=service-kdc,o=org":
|
||||
|
||||
.. _kdb5_ldap_util_stashsrvpw_end:
|
||||
|
||||
create_policy
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_create_policy:
|
||||
|
||||
**create_policy**
|
||||
[**-maxtktlife** *max_ticket_life*]
|
||||
[**-maxrenewlife** *max_renewable_ticket_life*]
|
||||
[*ticket_flags*]
|
||||
*policy_name*
|
||||
|
||||
Creates a ticket policy in the directory. Options:
|
||||
|
||||
**-maxtktlife** *max_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum ticket life for
|
||||
principals.
|
||||
|
||||
**-maxrenewlife** *max_renewable_ticket_life*
|
||||
(:ref:`getdate` string) Specifies maximum renewable life of
|
||||
tickets for principals.
|
||||
|
||||
*ticket_flags*
|
||||
Specifies the ticket flags. If this option is not specified, by
|
||||
default, no restriction will be set by the policy. Allowable
|
||||
flags are documented in the description of the **add_principal**
|
||||
command in :ref:`kadmin(1)`.
|
||||
|
||||
*policy_name*
|
||||
Specifies the name of the ticket policy.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU create_policy -maxtktlife "1 day"
|
||||
-maxrenewlife "1 week" -allow_postdated +needchange
|
||||
-allow_forwardable tktpolicy
|
||||
Password for "cn=admin,o=org":
|
||||
|
||||
.. _kdb5_ldap_util_create_policy_end:
|
||||
|
||||
modify_policy
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_modify_policy:
|
||||
|
||||
**modify_policy**
|
||||
[**-maxtktlife** *max_ticket_life*]
|
||||
[**-maxrenewlife** *max_renewable_ticket_life*]
|
||||
[*ticket_flags*]
|
||||
*policy_name*
|
||||
|
||||
Modifies the attributes of a ticket policy. Options are same as for
|
||||
**create_policy**.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H
|
||||
ldaps://ldap-server1.mit.edu -r ATHENA.MIT.EDU modify_policy
|
||||
-maxtktlife "60 minutes" -maxrenewlife "10 hours"
|
||||
+allow_postdated -requires_preauth tktpolicy
|
||||
Password for "cn=admin,o=org":
|
||||
|
||||
.. _kdb5_ldap_util_modify_policy_end:
|
||||
|
||||
view_policy
|
||||
~~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_view_policy:
|
||||
|
||||
**view_policy**
|
||||
*policy_name*
|
||||
|
||||
Displays the attributes of the named ticket policy.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU view_policy tktpolicy
|
||||
Password for "cn=admin,o=org":
|
||||
Ticket policy: tktpolicy
|
||||
Maximum ticket life: 0 days 01:00:00
|
||||
Maximum renewable life: 0 days 10:00:00
|
||||
Ticket flags: DISALLOW_FORWARDABLE REQUIRES_PWCHANGE
|
||||
|
||||
.. _kdb5_ldap_util_view_policy_end:
|
||||
|
||||
destroy_policy
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_destroy_policy:
|
||||
|
||||
**destroy_policy**
|
||||
[**-force**]
|
||||
*policy_name*
|
||||
|
||||
Destroys an existing ticket policy. Options:
|
||||
|
||||
**-force**
|
||||
Forces the deletion of the policy object. If not specified, the
|
||||
user will be prompted for confirmation before deleting the policy.
|
||||
|
||||
*policy_name*
|
||||
Specifies the name of the ticket policy.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU destroy_policy tktpolicy
|
||||
Password for "cn=admin,o=org":
|
||||
This will delete the policy object 'tktpolicy', are you sure?
|
||||
(type 'yes' to confirm)? yes
|
||||
** policy object 'tktpolicy' deleted.
|
||||
|
||||
.. _kdb5_ldap_util_destroy_policy_end:
|
||||
|
||||
list_policy
|
||||
~~~~~~~~~~~
|
||||
|
||||
.. _kdb5_ldap_util_list_policy:
|
||||
|
||||
**list_policy**
|
||||
|
||||
Lists ticket policies.
|
||||
|
||||
Example::
|
||||
|
||||
kdb5_ldap_util -D cn=admin,o=org -H ldaps://ldap-server1.mit.edu
|
||||
-r ATHENA.MIT.EDU list_policy
|
||||
Password for "cn=admin,o=org":
|
||||
tktpolicy
|
||||
tmppolicy
|
||||
userpolicy
|
||||
|
||||
.. _kdb5_ldap_util_list_policy_end:
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kadmin(1)`, :ref:`kerberos(7)`
|
||||
|
|
@ -0,0 +1,502 @@
|
|||
.. _kdb5_util(8):
|
||||
|
||||
kdb5_util
|
||||
=========
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
.. _kdb5_util_synopsis:
|
||||
|
||||
**kdb5_util**
|
||||
[**-r** *realm*]
|
||||
[**-d** *dbname*]
|
||||
[**-k** *mkeytype*]
|
||||
[**-kv** *mkeyVNO*]
|
||||
[**-M** *mkeyname*]
|
||||
[**-m**]
|
||||
[**-sf** *stashfilename*]
|
||||
[**-P** *password*]
|
||||
[**-x** *db_args*]
|
||||
*command* [*command_options*]
|
||||
|
||||
.. _kdb5_util_synopsis_end:
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
kdb5_util allows an administrator to perform maintenance procedures on
|
||||
the KDC database. Databases can be created, destroyed, and dumped to
|
||||
or loaded from ASCII files. kdb5_util can create a Kerberos master
|
||||
key stash file or perform live rollover of the master key.
|
||||
|
||||
When kdb5_util is run, it attempts to acquire the master key and open
|
||||
the database. However, execution continues regardless of whether or
|
||||
not kdb5_util successfully opens the database, because the database
|
||||
may not exist yet or the stash file may be corrupt.
|
||||
|
||||
Note that some KDC database modules may not support all kdb5_util
|
||||
commands.
|
||||
|
||||
|
||||
COMMAND-LINE OPTIONS
|
||||
--------------------
|
||||
|
||||
.. _kdb5_util_options:
|
||||
|
||||
**-r** *realm*
|
||||
specifies the Kerberos realm of the database.
|
||||
|
||||
**-d** *dbname*
|
||||
specifies the name under which the principal database is stored;
|
||||
by default the database is that listed in :ref:`kdc.conf(5)`. The
|
||||
password policy database and lock files are also derived from this
|
||||
value.
|
||||
|
||||
**-k** *mkeytype*
|
||||
specifies the key type of the master key in the database. The
|
||||
default is given by the **master_key_type** variable in
|
||||
:ref:`kdc.conf(5)`.
|
||||
|
||||
**-kv** *mkeyVNO*
|
||||
Specifies the version number of the master key in the database;
|
||||
the default is 1. Note that 0 is not allowed.
|
||||
|
||||
**-M** *mkeyname*
|
||||
principal name for the master key in the database. If not
|
||||
specified, the name is determined by the **master_key_name**
|
||||
variable in :ref:`kdc.conf(5)`.
|
||||
|
||||
**-m**
|
||||
specifies that the master database password should be read from
|
||||
the keyboard rather than fetched from a file on disk.
|
||||
|
||||
**-sf** *stash_file*
|
||||
specifies the stash filename of the master database password. If
|
||||
not specified, the filename is determined by the
|
||||
**key_stash_file** variable in :ref:`kdc.conf(5)`.
|
||||
|
||||
**-P** *password*
|
||||
specifies the master database password. Using this option may
|
||||
expose the password to other users on the system via the process
|
||||
list.
|
||||
|
||||
**-x** *db_args*
|
||||
specifies database-specific options. See :ref:`kadmin(1)` for
|
||||
supported options.
|
||||
|
||||
.. _kdb5_util_options_end:
|
||||
|
||||
|
||||
COMMANDS
|
||||
--------
|
||||
|
||||
create
|
||||
~~~~~~
|
||||
|
||||
.. _kdb5_util_create:
|
||||
|
||||
**create** [**-s**]
|
||||
|
||||
Creates a new database. If the **-s** option is specified, the stash
|
||||
file is also created. This command fails if the database already
|
||||
exists. If the command is successful, the database is opened just as
|
||||
if it had already existed when the program was first run.
|
||||
|
||||
.. _kdb5_util_create_end:
|
||||
|
||||
destroy
|
||||
~~~~~~~
|
||||
|
||||
.. _kdb5_util_destroy:
|
||||
|
||||
**destroy** [**-f**]
|
||||
|
||||
Destroys the database, first overwriting the disk sectors and then
|
||||
unlinking the files, after prompting the user for confirmation. With
|
||||
the **-f** argument, does not prompt the user.
|
||||
|
||||
.. _kdb5_util_destroy_end:
|
||||
|
||||
stash
|
||||
~~~~~
|
||||
|
||||
.. _kdb5_util_stash:
|
||||
|
||||
**stash** [**-f** *keyfile*]
|
||||
|
||||
Stores the master principal's keys in a stash file. The **-f**
|
||||
argument can be used to override the *keyfile* specified in
|
||||
:ref:`kdc.conf(5)`.
|
||||
|
||||
.. _kdb5_util_stash_end:
|
||||
|
||||
dump
|
||||
~~~~
|
||||
|
||||
.. _kdb5_util_dump:
|
||||
|
||||
**dump** [**-b7**\|\ **-r13**\|\ **-r18**]
|
||||
[**-verbose**] [**-mkey_convert**] [**-new_mkey_file**
|
||||
*mkey_file*] [**-rev**] [**-recurse**] [*filename*
|
||||
[*principals*...]]
|
||||
|
||||
Dumps the current Kerberos and KADM5 database into an ASCII file. By
|
||||
default, the database is dumped in current format, "kdb5_util
|
||||
load_dump version 7". If filename is not specified, or is the string
|
||||
"-", the dump is sent to standard output. Options:
|
||||
|
||||
**-b7**
|
||||
causes the dump to be in the Kerberos 5 Beta 7 format ("kdb5_util
|
||||
load_dump version 4"). This was the dump format produced on
|
||||
releases prior to 1.2.2.
|
||||
|
||||
**-r13**
|
||||
causes the dump to be in the Kerberos 5 1.3 format ("kdb5_util
|
||||
load_dump version 5"). This was the dump format produced on
|
||||
releases prior to 1.8.
|
||||
|
||||
**-r18**
|
||||
causes the dump to be in the Kerberos 5 1.8 format ("kdb5_util
|
||||
load_dump version 6"). This was the dump format produced on
|
||||
releases prior to 1.11.
|
||||
|
||||
**-verbose**
|
||||
causes the name of each principal and policy to be printed as it
|
||||
is dumped.
|
||||
|
||||
**-mkey_convert**
|
||||
prompts for a new master key. This new master key will be used to
|
||||
re-encrypt principal key data in the dumpfile. The principal keys
|
||||
themselves will not be changed.
|
||||
|
||||
**-new_mkey_file** *mkey_file*
|
||||
the filename of a stash file. The master key in this stash file
|
||||
will be used to re-encrypt the key data in the dumpfile. The key
|
||||
data in the database will not be changed.
|
||||
|
||||
**-rev**
|
||||
dumps in reverse order. This may recover principals that do not
|
||||
dump normally, in cases where database corruption has occurred.
|
||||
|
||||
**-recurse**
|
||||
causes the dump to walk the database recursively (btree only).
|
||||
This may recover principals that do not dump normally, in cases
|
||||
where database corruption has occurred. In cases of such
|
||||
corruption, this option will probably retrieve more principals
|
||||
than the **-rev** option will.
|
||||
|
||||
.. versionchanged:: 1.15
|
||||
Release 1.15 restored the functionality of the **-recurse**
|
||||
option.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
The **-recurse** option ceased working until release 1.15,
|
||||
doing a normal dump instead of a recursive traversal.
|
||||
|
||||
.. _kdb5_util_dump_end:
|
||||
|
||||
load
|
||||
~~~~
|
||||
|
||||
.. _kdb5_util_load:
|
||||
|
||||
**load** [**-b7**\|\ **-r13**\|\ **-r18**] [**-hash**]
|
||||
[**-verbose**] [**-update**] *filename*
|
||||
|
||||
Loads a database dump from the named file into the named database. If
|
||||
no option is given to determine the format of the dump file, the
|
||||
format is detected automatically and handled as appropriate. Unless
|
||||
the **-update** option is given, **load** creates a new database
|
||||
containing only the data in the dump file, overwriting the contents of
|
||||
any previously existing database. Note that when using the LDAP KDC
|
||||
database module, the **-update** flag is required.
|
||||
|
||||
Options:
|
||||
|
||||
**-b7**
|
||||
requires the database to be in the Kerberos 5 Beta 7 format
|
||||
("kdb5_util load_dump version 4"). This was the dump format
|
||||
produced on releases prior to 1.2.2.
|
||||
|
||||
**-r13**
|
||||
requires the database to be in Kerberos 5 1.3 format ("kdb5_util
|
||||
load_dump version 5"). This was the dump format produced on
|
||||
releases prior to 1.8.
|
||||
|
||||
**-r18**
|
||||
requires the database to be in Kerberos 5 1.8 format ("kdb5_util
|
||||
load_dump version 6"). This was the dump format produced on
|
||||
releases prior to 1.11.
|
||||
|
||||
**-hash**
|
||||
stores the database in hash format, if using the DB2 database
|
||||
type. If this option is not specified, the database will be
|
||||
stored in btree format. This option is not recommended, as
|
||||
databases stored in hash format are known to corrupt data and lose
|
||||
principals.
|
||||
|
||||
**-verbose**
|
||||
causes the name of each principal and policy to be printed as it
|
||||
is dumped.
|
||||
|
||||
**-update**
|
||||
records from the dump file are added to or updated in the existing
|
||||
database. Otherwise, a new database is created containing only
|
||||
what is in the dump file and the old one destroyed upon successful
|
||||
completion.
|
||||
|
||||
.. _kdb5_util_load_end:
|
||||
|
||||
ark
|
||||
~~~
|
||||
|
||||
**ark** [**-e** *enc*:*salt*,...] *principal*
|
||||
|
||||
Adds new random keys to *principal* at the next available key version
|
||||
number. Keys for the current highest key version number will be
|
||||
preserved. The **-e** option specifies the list of encryption and
|
||||
salt types to be used for the new keys.
|
||||
|
||||
add_mkey
|
||||
~~~~~~~~
|
||||
|
||||
**add_mkey** [**-e** *etype*] [**-s**]
|
||||
|
||||
Adds a new master key to the master key principal, but does not mark
|
||||
it as active. Existing master keys will remain. The **-e** option
|
||||
specifies the encryption type of the new master key; see
|
||||
:ref:`Encryption_types` in :ref:`kdc.conf(5)` for a list of possible
|
||||
values. The **-s** option stashes the new master key in the stash
|
||||
file, which will be created if it doesn't already exist.
|
||||
|
||||
After a new master key is added, it should be propagated to replica
|
||||
servers via a manual or periodic invocation of :ref:`kprop(8)`. Then,
|
||||
the stash files on the replica servers should be updated with the
|
||||
kdb5_util **stash** command. Once those steps are complete, the key
|
||||
is ready to be marked active with the kdb5_util **use_mkey** command.
|
||||
|
||||
use_mkey
|
||||
~~~~~~~~
|
||||
|
||||
**use_mkey** *mkeyVNO* [*time*]
|
||||
|
||||
Sets the activation time of the master key specified by *mkeyVNO*.
|
||||
Once a master key becomes active, it will be used to encrypt newly
|
||||
created principal keys. If no *time* argument is given, the current
|
||||
time is used, causing the specified master key version to become
|
||||
active immediately. The format for *time* is :ref:`getdate` string.
|
||||
|
||||
After a new master key becomes active, the kdb5_util
|
||||
**update_princ_encryption** command can be used to update all
|
||||
principal keys to be encrypted in the new master key.
|
||||
|
||||
list_mkeys
|
||||
~~~~~~~~~~
|
||||
|
||||
**list_mkeys**
|
||||
|
||||
List all master keys, from most recent to earliest, in the master key
|
||||
principal. The output will show the kvno, enctype, and salt type for
|
||||
each mkey, similar to the output of :ref:`kadmin(1)` **getprinc**. A
|
||||
``*`` following an mkey denotes the currently active master key.
|
||||
|
||||
purge_mkeys
|
||||
~~~~~~~~~~~
|
||||
|
||||
**purge_mkeys** [**-f**] [**-n**] [**-v**]
|
||||
|
||||
Delete master keys from the master key principal that are not used to
|
||||
protect any principals. This command can be used to remove old master
|
||||
keys all principal keys are protected by a newer master key.
|
||||
|
||||
**-f**
|
||||
does not prompt for confirmation.
|
||||
|
||||
**-n**
|
||||
performs a dry run, showing master keys that would be purged, but
|
||||
not actually purging any keys.
|
||||
|
||||
**-v**
|
||||
gives more verbose output.
|
||||
|
||||
update_princ_encryption
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**update_princ_encryption** [**-f**] [**-n**] [**-v**]
|
||||
[*princ-pattern*]
|
||||
|
||||
Update all principal records (or only those matching the
|
||||
*princ-pattern* glob pattern) to re-encrypt the key data using the
|
||||
active database master key, if they are encrypted using a different
|
||||
version, and give a count at the end of the number of principals
|
||||
updated. If the **-f** option is not given, ask for confirmation
|
||||
before starting to make changes. The **-v** option causes each
|
||||
principal processed to be listed, with an indication as to whether it
|
||||
needed updating or not. The **-n** option performs a dry run, only
|
||||
showing the actions which would have been taken.
|
||||
|
||||
tabdump
|
||||
~~~~~~~
|
||||
|
||||
**tabdump** [**-H**] [**-c**] [**-e**] [**-n**] [**-o** *outfile*]
|
||||
*dumptype*
|
||||
|
||||
Dump selected fields of the database in a tabular format suitable for
|
||||
reporting (e.g., using traditional Unix text processing tools) or
|
||||
importing into relational databases. The data format is tab-separated
|
||||
(default), or optionally comma-separated (CSV), with a fixed number of
|
||||
columns. The output begins with a header line containing field names,
|
||||
unless suppression is requested using the **-H** option.
|
||||
|
||||
The *dumptype* parameter specifies the name of an output table (see
|
||||
below).
|
||||
|
||||
Options:
|
||||
|
||||
**-H**
|
||||
suppress writing the field names in a header line
|
||||
|
||||
**-c**
|
||||
use comma separated values (CSV) format, with minimal quoting,
|
||||
instead of the default tab-separated (unquoted, unescaped) format
|
||||
|
||||
**-e**
|
||||
write empty hexadecimal string fields as empty fields instead of
|
||||
as "-1".
|
||||
|
||||
**-n**
|
||||
produce numeric output for fields that normally have symbolic
|
||||
output, such as enctypes and flag names. Also requests output of
|
||||
time stamps as decimal POSIX time_t values.
|
||||
|
||||
**-o** *outfile*
|
||||
write the dump to the specified output file instead of to standard
|
||||
output
|
||||
|
||||
Dump types:
|
||||
|
||||
**keydata**
|
||||
principal encryption key information, including actual key data
|
||||
(which is still encrypted in the master key)
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**keyindex**
|
||||
index of this key in the principal's key list
|
||||
**kvno**
|
||||
key version number
|
||||
**enctype**
|
||||
encryption type
|
||||
**key**
|
||||
key data as a hexadecimal string
|
||||
**salttype**
|
||||
salt type
|
||||
**salt**
|
||||
salt data as a hexadecimal string
|
||||
|
||||
**keyinfo**
|
||||
principal encryption key information (as in **keydata** above),
|
||||
excluding actual key data
|
||||
|
||||
**princ_flags**
|
||||
principal boolean attributes. Flag names print as hexadecimal
|
||||
numbers if the **-n** option is specified, and all flag positions
|
||||
are printed regardless of whether or not they are set. If **-n**
|
||||
is not specified, print all known flag names for each principal,
|
||||
but only print hexadecimal flag names if the corresponding flag is
|
||||
set.
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**flag**
|
||||
flag name
|
||||
**value**
|
||||
boolean value (0 for clear, or 1 for set)
|
||||
|
||||
**princ_lockout**
|
||||
state information used for tracking repeated password failures
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**last_success**
|
||||
time stamp of most recent successful authentication
|
||||
**last_failed**
|
||||
time stamp of most recent failed authentication
|
||||
**fail_count**
|
||||
count of failed attempts
|
||||
|
||||
**princ_meta**
|
||||
principal metadata
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**modby**
|
||||
name of last principal to modify this principal
|
||||
**modtime**
|
||||
timestamp of last modification
|
||||
**lastpwd**
|
||||
timestamp of last password change
|
||||
**policy**
|
||||
policy object name
|
||||
**mkvno**
|
||||
key version number of the master key that encrypts this
|
||||
principal's key data
|
||||
**hist_kvno**
|
||||
key version number of the history key that encrypts the key
|
||||
history data for this principal
|
||||
|
||||
**princ_stringattrs**
|
||||
string attributes (key/value pairs)
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**key**
|
||||
attribute name
|
||||
**value**
|
||||
attribute value
|
||||
|
||||
**princ_tktpolicy**
|
||||
per-principal ticket policy data, including maximum ticket
|
||||
lifetimes
|
||||
|
||||
**name**
|
||||
principal name
|
||||
**expiration**
|
||||
principal expiration date
|
||||
**pw_expiration**
|
||||
password expiration date
|
||||
**max_life**
|
||||
maximum ticket lifetime
|
||||
**max_renew_life**
|
||||
maximum renewable ticket lifetime
|
||||
|
||||
Examples::
|
||||
|
||||
$ kdb5_util tabdump -o keyinfo.txt keyinfo
|
||||
$ cat keyinfo.txt
|
||||
name keyindex kvno enctype salttype salt
|
||||
K/M@EXAMPLE.COM 0 1 aes256-cts-hmac-sha384-192 normal -1
|
||||
foo@EXAMPLE.COM 0 1 aes128-cts-hmac-sha1-96 normal -1
|
||||
bar@EXAMPLE.COM 0 1 aes128-cts-hmac-sha1-96 normal -1
|
||||
$ sqlite3
|
||||
sqlite> .mode tabs
|
||||
sqlite> .import keyinfo.txt keyinfo
|
||||
sqlite> select * from keyinfo where enctype like 'aes256-%';
|
||||
K/M@EXAMPLE.COM 1 1 aes256-cts-hmac-sha384-192 normal -1
|
||||
sqlite> .quit
|
||||
$ awk -F'\t' '$4 ~ /aes256-/ { print }' keyinfo.txt
|
||||
K/M@EXAMPLE.COM 1 1 aes256-cts-hmac-sha384-192 normal -1
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kadmin(1)`, :ref:`kerberos(7)`
|
||||
|
|
@ -0,0 +1,60 @@
|
|||
.. _kprop(8):
|
||||
|
||||
kprop
|
||||
=====
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**kprop**
|
||||
[**-r** *realm*]
|
||||
[**-f** *file*]
|
||||
[**-d**]
|
||||
[**-P** *port*]
|
||||
[**-s** *keytab*]
|
||||
*replica_host*
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
kprop is used to securely propagate a Kerberos V5 database dump file
|
||||
from the primary Kerberos server to a replica Kerberos server, which is
|
||||
specified by *replica_host*. The dump file must be created by
|
||||
:ref:`kdb5_util(8)`.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
**-r** *realm*
|
||||
Specifies the realm of the primary server.
|
||||
|
||||
**-f** *file*
|
||||
Specifies the filename where the dumped principal database file is
|
||||
to be found; by default the dumped database file is normally
|
||||
|kdcdir|\ ``/replica_datatrans``.
|
||||
|
||||
**-P** *port*
|
||||
Specifies the port to use to contact the :ref:`kpropd(8)` server
|
||||
on the remote host.
|
||||
|
||||
**-d**
|
||||
Prints debugging information.
|
||||
|
||||
**-s** *keytab*
|
||||
Specifies the location of the keytab file.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kpropd(8)`, :ref:`kdb5_util(8)`, :ref:`krb5kdc(8)`,
|
||||
:ref:`kerberos(7)`
|
||||
|
|
@ -0,0 +1,144 @@
|
|||
.. _kpropd(8):
|
||||
|
||||
kpropd
|
||||
======
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**kpropd**
|
||||
[**-r** *realm*]
|
||||
[**-A** *admin_server*]
|
||||
[**-a** *acl_file*]
|
||||
[**-f** *replica_dumpfile*]
|
||||
[**-F** *principal_database*]
|
||||
[**-p** *kdb5_util_prog*]
|
||||
[**-P** *port*]
|
||||
[**--pid-file**\ =\ *pid_file*]
|
||||
[**-D**]
|
||||
[**-d**]
|
||||
[**-s** *keytab_file*]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
The *kpropd* command runs on the replica KDC server. It listens for
|
||||
update requests made by the :ref:`kprop(8)` program. If incremental
|
||||
propagation is enabled, it periodically requests incremental updates
|
||||
from the primary KDC.
|
||||
|
||||
When the replica receives a kprop request from the primary, kpropd
|
||||
accepts the dumped KDC database and places it in a file, and then runs
|
||||
:ref:`kdb5_util(8)` to load the dumped database into the active
|
||||
database which is used by :ref:`krb5kdc(8)`. This allows the primary
|
||||
Kerberos server to use :ref:`kprop(8)` to propagate its database to
|
||||
the replica servers. Upon a successful download of the KDC database
|
||||
file, the replica Kerberos server will have an up-to-date KDC
|
||||
database.
|
||||
|
||||
Where incremental propagation is not used, kpropd is commonly invoked
|
||||
out of inetd(8) as a nowait service. This is done by adding a line to
|
||||
the ``/etc/inetd.conf`` file which looks like this::
|
||||
|
||||
kprop stream tcp nowait root /usr/local/sbin/kpropd kpropd
|
||||
|
||||
kpropd can also run as a standalone daemon, backgrounding itself and
|
||||
waiting for connections on port 754 (or the port specified with the
|
||||
**-P** option if given). Standalone mode is required for incremental
|
||||
propagation. Starting in release 1.11, kpropd automatically detects
|
||||
whether it was run from inetd and runs in standalone mode if it is
|
||||
not. Prior to release 1.11, the **-S** option is required to run
|
||||
kpropd in standalone mode; this option is now accepted for backward
|
||||
compatibility but does nothing.
|
||||
|
||||
Incremental propagation may be enabled with the **iprop_enable**
|
||||
variable in :ref:`kdc.conf(5)`. If incremental propagation is
|
||||
enabled, the replica periodically polls the primary KDC for updates, at
|
||||
an interval determined by the **iprop_replica_poll** variable. If the
|
||||
replica receives updates, kpropd updates its log file with any updates
|
||||
from the primary. :ref:`kproplog(8)` can be used to view a summary of
|
||||
the update entry log on the replica KDC. If incremental propagation
|
||||
is enabled, the principal ``kiprop/replicahostname@REALM`` (where
|
||||
*replicahostname* is the name of the replica KDC host, and *REALM* is
|
||||
the name of the Kerberos realm) must be present in the replica's
|
||||
keytab file.
|
||||
|
||||
:ref:`kproplog(8)` can be used to force full replication when iprop is
|
||||
enabled.
|
||||
|
||||
|
||||
OPTIONS
|
||||
--------
|
||||
|
||||
**-r** *realm*
|
||||
Specifies the realm of the primary server.
|
||||
|
||||
**-A** *admin_server*
|
||||
Specifies the server to be contacted for incremental updates; by
|
||||
default, the primary admin server is contacted.
|
||||
|
||||
**-f** *file*
|
||||
Specifies the filename where the dumped principal database file is
|
||||
to be stored; by default the dumped database file is |kdcdir|\
|
||||
``/from_master``.
|
||||
|
||||
**-F** *kerberos_db*
|
||||
Path to the Kerberos database file, if not the default.
|
||||
|
||||
**-p**
|
||||
Allows the user to specify the pathname to the :ref:`kdb5_util(8)`
|
||||
program; by default the pathname used is |sbindir|\
|
||||
``/kdb5_util``.
|
||||
|
||||
**-D**
|
||||
In this mode, kpropd will not detach itself from the current job
|
||||
and run in the background. Instead, it will run in the
|
||||
foreground.
|
||||
|
||||
**-d**
|
||||
Turn on debug mode. kpropd will print out debugging messages
|
||||
during the database propogation and will run in the foreground
|
||||
(implies **-D**).
|
||||
|
||||
**-P**
|
||||
Allow for an alternate port number for kpropd to listen on. This
|
||||
is only useful in combination with the **-S** option.
|
||||
|
||||
**-a** *acl_file*
|
||||
Allows the user to specify the path to the kpropd.acl file; by
|
||||
default the path used is |kdcdir|\ ``/kpropd.acl``.
|
||||
|
||||
**--pid-file**\ =\ *pid_file*
|
||||
In standalone mode, write the process ID of the daemon into
|
||||
*pid_file*.
|
||||
|
||||
**-s** *keytab_file*
|
||||
Path to a keytab to use for acquiring acceptor credentials.
|
||||
|
||||
**-x** *db_args*
|
||||
Database-specific arguments. See :ref:`Database Options
|
||||
<dboptions>` in :ref:`kadmin(1)` for supported arguments.
|
||||
|
||||
|
||||
FILES
|
||||
-----
|
||||
|
||||
kpropd.acl
|
||||
Access file for kpropd; the default location is
|
||||
``/usr/local/var/krb5kdc/kpropd.acl``. Each entry is a line
|
||||
containing the principal of a host from which the local machine
|
||||
will allow Kerberos database propagation via :ref:`kprop(8)`.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kprop(8)`, :ref:`kdb5_util(8)`, :ref:`krb5kdc(8)`,
|
||||
:ref:`kerberos(7)`, inetd(8)
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
.. _kproplog(8):
|
||||
|
||||
kproplog
|
||||
========
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
||||
**kproplog** [**-h**] [**-e** *num*] [-v]
|
||||
**kproplog** [-R]
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
The kproplog command displays the contents of the KDC database update
|
||||
log to standard output. It can be used to keep track of incremental
|
||||
updates to the principal database. The update log file contains the
|
||||
update log maintained by the :ref:`kadmind(8)` process on the primary
|
||||
KDC server and the :ref:`kpropd(8)` process on the replica KDC
|
||||
servers. When updates occur, they are logged to this file.
|
||||
Subsequently any KDC replica configured for incremental updates will
|
||||
request the current data from the primary KDC and update their log
|
||||
file with any updates returned.
|
||||
|
||||
The kproplog command requires read access to the update log file. It
|
||||
will display update entries only for the KDC it runs on.
|
||||
|
||||
If no options are specified, kproplog displays a summary of the update
|
||||
log. If invoked on the primary, kproplog also displays all of the
|
||||
update entries. If invoked on a replica KDC server, kproplog displays
|
||||
only a summary of the updates, which includes the serial number of the
|
||||
last update received and the associated time stamp of the last update.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
**-R**
|
||||
Reset the update log. This forces full resynchronization. If
|
||||
used on a replica then that replica will request a full resync.
|
||||
If used on the primary then all replicas will request full
|
||||
resyncs.
|
||||
|
||||
**-h**
|
||||
Display a summary of the update log. This information includes
|
||||
the database version number, state of the database, the number of
|
||||
updates in the log, the time stamp of the first and last update,
|
||||
and the version number of the first and last update entry.
|
||||
|
||||
**-e** *num*
|
||||
Display the last *num* update entries in the log. This is useful
|
||||
when debugging synchronization between KDC servers.
|
||||
|
||||
**-v**
|
||||
Display individual attributes per update. An example of the
|
||||
output generated for one entry::
|
||||
|
||||
Update Entry
|
||||
Update serial # : 4
|
||||
Update operation : Add
|
||||
Update principal : test@EXAMPLE.COM
|
||||
Update size : 424
|
||||
Update committed : True
|
||||
Update time stamp : Fri Feb 20 23:37:42 2004
|
||||
Attributes changed : 6
|
||||
Principal
|
||||
Key data
|
||||
Password last changed
|
||||
Modifying principal
|
||||
Modification time
|
||||
TL data
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
See :ref:`kerberos(7)` for a description of Kerberos environment
|
||||
variables.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
:ref:`kpropd(8)`, :ref:`kerberos(7)`
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue