These steps are how I established my development setup for the MS-KKDCPP. I had a Windows 2012 Server that was a Domain Controller testbed in a previous life, and a Windows 8 machine as client. The MS-KKDCP is running on the server. Both were virtualized using RHEVM in the same lab.

Server

One will need a Windows 2012 Server installed, with Domain and KDC configured, which is providing DNS. It has been reported to me that you also need “Remote Desktop Gateway” (under “Remote Desktop Service”) enabled, though I cannot test this myself due to virtualization constraints.

  1. Start the KDC Proxy service on the server. To do this, go into Server Manager, then from the “Tools” menu, click on “Services”. Make sure the KDC is running, then right-click on the “Kerberos KDC Proxy Service (KPS)” entry and choose “Properties”. Under the “Log on” tab, choose “Local System Account” and click the checkbox for “Allow service to interact with desktop”. Under the “General” tab, set startup type to “Automatic” and start the service. Click “Apply” and close the window.

  2. Configure web services on the server. To do this, in Server Manager, from the “Tools” menu, choose “Internet Information Services (IIS) Manager”. Expand the dropdown for the current mahine on the left, and again for “Sites”. Right-click on “Default” and select “Edit Bindings”. Click the “Add” button. Type should be https, IP address should be “All Unassigned”, Port 443, Hostname the name of the machine, and SSL certificate the certificate for the website. Finish and close the bindings window. Then under “Manage Website” on the right, stop the website if it is running, then start it again.

    If you do not have a certificate, you will need to generate one. In IIS, click on the computer, then double-click on “Server Certificates”. From the “Actions” secton on the right side, choose “Create Domain Certificate…”. Set “Common Name” to the all-caps FQDN for the website, fill in the remaining fields (their values do not matter), then click “Next”. Click “Select” to specify the CA, and give it the “Friendly Name” of your FQDN, again in all caps. Click “Finish” to create the certificate.

  3. Configure policy to use the MS-KKDCP. In Server Manager, from the “Tools” menu, choose “Group Policy Management”. On the left, expand the “Forest”, then “Domains”, then the target domain. Right-click the policy (for me it’s “Default Domain Policy”) and choose “Edit…”. In the new window, on the left expand “Computer Configuration”, then “Policies”, then “Administrative Templates”, then “System”, and finally select “Kerberos”. In the main part of the window, right-click “Specify KDC proxy servers for Kerberos clients” and choose “Edit”. The syntax for this is important, so be sure to read the bottom left pane before clicking the “Show…” button. Set “value name” to *, and then set value to the address of the server (in the form shown under the last example). Make sure this entry in the table is selected such that the |> glyph is on the desired line before clicking “OK”. On the top left of the window, switch from “Disabled” to “Enabled”, then click “Apply” and close the window. Then close the Group Policy Editor window. Close and reopen Group Policy Management, and under the policy you should now see, under the Settings tab, an entry for Kerberos (you may have to expand a few levels in the main window section).

Client

To join the client into the domain:

  1. Log in to the client as a local administrator. Open the file browser, then right-click “Computer” on the left and choolse “Properties…”. Click “Advanced System Settings” on the left, then choose the “Computer Name” tab. Click the “Change…” button, and enter the name of the Domain in the Domain field. Then click “OK”.

    In order to join the domain, the client will need to be able to resolve addresses in the domain. Most likely this will require switching DNS to use the controller DNS service. To do this, open Control Panel, then click “Network and Internet”. Click “Network and Sharing Center”, then “Change Adapter Settings”. Right-click the Ethernet entry, and select “Properties…”. Select “Internet Protocol Version 4 (TCP/IPv4) and click “Properties”. Switch to “Use the following DNS server address:” and enter the address of the domain controller there, then click “OK”.

To update group policy on the client:

  1. Log in to the client as an administrative user on the domain. This may work for an administrative user not on the domain but I have not tested it.

  2. Force an update. From the start menu, launch “Command prompt”. At the prompt, type gpupdate /force (without the backticks). When the command completes, policy should be updated.

    In order for new policy to take effect, at least a logout and possibly a reboot is needed.

To force Kerberos traffic to use the MS-KKDCPP:

  1. Open Control Panel. Choose “System and Security”, then “Windows Firewall”. On the left, choose “Advanced Settings” to open the firewall rules. On the left, select “Outbound Rules”. On the right, click “New Rule…”. Choose “Port” for the rule type, then click “Next”. Choose TCP, then specify port 88. Click “Next”. Select “Block the connection”, then click “Next”. Make sure it applies to the Domain network at minimum, though I had it apply to all, then click “Next”. Give it a memorable name such as “Kerberos Block TCP”, and click “Finish”. Repeat this process for UDP as well.

Observing traffic

To observe traffic, I ran wireshark on the server. In general, this is really bad practice; however, since both machines are virtual, the only other option would have been to install on the hypervisor and run there. (I did try running it on another machine in the same lab; it cannot see the traffic.) Ideally, one would run at least the client in a local vm, and then capture traffic between them on the host.

To setup wireshark:

  1. Verify the certificate is exportable. Open IIS as before, then select the machine on the left. Double-click on “Server Certificates”, then right-click the certificate in use and choose “View…”. Make sure that under the “General” tab it indicates that a private key is available; otherwise, you will need to genearte a new certificate as explained above and use that instead. Record the cerficate hash; it will be needed for the next step.

  2. Open command prompt. Run certutil -exportpfx <hash> <name> replacing <hash> with the hash from step (1) and <outfile> with the name of the file to write out to. You will be prompted for a password; unlike openssl, if you leave this blank, it uses a blank password as the password.

  3. Copy the file to a linux machine with OpenSSL installed. By far the easiest way to do this is to use WinSCP on the windows machine to copy the file over.

  4. On the linux machine, in a shell, run openssl pkcs12 -in <input> -nodes -out <output>.pem -nocerts -nodes replacing <input> with the name of the file copied over and <output>.pem with the name of the desired result file. You will be prompted for a password; enter the password used in step (2), remembering that if the password in step (2) was blank, so should this be.

  5. Copy the file back to the Windows machine. Again, run WinSCP from the Windows machine to do this.

  6. Open wireshark. From the “Edit” menu, choose “Preferences…”, then expand “Protocols”. Scroll down and select SSL. Set an “SSL debug file:” and be sure that both “Reassemble SSL records spanning multiple TCP segments” and “Reassemble SSL Application Data spanning multiple SSL records:” are checked. Then next to “RSA keys list:” click the “Edit…” button. Click new, then enter the IP address of the server. For “Port:”, enter 443, and for “Protocol:”, enter http (not https). Select the “Key File”, and leave the “Password:” field blank. Then click “OK”, “Apply”, “OK, “Apply”, and “OK”.

  7. Once setup is complete, the client machine will use the MS-KKDCPP to send Kerberos traffic to the server. The easiest way to trigger traffic is to log out and log back in on the client machine.

Troubleshooting

If no HTTPS traffic is observed but there is Kerberos traffic observed, check the firewall settings on the client. If they check out okay, check the policy settings on the server, then force an update on the client.

If no HTTPS or Kerberos traffic is observed, run klist (without the backticks) in a Command Prompt on the client. If the user has tickets, reboot the client machine and try again (and if that doesn’t fix it, check your wireshark settings). Otherwise, verify the policy on the server and update the client.

If HTTPS traffic is observed but cannot be decrypted, examine the wireshark SSL log file for details. If nothing seems awry, it is likely that the initial handshake has not been captured. Rebooting one or both machines may fix the problem.