The create-keytab script, when executed will ask a number of questions to guide the creation of the keytab. At the end the keytab will be validated to ensure it was created successfully. There are a number of features but of note is the ability to create a keytab against an existing service account and reset the password to something secret. How to create a kerberos keytab on Active Directory for Red Hat Enterprise Linux Solution Verified - Updated 2017-08-22T18:17:13+00:00 - English.
- How To Generate Keytab File For Mac Os
- How To Generate Keytab File For Mac Download
- How To Generate Keytab File In Windows
Background
- Now we got the magic krb5.keytab.proxy keyfile at least upload it via Webadmin at the bottom of this tab Web Security - HTTP/s - Advanced Now Login with the testuser on the 'client' mac via open directory and go to.
- The GlobalProtect™ app for Mac endpoints now supports Kerberos V5 single sign-on (SSO) for GlobalProtect portal and gateway authentication. Kerberos SSO maintains a seamless logon experience by providing accurate User-ID™ information without user interaction.
- To use SNC with Kerberos authentication, you need a keytab file. We use cookies and similar technologies to give you a better experience, improve performance, analyze traffic, and to personalize content. By continuing to browse this website you agree to the use of cookies. Create Custom PDF.
As well as storing user accounts and their passwords, the Kerberos servers (KDCs) store accounts and keys (similar to passwords) for systems. Those accounts and keys are used as part of the authentication process to verify which user is connecting to a network service. These accounts are generally called service principals.
Every network service to which a user may authenticate needs to have a service principal with a corresponding key. The network service has to have a copy of that key on the system so that it can verify a user's identity. That key is stored in a specially formatted file called a keytab. One keytab file can store multiple keys, either multiple keys for the same service principal or even keys for several different service principals. On a UNIX system, you can view the contents of a keytab with the
klist -k
command.Applications that need to authenticate to network services on an automated basis also need to have service principals and keys in a keytab. For example, any process that writes into a protected directory in AFS needs to have a service principal that it can use to authenticate to AFS.
Due to how Kerberos works, a network service needs to have a separate key for every type of encryption that it supports. We currently support 256-bit AES encryption (the strongest and most modern, but not universally supported yet), triple-DES, and (for legacy compatibility, which will be phased out) DES. Most service principals will therefore have three keys, one for each type of encryption. Kerberos automatically selects the strongest key supported by both the client and server, so normally you don't have to worry about this implementation detail.
To recap, a service principal is an account, an identity, stored in Kerberos for a particular application. That service principal has one or more keys, similar to passwords. Those keys are stored on the server on which the service runs in a file called a keytab, which you can view with the
klist -k
command.Types of service principals
There are two basic types of service principals in use at Stanford. The first set are called the 'host-based' service principals, meaning that they're tied to a network service running on a particular host. Principals of this type will always have a name like:
where type specifies the type of service and system is the system on which that service is running. The most commonly used service types are:
host/*
— remote logins via SSH, rlogin, or rsh, and verification of local loginswebauth/*
— WebAuth authentication for web servers
To allow remote login to a system using Kerberos authentication, that system must have a host/* service principal. That principal is also used to verify local logins (to the console, for example) if it exists. The keytab for that service principal must be installed locally in the path expected by the login servers (usually /etc/krb5.keytab).
Can you cook crack in a microwave. To use WebAuth, the web server must have a webauth/* service principal and its keytab must be installed in the location set in the WebAuth configuration.
Host-based principals should not be shared and should not be reused. Each host providing a service should have a separate host-based principal for that service, and if that host is replaced by another with a new name, a new host-based principal should be obtained. Specifically, even if a set of web servers are part of a pool that uses WebAuth to serve one site, each server should have a separate host-based WebAuth principal and not share the same one. The principal name is independent of the URL of the web site being served and should match the system's primary name in NetDB.
Other supported but less-often-used services are:
HTTP/*
— HTTP Negotiate-Authafpserver/*
— Mac OS file sharingcifs/*
— CIFS (primarily Windows file sharing)ftp/*
— FTP file transferimap/*
— IMAP mail accessldap/*
— LDAP directorieslpr/*
— printingnfs/*
— NFSv3 and later file servicespop/*
— POP mail accesssieve/*
— Sieve mail filter editing on Cyrus IMAPsmtp/*
— authenticated SMTPxmpp/*
— Jabber
In order to use Kerberos authentication with the corresponding network service, you must have the appropriate service principal and install the keytab in a location used by that network service.
The second type of service principal is a principal used by an application to authenticate to other network services. The most common network services to which automated processes want to authenticate is the campus LDAP directory service and campus-wide AFS file system, but some applications may need access to other services as well. These types of service principals are associated with an application rather than a particular system and would move to a different system if that application were moved. At Stanford, these principals are named:
where application is some concise but meaningful designator for the application that will use this service principal.
Creating service principals
Stanford uses a system called the wallet for managing nearly all service principals and setting permissions on those principals so that campus system administrators can download and install keytabs for the appropriate service principals. For information about that process, see Downloading Keytabs with the Wallet.
kinit is used to obtain and cache Kerberos ticket-granting tickets. This tool is similar in functionality to the kinit tool that are commonly found in other Kerberos implementations, such as SEAM and MIT Reference implementations.
The user must be registered as a principal with the Key Distribution Center (KDC) prior to running kinit.
SYNOPSIS
DESCRIPTION
By default, on the Windows platform a cache file named
<USER_HOME>krb5cc_<USER_NAME>
will be generated. <uid>
is the user identification number of the user logged into the system.<USER_HOME>
is obtained from the java.lang.System
property user.home
. <USER_NAME>
is obtained from java.lang.System
property user.name
. If <USER_HOME>
is null, the cache file would be stored in the current directory that the program is running from. <USER_NAME>
is the operating system's login username. This username could be different than the user's principal name. For example on Windows NT, it could be c:winntprofilesdukekrb5cc_duke
, in which duke
is the <USER_NAME>
and c:winntprofilesduke
is the <USER_HOME>
.By default, the keytab name is retrieved from the Kerberos configuration file. If the keytab name is not specifed in the Kerberos configuration file, the name is assumed to be
<USER_HOME>krb5.keytab
If you do not specify the password using the
password
option on the command line, kinit will prompt you for the password.- Note:
password
is provided only for testing purposes. Do not place your password in a script or provide your password on the command line. Doing so will compromise your password.
For more information see the man pages for kinit.
How To Generate Keytab File For Mac Os
COMMANDS
Usage:
kinit [-fp] [-c <cache_name>] [-k] [-t <keytab_filename>] [<principal>] [<password>] [-help]
How To Generate Keytab File For Mac Download
Command Option | Description |
---|---|
-A | Do not include addresses. |
-f | Issue a forwardable ticket. |
-p | Issue a proxiable ticket. |
-c <cache_name> | The cache name (i.e., FILE:d:tempmykrb5cc ). |
-k | Use keytab |
-t <keytab_filename> | The keytab name (i.e, d:winntprofilesdukekrb5.keytab ). |
<principal> | The principal name (i.e., [email protected] ). |
<password> | The principal's Kerberos password. (DO NOT SPECIFY ON COMMAND LINE OR IN A SCRIPT.) |
-help | Displays instructions. |
EXAMPLES
Requesting credentials valid for authentication from the current client host, for the default services, storing the credentials cache in the default location (
c:winntprofilesdukekrb5cc_duke
):Requesting proxiable credentials for a different principal and storing these credentials in a specified file cache:
Requesting proxiable and forwardable credentials for a different principal and storing these credentials in a specified file cache:
Displaying the help menu for kinit:
SECURITY ALERT
How To Generate Keytab File In Windows
The
password
flag is for testing purposes only. Do not specify your password on the command line. Doing so is a security hole since an attacker could discover your password while enumerating all running processes in the system, for example.Copyright © 1993, 2020, Oracle and/or its affiliates. All rights reserved.