Skip to main content
NetApp Knowledge Base

Does Data ONTAP support kerberos authentication requests across forest trusts?

  1. Last updated
  2. Save as PDF
Views:
1,060
Visibility:
Public
Votes:
1
Category:
ontap-9
Specialty:
nas
Last Updated:

​ ​ ​  

Applies to

ONTAP 9

Answer

  • Yes ONTAP supports Kerberos authentication requests across forest trusts
    • In order to perform authentication with Kerberos, the client requests a service ticket for the filer. 
    • When the client receives the ticket, it then given to the filer. 
    • The filer itself then decrypts the ticket using its own version of the password hash. 
    • If decryption is successful, authentication is completed. 

Additional Information

Kerberos-based processing of authentication requests across forest trusts:

  • When two Windows Server forests are connected by a forest trust,
    • Authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both the forests.
    • When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores the information in a TDO.
    • Trusted namespaces include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest.
    • TDO objects are replicated in the global catalog.
  • Before authentication protocols can follow the forest trust path,
    • The service principal name (SPN) of the resource computer must be resolved to a location in the other forest.
    • An SPN can be one of the following: the Domain Name System (DNS) name of a host, the DNS name of a domain, or the distinguished name of a service connection point object.
    • When a workstation in one forest attempts to access data on a resource computer in another forest, the Kerberos authentication process contacts the local domain controller for a service ticket of the resource computer’s SPN.
  • Once the domain controller queries the global catalog and determines that the SPN is not in the same forest as the domain controller,
    • The domain controller sends a referral for its parent domain back to the workstation.
    • At that point, the workstation queries the parent domain for the service ticket and continues to follow the referral chain until it reaches the domain where the resource is located.

 

The following illustration has detailed description of the Kerberos authentication process for users running a Windows client attempting to access resources from another computer located in a different forest.

krb_auth.JPG

  1. User1 logs on to Workstation1 using credentials from the europe.corp.goodstorage.com domain.
    • The user then attempts to access a shared resource on Filer1 located in the usa.corp.nicestorage.com forest.
  2. Workstation1 contacts the Kerberos Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the Filer1 SPN.
  3. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domain in the goodstorage.com forest contains this SPN.
    • As a global catalog is limited to its own forest, the SPN is not found.
    • The global catalog then checks its database for information about any forest trusts that are established with its forest, and, if found, compares the name suffixes listed in the forest trust's trusted domain object (TDO) with the suffix of the target SPN to find a match.
    • Once a match is found, the global catalog provides a routing hint back to ChildDC1.
    • Routing hints help direct authentication requests towards the destination forest, and are only used when all traditional authentication channels (local domain controller and then global catalog) fail to locate an SPN.
  4. ChildDC1 sends a referral for its parent domain back to Workstation1.
  5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ForestRootDC2) in the forest root domain of the nicestorage.com forest.
  6. Workstation1 contacts ForestRootDC2 in the nicestorage.com forest for a service ticket to the requested service.
  7. ForestRootDC2 contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it back to ForestRootDC2.
  8. ForestRootDC2 then sends the referral to usa.corp.nicestorage.com back to Workstation1.
  9. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to Filer1.
  10. Once Workstation1 has a service ticket, it sends the service ticket to Filer1, which reads User1’s security credentials and constructs an access token accordingly.

 

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.