Microsoft trusting MIT Kerberos

© 2009 Dennis Leeuw dleeuw at made-it dot com
License: GPLv2 or later


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

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.


FIXME: Check!

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

  1. AS-REQ and AS-REP bofh015$ for initial TGT from Windows Domain (krbtgt/FOREST.EXAMPLE.COM)

  2. TGS-REQ and TGS-REP for cifs/ for BOFH015$

  3. TGS-REQ and TGS-REP for krbtgt/FOREST.EXAMPLE.COM for BOFH015$

  4. TGS-REQ and TGS-REP for LDAP/ for BOFH015$

  5. Windows requests an initial TGT from the MIT realm (krbtgt/EXAMPLE.COM) when the user logs in.

  6. Windows then obtains a service ticket from the MIT realm (krbtgt/FOREST.EXAMPLE.COM)

  7. 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

  8. With that TGT from the MIT realm, Windows is now able to obtain an LDAP service ticket from Active Directory (ldap/FOREST.EXAMPLE.COM)

  9. 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

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


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


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.

Log in and use the command line to add the kerberos realm:

ksetup /addkdc 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
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:
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
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/

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:

  1. A client asks for a ticket for cifs/

  2. AD searches through its accounts for that SPN

  3. If it doesn't find it AD searches for host/

  4. 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	SMB	Session Setup AndX Request

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



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

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

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: LDAP KRB5KRB_AP_ERR_MODIFIED
This error is generated if you try to add an entirely empty ldif to AD :)


  1. User can browse a share

  2. User can change his password

Appendix A: Other Resources

Kerberos documentation

Installation Guide

Administration Guide

User Guide

Active Directory

MS Kerberos Troubleshooting Guide:

Delegation issues:


Software tools:

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

SPN logic:

User accounts

LDAP errors

AD and kerberos integration

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)


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_RC4_PLAIN -140