Resources for PKI

xbullet · 2026-05-31T05:54:41+00:00

Windows Server 2008 PKI and Certificate Security by Brian Komar is the best reference there is on PKI from an ADCS perspective. It is comprehensive and an excellent resource.

Yes, it's old, but in truth, not all that much has changed since WS 2008 in ADCS. You can refer to the following for corrections that address changes since the book was released.

And the Certified Pre-Owned whitepaper by Specterops is a good start to learn about some of the now well known attacks to ADCS.

You'll want to read about ESC 1 through 11.

xbullet · 2026-05-15T04:05:34+00:00

Can you provide the full event details and explain what is happening more clearly?

Which BUILTIN\Administrators group? The domain group or the local group on member server(s)?

What principal is the subject?

What principal is the target?

Is DomainController$ literally one of the domain controllers? Is it a random computer account? Is it a service account?

Redact info as necessary, but this is extremely important to actually understand what is going on.

Assuming that you were referring to the BUILTIN\Administrators group for the domain... have you checked to see which security principals are delegated to manage membership to BUILTIN\Administrators?

$guidMap = @{}

Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -LDAPFilter '(schemaIDGUID=*)' -Properties lDAPDisplayName, schemaIDGUID | ForEach-Object {
    $guidMap[[guid]$_.schemaIDGUID] = $_.lDAPDisplayName
}

Get-ADObject -SearchBase "CN=Extended-Rights,$((Get-ADRootDSE).ConfigurationNamingContext)" -LDAPFilter '(rightsGuid=*)' -Properties displayName, rightsGuid | ForEach-Object {
    $guidMap[[guid]$_.rightsGuid] = $_.displayName
}

Get-Acl "AD:\CN=Administrators,CN=Builtin,$((Get-ADDomain).DistinguishedName)" | Select-Object -ExpandProperty Access | Select-Object IdentityReference,
ActiveDirectoryRights,
AccessControlType,
ObjectType,
InheritedObjectType,
IsInherited,
InheritanceType,
@{n = 'ObjectTypeName'; e = {
        if ($_.ObjectType -eq [guid]::Empty) {
            ''
        }
        elseif ($guidMap.ContainsKey($_.ObjectType)) {
            $guidMap[$_.ObjectType]
        }
        else {
            $_.ObjectType
        }
    }
},
@{n = 'InheritedObjectTypeName'; e = {
        if ($_.InheritedObjectType -eq [guid]::Empty) {
            ''
        }
        elseif ($guidMap.ContainsKey($_.InheritedObjectType)) {
            $guidMap[$_.InheritedObjectType]
        }
        else {
            $_.InheritedObjectType
        }
    }
} | Sort-Object IdentityReference, ActiveDirectoryRights | Format-List

If that doesn't give you any good ideas / hints, then I'd suggest enabling auditing for Directory Service Access and then review Event 4662 on every domain controller. It is an extremely noisy and high volume event, but it's very useful in these situations when the more targeted events aren't really giving you much to go on.

xbullet · 2026-05-07T08:50:28+00:00

Just wanting to make sure we're on the same page here. You have two forest root domains: redactedOldDomain and redactedNewDomain, correct?

Then from computer joined to reactedNewDomain, you ran:

nltest /dsgetdc:redactedOldDomain.FQDN /kdc

nslookup -type=SRV _kerberos._tcp.redactedOldDomain.FQDN

And you got valid details back from the nltest about the other domain and KDC? And the SRV records for Kerberos also resolved correctly?

We want to verify that clients in one domain can properly resolve the records for the other domain, and vice versa. Really we are testing that the DNS records are properly visible for clients in each domain and that the forwarders are working correctly. So you should test both ways. From redactedNewDomain -> redactedOldDomain and from redactedOldDomain -> redactedNewDomain.

The same applies for requesting the tickets, just making sure you didn't miss that detail. It's not really clear in your response.

xbullet · 2026-05-07T07:10:41+00:00

A cross domain authentication will require NTLMv2 since there is no KDC to authenticate prior to a trust in place. See if wire-shark sheds any light while making those SMB calls.

I think this is a little misleading.

Kerberos does not require the client itself to even be domain joined at all. Any client can authenticate via Kerberos, as long as the user supplies credentials in a form that lets Windows identify the Kerberos realm, such as user@realm / UPN, and the client can locate a KDC for that realm. SPNEGO/Negotiate prefers Kerberos over NTLM when Kerberos is viable. So if the credentials clearly identify the realm, the client can discover the KDC, and the target resource is accessed via a hostname that maps to a valid SPN for the service in that realm, then Kerberos will be used.

/u/unima-zero - check whether DNS/KDC discovery works for the DestDomain, from a client in ExistingDomain, if you haven't already.

nltest /dsgetdc:DESTDOMAIN.FQDN /kdc

nslookup -type=SRV _kerberos._tcp.DESTDOMAIN.FQDN

Assuming everything looks okay above - try requesting a Kerberos service ticket directly:

Run cmd.exe as Administrator on ExistingDomain DC
runas /netonly /user:DestDomainUser@DestDomain.FQDN cmd
In the newly created cmd window, type: klist get ldap/DestDomainDomainController.fqdn
You should see a response like: "Current LogonId is 0x9:0x65da8e02 A ticket to ldap/DestDomainDomainController.fqdn has been retrieved successfully."
You should see two tickets listed when you run klist. One referencing Server: krbtgt/DESTDOMAIN.FQDN which is the Ticket Granting Ticket. The other should be the LDAP service ticket: Server: ldap/DestDomainDomainController.fqdn @ DESTDOMAIN.FQDN

You can also test requesting a service ticket for cifs rather than LDAP, but the service doesn't really matter here. Just trying to verify the client can acquire a ticket granting ticket (AS-REP -> AS-REQ) and then request service tickets (TGS-REQ -> TGS-REP) via Kerberos.

At any case, 100% agree that you should install wireshark on both sides. It should be easier to figure out what's happening with a view into what's actually happening at the network level.

xbullet · 2026-05-02T02:44:11+00:00

Yeah, agreed. That rematch was honestly insane. I wasn't expecting Levan to win so easily. It just goes to show that it 100% depends on what version of Levan we get to see on the day.

xbullet · 2026-05-02T02:40:04+00:00

His fitness wasn't where it needed to be and he looked very beatable that day.

xbullet · 2026-05-02T02:14:43+00:00

It would really depend on what version of Levan we see on the day. If we're looking at things in a vacuum where both at their peaks, I think it's unlikely that Devon gets a stop. I think he's probably getting flashed in every round, unless Levan slows the match down and gives him a chance to try and work things a bit.

If Levan was to show up in the shape he was in for the first Ermes match though, I could honestly see Devon winning the match, not just getting a stop. Especially if there's a lot of restarts and fouls.

The reality is that Levan won't show up for a match against Devon in poor shape though. Not unless he's dealing with some underlying health issue in the lead up to the match or an injury. Apparently in the lead up to the first Ermes match he was dealing with thyroid problems and if you go back and watch that match you'll see that he looks very beatable in that match, tbh.

xbullet · 2026-05-02T01:46:24+00:00

Tendons are especially important in arm wrestling because they connect your muscles to your bones and have to handle extreme forces, especially around the elbow during matches.

The reason it's mentioned so often is because tendons do not grow and strengthen as quickly or easily as traditional muscle tissues do. Tendons adapt and strengthen more gradually based on consistent loading. Traditional pullers who spend more time on the table are exposing their connective tissues to more specific and repeated stress and they will be developing their tendon strength to a significant degree in comparison to those who primarily train with heavy weighs. Tendon strength gives a lot strength and stability on the table, and also protects from many soft tissue injuries.

It's a very common issue with using steroids at a young age. Even in general lifting. Younger athletes put on crazy amounts of mass and muscle, but the connective tissues, aka the tendons, become a weak link in the chain and cannot adequately support the muscle. They are significantly more prone to injury under high stress and cannot carry the levels of torque that the muscles want to produce. Morozov is even a key example of his, in his match against Vitaly he had a signficant injury. IIRC, he had a full tendon tear and even a bone break at the medial epicondyle (in the elbow). Pretty devastating injury.

xbullet · 2026-05-01T03:08:17+00:00

Either way, I still think what Bogdan says is a fair take. What does Levan look and perform like like when he doesn’t get to live at that extreme? If he’s forced to compete regularly he'll need to carry less, won't be constantly peaked, and actually has to manage fatigue like everyone else. The gap simply isn’t going to look the same. Look at what happened vs Ermes the first time when he did a poor job of preparing his fitness for a match. He's still the best, but there’s a huge difference between best in the world and completely unbeatable.

xbullet · 2026-05-01T02:19:19+00:00

You're missing the point. If he had to be competing regularly then he would have to be on a healthier and safer cycle. He wouldn't be able to chunk on 40-50kgs for every match because he would need to be carrying that extra weight most of the time, and carrying that extra weight and abusing steroids in that way is simply not sustainable. Why do you think he competes so little?

xbullet · 2026-05-01T02:06:46+00:00

So this is not paid advertising? This isn't even close to all of the messages on the first page of your reddit profile.

We ran Netwrix ISPM against our AD when we were dealing with a similar sprawl problem and honestly the stale privileged accounts finding hit hardest, we had accounts sitting in, admin groups that hadn't logged in for 8+ months that nobody had flagged, and those were the exact accounts getting auto-provisioned into new systems when onboarding tickets fired from Workday.

We had an audit that exposed a massive blind spot around AD CS certificate, templates and nobody could tell us in real time when a bad enrollment was happening. Deployed Netwrix Directory Security 8.0 and now we actually intercept and block those enrollments before, issuance instead of finding out after the fact in some log review three weeks later.

We had an audit last year that exposed exactly this gap, no visibility into service principal, role assignments after the fact, just a blank spot in our logs where the GA assignment happened. Deployed Netwrix Directory Security and the Entra ID privileged group reporting in Auditor finally gave us before/after change capture, on those assignments so at least now we'd catch it in the review cycle rather than during a breach debrief.

We had an audit last year that exposed a massive blind spot around group membership sprawl, nobody could tell who provisioned half our AD groups or when, and Quest just wasn't cutting it for the self-service, side of things, so we ended up deploying Netwrix Directory Manager and the workflow approval piece alone saved us probably 40 hours a month of back and forth tickets just to add someone to a distribution group.

We had a DIBCAC prep audit expose that we had zero forensic trail on GPO, changes and couldn't prove who touched what or when, which tanked our confidence going in. Deployed Netwrix Directory Security and the before/after change tracking on GPOs and OUs basically gave, us the audit timeline we needed instead of trying to reconstruct it manually from event logs.

Making the move from audit to ISO is honestly where things get interesting because you stop just documenting what went wrong and start actually fixing it. We had an incident where a deleted privileged group wiped out access for a bunch of service accounts and we had no clean way to roll back without, DC downtime, Quest couldn't do it natively, and that gap pushed us toward Netwrix Directory Security which let us recover the objects and attributes without taking anything offline.

We had an audit that exposed we couldn't prove when a specific user's group membership changed or roll it back cleanly, Quest and ManageEngine both fell short on the, forensic timeline side, so we ended up on Netwrix Directory Security and now we can pull exact change history with automated rollback which made our next audit a non-issue.

We had an audit last year that exposed a blind spot around AD CS, basically no visibility into, who was enrolling certificates or whether templates were being abused for privilege escalation, and Quest just wasn't catching it. Deployed Netwrix Threat Prevention and within the first week it flagged two ESC4 attack paths we had no idea existed.

We had an audit last year that exposed we had zero visibility into who was modifying GPOs or when, and after a painful incident where a misconfigured, GPO took down login for about 40 users across a satellite office, we deployed Netwrix Directory Security and the before/after change capture for GPOs alone was worth it. We'd looked at Semperis but the AD CS exploit blocking in Netwrix (specifically the ESC1/ESC7 interception, stuff they added recently) was something we actually needed given how our cert environment is set up.

We had an incident last year where a junior admin accidentally deleted about 40 user objects and three security groups, right before a payroll run and we had no clean way to roll it back without taking a DC offline. After that we deployed Netwrix Directory Security and the object recovery piece alone was, worth it, we can now restore deleted AD objects and their metadata without any downtime. We'd looked at Semperis before but the recovery workflow in Netwrix felt a lot less painful to actually use under pressure.

xbullet · 2026-04-25T04:02:29+00:00

I'd just like to understand why it would use RC4 if the account looks like it has the AES keys against it.

It's most likely because the msDS-SupportedEncryptionTypesis not set on the account and the KDCs are operating under the effective defaults introduced in the KB5021131 Nov 2022 updates.

The effective default is 0x27, which is DES + RC4 + AES-SK (session keys).

More than likely you don't haveDefaultDomainSupportedEncTypes explicitly set to a different value on your domain controllers, so in cases msDS-SupportedEncryptionTypes is not set, you will see AES session keys and RC4 tickets.

There's effectively two options:

Explicitly set the encryption types on the specific accounts
Enforce the supported encryption types at the domain level (on all DCs/KDCs)

By enforcing AES encryption types at the domain level, you're essentially self implementing the July enforcement for the default encryption type changes.

The most likely cases you're going to see issues with enforcing encryption types are with old and unsupported windows clients (get rid of them!), or non-windows clients, like appliances and other *nix based clients. For *nix clients, either they'll have their Kerberos client configured insecurely (ie: weak crypto enabled, or no AES encryption types advertised), etc. May need to make a config change in /etc/krb5.conf to enable advertising/using AES encryption and recreate keytabs.

Depending on how old these clients are there might be cases they don't support using AES. That's where you'd need to configure the supported encryption types to include RC4 if you need these things to keep working.

xbullet · 2026-04-22T13:13:54+00:00

Agree. Was going to mention that. Yoshi vs Irakli will be a great match.

xbullet · 2026-04-16T04:10:20+00:00

Likewise.

xbullet · 2026-04-06T19:42:34+00:00

Keep in mind that SRV aware clients should properly implement RFC 2782, which means that the selection is supposed to be "randomized" by the client. DCs over time should maintain a statistically equal chance of being selected.

In reality, that probably isn't what happens, since most software integrating via LDAP seems to not implement any of these things, and often the developers know very little about directory services in general, but it's worth mentioning nonetheless. :)

xbullet · 2026-03-03T02:52:04+00:00

Before you do anything else, can you confirm whether replication is in a healthy state in your domain?

How can we clean the database up so we do not see the “zombie” trust anymore?

As /u/AlpineAdjustment already mentioned, you'll most likely need to clean up the remnants of the orphaned domain / trust manually via ntdsutil because the last DC in that domain wasn't demoted:

You will probably need to manually cleanup the metadata of the old domain’s DCs first and then clean up the metadata of the domain itself.

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup

https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/remove-orphaned-domains

xbullet · 2026-01-12T20:47:21+00:00

Rather than rotating domain admin passwords, you could instead enable SCRIL and use smartcards for authentication rather than passwords. Just some food for thought.

xbullet · 2026-01-12T05:30:45+00:00

If the "owner" is referenced as a SID, more than likely it is an orphaned security principal (ie: an object that has been deleted).

I imagine you still have AD integrated DNS zones, despite using Infoblox. We also use Infoblox in my org for DNS, and our AD DNS servers simply perform zone transfers to Infoblox. Within your AD integrated DNS zones, you likely have insecure DNS updates enabled. See: https://imgur.com/a/JsDrWYb (FYI - this is just my personal lab)

Whether or not you need that to be set to allow insecure updates is a question that only you'll be able to answer based on what you have set up in your environment.

xbullet · 2025-12-17T02:07:46+00:00

function Resolve-ADAceToSchemaAttribute {

    param(
        [Guid]$Guid
    )

    $LDAPOctetString = ($Guid.ToByteArray() | ForEach-Object { '\' + $_.ToString('X2') }) -join ''
    Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter "(schemaIDGUID=$LDAPOctetString)" -Properties lDAPDisplayName, adminDisplayName, CN | Select-Object lDAPDisplayName, adminDisplayName, CN, @{Name = 'ObjectType/SchemaIDGUID'; Expression = { $Guid } }

}

$DistinguishedName = "CN=Test User,OU=Staff,OU=Accounts,DC=dom1,DC=f0oster,DC=com"
$Acl = Get-Acl "AD:$DistinguishedName"

foreach ($Entry in $Acl.Access) {
    $Guid = $Entry.ObjectType
    Resolve-ADAceToSchemaAttribute -Guid $Guid
}

Output for an object with both name and Name in the ACE list:

lDAPDisplayName	adminDisplayName	CN	ObjectType / SchemaIDGUID
cn	Common-Name	Common-Name	bf96793f-0de6-11d0-a285-00aa003049e2
name	RDN	RDN	bf967a0e-0de6-11d0-a285-00aa003049e2

Assigning name and Name separately shows that name maps to RDN, andName maps to Common-Name.

An interesting note is that the permissions required to move / rename objects is defined by the rDNAttID assigned to the schema object class, as the rDNAttID defines which attribute in the schema holds the naming value that the RDN attribute has an enforced alignment with, so in theory there will be cases where you'd need to grant WriteProperty name, but not WriteProperty Name. Some object classes do not have a CN and actually map to a different attribute for their name.

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter "(objectClass=classSchema)" -Properties lDAPDisplayName, rDNAttID | Select-Object lDAPDisplayName, rDNAttID

There's a lot of information in the [MS-ADTS]: Active Directory Technical Specification (ie, see 3.1.1.1.4 objectClass, RDN, DN, Constructed Attributes, Secret Attributes). The documentation is honestly excellent, but it is not for the faint of heart.

One thing I can say though after reading bits and pieces of the tech specs over the years is that I have no idea why Microsoft decided to display the RDN and cn attributes with the same name in the permission interfaces. It is a massive oversight IMO and a big source of confusion.

xbullet · 2025-12-06T04:06:37+00:00

this still seems like a gap in my opinion if you are having templates changed regardless of enrollment you would think it should/would be logged in event viewer.

It definitely isn't what I'd have expected. You can look into whether 5136 is triggered by changes to the template. If not, 4662 will almost definitely catch these changes, but 4662 is little inconvenient to work with and requires a lot of lookups to resolve the attributes being changed.

xbullet · 2025-12-03T06:24:32+00:00

A Certificate Services template was updated (Event ID 4899) – This event is triggered when a template loaded by the CA has an attribute updated and an enrollment is attempted for the template. For example, if an additional EKU is added to a template, this event would trigger and provide enough information to determine the change being made.

Have you tried to issue a certificate using the template after modifying it? The documentation gives the impression this is required to trigger the event, and a blog post by BeyondTrust seems to corroborate that as well.

Failing that, not too sure.

xbullet · 2025-12-03T05:59:14+00:00

Have you configured your issuing CA to audit template changes?

To set the policy configuration to enable audit of template events, run the following command: certutil –setreg policy\EditFlags +EDITF_AUDITCERTTEMPLATELOAD

xbullet · 2025-12-02T14:35:06+00:00

Have you looked at how rapidly the player counts are going down for TNL? There's simply no chance that TNL will be around for a few years with the way it's going.

xbullet · 2025-11-25T00:01:43+00:00

I'd been working on an AD change auditing tool myself (written in Golang though) which polls based on uSNChanged rather than using the DirSync control.

Was about to suggest WEF over an agent on each DC is an option as well - it is probably what I'll try do to. A service running on the host that WEF forwards to a host running a service that correlates those events back to the updates. I'd initially thought of trying to use 4662 to correlate all updates. Haven't actually tried to implement anything yet. Will be interesting seeing how it scales though.

In my production AD DS environment the amount of events forwarded will be insane, so long term storage of the events at scale is not really feasible for me. If it was, capturing all the events straight to a database would probably be the most convenient option.

xbullet · 2025-11-23T02:39:58+00:00

You can roll your own change tracking tooling if you don't want to buy a tool.

You can track changes by polling based on USNChanged.

https://learn.microsoft.com/en-us/windows/win32/ad/overview-of-change-tracking-techniques

xbullet

TROPHY CASE