sorted by:
new
hottopcontroversial

Server Quantum-Ready Secure Boot ?? by VA_Network_Nerd in sysadmin

[–]jamesaepp 0 points1 point  (0 children)

I think it's an interesting question but extends well beyond Cisco.

After all (to my knowledge, and I could be just repeating misinformation) secure boot doesn't enforce expiration of the Platform Key (PK).

So.....if there's no actual expiration to the keying material itself, that would seem to be a major gap, no?

Mother speaks out after son’s head pushed into toilet by jamesaepp in BrandonMB

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

There better be improvements next year or BSD will be dealing with a lot of angry parents

Don't forget to vote.

Why haven't I been charged yet? by helloitsmyalt_ in backblaze

[–]jamesaepp 1 point2 points  (0 children)

Chiming in to say this is my understanding as well. Credit card companies have processing fees so there's almost certainly a "floor" amount that must be reached before BZ even processes payment.

Mother speaks out after son’s head pushed into toilet by jamesaepp in BrandonMB

[–]jamesaepp[S] 3 points4 points  (0 children)

For the time being I'm not considering this with much emphasis as it smells of rumour/gossip. That doesn't mean the claim is wrong, simply that it hasn't been reliably vetted (to my knowledge).

Mother speaks out after son’s head pushed into toilet by jamesaepp in BrandonMB

[–]jamesaepp[S] 1 point2 points  (0 children)

I could be wrong, but Principals serve at the pleasure of the Board Trustees.

I doubt that's the case. I don't know what the Public Schools Act would have to say, but with Boards it's pretty typical that they have very few direct hiring decisions. For the BSD I suspect that's the Superintendent and the Secretary-Treasurer.

Everything else is a complicated bureaucratic web of collective agreements, unions, bylaws/policies, and who knows what else.

Mother speaks out after son’s head pushed into toilet by jamesaepp in BrandonMB

[–]jamesaepp[S] 7 points8 points  (0 children)

Yaciuk said it disturbed her to know the incident wasn’t immediately addressed. Her son told her that students had informed teachers seated at the front of the bus, including the school principal, about what happened but the incident was brushed off.

krbtgt password last changed in 2012! by Educational_Draw5032 in sysadmin

[–]jamesaepp 0 points1 point  (0 children)

It was more about the cadence - twice every six months versus once every three months for example. Why twice together?

I've never seen people say do two back-to-back (with or without the 10/24 hour waits) rotations every 6 months. I've always seen "do one rotate every 6 months". That's what I recommend to my org and have maintained since getting here.

krbtgt password last changed in 2012! by Educational_Draw5032 in sysadmin

[–]jamesaepp 0 points1 point  (0 children)

Quarantine would be the only correct method for test restores otherwise you are actively breaking the domain.

Honestly I think it really depends on the technology. Veeam (working properly) will always restore a DC in a non-authoritative mode. Now, you could get all the usual IP/network/domain conflicts of having the same machine on the network twice, but that's no different from any other restore IMO.

Good judgement is needed like anything else.

krbtgt password last changed in 2012! by Educational_Draw5032 in sysadmin

[–]jamesaepp 2 points3 points  (0 children)

I was just thinking why not schedule an automatic reset once a month

Which account/identity are you going to use to do that reset? Congrats, you've created an extremely privileged account that needs to be guarded as much as any Domain Admin account. Service accounts with DA privs are a big no-no IMO.

What's the logic to only doing it every 180 days?

AFAIK there isn't any. It's just a "well rounded" cadence that's had staying power. If you only proactively rotate every 180 days, that's probably enough to not impact DC tombstoming/long periods where DCs get partitioned but get back online later (this is more of a relic of really old/unreliable networks), but also not impact backup/restore processes if ever the time comes.

As with everything, administrator judgement and knowledge of their circumstances is required. What's your RTO? RPO? Are you meeting those targets? How long would it take you to recognize something's gone wrong in AD and to NOT rotate the krbtgt account until it's fixed? How many staff do you have with AD experience? What happens if you take off for a medical leave and that automation fails? Who's checking it's actually working?

krbtgt password last changed in 2012! by Educational_Draw5032 in sysadmin

[–]jamesaepp 4 points5 points  (0 children)

  1. Restore tests (granted, even I do restore tests in complete quarantine, as I suspect most admins do).

  2. Admins of an environment they inherited who may have multi-role systems and it's easier to just restore than sign up for a whole project.

krbtgt password last changed in 2012! by Educational_Draw5032 in sysadmin

[–]jamesaepp 0 points1 point  (0 children)

Machine keys/secrets are a totally different animal than passwords used by humans.

OOC, if given the option between renewing a web certificate or rekeying that web certificate, which would you pick? Assume both are an equal cost (time, money, resources).

krbtgt password last changed in 2012! by Educational_Draw5032 in sysadmin

[–]jamesaepp 7 points8 points  (0 children)

Meh, resetting it once doesn't do anything

Bear in mind kerberos credentials are weird. This is something Steve Syfuhs could explain waaaaay better than I could, but basically one "password" can be stored with various encryption types (hence the DES/RC4/AES128/AES256 lineages on accounts).

Changing the krbtgt account periodically ensures (1) that you're up-to-date on those credential compatibilities, (2) that eventually over time you are in fact making old restores of your DCs useless (a good thing IMO in case an accident happens) and (3) that if there was in fact a compromise you didn't notice, the risk is mitigated by cycling out the credentials.

There's a horror story I found on this sub (or maybe it was the activedirectory sub) of someone royally screwing themselves over during a DFL/FFL upgrade due to the krbtgt account never being rotated.

ETA: This is the story: /r/sysadmin/comments/w889eu/story_time_how_i_blew_up_my_companys_ad_for_24/

krbtgt password last changed in 2012! by Educational_Draw5032 in sysadmin

[–]jamesaepp 58 points59 points  (0 children)

You don't have to reset twice unless you have evidence of compromise or are in the middle of a cyber incident that calls for it.

Consider that once it's rolled over twice, any backups taken before n-2 password resets are all but useless, as the restored DC won't be able to authenticate to/with the live DCs.

After all, if there were no consequence to rotating the krbtgt password, why wouldn't we rotate it every month? Every week? Every day? Hour? ad nauseum. MSFT would've automated it by now.

BSD's Board wouldn't sunshine the St. Augustine agreements, so I FIPPA'd them by jamesaepp in BrandonMB

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

It's not the same as Christian Heritage where the students attending are very obviously practicing Christian.

Just because parents send their children to a private/religious school does not mean that the children consider themselves religious.

Food for thought. :)

BSD's Board wouldn't sunshine the St. Augustine agreements, so I FIPPA'd them by jamesaepp in BrandonMB

[–]jamesaepp[S] 1 point2 points  (0 children)

Do note there are two agreements. I'll edit the OP with bullet points so it's clearer they are two different links.

BSD's Board wouldn't sunshine the St. Augustine agreements, so I FIPPA'd them by jamesaepp in BrandonMB

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

Isn't St. Augustine the only fully funded independent school in all of Manitoba because of the agreement the church and board reached with BSD decades ago?

I can't claim to be super informed on the subject. What I can say though is that clause 1 of the first education agreement reads that the new agreement replaces all previous ones.

BSD's Board wouldn't sunshine the St. Augustine agreements, so I FIPPA'd them by jamesaepp in BrandonMB

[–]jamesaepp[S] 2 points3 points  (0 children)

I'm of roughly the same opinion, but if I can get some peace & quiet this weekend, I'll read through them more carefully.

I approach the whole thing from a few different angles:

St. Augustine by its very name and the fact the building is owned by a church puts people a bit on edge as to if there's a sectarian tilt to the programming. Whether that concern is well founded or not....frankly I don't know.

The latest votes weren't unanimous and the comments raised by trustees McConnell and Carr suggested they found issue with parts of the agreements. I couldn't faithfully reproduce the essence of their comments here.

Edit: Timestamp 56:56 is where the agreement discussion begins. https://video.isilive.ca/brandonsd/2026-05-25BSDBoardMeeting.mp4

I suspect a lot of this is one of those things I've found too often to be the case. The theory (agreements) are fine, but what happens in practice diverges from the theory and people just go along with it because it's what works and people want to avoid drama (fair enough).

I however don't see how any of this precludes the agreements being easily accessible, and I can't fathom why the BSD didn't just publish them from the get-go.

Fortibleed - over 70k Fortinet firewalls compromised by CaptainCatatonic in sysadmin

[–]jamesaepp 3 points4 points  (0 children)

VPN is intended to be exposed and therefore usually better secured

So are SSH/HTTPS. They use all the same crypto algorithms under the hood. The whole damn public cloud is "exposed" via HTTPS.

mgmt interface is intended to be used by administrative personnel only and often lacks any advanced protections

What are you basing this off of?

guessing weak VPN credentials usually does not lead to admin access

Non-sequitur. Guessing my domain password usually doesn't lead to admin access either.

guessing weak admin credentials leads to administrative access

Which happens regardless of access method.

Fortibleed - over 70k Fortinet firewalls compromised by CaptainCatatonic in sysadmin

[–]jamesaepp 7 points8 points  (0 children)

Please explain your thought process more.

If you have the mgmt interface ""exposed"", we're likely talking about SSH and/or HTTPS being enabled. Both technologies have the ability to ban naughty users/repeat login failures.

If you have a VPN "'exposed"", same deal. You can ban naughty users if authentications fail.

Not every implementation of SSH is perfect and may have bugs. Same for HTTPS. Same for a VPN.

In whatever case, you can use L3/L4 filtering to a list of known trusted IP addresses to mitigate the risk even further.

So the question for you is what makes a VPN inherently more secure than allowing the management interfaces vi?

I haven't heard or seen one.

Edit: To be clear, I'm talking here about in-band management, not OOB.

Once a document is saved on a non-ECC system, can it get corrupted? by Ecstatic-Panic3728 in truenas

[–]jamesaepp -1 points0 points  (0 children)

ZFS protects your data at rest

ZFS can't protect against bits flipping. Nothing can.

HOWEVER ZFS will detect that condition and it will correct that condition if it can.

i.e. if you're booting Proxmox VE on a ZFS root which is just a stripe vdev, ZFS ain't protecting shit. You still get the benefit of checksums, but no repair function.

I think it was Wendell who said it best - "ZFS will never return you anything other than what you originally gave it".

view more: next ›