Kerberos in an Active Directory forest trust vs. external trust

As outlined in the MS Technet article, the “Kerberos Authentication Process Over Forest Trusts” works as follows:

1.User1 logs on to Workstation1 using credentials from […] [childx.rootx.tld]. The user then attempts to access a shared resource on FileServer1 located in the […] [childy.rooty.tld]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 FileServer1 SPN.

3.ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the […] [rootx.tld] forest contain this SPN. Because 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, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match.

[Important: The needed information regarding name suffixes is stored in the “msDS-TrustForestTrustInfo” attribute of the corresponding TDO. The TDO is stored in Active Directory in the “System” container.
This attribute is only maintained in cases of a forest trust. When the TDO represents an external trust, this attribute is empty and contains no information. As a result, Kerberos authentication fails at this point when executed over an external trust.
To examine the information of the “msDS-TrustForestTrustInfo” attribute, the following command can be used:

netdom trust childx.rootx.tld /domain:childy.rooty.tld 
/NAMESUFFIXES:childx.rootx.tld

In the case of a external Trust, this command will return no information, but instead the message: “The trust is not a forest trust”.]

Once a match is found, the global catalog provides a routing hint back to ChildDC1. Routing hints help direct authentication requests toward the destination forest, and are only used when all traditional authentication channels (local domain controller and then global catalog) fail to locate a 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 […] [rooty.tld] forest.

6.Workstation1 contacts ForestRootDC2 in the […] [rooty.tld] 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.wingtiptoys.com back to Workstation1.

9.Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to FileServer1.

10.Once Workstation1 has a service ticket, it sends the service ticket to FileServer1, which reads User1’s security credentials and constructs an access token accordingly.

To make Kerberos working over an external Trust, the missing information of the TDO objects  “msDS-TrustForestTrustInfo”  attribute must be provided manually to the KDC configuration, which can be done using the following GPO settings:

Computer Configuration\Policies\Administrative Templates\System\Kerberos\[KDC]:
Use forest search order

By configuring this setting, a list of forests to be searched can be added using the the FQDNs of the corresponding forrest.

Note: This procedure applies only to a Windows Server 2008/R2 environment.

Additional Reading and References
Please see also the MS post “Conditions for Kerberos to be used over an External Trust” and the post “Kerberos Authentication Over An External Trust – Is It Possible? (Part 6)“.
For testing the authentication method used when accessing a web page, the tool „DelegConfig“ can help.

Advertisements
Posted in Active Directory | Leave a comment

Troubleshooting Kerberos-Authentication and UDP packet size

When windows initiates a Kerberos authentication over user datagram packages (UDP), the following network communication occurs:

1.    The Kerberos client requests a Ticket Granting Ticket (TGT) from the Domain Controller, respectively the Key Distribution Center (KDC).
2.    The KDC replies to the client sending the TGT, if the authenticaction was successful.
3.    The Kerberos client requests a service ticket from the Ticket Granting Service (TGS), containing the TGT which has been issued before (krbtgt/<DOMAIN>) and the service principal name (SPN) for the service being requested for access (<SERVICETYPE>/<FQDN of Server>).
4.    The KDC replies to the client by sending the service ticket.

In some special cases, the network infrastructure may have problems with the UDP package, because it may be too big (exceeds the maximum UDP package size). As a result, the package will be fragmented and the KDC may not receive the package fragments in the correct order. As UDP is not a connection oriented protocol, this causes the KDC to fail processing the package. In this case, instead of replying to the client with a valid TGT, the KDC will respond with the following error message and the authentication process will be stopped:

KRB Error: KRB5KRB_ERR_RESPONSE_TOO_BIG (52)

In this scenario, windows logon may take a long time seeming to hang after entering the password and loading the user profile. Also, once logged in, accessing a new service (like connecting a share) may take a long time, when the service ticket for the requested service is not already available and needs to be requested first.

When Windows recognizes, that Kerberos over UDP fails, it will retry the authentication over TCP after a time out which is the reason behind the fact, that the authentication works finally but takes a while longer.

To avoid this behavior, Windows can be forced to use TCP directly instead of trying UDP first, by setting the following registry value:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\
Parameters]
"MaxPacketSize"=dword:00000001

Please find additional information regarding this behavior in the MSKB244474 .

Posted in Active Directory | 2 Comments

The PXE boot process and SCCM OS deployment

When a client boots from the network over PXE in a Microsoft SCCM environment, the following procedure takes place:

  1. The PXE client broadcasts an EXTENDED DHCPDISCOVER package (containing the DHCP option 60) from port 68 and both, the DHCP and the WDS/PXE server in the same broadcast domain receive the discover on port 67.
  2. The DHCP server broadcasts a DHCPOFFER package from port 67, offering the client a free IP address. The client receives this offer on port 68.
  3. The WDS/PXE server broadcasts an EXTENDED DHCPOFFER package from port 67 (containing DHCP option 60 incl. the IP address of the PXE server). The client receives this offer on port 68.
  4. The PXE client broadcasts a DHCPREQUEST package from port 68, requesting the acknowledgement of the IP offer. The server receives this request on port 67.
  5. The DHCP server broadcasts a DHCPACK package from port 67, acknowledging the requested IP address. The client receives the acknowledgement on port 68, knowing now that it can use this IP.
  6. The PXE client uni casts an EXTENDED DHCPREQUEST package (containing the DHCP option 60) from port 68 to the WDS/PXE server. The server receives this request on port 4011.
  7. The WDS/PXE server uni casts an EXTENDED DHCPACK package (containing the DHCP option 60 and the boot file name path to download the NBP via TFTP). The client receives this acknowledgement on port 68 and starts downloading the boot image via the TFTP protocol from the known location.

When running PXE during a SCCM OS deployment, the WDS/PXE server forwards the EXTENDED DHCPDISCOVER to the “ConfigMgr PXE service point” component, which is implemented on the WDS/PXE server as an additional PXE provider (“SMSPXE”). The SMSPXE provider talks to the central SCCM management point to receive additional information about the client which is currently running the PXE boot:

  1. SMSPXE executes a “LookupDevice” to verify based on the MAC address of the PXE client, if the client is known. The result “Device found in the database” is expected.
  2. SMSPXE executes a “GetBootAction” to verify, if the client has an advertisement which is enabled for PXE boot. The result “Found optional [mandatory] advertisement” is expected. Note: “GetBootAction” will not be executed at all, when there are no boot images installed on the “SMSPXEIMAGES$” share of the WDS/PXE server.
  3. SMSPXE sends the EXTENDED DHCPOFFER package. Note: the DHCPOFFER will NOT be sent, when the above prerequisites are not fulfilled. This will results in a failed PXE boot on the client.

Troubleshooting PXE boot issues

When the PXE boot fails during a SCCM OS deployment, the following points can be checked:

  1. Is PXE boot activated on the client and does the “DHCP…/” message appear on the screen?
  2. Does the WDS/PXE server receive the EXTENDED DHCPDISCOVER (WDS service is running, port 67 is open and receives broadcasts) and does the smspxe.log file log the action “LookupDevice” for the client’s MAC address?
  3. Are the PXE boot loader files available on the PXE server in the folder “C:\Windows\Temp\PXEBootFiles”? If not, the following error may be reported during PXE boot:  PXE-T01: The specified file was not found, PXE-E3B: TFTP Error – File not found. Note: In some cases the WDS may have problems in copying the boot loader files to that folder while starting and as a result, the service cannot start at all. When this happens, a helping workaround is to rename (or delete if possible) the “PXEBootFiles” folder and restart the WDS service.
  4. Is the PXE device listed in the SCCM database with the correct MAC address and does the smspxe.log file log the action “Device found in the database” ? Note: To force the WDS/PXE server to check the SCCM database against a MAC address with each PXE request, it is needed to set the registry value “CacheExpire” to “1” (“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\PXE“). Else the WDS/PXE server will use cached information for the “LookupDevice” action which will be refreshed by default only once per hour.
  5. Are both default boot images (x64 and x86) replicated to the WDS/PXE server and does the smspxe.log log the action “GetBootAction“?
  6. Does the PXE device has a “PXE enabled” advertisement which advertises a task sequence having a boot image assigned and does the smspxe.log log the action “Found optional [mandatory] advertisement“?
  7. Does the WDS/PXE server send the EXTENDED DHCPOFFER and does the client start downloading the boot image?
  8. Does the SCCM “Network Access Account” have access to the “SMSPXEIMAGES$” share and the folder “[SMSDRIVE]:\RemoteInstall\SMSIMAGES” on the WDS/PXE server and is the boot image package up to date (“Update Distribution Point”)?
Posted in System Center Configuration Manager | 5 Comments