Score:0

Kerberos settings in GPO never seem to apply in spite of the GPO otherwise working

us flag

Server 2019 Domain Environment. Issue is related to the DCs themselves.

I've a self-created GPO on my DC OU that sets a bunch of things, several of which are Kerberos settings:

enter image description here

Curiously, while other things in the GPO seems to set on the DCs in question, these specific ones do not. Scanning through GPResult outputs does not seem to show those settings being misconfigured by some other GPO (they don't show up at all in GPResult's HTML file or even in RSOP).

Googling around got me nowhere except finding references to a built in GPO called "Default Domain Policy" that actually appears to be completely absent in my (inherited) environment.

Is there some other special configuration required in AD to get GPO settings for Kerberos to apply?

Score:1
cn flag

All account policies settings applied by using Group Policy are applied at the domain level. Default values are present in the built-in default domain controller policy for Password Policy settings, Account Lockout Policy settings, and Kerberos Policy settings. The domain account policy becomes the default local account policy of any device that is a member of the domain. If these policies are set at any level below the domain level in Active Directory Domain Services (AD DS), they affect only local accounts on member servers.

The only exception is when another account policy is defined for an organizational unit (OU). The account policy settings for the OU affect the local policy on any computers that are contained in the OU. For example, if an OU policy defines a maximum password age that differs from the domain-level account policy, the OU policy will be applied and enforced only when users sign in to the local computer. The default local computer policies apply only to computers that are in a workgroup or in a domain where both an OU account policy and a domain policy don't apply.

Note:

Each domain can have only one account policy. The account policy must be defined in the default domain policy or in a new policy that is linked to the root of the domain and given precedence over the default domain policy, which is enforced by the domain controllers in the domain. These domain-wide account policy settings (Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the domain; therefore, domain controllers always retrieve the values of these account policy settings from the default domain policy Group Policy Object (GPO).

https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/account-policies

us flag
Alright, near as I can tell my "Default Domain Policy" was removed in some way prior to me gaining administration of the system. The policy that I created that *should* be setting these is attached to the DC OU, not the root of the Domain. It sounds like I need to create one that attaches to the root of the domain and not the OU, then?
cn flag
@TheITeaGuy: You can create a separate GPO, linked at the domain level, with a higher precedence and that should work.
us flag
Awesome; gave this a shot and it appears to have solved the issue. I am unsure how I did not come across this myself while Googling around for an answer, but you certainly seem to have found it. Thanks!
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.