How to create trust between MIT kerberos realm and AD

Copy from this page
Please reference this page from Microsoft

Configuring a Local MIT Kerberos Realm to Trust Active Directory

On the Active Directory Server

1. Type the following command to specify the local MIT KDC host name (for example, kdc-server-hostname.cluster.corp.company.com) and local realm (for example, YOUR-LOCAL-REALM.COMPANY.COM):

   ksetup /addkdc YOUR-LOCAL-REALM.COMPANY.COM kdc-server-hostname.cluster.corp.company.com

   Run this command on every domain controller that will be referenced by the cluster'skrb5.conf file. If load balancing is being used and a single KDC hostname has to be provided to all domain controllers, refer the Microsoft documentation instead of explicitly using theksetup command on individual domain controllers.
2. Type the following command to add the local realm trust to Active Directory:

   netdom trust YOUR-LOCAL-REALM.COMPANY.COM /Domain:AD-REALM.COMPANY.COM /add /realm /passwordt:

3. Type the following command to set the encryption type:
   On Windows 2003 RC2:
   Windows 2003 server installations do not support AES encryption for Kerberos. Therefore RC4 should be used. Please see the Microsoft reference documentation for more information.

   ktpass /MITRealmName YOUR-LOCAL-REALM.COMPANY.COM /TrustEncryp RC4

   On Windows 2008:

     Note: When using AES 256 encryption with Windows 2008 you must update the proper Java Cryptography Extension (JCE) policy files for the version of JDK you are using.

   • JCE Policy Files - JDK 1.6
   • JCE Policy Files - JDK 1.7

   ksetup /SetEncTypeAttr YOUR-LOCAL-REALM.COMPANY.COM 

   Where the  parameter can be replaced with parameter strings for AES, DES, or RC4 encryption modes. For example, for AES encryption, replace  with AES256-CTS-HMAC-SHA1-96 or AES128-CTS-HMAC-SHA1-96 and for RC4 encryption, replace with RC4-HMAC-MD5. See the Microsoft reference documentation for more information.
     Important:

   Make sure the encryption type you specify is supported on both, your version of Windows Active Directory and your version of MIT Kerberos.

On the MIT KDC server

Type the following command in the kadmin.local or kadmin shell to add the cross-realm krbtgt principal. Use the same password you used in the netdom command on the Active Directory Server.

kadmin:  addprinc -e "" krbtgt/YOUR-LOCAL-REALM.COMPANY.COM@AD-REALM.COMPANY.COM

where the  parameter specifies the types of encryption this cross-realm krbtgt principal will support: either AES, DES, or RC4 encryption. You can specify multiple encryption types using the parameter in the command above, what's important is that at least one of the encryption types corresponds to the encryption type found in the tickets granted by the KDC in the remote realm.

Examples by Active Directory server type

• For Windows 2003:

  kadmin: addprinc -e "rc4-hmac:normal" krbtgt/YOUR-LOCAL-REALM.COMPANY.COM@AD-REALM.COMPANY.COM

• For Windows 2008:

  kadmin: addprinc -e "aes256-cts:normal aes128-cts:normal rc4-hmac:normal" krbtgt/YOUR-LOCAL-REALM.COMPANY.COM@AD-REALM.COMPANY.COM

  Note:

The cross-realm krbtgt principal that you add in this step must have at least one entry that uses the same encryption type as the tickets that are issued by the remote KDC. If no entries have the same encryption type, then the problem you will see is that authenticating as a principal in the local realm will allow you to successfully run Hadoop commands, but authenticating as a principal in the remote realm will not allow you to run Hadoop commands.

On all of the cluster machines

1. Verify that both Kerberos realms are configured on all of the cluster boxes. Note that the default realm and the domain realm should remain set as the MIT Kerberos realm which is local to the cluster.

   [realms]
     AD-REALM.CORP.FOO.COM = {
       kdc = ad.corp.foo.com:88
       admin_server = ad.corp.foo.com:749
       default_domain = foo.com
     }
     CLUSTER-REALM.CORP.FOO.COM = {
       kdc = cluster01.corp.foo.com:88
       admin_server = cluster01.corp.foo.com:749
       default_domain = foo.com
     }

2. To properly translate principal names from the Active Directory realm into local names within Hadoop, you must configure the hadoop.security.auth_to_local setting in the core-site.xml file on all of the cluster machines. The following example translates all principal names with the realm AD-REALM.CORP.FOO.COM into the first component of the principal name only. It also preserves the standard translation for the default realm (the cluster realm).

   
     hadoop.security.auth_to_local
     
       RULE:[1:$1@$0](^.*@AD-REALM\.CORP\.FOO\.COM$)s/^(.*)@AD-REALM\.CORP\.FOO\.COM$/$1/g
       RULE:[2:$1@$0](^.*@AD-REALM\.CORP\.FOO\.COM$)s/^(.*)@AD-REALM\.CORP\.FOO\.COM$/$1/g
       DEFAULT
     
   

For more information about name mapping rules, see:  Configuring the Mapping from Kerberos Principals to Short Names

How to reduce RDS CALs using WMI privider

Credit: TP (MVP)

Taken from: Technet Forum

You may uninstall license keypacks, reduce the number of install licenses, etc, using the Remote Desktop License Server WMI Provider.  For example, if you just need to reduce the installed count of one of the packs from 30 to 25 you could use the RemoveLicensesWithIdCount method.  Below is the documentation for the Win32_TSLicenseKeyPack Class:

http://msdn.microsoft.com/en-us/library/aa383803(v=VS.85).aspx 

Here are the basic steps for this example.

1. Get a list of installed keypacks.  Open a administrator command prompt and then enter the following commands:

wmic /namespace:\\root\CIMV2 PATH Win32_TSLicenseKeyPack>keypacks.txt

notepad keypacks.txt

2. Let's say you look at the keypacks.txt file and see that the keypack you want to modify is KeyPackId 3, and that you want to uninstall 5 licenses.  In that case you would enter a command similar to this:

wmic /namespace:\\root\CIMV2 PATH Win32_TSLicenseKeyPack CALL RemoveLicensesWithIdCount 3,5

Another example, say you want to uninstall the keypack (id 3 in our example).  Instead of the command in step 2 above, you would enter a command similar to this:

wmic /namespace:\\root\CIMV2 PATH Win32_TSLicenseKeyPack CALL UninstallLicenseKeyPackWithId 3

An alternative to the above is to Deactivate the licensing server, uninstall the RD/TS Licensing Role Service/reinstall the Role Service, Activate, and install your license pack(s) again.  This wipes out the license server database and recreates it.  You may need to contact the Clearinghouse if you get an error when re-installing your license pack(s).

Kerberos event 4/Target account name is incorrect/ troubleshooting

This error is reported whenever the service provider (e.g. file server) cannot decrypt a service ticket that was sent to it. This is caused by the fact that the ticket was encrypted by one machine then sent to a different machine. In this case, the second machine doesn't have the private key to decrypt the ticket.

Troubleshooting steps

- make sure there is not duplicate SPN for the service you are trying to get. For example, if you want to access \\serverName1\sharePath and get above error; or on a file server you see kerberos event 4, you want to check if there is duplicate SPN host\serverName*. In the past, it takes a little effort to find duplicate SPNs, but started Windows7/2008, you can run setspn -X to find all duplicated SPNs in your domain

- make sure you don't have duplicate DNS entries for same server to different IPs (unless the server does have multiple IP, and all DNS entries are correct).

- if access using FQDN works but not short name (e.g. \\server.FQDN.com\sharePath works but not \\server\sharePath), and you have WINS in your environment, make sure the target server register correct 20h record (File Server) in WINS

- If your target computer has multiple names (mostly added by command netdom computername), then you should make sure you add SPNs for all the alias you have. For example, if you have a server has both names as server1 and server2, you should below spn registered in AD:

• host/server1.fqdn.com
• host/server1
• host/server2.fqdn.com
• host/server2

- make sure you don't have hosts file entries that resolve to wrong IP

- Log into the system that actually owns wrong IP, make sure it's not registering wrong name. For DNS, check NIC TCP/IP stack; for WINS, check "netdom computername localhost /enum", as well as check HKLM\CCS\Services\lanmanserver\parameters\OptionalNames