Understanding KDC Architecture


The KDC process is called krb5kdc, which is located inside /usr/sbin, and is started and monitored by the kdcmond daemon, which is specified by the launchd XML property list/System/Library/LaunchDaemons/com.apple.kdcmond.xml. The configuration file, /var/ db/krb5kdc/kdc.conf, specifies per-realm configuration data to be used by the KDC, and it also specifies the port (88 UDP and TCP/IP) over which the krb5kdc process communicates. As the following figure illustrates, krb5kdc is controlled by the command kdb5_util and reads from kdc.conf, .k5.YOURSERVER.YOURREALM.COM, and /var/db/krb5kdc/principal.

The KDC's user, host, and service principals are stored in /var/db/krb5kdc/principal. The principal database is encrypted with a key stored in a stash file called .k5.YOURSERVER. YOURREALM.COM (where YOURSERVER.YOURREALM.COM is the KDC's realm).

Tip

The files located in /var/db/krb5kdc are extremely sensitive and should be accessible only by root.


The Kerberos configuration files and data are backed up as part of the Open Directory Archive feature in Server Admin. You can back up just the KDC using kdb5_util, a utility for maintaining the Kerberos database. Like any database, it is problematic to back up the KDC while the krb5kdc process is running. Among other things, kdb5_util is useful for dumping the principal database to text to get a reliable backup. Keep in mind that the data in question is extremely sensitive; creating a copy of it, by definition, decreases your overall security. Generally this is an acceptable risk, given the improved redundancy that comes from a valid backup. Also keep in mind that these backups should be subject to the same security precautions as the other KDC files.

To dump the KDC's database, execute the following command:

sudo kdb5_util dump > /path/to/secure/backup


To load KDC data from a dumped file, execute the following command:

sudo kdb5_util load /path/to/secure/backup


Although these functions are not used regularly, the kdb5_util utility can be used to create and delete Kerberos databases and to manage the location of the stash file used to encrypt the database.

Kerberos Administration Architecture

The krb5kdc process largely accesses its database in a read-only fashionit doesn't make changes to Kerberos principals. For principal management, Apple has leveraged MIT's Kerberos administration architecture. The Kerberos administration daemon, kadmind, is responsible for making changes to the Kerberos database. Outside of Open Directory, kadmind is largely manipulated by the kadmin and kadmin.local command-line utilities. (These utilities will be covered in more depth in the next section.) Generally, in Mac OS X, the Apple tools are responsible for telling the kadmin tools what to do.

Several configuration files are used by kadmind, some of which can be modified for advanced customization but all of which are important for the sake of understanding the KDC's underlying structure. All of these files reside in /var/db/krb5kdc, because some are also used by the krb5kdc process. It can be confusing, but keep in mind that although krb5kdc reads the /var/db/krb5kdc/principal database, kadmind is primarily responsible for writing to it. The two processes are closely linked, and their configuration is intertwined. In reality, kadmind acts much like any other kerberized service required to have access to a secret key shared with the KDC. Typically keys are stored in /etc/krb5.keytab, but the key for kadmind is stored in /var/db/krb5kdc/keytab.

The kadm5.acl file is a list of Kerberos principals that have various administrative privileges. Kerberos's access controls are granular, as any principal may be granted one or more of a set of operations over any set of one or more other principals. However, in an out-of-the-box configuration, an Open Directory master has only two significant entries in kadm5.acl:

## This file autogenerated by KDCSetup ##

*/admin@MAINSERVER.PRETENDCO.COM *

diradmin *

The first line is a comment. The second line specifies that any principal with the /admin suffix can access any kadmin function. The last line specifies the principal that has complete access to all principals in the database (the administrator created when the machine was promoted to the Open Directory master role, by default).

Note

As of Mac OS X version 10.4, none of Apple's server management tools supports the /admin convention.


The database called principal.kadm5 is the kadmind process's policy database. It resides at /var/db/krb5kdc. While principals and their keys are stored in /var/db/krb5kdc/ principal, policies that can be applied to principals are stored in principal.kadm5.

You would edit this file when user-specific policies, such as a 60-day password change policy, are necessary for a given organization.

Finally, principal.kadm5.lock is a lock file used by kadmind. It acts essentially in the opposite of most lock files, though, as kadmind will not write to either the policy or principal database unless it exists.

Kerberos Administration Utilities

Kerberos administration in Mac OS X Server is integrated to such a level that administrators will rarely need to administer Kerberos manually using the Kerberos command-line tools. All of the Apple tools work together to manage Kerberos authentication data.

The kadmin command-line tool is the native MIT administrative client to kadmind. When kadmin starts, it reads the Kerberos configuration file, edu.mit.kerberos, to discover the network location of the kadmind server. kadmin does not need to be run from the KDC because it can be run remotely, over port 749. kadmin authenticates as any principal listed in the kadm5.acl file and is bound by the access controls listed there. While that provides remote administration, it also opens up another port on the server, but you have another option when attempting to manage certain aspects of Kerberos.

Unlike kadmin, kadmin.local cannot be run remotely, nor is it bound by the access controls of kadmind. Instead, it is a brute-force tool that is always run as root with full administrative privileges over the kadmind and KDC databases. This capability, as you will see later, is central to Apple's strategy to keep authentication data synchronized in Open Directory.

Both kadmin and kadmin.local can be run interactively or in query mode (using the -q flag). Despite the implication, "query" does not necessarily imply a read operation; query mode is useful for scripting changes to the Kerberos database.

The following are example applications of these tools:

  • Add a principal:

    sudo kadmin.local -q "add_principal johnisigna"

  • Add an admin principal, specifying a password:

    sudo kadmin.local -q "add_principal dave/admin -pw v3ryL8"

  • Add a principal that expires tomorrow:

    kadmin -p diradmin -q "add_principal -expire tomorrow temp0"

    Note

    Use kadmin rather than kadmin.local. kadmin makes some assumptions that are incorrect on Mac OS X as of v10.3.3, so use the -p flag to specify the proper principal.


  • Add a service principal:

    sudo kadmin.local -q "add_principal afpserver/secondaryserver.pretendco.com"

  • Delete a principal:

    sudo kadmin.local -q "delete_principal johnsigna"

  • Change the password on dave's admin principal:

    sudo kadmin.local -q "change_password dave/admin"

  • Get data about the principal tmp0:

    sudo kadmin.local -q "get_principal tmp0"

  • List all principals:

    sudo kadmin.local -q list_principals

    Note

    Policies are actually set up as an explicit set of requirements and then applied to a particular principal.


  • Establish a policy named salesforce:

    sudo kadmin.local -q "add_policy -minlength 8 -history 10 salesforce"

  • Add the salesforce policy to the principal deborah:

    sudo kadmin.local -q "modify_principal -policy salesforce deborah"

In general, a policy relates specifically to password requirements, such as history, length, and character restrictions. Other Kerberos settings, namely the password expiration date and change requirement, are stored in the principal, as seen in the output of the get_principal flag:

mainserver:~ nadmin$ sudo kadmin.local -q "get_principal deborah"


Here you are authenticating as principal: root/diradmin@MAINSERVER.PRETENDCO.COM so that you can view another user's principal.

Principal: deborah@MAINSERVER.PRETENDCO.COM Expiration date: Sat Oct 1 00:00:00 PDT 2005 Last password change: Sat Sep 24 19:46:35 PDT 2005 Password expiration date: [none] Maximum ticket life: 0 days 10:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Sat Sep 24 19:46:35 PDT 2005 (root/diradmin@MAINSERVER.PRETENDCO.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 4 Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt Key: vno 2, ArcFour with HMAC/md5, no salt Key: vno 2, DES cbc mode with CRC-32, no salt Key: vno 2, DES cbc mode with CRC-32, Version 4 Attributes: REQUIRES_PRE_AUTH REQUIRES_PWCHANGE Policy: policy11520min





Apple Training Series. Mac OS X System Administration Reference, Volume 1
Apple Training Series: Mac OS X System Administration Reference, Volume 1
ISBN: 032136984X
EAN: 2147483647
Year: 2005
Pages: 258
Authors: Schoun Regan

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net