0

On the DC of a single-AD forest, I am logged in as the default domain administrator Administrator (in this case also the enterprise administrator). In an elevated PowerShell, I try to get the Kerberos encryption types with the following command (as documented here):

ksetup /getenctypeattr my.example.com

But I get an error message instead:

Query of attributes on MY.EXAMPLE.COM failed with 0xc0000034
Failed /GetEncTypeAttr : 0xc0000034

In consequence (most probably), I also get this error when trying to set the encryption types, as described in this question, which currently does not have a serious answer, unfortunately.

This does happen on Windows Server 2016 and also on Windows Server 2019, which have been setup by mostly using default settings. How can a simple get fail? The error code does not seem to be documented. Does someone know how to troubleshoot or solve this problem?

stackprotector
  • 445
  • 1
  • 3
  • 20

1 Answers1

1

How can a simple get fail?

Either by trying to 'get' a nonexistent attribute, or an attribute of a nonexistent entry.

0xc0000034 is a standard NTSTATUS value (errno) named "STATUS_OBJECT_NAME_NOT_FOUND" and documented as "The object name is not found."

Based on getting the same error on set, it sounds like the whole entry doesn't exist in AD – that is, you don't have a "trust" configured with the specified realm.

As far as I know, the command you're using isn't meant for enabling/disabling encryption types for the local realm – that's defined by KDC software, registry configuration, keys held by the 'krbtgt' principal. Instead, the command only adjusts configuration for inter-realm trusts, allowing the local KDC to know what encryption types are currently supported by the specified remote realm's KDCs.

user1686
  • 8,717
  • 25
  • 38
  • I actually _was_ using a multi-domain setup and tried to reproduce the problem on a _more simple_ (single AD) setup. It turned out, on the multi-domain forest setup, I was not testing enough. The command indeed works, if you execute it for a trusted domain, and not for the domain your are currently logged on to (although you can configure all trust directions trough `domain.msc`). – stackprotector May 04 '22 at 09:21