And then only in the case where the administrator wishes to integrate their application server to AD via Kerberos SSO. In other words, if you wish for your client systems to logon to the non-Windows system using their AD credentials via SSO not challenged again for username and password and be silently authenticated to the application server, a keytab will be required.
This is the critical role of the keytab during Kerberos authentication. The Keytab must be generated on either a member server or a domain controller of the Active Directory domain using the ktpass. Use the Windows Server built-in utility ktpass. The ktpass command must be run on either a member server or a domain controller of the Active Directory domain.
Further, Keytabs must be created on a Windows Server operating system such as Windows Server , , or Keytabs cannot be created on a workstation operating system, such as Windows 7, 8 or Windows When running ktpass. The keytab must be created in such a way that it contains the service principal name, realm name, and the encrypted hash of the password of the AD user or computer account to which the service principal inside of the keytab is related.
The keytab is much more flexible if it is tied to an AD user service account than a computer account. Because an AD service account cannot run on a non-Windows system, the keytab provides the function of the AD service account in its place. A keytab file is small — only 1 kilobyte in size. Note that if you re-create a keytab using the same SPN, you will need to 1 first ensure the application server config is pointed to the new keytab file name if you've changed it and 2 you will also need to restart the application service engine.
Type the name of the UNIX host. Use the Ktpass tool to set up an identity mapping for the user account. Use the following command:. This is the purpose of using Ktpass with the -princ and —mapuser switches. You will need to create a complex password to complete this procedure.
Use the command:. After executing the above command you will be prompted to provide a password. Provide a complex password and make note of it. You will be required to provide the same password in a subsequent command on the Windows Server client.
Since the MIT realm is not an Active Directory domain, the computer will be configured as a member of a workgroup. This is automatic when you set the Kerberos realm and add a KDC server. You will be required to restart your computer for the changes to take effect. Run the following commands:. COM kdc. Set the local machine account password. Restart your computer for the changes to take effect. Whenever changes are made to the realm or domain membership, a restart is required.
Use Ksetup to configure single sign on to local workstation accounts. In order to do this, you define the account mappings which maps local machine accounts to Kerberos principals. For example:. COM guest. Use Ksetup with no arguments to see the current settings. You can set up a trust relationship between Windows Server domains and non-Windows Kerberos realms. To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.
By default the trust will be non-transitive. This can be changed to transitive within the New Trust Wizard or by using the netdom.
See the tool Help menu for details. Workstation computers that use services in an MIT realm need to have a realm entry added. To do this, use the Ksetup command on each system that uses the MIT realm for services. The following procedures use the Active Directory Domains and Trusts snap-in. See the Windows Support Tools Help for details. On the domain controller for the Windows Server domain, use the following command to set up the configuration for the non-Windows Kerberos realm:.
To enable delegation across the Realm trust run the following command:. COM Delegate. Start the Active Directory Domains and Trusts snap-in. Right-click on Properties of your domain, then select the Trusts tab and select New Trust. The passwords used in this step are described in Step 5. Create a trusted domain relationship with the MIT Kerberos realm using the following parameters:. Trust Type: Realm. Transitivity of Trust: Transitive.
Direction of Trust: Two-way. Procedural steps for creating a trust relationship are available in Create a two-way, realm trust in the Active Directory Operations Guide or in Create a realm trust in the Active Directory product help of the Windows Server Technical Library. Add - Adds the value of the specified local user name. This is the default. DES-only encryption is set by default. Important: Windows doesn't support DES by default. Specifies the. Specifies a password for the principal user name that is specified by the princ parameter.
All - States that all supported cryptographic types can be used. Specifies the iteration count that is used for AES encryption. Specifies the principal type. Sets the background answer mode: - Answers reset password prompts automatically with NO. Sets which domain controller to use. The output of this parameter shows the MIT salt algorithm that is being used to generate the key. If the ktpass command fails, try the following troubleshooting options:.
If the user is found but ktpass fails to create the keytab, there may be problems with the domain controller setup. If the DNS test fails, it is probable that some of the DNS entries required by the domain controller are not registered.
0コメント