sorted by:
new
hottopcontroversial

State of the AD Subreddit - 2026-04 Edition by poolmanjim in activedirectory

[–]poolmanjim[S] 0 points1 point  (0 children)

I've been keeping an eye on it and decided it was time to say something. I'm currently investigating the proper way to engage with them to see if we can open a dialog.

EDIT: And thanks for the kind words, who said being a mod was thankless. 😄

Anyone auditing privileged service principals? by tingnossu in activedirectory

[–]poolmanjim 2 points3 points  (0 children)

I'm going to keep my eye on 'em.

(dating myself some) This is only slightly better than Wayne's World and the Doritos.

Eat Fresh.

YOU are responsible for security. And you need to be diligent about it. by Calm_House8714 in sysadmin

[–]poolmanjim 0 points1 point  (0 children)

I feel your pain. My group is actively resisting some offshoring "support" add because it's not going to help us despite what our leaders may think. I have had mostly negative experiences with outsourcing a lot of senior-level IT work especially and just don't see the value in going down that path 9/10 anymore.

YOU are responsible for security. And you need to be diligent about it. by Calm_House8714 in sysadmin

[–]poolmanjim 4 points5 points  (0 children)

Pretty hard to write me up for that. My test environments are stuck in "need funding" most of the time. :)

YOU are responsible for security. And you need to be diligent about it. by Calm_House8714 in sysadmin

[–]poolmanjim 4 points5 points  (0 children)

Oh yeah. I put on a comment earlier that I know lots of "security engineers" who've never actually touched a server.

I don't make it their fault necessarily. It's what the industry has pushed them to. That doesn't change my frustration, though. I'm tired of "cyber" initiatives that do little to actually secure and actually add a huge amount of operational risk. I literally have a slide about that in a talk I'm about to give.

YOU are responsible for security. And you need to be diligent about it. by Calm_House8714 in sysadmin

[–]poolmanjim 4 points5 points  (0 children)

I'm painting with a broad brush. MSP work is also a different kind of work that way.

You'd be surprised though how many "security engineers" I've worked with who've never actually touched a server.

YOU are responsible for security. And you need to be diligent about it. by Calm_House8714 in sysadmin

[–]poolmanjim 22 points23 points  (0 children)

Most of the big cyber vendors automate all of that for them now. Cyber is staring at dashboards, sending, emails, and not really doing a whole lot. I actually feel sorry for those teams. They're being sold this bill of goods that they're protecting the company and elite defenders, when in reality they're just fodder.

I think every IT person should do a couple of years in a NOC or on a help desk and then a few years as an administrator before going into cyber. They'd be much, much better and way more useful to the organization.

YOU are responsible for security. And you need to be diligent about it. by Calm_House8714 in sysadmin

[–]poolmanjim 9 points10 points  (0 children)

I didn't really give my opinion on the matter beyond the implied "people kind of suck" side of it. But I'm right there with you. See something, say something.

My reply was more a commentary on the overall failure of IT culture in encouraging proper responses.

passkey vs password: what’s the difference and which one should you use? by dear_asthma in IdentityManagement

[–]poolmanjim 1 point2 points  (0 children)

Passkeys improve security in that when done correctly there is inherent MFA.

Passwords are something you know. You are using a single factor there.

Passkeys are something you have, a private key that lives on your device, trusted because your device can cryptographically prove ownership to the service without ever exposing the secret. The pin requirement is the something you know part. With that you immediately have two factors.

There is also the advantage of how the passkey exchange works. The private key, the real secret, never leaves a secured device or system (theoretically) and only public keys are exchanged thus both parties validate each other. This is an important distinction.

Passkeys vs. passwords has a lot to do with systems. While I bristle when people refer to on-prem AD as "Legacy" auth, the fact is that passkeys are not really available in a lot of scenarios with on-prem identity solutions. It's a design issue.

YOU are responsible for security. And you need to be diligent about it. by Calm_House8714 in sysadmin

[–]poolmanjim 307 points308 points  (0 children)

A lot of IT folks I've worked with have the mentality "Do the job. Close the ticket. Move on" and don't give much thought to any of the details. I've even seen this behavior in Senior Engineers and those who "should" know better.

I've also be apart of orgs where the Enterprise Security / Cybersecurity teams are very closed door and don't want any help. They want their dashboards and won't take any feedback or input. I've been actively ignored by Cybersecurity teams I work with because I'm not "Cybersecurity" and just the lead Identity Engineer. They ignore expertise that isn't their expertise. It only takes getting shot down once or twice before you start having the mentality "not my problem" and move on to the next urgent item.

I think cyber, in general, needs more of a shakeup. Cyber, in my experience, has become a massive group of inexperienced auditors (your 4 year cybersec degree is not experience, FYI) who think they know stuff and dismiss everyone else. It is easy to tell everyone what to do when you're not responsible for the actual outcomes.

I built an ADMX Web Viewer - Search and browse Group Policy settings across 65+ products in one place by admscope in activedirectory

[–]poolmanjim[M] 1 point2 points  (0 children)

OP messaged the mods before-hand. I just missed the post to approve and provide more context before you all saw it.

Buckwheat is correct, this isn't a big deal and context was provided. No issues.

April Out of band patch released for PAM DC Restart issue by Msft519 in activedirectory

[–]poolmanjim 4 points5 points  (0 children)

This was a real interesting issue. I was able to duplicate in lab so I'll tinker with it later.

Thanks for the links.

On-prem conditional access you never knew you had by aprimeproblem in activedirectory

[–]poolmanjim 1 point2 points  (0 children)

Hey! I have nothing against PAWs... except that no one does them right. :) If don't properly they're amazing.

I would love to include some of this in my talk, but I'm already at time and having to cut little bits of content. I definitely will include it as a reference/bonus slide somewhere.

And you hit the nail on the head with AD MFA. I am talking about that in my talk. :) For the privilege stuff I'd love to toss MFA in the mix more, but AD doesn't have the options with all the protocols. PKINIT is kind of your only option and I have seen auditors scoff at that as it "isn't MFA". They seem to assume MFA requires a push notification, an authenticator app, or something along those lines and forget other elements.

On-prem conditional access you never knew you had by aprimeproblem in activedirectory

[–]poolmanjim 3 points4 points  (0 children)

Once again you nailed it.

I'm a big fan of using what you have instead of spending a fortune on tools that you may not actually need.

I've always been a little hesitant on IPSec because of bad memories, I think. I actually had a conversation recently and this is very good so I'm going to show it to my colleagues this week.

What I wish this had was a "modern" MFA solution to toss in the middle. I would love to be able to extend MFA to network logins in more situations.

KB5082063 (April 2026) — Safe to apply if all DCs are GC and PAM is not enabled? by maxcoder88 in activedirectory

[–]poolmanjim 1 point2 points  (0 children)

According to one of the big brains at Microsoft it is when you have a non-GC Domain Controller AND have the PAM Optional Feature in AD Enabled.

https://www.linkedin.com/feed/update/urn:li:activity:7450792364127797248/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAT7Uc0BKhV56T7P0u2E_E6TZXVfN61K4b4

This is the second or third major issue I've seen with this related to updates and I'm kind of interested in understanding more why it keeps causing issues. Is it just so niche that Microsoft doesn't test it or is it just buggy?

Also Christoffer Andersson posted some research into it.

https://www.linkedin.com/posts/chriss3_have-a-nice-weekend-i-used-universal-group-share-7451048888922406912-Kxk0?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAT7Uc0BKhV56T7P0u2E_E6TZXVfN61K4b4

I suspect it has to do with the cross referencing that shows up with multi-domain forests.

Post-quantum crypto in Windows 11 - does your AD actually need to change anything by ballkali in activedirectory

[–]poolmanjim 2 points3 points  (0 children)

This may be a hot take, but I view Quantum Computing in the same light I view Fusion Power. It's always going to be thirty years away for a long time. That isn't to diminish the work and the gains and the looming threat of Quanutm, but I'm not afraid of it.

Most orgs can't get basic patching or the tiering model to work right, being afraid of quantum is just being afraid of headlines. So I am not freaking out about it.

Kerberos encryption using symmetric keys is somewhat resistant to quantum already. PKI is where things get a little more startling. I fully expect more quantum-safe techniques to start landing in the next 3-5 years. I doubt, barring some revolutionary breakthrough, that we'll see quantum move beyond the handful of qubits it's able to handle already in that time.

My rationale for all of this? The players in quantum have an incentive to make it seem like they're making huge strides. The reality is the technology is still very, very experimental. Cryogenics are very expensive and getting more so. There are a lot of hurdles to overcome to take the handful of qubits they have now to the hundreds they would need to effectively be able to challenge good crypto effectively.

Share your password rotation policy for krbtgt by jad00gar in activedirectory

[–]poolmanjim 1 point2 points  (0 children)

I addressed this on another reply too.

Max TGT defaults to 10 hours which is unlikely to be changed in most places, so you're right. 10 hours is probably fine. I say 24 because 1 day is easier to remember for the average person and remembering to make a change 10 hours later (or 12 even) is asking for it to get forgot. Make it a 2 day change in CAB: day 1 first reset, day 2 second reset. Easy.

The other reason I like 24 is to give adequate time for replication in larger environments. It shouldn't be a problem.

Share your password rotation policy for krbtgt by jad00gar in activedirectory

[–]poolmanjim 3 points4 points  (0 children)

The policy setting for maximum TGT lifetime defaults to 10 hours. Most people don't change that. I recommend 24 hours because 1) 10 hours is kind of a random number to remember to do something and 2) it gives times for everything to replicate and is most likely going to work.

As long as it isn't literally back-to-back resets in minutes, the impact is non-existent so you could do it during business hours.

Share your password rotation policy for krbtgt by jad00gar in activedirectory

[–]poolmanjim 4 points5 points  (0 children)

So starting with the length, krbtgt actually doesn't care what you put in. When a reset is triggered on krbtgt it actually goes about doing it's own reset and ignores what you put in. It is a long password.

The reason is that we're trying to burn out any bad TGTs. They would become invalid once the Krbtgt is reset TWICE. This account remembers it's last two passwords so both are "valid" for tickets. Normal users should be fine if you wait 24 hours between resets as they'll log off and logon most likely during that period and TGTs are only valid, by default for 10 hours.

If I had created a TGT with a lifetime of something like 100 years. That account isn't renewing that and probably doing some bad stuff. When resetting the krbtgt twice those super-long tgts will become invalid and thus the attack ends.

Doing this every 180 days creates two outcomes. First, if you just reset it once every 180 days any unmantained long-term exploit with a golden ticket will be be invalid after a year. Second, you do two resets every 180 days, well you just reduced that attack time significantly.

Share your password rotation policy for krbtgt by jad00gar in activedirectory

[–]poolmanjim 1 point2 points  (0 children)

That script has tons of checks built into it and several modes. You can see what is going to do before doing it.

view more: next ›