Microsoft trusting MIT Kerberos

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

Credits

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.

Process

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/ads.forest.example.com for BOFH015$

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

  4. TGS-REQ and TGS-REP for LDAP/ads.forest.example.com 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 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.

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

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:

  1. A client asks for a ticket for cifs/ads.forest.example.com

  2. AD searches through its accounts for that SPN

  3. If it doesn't find it AD searches for host/ads.forest.example.com

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

  1. User can browse a share

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