Unix kerberos windows

Since such a system might not be participating in the AD domain in any other way, there must be some common authentication mechanism to allow this to work. The Kerberos single sign-on SSO protocol accomplishes this task. Think of the SPN as the centerpiece to this arrangement, and the keytab as the glue.

SPNs will be the topic of another article; we will focus only on the keytab in this conversation. Kerberos keytabs, also known as key table files, are only employed on non-Windows servers. This is also why Kerberos client configuration files, such as krb5. 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. Skip to main content. This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode.

Please rate your experience Yes No. Any additional feedback? A realm is somewhat similar to a domain in a Windows network. Users belong to specific realms and they authenticate to their respective realms just as Windows network users authenticate to the domains of which they are members. The KDC and the services and applications that use Kerberos make up the realm.

Applications and services that use Kerberos are referred to as Kerberized applications. In addition to the application itself, the authentication data is saved in a credential cache. The tickets that are issued to identify Kerberized applications are cached so that they can be reused until their expiration period is up.

Windows Kerberos supports transitive trusts between domains; this means that if Domain 1 trusts Domain 2 and Domain 2 trusts Domain 3, then there is an implicit trust between domains 1 and 3.

Windows domains are arranged into hierarchical trees that form a namespace parent domains spawn child domains that incorporate the domain name of the parent. For example, sales. Groups of domain trees comprise a forest. Each tree has its own namespace, but there is a trust relationship between all trees in a forest.

Windows uses the standard Kerberos protocol as specified in RFC You also need to consider the resources being accessed; that is, whether they're stored on a Windows or UNIX server. You'll need to set up the Kerberos client software to use the correct KDC and realm.

This is usually configured for logon to the local computer. If network resources reside in an MIT Kerberos realm and you need Windows clients to be able to access them on a regular basis, you can do this by creating a one-way trust between Kerberos realm and the Windows domain, so that the realm trusts the domain. This way, when Windows users log onto the Windows domain, the UNIX Kerberos server will automatically trust them because they've authenticated to the Windows server.