Microsoft trusting MIT Kerberos

Credits

Many thanks go out to Rene Dokter for his help on the Microsoft related parts. Without him I wouldn't have succeeded.

Introduction

When you have a heterogeneous network with Windows servers, Mac OS X servers and GNU/Linux servers you quickly discover that it is very hard to maintain a single database with passwords. You do not want to have NIS, OpenLDAP, AD, Open Directory, smbpasswd, and what have you, in your data center and maintain all those different databases with identical passwords and user information. We want an unified solution to store passwords.

The authentication solution: Kerberos

This document assumes the use of Kerberos V5, since that is what Microsoft, and Apple use. So also on the GNU/Linux installation we will be using the V5 version, and only the V5 solution.

The Pro's

Kerberos also makes sure no passwords are transmitted over the wire which makes it inherently more safe then any other product in the world.

By using trusts between the different systems a user logging in to e.g. Active Directory can use services on the GNU/Linux network without the need of logging in again. The user is “trusted”.

Next to these security and interoperability benefits there is also the gain of Single-Sign-On.

The first step of integration that we are talking about is the use of a single password store. Meaning that the user password is stored in a single place, and maintained in a single place. Active Directory and Open Directory should thus both use the MIT Kerberos server or trust the MIT kerberos server.

Definitions

Before we dive into the world of Kerberos and related stuff we would like you to read: http://web.mit.edu/kerberos/www/dialogue.html. And please, read it again, because understanding this story is crucial to understanding the rest of the document. After you have read the dialogue, we can start to introduce the key terms of Kerberos:

Security Principal or often just plain Principle

is the entity in the Kerberos database for a user or computer. You could compare this with the user name on other systems.

Realm

The collection of principals belonging to the same security group, or network. A windows domain is really a realm.

Ticket

Encrypted information used by all parties to authenticate a security principal. For every form of access a ticket is needed.

KDC

Key Distribution Center. The server responsible for supplying the tickets. It actually consists of two parts. The authentication service (AS) and the ticket granting service (TGS).

Authentication Service (AS): The service that initially verifies that a user is who he claims to be. When a user is authenticated, the KDC issues a ticket-granting ticket or TGT.
TGT: TGT is a Ticket-Granting-Ticket. With the TGT a user can request additional tickets to access services on the network. It is the TGT that makes Single Sign On possible.
Ticket Granting Service (TGS): The Ticket Granting Service verifies the user's identity using the Ticket Granting Ticket and issues a ticket for the desired service.

KRBTGT Account

This is a special account to create Ticket Granting Tickets.

Validating Server

Is the server that the client tries to access.

Session Key

Random number generated by the KDC when it builds a ticket. It is the shared secret that the KDC, the client, and the validating server have in common.

Key salt

the salt is a string concatenated to the password to make sure the string2key function creates a unique encryption key, via a one-way hash. In Kerberos 5 the salt is the complete principal name including the realm. The reason the salt is used is to make sure the outcome of the one way hash is unique across realms.

kvno

is an acronym for Key version number. Kerberos can hold multiple keys for a principal. To distinguish between those keys every key has version number. The number is incremented by one when the password or encryption is changed.

Active Directory

Since Microsoft Windows is a bit different from the rest of the world, it is worth a couple of words. The Microsoft Kerberos implementation is meant to replace NTLM. So a couple of services are still NTLM only and can not be used or can only by used through the GSSAPI which is called SSPI on Windows.

The domain name in Windows is case insensitive, while in MIT Kerberos it is case sensitive. Recent revisions to the Kerberos standard have specified that uppercase realm names are preferred and lowercase realm names have been depreciated.

Unlike the MIT implementation, the Windows Kerberos implementation uses an in-memory credential cache to store tickets and TGTs (the MIT implementation uses a disk file).

Microsoft also uses a couple of Microsoft specific terms:

User Principle Name - A Kerberos user principal
Service Principle Name - A Kerberos service or host principal
Update Sequence Number might be identical to kvno ???
Local Security Authority - Portion of Windows that calls upon log in services (WINLOGON and NETLOGON) to get security credentials from users. The user-side is the Local Security Subsystem (LSASS.EXE) and the server side is the Security Reference Monitor (SRM).

Con's

Of course there aren't only positive things about Kerberos, there are also weak points. So here we will give you some things to think about when using Kerberos and to maintain a secure system:

Kerberos uses a principal's password as the fundamental proof of identity, so as with every other kind of password based security, it is essential to keep the password private.
The strength of the security within Kerberos is based on the unbreakability of the encryption technology. Since we need to connect with Active Directory we are bound to rc4-hmac encryption.
A brute force attack on the KDC could compromise the entire network, since it contains all the passwords (in an encrypted version, but still). So the security of the KDC is essential.
Kerberos assumes that the host it is running on is safe, so if an attacker can get hold of a client it can steal tickets and during the lifetime of the ticket do the same things a normal user could.
On multi-user systems the above point even becomes more important. Meaning that the different users should not be able to access each others files and memory.
Since anybody can request a TGT of any user, and that ticket is encrypted with the user's secret key (password), it is simple to perform an offline attack on this ticket by trying to decrypt it with different passwords. Kerberos 5 introduced to solve this problem.

A MIT Kerberos installation

Expected knowledge

GNU/Linux (Operating System, DNS, OpenLDAP) knowledge is a must, Microsoft Windows (Operating System, DNS, AD) knowledge is a must and a good understanding of how user id's are used in the different systems is a must.

We also assume that the reader has setup an LDAP system before and knows his way around with tools that deal with user account creation on the different platforms.

Software used

Function	Host name	Software
AD server	ads.forest.example.com	Windows 2003 R2 Enterprise Edition Service Pack 2
Windows client	bofh015	Windows XP Professional Version 2002 Service Pack 3
GNU/Linux client	bofh011	Fedora release 9 (Sulphur), MIT Kerberos 1.6.3
GNU/Linux server	krb5.example.com	CentOS release 5.2 (Final), MIT Kerberos 1.6.1, OpenLDAP 2.3.27

It's about time

Kerberos is very time sensitive so make sure all your computers (servers and clients) use NTP. And are synced against the same time server. For our situation we used krb5.example.com as the NTP server.

DNS, realm or domain

MS Kerberos uses DNS for everything it needs to know about Kerberos, MIT also recommends the use of DNS, so we will do too.

It is possible to use non-DNS style Kerberos names, however that is not recommended and we will thus not use them. The advise is to use the uppercase naming of the DNS domain as the name for the Kerberos realm.

And for the GNU/Linux with MIT kerberos we use:

DNS: example.com

realm: EXAMPLE.COM

Note that MS also uses a NetBIOS name for its systems called the domain name, which might create confusion. For the Windows network we use:

DNS: forest.example.com

realm: FOREST.EXAMPLE.COM

NETBIOS: FOREST

Throughout this document, when we refer to domain, we mean the DNS domain. For Kerberos we will refer to realm and for NetBIOS we will call it the NetBIOS name or Microsoft domain.

The MIT Kerberos server

The krb5.conf file is a Windows INI style configuration file. This file is located in the /etc directory and used on both the workstation and the server to configure Kerberos.

This file can have different sections, which are headed by the section name in square brackets ([]). The available sections are:

libdefaults – contains default values for the kerberos library
login – contains default values for the klogin program
appdefaults – contains the defaults for kerberized applications
realms – contains realm descriptions
domain_realm – describes relationships between DNS domains and realms
logging – describes how logging is performed (only needed on the KDC)
capaths – contains the authentication paths for cross-realm authentication

If there is no DNS TXT record you must specify the default_domain in the realms section. If no SRV records are used the KDC an admin_server tags are mandatory in the realms section. Since our DNS is setup correctly we strictly speaking only need the admin_server tag. To make sure that even without the SRV tags everything works we provide you with a full krb5.conf configuration file, if you also mention the host names with IP addresses in you host file, Kerberos will keep on running even without DNS:

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = true

[realms]
EXAMPLE.COM = {
	kdc = kerberos.example.com:88
	admin_server = kerberos.example.com:749
	default_domain = EXAMPLE.COM
}

[domain_realm]
.examle.com = EXAMPLE.COM
example.com = EXAMPLE.COM

[appdefaults]
pam = {
	debug = true
	ticket_lifetime = 36000
	renew_lifetime = 36000
	forwardable = true
	krb4_convert = false
}

Next we need to setup the kdc.conf file, which is also a windows style INI file. It can be found in /var/kerberos/krb5kdc/kdc.conf. The sections in the file are:

kdcdefaults – defaults for overall KDC behaviour
realms – specifies realm specific information

In the realms section we have reduced the amount of supported_enctypes to the ones supported by Microsoft Windows. Since Open Directory uses MIT Kerberos all systems should use the same encryption types (also known as etypes, more on etypes can be found in Appendix A).

[kdcdefaults]
v4_mode = none
# kdc_tcp_ports = 88

[realms]
EXAMPLE.COM = {
	# GENERIC STUFF
	#master_key_type = des3-hmac-sha1
	dict_file = /usr/share/dict/words
	supported_enctypes = rc4-hmac:normal rc4-hmac-exp:normal des-cbc-crc:normal

	# DB stuff
	acl_file = /var/kerberos/krb5kdc/example.com/kadm5.acl
	admin_keytab = /var/kerberos/krb5kdc/example.com/kadm5.keytab
	database_name = /var/kerberos/krb5kdc/example.com/principals

	# PRINCIPAL stuff

}

We store our database information in a realm specific directory, so we will be able to add realms in the future and have a directory per realm, we thus need to create the directory:

mkdir /var/kerberos/krb5kdc/example.com

To give certain users the ability to change settings in the password store, and others only the ability to query we have to create an access control list called the kadmin.acl in the directory of the realm:

krbadm@EXAMPLE.COM *
*/admin@EXAMPLE.COM *
*/*@EXAMPLE.COM i
*@EXAMPLE.COM i

Now that everything is in place we can create our database:

kdb5_util create -r EXAMPLE.COM -s

The -s option generates a stash file.

NOTE: The database can be remove with:

rm -f /var/kerberos/krb5kdc/example.com/principals*
rm -f /var/kerberos/krb5kdc/.k5.EXAMPLE.COM

Add administrators to the Kerberos database

Create an admin account that acts as our root account on Kerberos:

kadmin.local
kadmin.local: addprinc admin/admin@EXAMPLE.COM

With the listprincs command you can get an overview of the currently available principals.

kadmin.local:  listprincs 
K/M@EXAMPLE.COM
admin/admin@EXAMPLE.COM 
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM 
kadmin/krb5.example.com@EXAMPLE.COM
kadmin/history@EXAMPLE.COM 
krbtgt/EXAMPLE.COM@EXAMPLE.COM

You see that besides our just created admin/admin account there are a couple more, which are automatically created for you and are needed by Kerberos to function correctly.

krb5.keytab

All non-Microsoft Kerberos machines need a file, called /etc/krb5.keytab, to authenticate to the KDC. The keytab file is an encrypted, local, on-disk copy of the KDC's key. In order to generate a keytab for a host, the host must have a principal in the Kerberos database.

Since our KDC is also a client for itself it needs such a krb5.keytab file. Before we can generate the keytab file, we first need to add krb5 to the database as a known host with a password, but we also want to be flexible, we do not want to change all keytab files when we promote e.g. a slave as a master. So we will not use krb5 as the host name, but it's alias kerberos.

The password that is generated for the key should never be changed, we thus use the -randkey option to generate a random password, which even we will not know. Using kadmin.local we generate the host principal for krb5 like this:

kadmin.local: addprinc -randkey host/kerberos.example.com

Now we can extract the needed keys to our local /etc/krb5.keytab file:

kadmin.local: ktadd host/kerberos.example.com
kadmin.local: ktadd kadmin/admin
kadmin.local: ktadd kadmin/changepw

Start the KDC and KADMIN

On Red Hat based systems, like ours, we run authconfig-tui and add Kerberos support to make sure PAM is setup correctly. After that we can start our services.

Starting krb5kdc

service krb5kdc start

Starting kadmind

Adjust the /etc/init.d/kadmin script to reflect our setup. Since the current script assumes everything to be in /var/kerberos/krb5kdc/ we had to tweak the script a bit.

For CentOS 5.2 change around line 25 the following:

# See where our KDC stores its stuff 
# we assume single realm. 
KDC_CONF="/var/kerberos/krb5kdc/kdc.conf"
	
db_file=`grep database_name ${KDC_CONF} |grep -v ^# | awk '{print $3}'`

For CentOS 5.3 change around line 29:

       if [ ! -f /var/kerberos/krb5kdc/principal ] ; then

into (note the plural):

       if [ ! -f /var/kerberos/krb5kdc/example.com/principals ] ; then

Now we can start kadmin:

service kadmin start

Reading MIT KDC logs

To help in debugging certain problems it helps to understand the logging of the MIT kerberos server. Let us start with a log line from the krb5kdc.log:

Feb 26 17:02:01 krb5.example.com krb5kdc[26922](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 192.168.1.3: \
	ISSUE: authtime 1235664121, etypes {rep=23 tkt=16 ses=23}, kprutser@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM

The first element is AS_REQ in our example. Here is a complete list of possible elements and their meaning:

AS_REQ is the initial user authentication request (i.e. made with kinit) This message is directed to the KDC component known as Authentication Server (AS);
AS_REP is the reply of the Authentication Server to the previous request. Basically it contains the TGT (encrypted using the TGS secret key) and the session key (encrypted using the secret key of the requesting user);
TGS_REQ is the request from the client to the Ticket Granting Server (TGS) for a service ticket. This packet includes the TGT obtained from the previous message and an authenticator generated by the client and encrypted with the session key;
TGS_REP is the reply of the Ticket Granting Server to the previous request. Located inside is the requested service ticket (encrypted with the secret key of the service) and a service session key generated by TGS and encrypted using the previous session key generated by the AS;
AP_REQ is the request that the client sends to an application server to access a service. The components are the service ticket obtained from TGS with the previous reply and an authenticator again generated by the client, but this time encrypted using the service session key (generated by TGS);
AP_REP is the reply that the application server gives to the client to prove it really is the server the client is expecting. This packet is not always requested. The client requests the server for it only when mutual authentication is necessary.

Between semi-colons are the etypes supported by the requester. The negative numbers are numbers used by protocol implementers, so they are vendor specific, and the positive numbers come from RFC 3961.

The IP address (192.168.1.3) mentioned is the IP address of the requesting party.

Then we get the authtime which is in seconds since 1970-01-01 00:00:00 UTC.

Then we get where this request was based on {rep=23, tkt=16, ses=23}, which is where in this case my problem was. The ticket is etype 16, while as we saw before, the client didn't support des3-cbc-sha1-kd. Both reply (rep) and session(ses) have the correct type. More on the different etypes can be found in Appendix B

Adding workstations

This section will add workstations and an user to the MIT Kerberos server.

Adding the user

Add a test user to the Kerberos database:

kadmin.local: addprinc kprutser
WARNING: no policy specified for kprutser@EXAMPLE.COM; defaulting to no policy 
Enter password for principal "kprutser@EXAMPLE.COM":
Re-enter password for principal "kprutser@EXAMPLE.COM": 
Principal "kprutser@EXAMPLE.COM" created.

For the GNU/Linux system this user should be present in a user database where the UID and GID can be resolved, like OpenLDAP. And for windows this user should be present in AD. See the PIG documentation on creating AD users with OpenLDAP tools.

The GNU/Linux workstation

On the Linux client we need a krb5.conf file that reflects our server setup, here we fully use the DNS features:

[libdefaults]
# default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = true

[appdefaults]
pam = {
	debug = true
	ticket_lifetime = 36000
	renew_lifetime = 36000
	forwardable = true
	krb4_convert = false
}

On Red Hat based systems we run authconfig-tui and add kerberos to the client machine.

Add the kerberos host to the local /etc/krb5.keytab file:

kadmin: ktadd host/kerberos.example.com 
kadmin: quit

Or copy the /etc/krb5.keytab file from your Kerberos host.

With klist make sure the kvno's are identical.

Tests

Use kinit to sign in. (we need to get a ticket)

kinit kprutser
Password for kprutser@EXAMPLE.COM:

Use klist to show that you got a real ticket

ssh to realm kdc (should be able to login without password)

ssh to kerberos (you should be able to connect without password)

The Windows XP Workstation

On a clean workstation add the realm to XP, by issuing on the command line:

ksetup /setrealm EXAMPLE.COM
ksetup /addkdc EXAMPLE.COM kerberos.example.com

Note1: No user mappings (for those that read the documentation elsewhere on the Internet)
Note2: But user needs to exist locally!!!

Make sure that the password for the windows client host principal is identical on windows and on kerberos (we can NOT use the -randkey option):

On the kerberos server use:

addprinc -pw password host/bofh015.example.com

On the windows client use:

ksetup /SetComputerPassword password

On the KDC you will see the following in your log files (lines wrapped for readability):

Mar 02 14:57:33 krb5.example.com krb5kdc[27027](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 192.168.1.3: \
	ISSUE: authtime 1236002253, etypes {rep=23 tkt=23 ses=23}, kprutser@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM 
Mar 02 14:57:33 krb5.example.com krb5kdc[27027](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 192.168.1.3: \
	ISSUE: authtime 1236002253, etypes {rep=23 tkt=23 ses=23}, kprutser@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM 
Mar 02 14:57:33 krb5.example.com krb5kdc[27027](info): TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 192.168.1.3: \
	ISSUE: authtime 1236002253, etypes {rep=23 tkt=23 ses=23}, kprutser@EXAMPLE.COM for host/bofh015.example.com@EXAMPLE.COM
Mar 02 14:57:33 krb5.example.com krb5kdc[27027](info): TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 192.168.1.3: \
	ISSUE: authtime 1236002253, etypes {rep=23 tkt=23 ses=23}, kprutser@EXAMPLE.COM for host/bofh015.krb5.example.com@EXAMPLE.COM 
Mar 02 14:57:39 krb5.example.com krb5kdc[27027](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.3: \
	ISSUE: authtime 1236002259, etypes {rep=23 tkt=23 ses=23}, kprutser@EXAMPLE.COM for krbtgt/ EXAMPLE.COM@EXAMPLE.COM 
Mar 02 14:57:39 krb5.example.com krb5kdc[27027](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.3: \
	ISSUE: authtime 1236002259, etypes {rep=23 tkt=23 ses=23}, kprutser@EXAMPLE.COM for krbtgt/ EXAMPLE.COM@EXAMPLE.COM

Which means you have a ticket for the user (first 2 log lines), a ticket for the machine (second two log lines) and a TGT (last two log lines).

Tests

It is a matter of trust

Up till now we verified that both GNU/Linux and MS Windows can act as a client to the MIT Kerberos server. Now it is time to go for our ultimate goal: The Windows workstation has a machine account and user credentials in AD and the user password is stored in MIT Kerberos. The user should be able to use its MIT Kerberos ticket to sign in to AD and get its profile and settings.

Process

FIXME: Check!

When setup correctly, the process is as follows after the user enters their log in information:

AS-REQ and AS-REP bofh015$ for initial TGT from Windows Domain (krbtgt/FOREST.EXAMPLE.COM)
TGS-REQ and TGS-REP for cifs/ads.forest.example.com for BOFH015$
TGS-REQ and TGS-REP for krbtgt/FOREST.EXAMPLE.COM for BOFH015$
TGS-REQ and TGS-REP for LDAP/ads.forest.example.com for BOFH015$
Windows requests an initial TGT from the MIT realm (krbtgt/EXAMPLE.COM) when the user logs in.
Windows then obtains a service ticket from the MIT realm (krbtgt/FOREST.EXAMPLE.COM)
Windows then obtains a service ticket from the MIT realm for EXAMPLE.COM (krbtgt/EXAMPLE.COM) with just the forwardable flag set - no initial flag
With that TGT from the MIT realm, Windows is now able to obtain an LDAP service ticket from Active Directory (ldap/FOREST.EXAMPLE.COM)
The TGS from KRB5.EXAMPLE.COM is used to obtain all further tickets for Active Directory services (i.e. HTTP, CIFS, etc)

The tickets are verified between domains because they're encrypted with the interdomain secret created by each trusting domain

Building trusts

We are going for a two way trust. So on the MIT server do:

kadmin.local: addprinc -pw trust123 krbtgt/EXAMPLE.COM@FOREST.EXAMPLE.COM
kadmin.local: addprinc -pw trust123 krbtgt/FOREST.EXAMPLE.COM@EXAMPLE.COM

On the AD server do from the command line:

ksetup /addkdc EXAMPLE.COM krb5.example.com

After that start the Domain Tree Management tool. Click Programs, then Administrative tools, and then Active Directory Domains and Trusts. Right-click on Properties of the domain, then select the Trust tab and press New Trust...

An issue we came across is that the domain you enter in the next screen should be the realm. If you fill in the realm name with small caps, everything should be small caps in your MIT Kerberos setup too. So you should really use the realm name like: EXAMPLE.COM. Thus make sure it is big caps in your log in screen. When you log in on a workstation it doesn't matter what you fill in with the

ksetup

tool.

In the following step use the password of the MIT step.

Click Next, Next, Finish.

Ktpass /MITRealmName EXAMPLE.COM /TrustEncryp rc4

To support rc4-hmac encryption.

Map the Kerberos principal to an AD account start the Directory Management tool:
Point to Programs, then Administrative tools, and then Active Directory Users and Computers. Start advanced features by clicking View, and then Advanced Features. Locate the account to which you want to create mappings, and right-click to view Name Mappings. Click the Kerberos Names mappings tab. Add

kprutser@EXAMPLE.COM

Connecting Windows XP

Put the workstation into the domain by right clicking My Computer and selecting properties. Select the tab Computer Name and click Change...

Select Domain and fill in the DNS domain name or NetBIOS name.

For us the account that has permission to join to a domain is Administrator.

If all went well you should receive:

Restart the computer for the changes to take effect.

ksetup /addkdc EXAMPLE.COM krb5.example.com

To be safe always reboot after changes to realms. We have experienced that Windows does a lot of caching, so not rebooting after a change (even a change on the MIT kerberos side) might reveal the same error, since you are talking to the cache.

Log in on the Windows XP workstation, selecting the EXAMPLE.COM realm. In your event viewer on Active Directory you should see a message like this:

Successful Network Logon:
User Name:		dleeuw
Domain:			EXAMPLE.COM
Logon ID:		(0x0,0x62146)
Logon Type:		3
Logon Process:		Kerberos
Authentication Package:	Kerberos
Workstation Name:	
Logon GUID:		{299349f8-83a6-248d-7e72-5d64113710e0}
Caller User Name:	-
Caller Domain:		-
Caller Logon ID:	-
Caller Process ID: 	-
Transited Services: 	-
Source Network Address:	192.168.1.3
Source Port:		0

This means that you successfully logged on to AD, you can also check this on the workstation by using:

C:\set l
LOGONSERVER=\\ADS

This should reveal the AD server and not the workstation NetBIOS name.

Let's share

On the MIT Kerberos server type:

kadmin.local: addprinc -randkey cifs/ads.forest.example.com

Remember to reboot your windows client it caches a wrong log in.

You should now be able to browse shares, if you are not then there is probably a problem with an SPN. Each service that uses kerberos authentication need to have an SPN set. CIFS and HTTP/S are known problem makers. The problem occurs as follows:

A client asks for a ticket for cifs/ads.forest.example.com
AD searches through its accounts for that SPN
If it doesn't find it AD searches for host/ads.forest.example.com
Now it will use that ticket to encrypt everything... and that is where it goes wrong!

In the output of a network analyzer you can see this happening like this:

574	15.553509	192.168.1.3	192.168.1.2	SMB	Session Setup AndX Request
575	15.554712	192.168.1.2	192.168.1.3	SMB	KRB Error: KRB5KRB_AP_ERR_MODIFIED, Error: STATUS_MORE_PROCESSING_REQUIRED

When you open the packet you will see the security blob that the request uses cifs/ads.forest.example.com and the answer denies host/ads.forest.example.com. This problem can be overcome by using a tool called

setspn.exe.

With:

setspn -L ads

you can view the current SPN settings.

The default command to set SPNs is:

setspn -A  ServiceClass/Host:Port AccountName

For CIFS the AccountName is the NetBIOS name of the host. So we can add CIFS to the SPN database by using:

setspn -A cifs/ads.forest.example.com ads

After these settings and a reboot of the workstation access to the shares provided by ads2 should be available.

The same holds true for http. Solve this one by using:

setspn -A HTTP/ads.forest.example.com ads

On the workstation you could use to see which tickets are issued to the workstation user.

Create account error:

ldap_sasl_interactive_bind_s: Local error (-2)
	additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Message stream modified)

Network analyzer (wireshark) line:

192.168.1.3 192.168.1.1 LDAP KRB5KRB_AP_ERR_MODIFIED

This error is generated if you try to add an entirely empty ldif to AD :)

Tests

User can browse a share
User can change his password

Appendix A: Other Resources

Kerberos documentation

http://web.mit.edu/Kerberos/krb5-1.6/#documentation

Installation Guide

Administration Guide

User Guide

http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/sec-kerberos-crossrealm.html

Active Directory

MS Kerberos Troubleshooting Guide:

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

Delegation issues: http://support.microsoft.com/kb/907272

Delegation:

http://www.microsoft.com/downloads/details.aspx?familyid=99b0f94f-e28a-4726-bffe-2f64ae2f59a2&displaylang=en

Software tools:

http://www.microsoft.com/downloads/details.aspx?FamilyID=4e3a58be-29f6-49f6-85be-e866af8e7a88&displaylang=en

Installs in C:\Program Files\Windows Resource Kits\Tools

SPN logic:

http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/the-biggest-mistake-serviceprincipalname-s.aspx

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

User accounts

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

LDAP errors

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

AD and kerberos integration

http://technet.microsoft.com/nl-nl/library/bb742433(en-us).aspx
http://acd.ucar.edu/~fredrick/linux/kerberos/
http://www.ualberta.ca/CNS/auth/ADS-install.htm
http://mailman.mit.edu/pipermail/kerberos/2006-November/010818.html
http://blogs.msdn.com/alextch/archive/2006/07/18/etypes.aspx

Appendix B: ETypes

RFC 3961

	encryption type                etype      section or comment
      -----------------------------------------------------------------
      des-cbc-crc                        1             6.2.3
      des-cbc-md4                        2             6.2.2
      des-cbc-md5                        3             6.2.1
      [reserved]                         4
      des3-cbc-md5                       5
      [reserved]                         6
      des3-cbc-sha1                      7
      dsaWithSHA1-CmsOID                 9           (pkinit)
      md5WithRSAEncryption-CmsOID       10           (pkinit)
      sha1WithRSAEncryption-CmsOID      11           (pkinit)
      rc2CBC-EnvOID                     12           (pkinit)
      rsaEncryption-EnvOID              13   (pkinit from PKCS#1 v1.5)
      rsaES-OAEP-ENV-OID                14   (pkinit from PKCS#1 v2.0)
      des-ede3-cbc-Env-OID              15           (pkinit)
      des3-cbc-sha1-kd                  16              6.3
      aes128-cts-hmac-sha1-96           17          [KRB5-AES]
      aes256-cts-hmac-sha1-96           18          [KRB5-AES]
      rc4-hmac                          23          (Microsoft)
      rc4-hmac-exp                      24          (Microsoft)
      subkey-keymaterial                65     (opaque; PacketCable)

Microsoft

From ntsecapi.h in the Microsoft SDK:

#define KERB_ETYPE_RC4_MD4 -128 // FFFFFF80
#define KERB_ETYPE_RC4_PLAIN2 -129
#define KERB_ETYPE_RC4_LM -130
#define KERB_ETYPE_RC4_SHA -131
#define KERB_ETYPE_DES_PLAIN -132
#define KERB_ETYPE_RC4_HMAC_OLD -133 // FFFFFF7B
#define KERB_ETYPE_RC4_PLAIN_OLD -134
#define KERB_ETYPE_RC4_HMAC_OLD_EXP -135
#define KERB_ETYPE_RC4_PLAIN_OLD_EXP -136
#define KERB_ETYPE_RC4_PLAIN -140
#define KERB_ETYPE_RC4_PLAIN_EXP -141

To make sure that our AD server also has this zone file we allow AD to transfer this file so our named.conf has the following setup:

zone krb5.example.com { 
        type master; 
        file internal/com.example.krb5.zone; 
        check-names ignore; 
        allow-transfer { 
            // ad server 
	    192.168.1.2; 
        };
	
        allow-update { 
            // test client 
	    192.168.1.3; 
        };

        notify no; 
};

You will note that we have an entry for a client to do updates, this is so that the client can put its IP address in the zone file, AD relies on the ability to resolve client host names to IP addresses, and since we use DHCP to supply IP addresses to our clients, we need a way to do automatic DNS updates (RFC2136). The reverse is not needed, at least not that we have found.