GSS Tsig

GSS-‐TSIG (3.7.1 / 6.7.1 and later)
Last update: August 7, 2012

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 1

Table of Contents

General Knowledge ...................................................................................................................................... 4

Ports ......................................................................................................................................................... 4
System specifications ............................................................................................................................... 4
Supported GSS-‐TSIG configurations ......................................................................................................... 4
GSS–TSIG Overview ...................................................................................................................................... 5
Kerberos ................................................................................................................................................... 5
What is Kerberos .................................................................................................................................. 5
Kerberos Server .................................................................................................................................... 5
Kerberos Clients ................................................................................................................................... 5
Kerberos Realms .................................................................................................................................. 6
Kerberos Authentication Step By Step ................................................................................................. 6
GSSAPI ...................................................................................................................................................... 8
What is GSSAPI ..................................................................................................................................... 8
How it works ........................................................................................................................................ 8
GSS-‐TSIG ................................................................................................................................................... 9
What is GSS-‐TSIG? ................................................................................................................................ 9
How it works ........................................................................................................................................ 9
GSS-‐TSIG Step by step ........................................................................................................................ 10
GSS-‐TSIG Context Negotiation ........................................................................................................... 10
GSS-‐TSIG Secure DDNS update ........................................................................................................... 11
Configuration on Windows Server ............................................................................................................. 12
Server Manager (WINDOWSDomain Controller) ................................................................................... 12
Computer Information ....................................................................................................................... 12
Security Information .......................................................................................................................... 12
Roles Summary ................................................................................................................................... 12
Features .............................................................................................................................................. 12
Windows Domain Controller Properties ............................................................................................ 13
DNS Manager ......................................................................................................................................... 13
Forward Zone Properties .................................................................................................................... 14
Reverse Zone Properties .................................................................................................................... 15
Windows Firewall with Advanced Security ............................................................................................ 16
Active Directory User – Adonis1 (DHCP Client for GSS-‐TSIG) ................................................................. 16
Configuration files on Adonis ..................................................................................................................... 18
etc/dhcpd.conf (Only master shown) ..................................................................................................... 18
etc/ntp.conf (Only master shown) ......................................................................................................... 19
replicated/etc/krb5.conf (Only master shown) ...................................................................................... 19
replicated/etc/krb5.keytab .................................................................................................................... 20
etc/resolv.conf (Only master shown) ..................................................................................................... 20
etc/hosts ................................................................................................................................................ 20

Commands on Adonis ................................................................................................................................ 22
Kinit ........................................................................................................................................................ 22
Typical usage ...................................................................................................................................... 22
Output ................................................................................................................................................ 22
Command options .............................................................................................................................. 22
Klist ......................................................................................................................................................... 23
Typical usage ...................................................................................................................................... 23
Output from command above ........................................................................................................... 23
Additional usage ................................................................................................................................. 23
Command options .............................................................................................................................. 24
Commands on Windows DC ....................................................................................................................... 25
Ktpass ..................................................................................................................................................... 25
Typical usage ...................................................................................................................................... 25
Command options .............................................................................................................................. 25
Setspn ..................................................................................................................................................... 27
Typical usage ...................................................................................................................................... 27
Command options .............................................................................................................................. 27
Adsiedit.msc ........................................................................................................................................... 29
Log files on Adonis ..................................................................................................................................... 30
var/log/syslog ..................................................................................................................................... 30
Complete initialization / negotiation of the security context ............................................................ 30
Log Breakdown ................................................................................................................................... 31
Windows 7 Client Release .................................................................................................................. 31
Windows 7 Client Renew ................................................................................................................... 32
Windows Event Viewer .......................................................................................................................... 32
Troubleshooting and Common Error Messages ......................................................................................... 33
Troubleshooting ..................................................................................................................................... 33
Clock Skew .......................................................................................................................................... 33
Encryption Types ................................................................................................................................ 34
Key Tables .......................................................................................................................................... 35
Domain/REALM Mapping ................................................................................................................... 35
Name Resolution ................................................................................................................................ 36
Firewall ............................................................................................................................................... 36
Common Error Messages ....................................................................................................................... 38
Kinit error messages ........................................................................................................................... 38
References / External Links ........................................................................................................................ 41


General Knowledge
Ports

Port TCP/UDP? Description
88 TCP + UDP Kerberos
53 TCP + UDP DNS
67 UDP DHCP
68 UDP DHCP
System specifications

VM Version RAM IP Notes
Proteus 3.7.1 4GB 172.21.12.101
Adonis 6.7.1 1GB 172.21.12.110 DHCP master
Adonis 6.7.1 1GB 172.21.12.111 DHCP failover
Windows DC 2008 EE R2 2GB 172.21.12.115 AD / DNS primary
Windows 7 1GB 172.21.12.116 DHCP client

All of these VM’s are hosted in VMware Lab Manager (torvlmw01.bluecatnetworks.corp) and available
only to Tim Krzywonos and Tyler Wheeler
Supported GSS-‐TSIG configurations

Currently there are three supported GSS-‐TSIG configurations. Only option 1 is outlined in this document,
but the troubleshooting section will be more generalized information. Options 2 and 3 will be added
later.
1. Adonis DHCP with Microsoft DNS -‐ Covered in this document
• Kerberos Server on Microsoft DC
• Microsoft DNS 2003 / 2008 (32/64 bit)
• Adonis DHCP (Managed by Proteus Server) NO XHA
• Proteus v3.7.0 P3 or newer only

2. Adonis DNS with Microsoft DHCP – Not covered in this document
• Microsoft DHCP 2003 / 2008 (32/64 bit)
• Adonis DNS (Managed by Proteus Server) NO XHA

3. Adonis DNS/DHCP – Not covered in this document
• Adonis DNS (Managed by Proteus Server) NO XHA
• Adonis DHCP (Managed by Proteus Server) NO XHA


GSS–TSIG Overview
Kerberos
What is Kerberos

The Kerberos protocol name is based on the three-‐headed dog figure from Greek mythology known as
Kerberos. The three heads of Kerberos comprise the Key Distribution Center (KDC), the client and server
with the desired service to access.

Kerberos is an authentication and network security protocol originally developed at MIT. Kerberos
provides a means for client and servers applications to authenticate each other over an insecure
network in a secure manner through the use of symmetric key cryptography; this involves using a
trusted third party, called a Key Distribution Center (KDC) composed of two logically separate parts: the
Authentication Server (AS) and the Ticket Granting Server (TGS).
Kerberos Server

The KDC software is installed on a server machine – Kerberos Server. The client applications (such as a
DDNS client) communicate with the KDC server in order to be able to authenticate themselves to the
server applications (such as a DNS server).

Server applications may not need to communicate with the KDC, as they usually hold a long-‐term key
that allows them to ensure the client is trusted by KDC.

There are two mainstream KDC implementations, one by Microsoft, and the other by MIT.
Proteus/Adonis components were only tested with Microsoft KDC, but there is no technical reason why
it shouldn’t work with the MIT Kerberos server implementation.
Kerberos Clients

Kerberos Clients are the client and server applications (such as DNS clients and servers) that
communicate with the KDC (or Kerberos Server) in order to authenticate each other. Kerberos Clients
use a Kerberos library for this purpose (both Microsoft and MIT provide such libraries).

On Linux, the MIT Kerberos library is provided as part of the installation in the libkrb5 package. Adonis
servers use this Kerberos library via the following shared objects: /usr/lib/libkrb5.so and
/usr/lib/libkrb5support.so.

On Adonis the MIT Kerberos library is configured using a configuration file that is usually located in
/etc/krb5.conf. This file contains the IP address or host name of the KDCs, and other information that
the client or server applications may need to communicate with the KDC and authenticate each other.

Both client and server applications are, in Kerberos terms, principals. Both have records in the Kerberos
database, and a password to authenticate them to the KDC. Non-‐interactive applications usually use
“long-‐term” keys that are derived from their respective passwords. For example, when a DHCP server

updates a DNS server, both client (DHCP) and server (DNS) applications are non-‐interactive, so both will
use these “long-‐term” keys.

On Linux, these keys are stored usually in /etc/krb5.keytab file. Adonis DHCP, for example, uses this file,
but Adonis DNS uses /jail/named/etc/krb5.keytab.

Note: If the password of the Kerberos principal changes, these keys must be regenerated for Kerberos
Authentication to continue working. As we later explain, with Adonis DNS and DHCP this is done at
deployment time, from Proteus.
Kerberos Realms

Much like the Microsoft Windows domains, Kerberos has the ability to divide the network in groups or
“realms”. This separation is made to avoid too many requests being sent to a single KDC, which would
become a bottleneck for the authentication service and thus for the whole network.

The realm name is typically mapped to the Domain Name of the network (DNS), or to sub-‐domain
names, although this is not mandatory it is the recommended approach. Each Kerberos realm typically
contains at least one mapped Service Principal Name (SPN). This is an item, user or service, which needs
to be authenticated. An example of a SPN is below:

Principal/instance@REALM. COM

Note: The realm is commonly written in capital letters to differentiate the Domain Name from the
Kerberos realm. As a best practice your realm names should be capitalized.
Kerberos Authentication Step By Step

The picture below illustrates the Kerberos Authentication process between non-‐interactive Linux based
client and server applications.

KDC (Key Distribution Center)
2 Database
5
Authentication Ticket Granting
Service Service
Q
3 A _REQ
EP
_ RE REP
S _R
GS S_
4 T 6 TG
S
1 A
Client Server
libkrb5.so 7 AP_REQ libkrb5.so
krb5.conf krb5.conf
8 AP_REP
krb5.keytab krb5.keytab


1. AS_REQ: The client application submits a request to the Authentication Service component of the
KDC (Kerberos Server). This request is submitted in clear text and simply contains the UserID. No
password is submitted (although the client application will have generated a secret key based on a
hash of the password, which it will use later to decrypt the response from the Authentication
Server).

2. The Authentication Service uses the UserID to lookup the password stored in its database. It uses
the hash of the password to encrypt a generated session key for the client application to begin
communications with the Ticket Granting Service (TGS).

3. AS_REP: The Authentication Service sends a response which contains two messages:

a. The encrypted session key for the Ticket Granting Service (TGS).

b. A Ticket Granting Ticket (TGT), which contains the client ID, client network address, ticket
validity period, and the Ticket Granting Service (TGS) session key; all encrypted using the
secret key of the Ticket Granting Service (TGS).

4. TGS_REQ: The client decrypts the session key using the password hash for the UserID that it is
authenticating. The client then submits a service ticket request to the TGS. The request is composed
of the Ticket Granting Ticket that it received from the Authentication Server (which the client will
not have been able to decrypt), along with the Service ID being requested; and an Authenticator
which includes the client’s ID and a timestamp encrypted using the decrypted session key

5. The TGS decrypts the Ticket Granting Ticket to obtain the session key that it can use to authenticate
the user by decrypting the Authenticator. The TGS is also able to lookup the service in the database,
using the Service ID, to obtain the secret key for the service.

6. TGS_REP: The TGS sends a response to the client, which includes the requested Service Ticket
(encrypted using the secret key of the service), and a Service Session Key generated by TGS and
encrypted using the Client/TGS session key.

7. AP_REQ: The client decrypts the Service Session Key, using the TGS session key that it obtained from
the Authentication Server. It then generates a service request to the server that it wishes to access.
The service request contains the Service Ticket (which the client has been unable to decrypt), along
with the Service Session Key that it has received from the TGS.

8. AP_REP: The server is able to decrypt the Service Ticket using its own secret key. Within the service
ticket is the information required to validate the Service Session Key that the client has submitted in
its request. The server is able to respond to the client, securely by encrypting traffic using the
Service Session Key, and can be certain that the client is properly authenticated.


Note: In Step #4, non-‐interactive client applications will use one of the “long-‐term” keys from their
Krb5.keytab file to decrypt the session key; it is important that the Kerberos Authentication Server uses

Note: In Step #7 and #8, AP_REQ and AP_REP are not standardized, and are application specific.one of
the encryption algorithms the client supports, i.e. it has a key in the keytab for that encryption
algorithm.

Note: In Step #8, non-‐interactive server applications will use one of the “long-‐term” keys from their
Krb5.keytab file to decrypt the Service Ticket. It is important that the Kerberos
GSSAPI
What is GSSAPI

The Generic Security Services Application Program Interface (GSSAPI, also GSS-‐API) is an application
programing interface for programs to access security services, such as Kerberos, NTLM, and others (the
dominant underlying security mechanism used with GSSAPI is Kerberos).

The GSSAPI, by itself, does not provide any security. Instead, security service vendors (such as MIT and
Microsoft) provide this. These are usually in the form of libraries installed with their security software.
These libraries presenta GSSAPI-‐compatible interface to application writers who can write their
application to use only the vendor-‐independent GSSAPI. If the security implementation ever needs
replacing, the application need not be rewritten.

On Linux, the MIT Kerberos package mentioned earlier includes a GSSAPI implementation for Kerberos
as a separate shared object: /usr/lib/libgssapi_krb5.so.

The Client and Server applications that need to authenticate each other can use the GSSAPI, rather than
the Kerberos libraries directly. In this case, the Client application (e.g. DHCP server updating DNS) would
use the GSSAPI library installed on the DHCP server machine and the server application (e.g. DNS Server)
would use the GSSAPI library installed on the DNS server machine.
How it works

The GSSAPI Client and Server applications exchange opaque messages (tokens) that hide the security
mechanism details from the higher-‐level application. The GSSAPI library provides calls to
generate/calculate these tokens, but does not provide/specify the means by which tokens are conveyed
between the Client and Server applications, this is application specific. However, GSSAPI tokens can be
sent over an insecure network as the mechanisms provide inherent message security.

After some number of tokens has been exchanged, the GSSAPI implementations at both ends inform
their local application that a security context has been established. Once the security context is
established, the parties can encrypt and/or sign sensitive application messages by using GSSAPI calls.
The Client and Server then can exchange these application messages.

The GSSAPI describes about 45 procedure calls. Significant ones are:
• GSS_Acquire_cred -‐ obtains the user's identity proof, often a secret cryptographic key

• GSS_Import_name -‐ converts a username or hostname into a form that identifies a security
entity

• GSS_Init_sec_context -‐ generates a client token to send to the server, usually a challenge

• GSS_Accept_sec_context -‐ processes a token from GSS_Init_sec_context and can generate a
response token to return

• GSS_Wrap -‐ converts application data into a secure message token (typically encrypted)

• GSS_Unwrap -‐ converts a secure message token back into application data
The GSSAPI has been standardized for the C (RFC 2744) and Java (JSR-‐072) languages.
GSS-‐TSIG
What is GSS-‐TSIG?

GSS-‐TSIG (Generic Security Service Transaction Signature) is an algorithm based on GSSAPI that allows
the DNS Client and Server applications to securely exchange/establish a key for securing DNS
transactions.

GSS-‐TSIG specifies exactly how the Client and Server applications exchange the GSSAPI tokens in order
to establish a GSS security context; this is done via TKEY DNS queries; recall that GSSAPI did not provide
for this
• How the Client application should use the established GSS security context to sign the DNS
requests and validate the signatures on the DNS responses

• How the Server application should use the GSS security context to validate the DNS request
signatures sent by the DNS clients, and generate the signatures for DNS responses
How it works

The DNS Client and Server applications are written to implement the respective Client and Server GSS-‐
TSIG algorithm. For example, the DHCP Server updating the DNS Server is a DNS client, so it must
implement the client side of the GSS-‐TSIG algorithm. The DNS Server would implement the server
aspects of the GSS-‐TSIG algorithm.

Both client and server implementations of the GSS-‐TSIG algorithm end up using the GSSAPI library calls
(which use Kerberos as the underlying security mechanism) to generate and process the GSS tokens. The
client and server use DNS requests/responses to exchange these tokens, until token processing routine
signals that the security context was established, on both client and server side.

The DNS client then uses another GSSAPI call to sign the DNS update message, and adds the signature to
the message, as specified by the GSS-‐TSIG.Upon receiving the DNS update request from the client, the
server uses the GSSAPI calls to validate the client’s signature, only then can it process the DNS update.

Before sending the response, the server will again use the GSSAPI to generate the response signature,
adds it to the response, and sends it back to the client.
GSS-‐TSIG Step by step

The following diagrams shows in more details the steps involved in the GSS-‐TSIG security context
negotiation and signed DDNS updates between a DHCP Server and a DNS Server that support GSS-‐TSIG.
For illustration purposes a Linux based DNS server is shown with a GSSAPI library and krb5 configuration
files. Microsoft DNS has an equivalent library, and may use registry or other Windows component for
storing configuration. But any DNS would perform the same steps for negotiating the GSS-‐TSIG security
context and executing a DDNS update.

Note: any GSS-‐TSIG enabled DNS Client would perform the same steps as the DHCP Server shown
below.
GSS-‐TSIG Context Negotiation

KDC (Key Distribution Center) DHCP Server (DNS Client) DNS Server
krb5.conf krb5.keytab krb5.conf krb5.keytab

Database DHCP Service libgssapi_krb5.so DNS Service libgssapi_krb5.so
Service Service
1 AS_REQ
Entry point for
2 Lookup First DHCP query
Client Pwd resulting in a
3 AS_REP secure DDNS
update
4 Acquire DHCP
Server Credential
5 DHCP Server
GSS Credential
6 Initialize
Security Context
7 TGS_REQ
8 Lookup
Server Pwd
9 TGS_REP
10 Return Token
(including TGS)
11 TKEY Request (AP_REQ)
(containing returned Token with TGS)
12 Accept
Security Context
13 Accept Result,
Token
14 TKEY Response (AP_REP)
(containing result, and Token)
15 Initialize
Security Context
16 Return Token
Save Security Context
17 Save Security Context


GSS-‐TSIG Secure DDNS update

KDC (Key Distribution Center) DHCP Server (DNS Client) DNS Server
krb5.conf krb5.keytab krb5.conf krb5.keytab

Database DHCP Service libgssapi_krb5.so DNS Service libgssapi_krb5.so
Service Service
Entry point for

Subsequent
DHCP queries
18 Obtain TSIG Key
resulting in a
from Security Context
secure DDNS
update 19 Generate
Request Signature
20 Signature
21 Signed DDNS update request

22 Verify Request
Signature
23 Verify Result
24 Perform DDNS Update
25 Obtain TSIG Key

from Security Context
26 Generate Response
Signature
27 Signature
28 Signed DDNS update response

29 Verify Response
Signature
30 Verify Result


Configuration on Windows Server

Below are screenshots of the key areas of the Windows Server (2008 EE R2) that was used in this
document. Since this is not a how-‐to document, all areas that need to be configured are not covered.

This document only coversoption 1 from the “supported GSS-‐TSIG configurations” list noted above.
Server Manager (WINDOWSDomain Controller)

Computer Information

Security Information

Roles Summary

Features


Windows Domain Controller Properties

This server has DC type of Global Catalog and was configured using DCPROMO utility. The default
functional level chosen was Windows 2003.

DNS Manager

The DNS Manager can be found in the Administrative Tools folder or in the Server Manager. Below
shows the forward zones for “w00t.com” and the reverse zone 12.21.172.in-‐addr.arpa (The reverse for
the 172.21.12.0 /24 network).


Forward Zone Properties

By right clicking on the forward zone “w00t.com”, choosing “properties” and selecting the “General”
tab, you can see the “Status:” shows “Running” and “Dynamic updates:” shows “Secure only”. This is
required for GSS-‐TSIG to function properly.

Note: Added additional forward DNS entries. They were created for all of our BlueCat systems used in
our config.


Reverse Zone Properties

By right clicking on the reverse zone “12.21.172.in-‐addr.arpa”, choosing “properties” and selecting the
“General” tab, you can see the “Status:” shows “Running” and “Dynamic updates:” shows “Secure only”.
This is required for GSS-‐TSIG to function properly in our scenario.

Note: Added forward DNS entries below. They were created when we added the forward
entries. Weselected the option to automatically create the reverse “PTR” records.


Windows Firewall with Advanced Security

In our scenario we wanted to make sure that we enabled the “Kerberos Key Distribution Center Inbound
Rules for (TCP-‐In) and (UDP-‐In)”. They should be already defined and only need to be enabled. You must
have all four Kerberos Key Distribution Center Rules enable for KDC server to work with GSS-‐TSIG
correctly. You can find the “Windows Firewall with Advanced Security” in “Administrator Tools”.

Active Directory User – Adonis1 (DHCP Client for GSS-‐TSIG)

The next few screenshots show the user that was created for adonis1 and adonis2 DHCP.


Notice the “User logon name:” in the second screen shot, was changed after running ktpass from
adonis1 to “DHCP/adonis1@w00t.com” (ktpass command and syntax are shown later in the document).

Note: We also selected AES256 encryption in Account Options.

Below shows the adonis1 is a Member of the “Domain Users” for “w00t.com/Users”


Configuration files on Adonis
/etc/dhcpd.conf (Only master shown)

The dhcpd.conf file is a free-‐form ASCII text file. The file may contain extra tabs and newlines for
formatting purposes. Keywords in the file are case-‐insensitive. Comments may be placed anywhere
within the file (except within quotes). Comments begin with the # character and end at the end of the
line. In general the dhcpd.conf contains configuration information for the dhcpd.

Note: Please note the area highlighted in yellow below. These are key entries for the zone declarations
andthe tkey configuration information for the gssapi credentials.

tkey-‐domain "W00T.COM";
tkey-‐gssapi-‐credential "DHCP/adonis1.w00t.com";

zone w00t.com
{
primary 172.21.12.115;
gss-‐tsig-‐updates true;
}

zone 12.21.172.in-‐addr.arpa
{
primary 172.21.12.115;
gss-‐tsig-‐updates true;
}

subnet 172.21.12.0 netmask 255.255.255.0
{
option subnet-‐mask 255.255.255.0;
option broadcast-‐address 172.21.12.255;
default-‐lease-‐time 300;
client-‐updates false;
ddns-‐domainname "w00t.com";
ddns-‐rev-‐domainname "in-‐addr.arpa";
ddns-‐updates true;
option domain-‐name-‐servers 172.21.12.115;
option routers 172.21.12.1;
pool
{
failover peer "ac150c6e-‐ac150c6f";
range 172.21.12.250 172.21.12.253;
}
}


/etc/ntp.conf (Only master shown)

The ntp.conf configuration file is read at initial startup by the ntpd daemon in order to specify the
synchronization sources, modes and other related
information. Usually, it is installed in the /etc directory, but could be installed elsewhere.

adonis1:~# cat /etc/ntp.conf
#-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
# /etc/ntp.conf, configuration for ntpd
# ntpd will use syslog() if logfile is not defined");
#-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
#
logfile /var/log/ntpd
driftfile /var/lib/ntp/ntp.drift
#
server 172.21.12.101 prefer
server 127.127.1.0
server 0.north-‐america.pool.ntp.org
server 0.europe.pool.ntp.org
fudge 127.127.1.0 stratum 7
#
#-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
#
#-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
Note: server 172.21.12.101 is the IP address of Proteus.
/replicated/etc/krb5.conf (Only master shown)

The krb5.conf file contains Kerberos configuration information, including the locations of KDCs and
admin servers for the Kerberos realms of interest, defaults for the current realm and for Kerberos
applications, and mappings of hostnames onto Kerberos realms.

[libdefaults]
default_realm = W00T.COM
dns_lookup_kdc = false
default_tkt_enctypes = aes256-‐cts aes128-‐cts arcfour-‐hmac des3-‐cbc-‐sha1 des-‐cbc-‐md5 des-‐cbc-‐crc
default_tgs_enctypes = aes256-‐cts aes128-‐cts arcfour-‐hmac des3-‐cbc-‐sha1 des-‐cbc-‐md5 des-‐cbc-‐crc

[realms]
W00T.COM = {
kdc = 172.21.12.115:88
dns_lookup_kdc = false
default_domain = w00t.com
}

Note: aes256-‐cts only appear when the AES256 libraries have been installed. Please see
troubleshooting section below for additional information.

• default_realm identifies the default realm to be used in a client host's Kerberos activity.

• dns_lookup_kdc indicates whether DNS SRV records should be used to locate the KDCs and
other servers for a realm, if they are not listed in the information for the realm. The default is to
use these records.

• default_tkt_enctypesidentifies the supported list of session key encryption types that should be
requested by the client, in the same format.

• default_tgs_enctypes identifies the supported list of session key encryption types that should
be returned by the KDC. The list may be delimited with commas or whitespace.

• kdc is the name of a host running a KDC for that realm. An optional port number (preceded by a
colon) may be appended to the hostname.

• default_domainidentifies the default domain for which hosts in this realm are assumed to be in.
/replicated/etc/krb5.keytab

Krb5.keytab is a Kerberos keytab file containing pairs of Kerberos principals and encrypted keys, which
are derived from the Kerberos password. You can use this file to log into Kerberos without being
prompted for a password. The most common personal use of keytab files is to allow scripts to
authenticate to Kerberos without human interaction or the storing of a password in a plaintext file.

Note: Since this is a binary file, we will not show the contents of the file here.

/etc/resolv.conf (Only master shown)

This is the resolver configuration file. Here we have defined the IP address of the Windows DNS / DC.

nameserver 172.21.12.115
• nameserverthis is the IP address of the Windows DNS server.
Note: This has to be added manually and is required for option 1 from the “supported GSS-‐TSIG
configurations” list noted above (page 5).
/etc/hosts

The hosts file is a static table lookup for hostnames. This simple text file associates IP addresses with
hostnames, one line per IP address. For each host a single line should be present with the following
information:

IP_address canonical_hostname [aliases...]


Below is the hosts file from adonis1:

127.0.0.1 localhost
172.21.12.110 adonis1.w00t.com adonis1
172.21.12.115 windows-‐dc.w00t.com

• 172.21.12.115 was added. It is the Windows DC / DNS server / Kerberos Server
Note: The Windows DC was added manually.


Commands on Adonis
Kinit
The kinit command obtains or renews a Kerberos TGT. The KDC options specified by the [kdcdefault]
and [realms] in the Kerberos configuration file (krb5.conf) are used if you do not specify a ticket flag on
the command line. If you are not renewing an existing ticket, the command reinitializes the credentials
cache and will contain the new ticket-‐granting ticket received from the KDC. The typical usage example
below has verbose output and specifies the keytab file to use with the service principal name.
Typical usage

kinit -‐Vkt /replicated/etc/krb5.keytab DHCP/adonis1.w00t.com@W00T.COM
Output

adonis1:/# kinit-‐Vkt /replicated/etc/krb5.keytab DHCP/adonis1.w00t.com@W00T.COM
Authenticated to Kerberos v5
Command options

Usage

kinit [-‐5] [-‐4] [-‐V] [-‐l lifetime] [-‐s start_time] [-‐r renewable_life] [-‐f | -‐F] [-‐p | -‐P] [-‐a | -‐A] [-‐v] [-‐R] [-‐k [-‐t
keytab_file]] [-‐c cachename] [-‐S service_name][-‐X <attribute>[=<value>]] [principal]

Options Valid with Kerberos version

-‐5 Kerberos 5 (available)
-‐4 Kerberos 4 (available)(Default behavior is to try Kerberos 5)
-‐V (verbose)Either 4 or 5
-‐l (lifetime) Either 4 or 5
-‐s (start time) 5
-‐r (renewable lifetime) 5
-‐f forwardable) 5
-‐F (not forwardable) 5
-‐p (proxiable) 5
-‐P (not proxiable) 5
-‐a (include addresses) 5
-‐A (do not include addresses) 5
-‐v (validate) 5
-‐R (renew)5, or both 5 and 4
-‐k (use keytab) 5, or both 5 and 4
-‐t (filename of keytab to use) 5, or both 5 and 4
-‐c (Kerberos 5 cache name) 5
-‐S (service) 5, or both 5 and 4
-‐X <attribute>[=<value>] 5

Klist

Klist displays the Kerberos principal and Kerberos tickets held in a credentials cache, or the keys held in
a keytab file.
Typical usage

klist -‐ket /replicated/etc/krb5.keytab
Output from command above

adonis2:/# klist -‐ket /replicated/etc/krb5.keytab
Keytab name: FILE:/replicated/etc/krb5.keytab
KVNO Timestamp Principal
-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
8 07/30/12 16:54:07 DHCP/adonis1.w00t.com@W00T.COM (AES-‐256 CTS mode with 96-‐bit SHA-‐1 HMAC)
8 07/30/12 16:54:07 DHCP/adonis1.w00t.com@W00T.COM (AES-‐128 CTS mode with 96-‐bit SHA-‐1 HMAC)
8 07/30/12 16:54:07 DHCP/adonis1.w00t.com@W00T.COM (ArcFour with HMAC/md5)
8 07/30/12 16:54:07 DHCP/adonis1.w00t.com@W00T.COM (Triple DES cbc mode with HMAC/sha1)
8 07/30/12 16:54:07 DHCP/adonis1.w00t.com@W00T.COM (DES cbc mode with RSA-‐MD5)
8 07/30/12 16:54:07 DHCP/adonis1.w00t.com@W00T.COM (DES cbc mode with CRC-‐32)
Additional usage

klist -‐e

adonis1:/# klist -‐e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: DHCP/adonis1.w00t.com@W00T.COM

Valid starting Expires Service principal
07/30/12 17:23:32 07/31/12 03:23:23 krbtgt/W00T.COM@W00T.COM
renew until 07/31/12 17:23:32, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with
HMAC/md5
07/30/12 17:23:23 07/30/12 19:23:32 DNS/windows-‐dc.W00T.COM@W00T.COM
renew until 07/31/12 17:23:32, Etype (skey, tkt): AES-‐256 CTS mode with 96-‐bit SHA-‐1 HMAC,
AES-‐256 CTS mode with 96-‐bit SHA-‐1 HMAC


Command options

Usage

klist [-‐5] [-‐4] [-‐e] [[-‐c] [-‐f] [-‐s] [-‐a [-‐n]]] [-‐k [-‐t] [-‐K]] [name]
(Default is Kerberos 5 and Kerberos 4)
-‐c specifies credentials cache
-‐k specifies keytab
(Default is credentials cache)
-‐e shows the encryption type

Options for credential caches

-‐f shows credentials flags
-‐s sets exit status based on valid tgt existence
-‐a displays the address list
-‐n do not reverse-‐resolve

Options for keytabs

-‐t shows keytab entry timestamps
-‐K shows keytab entry DES keys


Commands on Windows DC
Ktpass

Configures the server principal name for the host or service in Active Directory Domain Services (AD DS)
and generates a keytab file that contains the shared secret key of the service. The keytab file is based on
the Massachusetts Institute of Technology (MIT) implementation of the Kerberos authentication
protocol. The Ktpass command-‐line tool allows non-‐Windows services that support Kerberos
authentication to use the interoperability features provided by the Kerberos Key Distribution Center
(KDC) service in Windows Server 2003 / 2008.
Typical usage

ktpass -‐princ DHCP/adonis1.w00t.com@W00T.COM -‐mapuser adonis1@W00T. -‐ptype
KRB5_NT_PRINCIPAL -‐crypto AES256-‐SHA1 -‐kvno 8 -‐pass Password123 -‐out adonis1.keytab

C:\Users\Administrator>ktpass -‐princ DHCP/adonis1.w00t.com@W00T.COM -‐mapuser ado
nis1@W00T.COM -‐ptype KRB5_NT_PRINCIPAL -‐crypto AES256-‐SHA1 -‐kvno 8 -‐pass Password123
-‐out adonis1.keytab
Targeting domain controller: windows-‐dc.w00t.com
Using legacy password setting method
Successfully mapped DHCP/adonis1.w00t.com to adonis1.
Key created.
Output keytab to adonis1.keytab:
Keytab version: 0x502
keysize 81 DHCP/adonis1.w00t.com@W00T.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 8 etyp
e 0x12 (AES256-‐SHA1) keylength 32 (0x6066ebbc640cc11b44cc41fdb4a53300bad69f9f368
1e02faf512fbab7f202a0)
Command options

Most useful arguments

[-‐ /] out : Keytab to produce
[-‐ /] princ : Principal name (user@REALM)
[-‐ /] pass : password to use
use '*' to prompt for password.
[-‐ +] rndPass : ... or use +rndPass to generate a random password
[-‐ /] minPass : minimum length for random password (def:15)
[-‐ /] maxPass : maximum length for random password (def:256)

Less useful arguments

[-‐ /] mapuser : map princ (above) to this user account (default: don't)
[-‐ /] mapOp : how to set the mapping attribute (default: add it)

[-‐ /] mapOp : is one of:
[-‐ /] mapOp : add : add value (default)
[-‐ /] mapOp : set : set value
[-‐ +] DesOnly : Set account for des-‐only encryption (default:don't)
[-‐ /] in : Keytab to read/digest

Options for key generation

[-‐ /] crypto : Cryptosystem to use
[-‐ /] crypto : is one of:
[-‐ /] crypto : DES-‐CBC-‐CRC : for compatibility
[-‐ /] crypto : DES-‐CBC-‐MD5 : for compatibility
[-‐ /] crypto : RC4-‐HMAC-‐NT : default 128-‐bit encryption
[-‐ /] crypto : AES256-‐SHA1 : AES256-‐CTS-‐HMAC-‐SHA1-‐96
[-‐ /] crypto : AES128-‐SHA1 : AES128-‐CTS-‐HMAC-‐SHA1-‐96
[-‐ /] crypto : All : All supported types
[-‐ /] IterCount : Iteration Count used for AES encryption
Default: ignored for non-‐AES, 4096 for AES
[-‐ /] ptype : principal type in question
[-‐ /] ptype : is one of:
[-‐ /] ptype : KRB5_NT_PRINCIPAL : The general ptype-‐-‐ recommended
[-‐ /] ptype : KRB5_NT_SRV_INST : user service instance
[-‐ /] ptype : KRB5_NT_SRV_HST : host service instance
[-‐ /] ptype : KRB5_NT_SRV_XHST :
[-‐ /] kvno : Override Key Version Number
Default: query DC for kvno. Use /kvno 1 for Win2K compat.
[-‐ +] Answer : +Answer answers YES to prompts. -‐Answer answers NO.
[-‐ /] Target : Which DC to use. Default:detect
[-‐ /] RawSalt : raw salt to use when generating key (not needed)
[-‐ +] DumpSalt : show us the MIT salt being used to generate the key
[-‐ +] SetUpn : Set the UPN in addition to the SPN. Default DO.
[-‐ +] SetPass : Set the user's password if supplied.


Setspn
A command-‐line tool that is built into Windows Server 2003 / 2008 and is available if you have the
Active Directory Domain Services (AD DS) server role installed.The setspn tool Reads, modifies, and
deletes the Service Principal Names (SPN) directory property for an Active Directory service account. You
use SPNs to locate a target principal name for running a service. You can use the setspntool to also view
the current SPNs, reset the account's default SPNs, and add or delete supplemental SPNs.
Typical usage

setspn –A DHCP/adonis1.w00t.com@W00T.COM adonis1


C:\Users\Administrator>setspn -‐A DHCP/adonis1.w00t.com@W00T.COM adonis1
Registering ServicePrincipalNames for CN=adonis1,CN=Users,DC=w00t,DC=com
DHCP/adonis1.w00t.com@W00T.COM
Updated objects
Command options

setspn [modifiers switch] [accountname]

Where "accountname" can be the name or domain\name
of the target computer or user account

Edit Mode Switches

-‐R = reset HOST ServicePrincipalName
Usage: setspn -‐R accountname

-‐A = add arbitrary SPN
Usage: setspn -‐A SPN accountname

-‐S = add arbitrary SPN after verifying no duplicates exist
Usage: setspn -‐S SPN accountname

-‐D = delete arbitrary SPN
Usage: setspn -‐D SPN accountname

-‐L = list SPNs registered to target account
Usage: setspn [-‐L] accountname

Edit Mode Modifiers

-‐C = specify that accountname is a computer account

-‐U = specify that accountname is a user account

Note: -‐C and -‐U are exclusive. If neither is specified, the toolwill interpret accountname as a
computer name if such a computerexists, and a user name if it does not.

Query Mode Switches

-‐Q = query for existence of SPN
Usage: setspn -‐Q SPN

-‐X = search for duplicate SPNs
Usage: setspn -‐X

Note: searching for duplicates, especially forest wide, can takea long period of time and a large
amount of memory. -‐Q will executeon each target domain/forest. -‐X will return duplicates that
existacross all targets. SPNs are not required to be unique across forests,but duplicates can
cause authentication issues when authenticatingcross-‐forest.

Query Mode Modifiers

-‐P = suppresses progress to the console and can be used when redirectingoutput to a file or when used
in an unattended script. There will be nooutput until the command is complete.

-‐F = perform queries at the forest, rather than domain level

-‐T = perform query on the specified domain or forest (when -‐F is also used)
Usage: setspn -‐T domain (switches and other parameters)
"" or * can be used to indicate the current domain or forest.

Note: these modifiers can be used with the -‐S switch in order to specifywhere the check for duplicates
should be performed before adding the SPN.

Note: -‐T can be specified multiple times.

Examples

setspn -‐T * -‐T foo -‐X
Will report all duplicate registration of SPNs in this domain and foo

setspn -‐T foo -‐F -‐Q */daserver
Will find all SPNs of the form */daserver registered in the forest towhich foo belongs


Adsiedit.msc

This is the Microsoft Active Directory Services Interface editor. It should be used when you need to
verify the KVNO # associated to a specific user account (associated with a SPN = Service Principal Name).
To do this, follow the instructions below.
On the Windows Domain Controller machine:

1. Go to Start/Run… and run adsiedit.msc; this will open an Active Directory LDAP explorer
2. Navigate to CN=Users/CN=<user name> in the left tree;
3. Right click and select Properties; this will open a list of properties for the user object
Scroll down and find msDS-‐KeyVersionNumber attribute; its value is the KVNO and will be
incremented every time user changes password or ktpass utility is executed

Log files on Adonis
/var/log/syslog

Below is the syslog output from the Adonis DHCP server (adonis1.w00t.com). This was captured using
“tail –f /var/log/syslog” and captures a Windows 7 Client on initial startup (with the initializing /
negotiation) of the security context, after a DHCP client release and renew.
Complete initialization / negotiation of the security context

Jul 23 13:59:18 adonis1 dhcpd: DHCPDISCOVER from 00:50:56:13:02:b3 via eth0
Jul 23 13:59:19 adonis1 dhcpd: DHCPOFFER on 172.21.12.250 to 00:50:56:13:02:b3 (Windows7-‐DHCP)
via eth0
Jul 23 13:59:19 adonis1 dhcpd: KDC host info not initialized, attempting to initialize
Jul 23 13:59:19 adonis1 dhcpd: acquiring GSS-‐TSIG credentials
Jul 23 13:59:19 adonis1 dhcpd: acquired GSS-‐TSIG credentials
Jul 23 13:59:19 adonis1 dhcpd: acquired GSS-‐TSIG credential
Jul 23 13:59:19 adonis1 dhcpd: GSS-‐TSIG security context for server 172.21.12.115 is new or marked for
retry, checking if server is alive...
Jul 23 13:59:19 adonis1 dhcpd: ns_lookup function for W00T.COM with type 6
Jul 23 13:59:19 adonis1 dhcpd: addr=172.21.12.115
Jul 23 13:59:19 adonis1 dhcpd: ns_lookup: answer returned 0
Jul 23 13:59:19 adonis1 dhcpd: Found SOA name=W00T.COM rdatalength=46
Jul 23 13:59:19 adonis1 dhcpd: Found MNAME name=windows-‐dc.W00T.COM
Jul 23 13:59:19 adonis1 dhcpd: Server 172.21.12.115 is alive; mname=windows-‐dc.W00T.COM
Jul 23 13:59:19 adonis1 dhcpd: GSS-‐TSIG security context state for server 172.21.12.115 changed to OK
Jul 23 13:59:19 adonis1 dhcpd: service principal DNS/windows-‐dc.W00T.COM@W00T.COM: ddnsgss.c:
686
Jul 23 13:59:19 adonis1 dhcpd: initializing/negotiating GSS-‐TSIG security context with requested lifetime
of 7200 seconds
Jul 23 13:59:19 adonis1 dhcpd: GSS-‐TSIG security context negotiation will continue
Jul 23 13:59:19 adonis1 dhcpd: initializing/negotiating GSS-‐TSIG security context with requested lifetime
of 7200 seconds
Jul 23 13:59:19 adonis1 dhcpd: GSS-‐TSIG security context negotiation completed; context will be valid
for 7209 seconds
Jul 23 13:59:19 adonis1 dhcpd: TSIG(GSSTSIG) verification success
Jul 23 13:59:20 adonis1 dhcpd: Added new forward map from Windows7-‐DHCP.w00t.com to
172.21.12.250
Jul 23 13:59:20 adonis1 dhcpd: added reverse map from 250.12.21.172.in-‐addr.arpa to Windows7-‐
DHCP.w00t.com
Jul 23 13:59:20 adonis1 dhcpd: DHCPREQUEST for 172.21.12.250 (172.21.12.110) from
00:50:56:13:02:b3 (Windows7-‐DHCP) via eth0
Jul 23 13:59:20 adonis1 dhcpd: DHCPACK on 172.21.12.250 to 00:50:56:13:02:b3 (Windows7-‐DHCP) via
eth0
Jul 23 13:59:23 adonis1 dhcpd: DHCPINFORM from 172.21.12.250 via eth0

Jul 23 13:59:23 adonis1 dhcpd: DHCPACK to 172.21.12.250 (00:50:56:13:02:b3) via eth0
Log Breakdown
• KDC host info not initialized, attempting to initialize– KDC host information is being initialized.

• acquiring GSS-‐TSIG credentials– Acquire DHCP server credentials

• acquired GSS-‐TSIG credentials – DHCP Server credentials acquired

• GSS-‐TSIG security context for server – GSS-‐TSIG security context initialization checks continue

• GSS-‐TSIG security context state for server – Security context state is checked. If checks on SOA
and MNAME found the security context state is marked OK

• service principal DNS/windows-‐dc.W00T.COM@W00T.COM-‐ This is the Windows DNS SPN

• initializing/negotiating GSS-‐TSIG security context with requested lifetime of 7200 seconds –
GSS-‐TSIG security context is initialized and requested lifetime of 2 hour (7200 sec.) requested.

• GSS-‐TSIG security context negotiation completed; context will be valid for 7209 seconds–A
valid security context has been created and is ready for use. Security context is now saved by
DNS server and DHCP server (DNS Client).

• TSIG(GSSTSIG) verification success– TSIG Key now obtained from valid Security Context DDNS
updates can now proceed. You will now see this message before DDNS updates are completed.

• added new forward map– from hostname.domain.com to x.x.x.x (standard DDNS forward map)

• added reverse map – from x.x.x.x.in-‐addr.arpa to hostname.domain.com (standard DDNS
reverse map)
Windows 7 Client Release

Jul 23 14:01:01 adonis1 dhcpd: if Windows7-‐DHCP.w00t.com IN TXT
"31cf7c6d47c31c290ef8cacf5683ddca64" rrset exists and Windows7-‐DHCP.w00t.com IN A
172.21.12.250 rrset exists delete Windows7-‐DHCP.w00t.com IN A 172.21.12.250: success.
Jul 23 14:01:01 adonis1 dhcpd: if Windows7-‐DHCP.w00t.com IN A rrset doesn't exist and Windows7-‐
DHCP.w00t.com IN AAAA rrset doesn't exist delete Windows7-‐DHCP.w00t.com IN TXT
"31cf7c6d47c31c290ef8cacf5683ddca64": success.
Jul 23 14:01:01 adonis1 dhcpd: removed reverse map on 250.12.21.172.in-‐addr.arpa
Jul 23 14:01:01 adonis1 dhcpd: DHCPRELEASE of 172.21.12.250 from 00:50:56:13:02:b3 (Windows7-‐
DHCP) via eth0 (found)

Note: The message “TSIG(GSSTSIG) verification success” before a DDNS mapping shows that the

following DDNS request is using GSS-‐TSIG updates.
Windows 7 Client Renew

Jul 23 14:02:42 adonis1 dhcpd: DHCPDISCOVER from 00:50:56:13:02:b3 via eth0
Jul 23 14:02:43 adonis1 dhcpd: DHCPOFFER on 172.21.12.250 to 00:50:56:13:02:b3 (Windows7-‐DHCP)
via eth0
Jul 23 14:02:44 adonis1 dhcpd: Added new forward map from Windows7-‐DHCP.w00t.com to
172.21.12.250
Jul 23 14:02:44 adonis1 dhcpd: added reverse map from 250.12.21.172.in-‐addr.arpa to Windows7-‐
DHCP.w00t.com
Jul 23 14:02:44 adonis1 dhcpd: DHCPREQUEST for 172.21.12.250 (172.21.12.110) from
00:50:56:13:02:b3 (Windows7-‐DHCP) via eth0
Jul 23 14:02:44 adonis1 dhcpd: DHCPACK on 172.21.12.250 to 00:50:56:13:02:b3 (Windows7-‐DHCP) via
eth0

Note: The message “TSIG(GSSTSIG) verification success” before a DDNS mapping shows that the
following DDNS request is using GSS-‐TSIG updates.

Windows Event Viewer

Windows 2003 and 2008 offer extensive logging through the event viewer. These errors should be
looked up through the “event log online help” or by searching the specific error by event ID or through
the general description output.


Troubleshooting and Common Error Messages

Troubleshooting
When you begin troubleshooting a Kerberos problem and you are certain that the configuration is
correct, there are a few common trouble spots that you should check first:

• Clock skew
• Encryption types
• Key tables
• Domain/realm mapping
• Name resolution
• Firewall

Note: Additional troubleshooting information can also be found on CARE in KB-‐2956
Clock Skew
Time differences are a common factor when dealing with Kerberos configuration. Kerberos requires that
all the computers in the environment have system times within 5 minutes of one another. If computers
that a client is attempting to use for either initial authentication (the Kerberos server) or resource access
(including both the application server and, in a cross-‐realm environment, an alternate Kerberos server)
have a delta greater than 5 minutes from the client computer or from one another, the Kerberos
authentication will fail.
Time Sync Error Messages
Time synchronization problems can be identified when an error similar to “Clock skew too great” is
returned, although other more obscure errors may also indicate time synchronization problems.
Windows-‐based computers may generate Event ID 11 from w32time in their event log if the computer is
having trouble synchronizing its time.
Common Time Sync Issues
• Basic time syncing. Is each computer in the environment within 5 minutes of all the others?
Note that an environment where the client is 3 minutes slower than the Kerberos server and the
application server is 3 minutes faster than the Kerberos server represents a time syncing
problem, as the total skew is 6 minutes.

• Time zone inconsistencies. Clocks may appear to be in sync and still create problems if time
zones on either computer are not set correctly. On UNIX-‐based computers the date -‐u command
can be used to check the absolute time of each computer.


Note: For additional information for “Configuring Time Services for a Heterogeneous UNIX and
Windows Environment.” Please navigate to:

http://technet.microsoft.com/en-‐us/library/bb463171.aspx

Encryption Types
Each Kerberos implementation supports a set of encryption types used to encrypt part of the Kerberos
traffic. The set of supported encryption types varies slightly by implementation, so in building a
heterogeneous environment encryption types that are supported for all involved implementations must
be selected. For example, Active Directory® directory service supports the RC4-‐HMAC encryption type,
but native UNIX and older MIT implementations do not.

Many UNIX implementations support the SHA1 encryption type, but Active Directory does not (except
with Windows 2008 and 2008 R2). Most implementations support DES-‐CRC and DES-‐MD5. Although
these encryption types are not as secure as RC4-‐HMAC and SHA1.

Note: Proteus and Adonis currently support the following encryption types:

• AES-‐128 CTS mode with 96-‐bit SHA1 HMAC (only for Windows 2008 server and 2008 R2)
• ArcFour with HMAC/md5
• Triple DES cbc mode with HMAC/sha1
• DES cbc mode with RSA-‐MD5
• DES cbc mode with CRC-‐32
Note: To add the AES256 encryption type, you will need to download the Java Cryptography Extension
(JCE) Unlimited Strength Jurisdiction Policy Files 6 from:

http://www.oracle.com/technetwork/java/javase/downloads/jce-‐6-‐download-‐429243.html

After you download jce_policy_6.zip file from the above URL, uncompress and extract the downloaded
files on your local system. Then follow the steps below:

1. SCP the two files located in the JCE folder (local_policy.jar and US_export_policy.jar) to the /root
folder on Adonis.
2. Locate the following two JAR files (local_policy.jar and US_export_policy.jar) on Adonis server by
running the following command as root:
find / -‐name "*policy.jar" –print

3. Backup the two files by navigating to path found in Step #2 above and running the following
commands:

cp local_policy.jar local_policy.BAK
cp US_export_policy.jar US_export_policy.BAK

4. Replace the two JAR files found in Step #2 above with the new ones copied to /root from Step
#1 by running the following commands (This must be done as root):

cp /root/*.jar /path/from/step2/
5. Restart command server on Adonis by running the following command:

commandServer.sh restart
Key Tables

In a Kerberos environment, both a client (a user) and a server (the server side component of an
application) must have a key (a password). On an application server, this key is stored in a key table (by
default a krb5.keytab file). If the key stored in the key table on the application server does not match
the key for this service stored in the Kerberos database, or if the application does not have access to
read the key from the table, the application will not be capable of completing its side of the Kerberos
transaction.
Common Key Table Issues

• The key, key version number, and key encryption type stored in the key table must match the
data for this service stored in Active Directory. To check the validity of the key, use the kinit
tool (e.g. kinit -‐Vkt /replicated/etc/krb5.keytab DHCP/adonis1.w00t.com@W00T.COM ) to
attempt to acquire an initial ticket because this service is based on the key stored in the key
table.

• The Keytable file becomes corrupted. You can re-‐run KTPass.exeon Windows to regenerate the
keytab file. When doing this a new output file should be specified. Remember that generating a
new key table will change the password of that account and increment the key version number.
It is always best to check adsiedit.msc (noted previously) and verify the msDS-‐
KeyVersionNumber attribute and then set Proteus to match.
Domain/REALM Mapping
To access Kerberized services, the client computer must be capable of resolving the DNS domain of the
target computer to the correct Kerberos REALM. This becomes an issue when the DNS domain name
does not match the Kerberos REALM name. Because mapping does not become an issue until the client
computer tries to access a service, domain to REALM mapping problems do not affect initial ticket
requests (TGTs). When mapping problems exist, service ticket requests may fail or access to Kerberized
services may fail. With Active Directory, the REALM name is always the uppercase equivalent of the DNS
domain name.

Look in your krb5.conf file to see if the [realms] section and the [domain_realm] section are correct for
your environment.
Name Resolution
Problems with Kerberos are often related to name resolution or Domain Name System (DNS) problems.
Active Directory domain controllers, Windows clients, UNIX clients, and application servers must all have
a shared understanding of the correct host names and IP addresses for each computer within the
environment. DNS is the typical way of computers doing name resolution; however, this might be
combined with hosts filesor other means. DNS will be the focus of this section. Configuration problems
with DNS can be subtle but still affect the functionality of Kerberos.
DNS-‐related Error Messages
Investigate DNS issues if you are experiencing error messages similar to those listed as follows:
• Server not found in Kerberos database.

• Cannot contact KDC for requested realm.
Common DNS Issues
• DNS problems are often encountered only during a service ticket request after a successful TGT
request. If a client can successfully authenticate initially but is then unable to acquire a service
ticket or access services, then DNS problems are the likely cause.
• The error “Server not found in Kerberos database” is common and can be misleading because it
often appears when the service principal is not missing. The error can be caused by
domain/realm mapping problems or it can be the result of a DNS problem where the service
principal name is not being built correctly. Server logs and network traces can be used to
determine what service principal is actually being requested.
• Kerberos is case sensitive. Problems can occur in an environment using host names with mixed
case. In the world of Kerberos, appserver1.EXAMPLE.COM and appserver1.example.com are not
the same. Check that DNS resolves host names with consistent case.
• Kerberos relies on the presence of both forward and reverse lookup entries in DNS. Check that
the host name of each computer can be resolved to its IP address and that its IP address can be
resolved to its host name.
• Look carefully at the configuration of any multihomed hosts. You might need to perform
network traces to determine which interfaces and what names are being used in requests to or
from computers with multiple network cards.
Firewall
Firewall systems can cause many different error messages to be misleading or non-‐existent. On
Windows based systems running firewall services, you must make sure Port 53 (UDP / TCP) and Port 88
(TCP / UDP) are open to reduce the problems with GSS-‐TSIG (using Option #1 as specified on page 5).
Note: You can verify if connection issues is on Adonis side by running the following TCPDump
command:

tcpdump -‐vvv -‐ni eth0 -‐s 0 port 88
Normal output
adonis1:~# tcpdump -‐vvv -‐ni eth0 -‐s 0 port 88

tcpdump: listening on eth0, link-‐type EN10MB (Ethernet), capture size 65535 bytes
20:59:23.020086 IP (tos 0x0, ttl 64, id 29941, offset 0, flags [DF], proto UDP (17), length 207)
172.21.12.110.53697 > 172.21.12.115.88: [udp sum ok] v5
20:59:23.021224 IP (tos 0x0, ttl 128, id 18158, offset 0, flags [none], proto UDP (17), length 258)
172.21.12.115.88 > 172.21.12.110.53697: [udp sum ok]
172.21.12.110.33894 > 172.21.12.115.88: [udp sum ok] v5
172.21.12.115.88 > 172.21.12.110.33894: [udp sum ok] v5
172.21.12.110.37773 > 172.21.12.115.88: [udp sum ok] v5
Blocked output
21:00:41.464628 IP (tos 0x0, ttl 64, id 13790, offset 0, flags [DF], proto TCP (6), length 60)
172.21.12.110.36378 > 172.21.12.115.88: S, cksum 0x713a (incorrect (-‐> 0xbac1),
3060986958:3060986958(0) win 5840 <mss 1460,sackOK,timestamp 178241936 0,nop,wscale 6>
172.21.12.110.37773 > 172.21.12.115.88: [udp sum ok] v5
172.21.12.110.36378 > 172.21.12.115.88: S, cksum 0x713a (incorrect (-‐> 0xb7d1),
172.21.12.110.37773 > 172.21.12.115.88: [udp sum ok] v5
172.21.12.110.36378 > 172.21.12.115.88: S, cksum 0x713a (incorrect (-‐> 0xb1f1),
Note: On Window Server in Event Viewer -‐> Security look for Event ID = 4768
Normal output
A Kerberos authentication ticket (TGT) was requested.
Account Information:
Account Name: adonis1

Supplied Realm Name: W00T.COM
User ID: W00T\adonis1
Service Information:

Service Name: krbtgt
Service ID: W00T\krbtgt

Network Information:
Client Address: 172.21.12.110
Client Port: 41192

Additional Information:
Ticket Options: 0x10
Result Code: 0x0
Ticket Encryption Type: 0x17
Pre-‐Authentication Type: 2
Common Error Messages

Kinit error messages

This section provides some general troubleshooting common Kerberos issues.
kinit(v5): Clock skew too great while getting initial credentials.

Time difference between the Adonis DHCP server and the Kerberos server; Windows Domain Controller
is too large. A Kerberos server will reject ticket requests from a client whose clock is not within the
specified maximum clock skew of the KDC. To address this issue, you must synchronize your system
clock with the KDC server clock. The default maximum allowed time skew is 5 minutes. Usually Adonis
system clock is synchronized with Proteus system clock, so you might need to adjust the system clock on
Proteus.

Best Practice: BlueCat recommends using NTP to synchronize the time on Proteus, Adonis and
Microsoft server.
kinit(v5): Clients credentials have been revoked while getting initial credentials.

Active Directory user account is disabled or locked. Check if the AD user account is enabled.
kinit(v5): Preauthentication failed while getting initial credentials

Wrong user password for DHCP service principal. Check that you have entered the correct user
password for the service principal in Proteus. The password needs to be matched with the Micosoft®
Active Directory user account password.

kinit(v5): Cannot contact any KDC for realm ‘EXAMPLE.COM’ while getting initial credentials.

KDC server is not available. Several network or service-‐related issues can be at the origin
of this message, including network disruption, incorrect IP configuration for the KDC server, or
temporary KDC serviceinterruption. Verify both server availability and network connectivity and verify if
the Kerberos realm name and KDC IP addresses configured in Proteus are correct.

kinit(v5): Cannot find KDC for requested realm while getting initial credentials

This error is caused by specifying the wrong Kerberos realm name. Verify that you have entered the
correct Kerberos realm name in Proteus.
kinit(v5): Client not found in Kerberos database while getting initial credentials

You have specified an incorrect DHCP service principal name in Proteus. Check the service principal
name matches the name in Active Directory.

Note: You may also see this error following periods of high DDNS traffic when AD synchronization is
running with Kerberos and DNS on the same server. In the DNS events log, we can see “Event ID: 4013
The DNS server is waiting for Active Directory Domain Services (AD DS) to signal that the initial
synchronization of the directory has been completed. The DNS server service cannot start until the
initial synchronization is complete because critical DNS data might not yet be replicated onto this
domain controller. If events in the AD DS event log indicate that there is a problem with DNS name
resolution, consider adding the IP address of another DNS server for this domain to the DNS server list
in the Internet Protocol properties of this computer. This event will be logged every two minutes until
AD DS has signaled that the initial synchronization has successfully completed.”
kinit(v5): KDC has no support for the encryption type

The Kerberos client (Adonis DHCP server) is trying to use an encryption type that the KDC does not
support. currently Proteus and Adonis support the following encryption types:

• ArcFour with HMAC/md5
• Triple DES cbc mode with HMAC/sha1
• DES cbc mode with RSA-‐MD5
• DES cbc mode with CRC-‐32
Syslog Error Messages
Dhcpd: Server <IP address> is NOT alive

DHCPD attempts to open a TCP port to the DNS server in question. Success indicates that the server is
operational. In addition, it performs a DNS request on the server in question by retrieving the SOA
record and server name using UDP. Therefore, we use these functions to determine the following:
• TCP path to the server exists

• UDP path to the server exists
• DNS is operational
• Server name is known

All of these are required to achieve successful communications with the DNS server using GSS-‐TSIG. In
the absence of one of these, the server is marked as non-‐operational and the alternate server is used (if
configured).
Example of an entry in syslog where the server is found to be alive:

Example of an entry in syslog where the server is found to not be alive:
Jul 23 13:59:19 adonis1 dhcpd: Server 172.21.12.115 is NOT alive

Example of syslog with entire found to be alive process:
Jul 23 13:59:19 adonis1 dhcpd: GSS-‐TSIG security context for server 172.21.12.115 is new or marked for
retry, checking if server is alive...
Jul 23 13:59:19 adonis1 dhcpd: ns_lookup function for W00T.COM with type 6
Jul 23 13:59:19 adonis1 dhcpd: addr=172.21.12.115
Jul 23 13:59:19 adonis1 dhcpd: ns_lookup: answer returned 0
Jul 23 13:59:19 adonis1 dhcpd: Found SOA name=W00T.COM rdatalength=46
Jul 23 13:59:19 adonis1 dhcpd: Server 172.21.12.115 is alive; mname=windows-‐dc.W00T.COM

Note: By default, a Kerberos client (i.e. the Adonis DHCP server when GSS-‐TSIG is deployed for Adonis
DHCP to update Microsoft Windows DNS) initially tries to send a request over UDP during
the Kerberos negotiation process. The server proceeds with preparing the response and attempting to
send it over UDP. If the response is too large to be sent over UDP, the Kerberos client automatically
switches to TCP. Although this process represents normal behavior, you may experience slower
response time for that request.

If TCP is preferred for the initial request, it can be configured on both the DNS and DHCP server side. To
force Windows to always use TCP, follow the instructions described in the following article:

http://support.microsoft.com/kb/244474


References / External Links

Secret Key Transaction Authentication for DNS (TSIG)
TSIG -‐ Wikipedia
Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-‐TSIG)
SPNEGO -‐ Wikipedia
Generic Security Service API Version 2 : C-‐bindings
JSR-‐000072 Generic Security Services API Specification 0.1
Oracle GSS-‐API Programming Guide
dhcp.conf man page
krb5.conf man page
What is a keytab, and how do I use one?
hosts(5) -‐ Linux man page
klist man page
Ktpass -‐ Windows Server 2008
Ktpass -‐ Windows Server 2003
Setspn -‐ Windows Server 2008
Setspn -‐ Windows Server 2003
MIT Kerberos Documentation
Kerberos (protocol) -‐ Wikipedia
Generic Security Services Application Program Interface-‐ Wikipedia
Configuring Time Services for a Heterogeneous UNIX and Windows Environment
Kerberos and LDAP Troubleshooting Tips
Additional Information Pertaining to GSS-‐TSIG in Proteus v3.7 P3 and later


GSS Tsig

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

GSS Tsig

Загружено:

Авторское право:

Доступные форматы

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 1

General Knowledge ...................................................................................................................................... 4

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 2

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 3

Supported GSS-­‐TSIG configurations

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 4

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 5

Kerberos Authentication Step By Step

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 6

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 7

How it works

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 8

How it works

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 9

GSS-­‐TSIG Step by step

GSS-­‐TSIG Context Negotiation

Authentication Ticket Granting

17 Save Security Context

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 10

Authentication Ticket Granting

Entry point for

21 Signed DDNS update request

24 Perform DDNS Update

25 Obtain TSIG Key

28 Signed DDNS update response

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 11

Server Manager (WINDOWSDomain Controller)

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 12

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 13

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 14

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 15

Active Directory User – Adonis1 (DHCP Client for GSS-­‐TSIG)

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 16

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 17

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 18

/replicated/etc/krb5.conf (Only master shown)

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 19

/etc/resolv.conf (Only master shown)

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 20

Note: The Windows DC was added manually.

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 21

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 22

Output from command above

Output from command above

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 23

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 24

Output from command above

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 25

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 26

Output from command above

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 27

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 28

On the Windows Domain Controller machine:

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 29

Complete initialization / negotiation of the security context

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 30

Windows 7 Client Release

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 31

Windows 7 Client Renew

Windows Event Viewer

INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION 32

Time Sync Error Messages

Common Time Sync Issues

Supported GSS-‐TSIG configurations

GSS-‐TSIG Step by step

GSS-‐TSIG Context Negotiation

Active Directory User – Adonis1 (DHCP Client for GSS-‐TSIG)

find / -‐name "*policy.jar" –print

DNS-‐related Error Messages

adonis1:~# tcpdump -‐vvv -‐ni eth0 -‐s 0 port 88

Jul 23 13:59:19 adonis1 dhcpd: Found MNAME name=windows-‐dc.W00T.COM