u/Reo_Strong

We are not using Entra ID as we're not blanket licensing everyone, just those for whom there is a benefit (about 20% of the staff), so manual onboarding is fine at the moment.

We stood it up on Bookworm because that was stable when we did it. If we did it today, it would be Trixie or Ubuntu 26. Since it's just a docker container, the details of the host don't really matter.

We run Bitwarden enterprise on prem, hosted on a Debian server.
As it's part of how we do MFA for some legacy systems, it was on the table for discussion.

The discussion was exactly like you expected: SPA <> CUI, so no FIPS encryption necessary. No further questions.

As far as implementation, their scrips for setup and update are dead simple, applying licensing is similarly straight forward.

--Edit: I for got about backups --
We backup the whole VM via Veeam. Quarterly, we manually export the database and store in a USB drive that sits unplugged in a safe deposit box until needed.

We don't.

PDQ knows about them based on LDAP domain scans, but the DCs (1) don't get anything pushed to them and (2) don't change enough to requires being scanned by Inventory.

Generally ERP -should- be the hub at the center of the business. This makes all of those spokes into integrations.

As others have said, the tracking and documentation is far more important than a raw number.

The only limitation there is if/when the ERP gets updated. The more integrations, the longer the lead time for testing.

1. Keep work and personal separate. Remove -every- reason a user has to touch their personal phone. We switched to a company password manager to support MFA tokens and secure account sharing.

2. Make sign-in/auth as secure, simple, and consistent as possible. We had Smart Cards, then moved to FIDO tokens with passthrough auth wherever it works. This increased security while removing authentication prompts in the middle of most workflows.

3. Train your staff. We use KnowBe4. The content leaves some things to be desired, but gets the job done. We also use it to test at least monthly, and for some, weekly. Having them consistently tested, on the high end of the complexity scale, makes them build a habit of thinking about security.

4. Always have at least two layers of security in place. Security works best when there are multiple layers, so use multiple systems and solutions, trend towards more vendors with overlap instead of a single vendor that does everything.

We ended up moving to the recommended config which is the PDQ repository.

This helps remediate the need of the LAPS accounts getting access to the UNC paths and it also forces us to keep the installers all in one location (instead of spread out all over the network). As a side-effect, this forces us to unify 99% of software installs to using PDQ (instead of a bunch of one-off install instructions).

1. Check out r/cableporn for inspiration.
   
2. Slow down.
   
3. Make a plan for what you want it to look like.
   
4. Make sure you have the appropriate resources to do what you want.
   
5. Get better, one project at a time.

When I started at my current role, the network frames were a rats nest.
For the next two years, they got worse because I was -always- in a hurry, and never had time to actually clean any of it up.
Once I made it a priority, I was able to take the necessary time, get the appropriate supplies (Velcro, wall hangers, and appropriate lengths of cable go a long way), things get better.

I still wouldn't deign to walk with the experts, but it's much, much better.

1. Aerospace mfg is split into two sides (Commercial and DoD), some companies specialize in one or the other, but most do some of both. Know your current split and what you expect to see over the next 10 years.

2. RE M365: Commercial -cannot- hold ITAR or CUI. If you are using it to store or transfer CUI or ITAR via Sharepoint, Teams, OneDrive, or Exchange, you need to be GCC (for CUI only) or GCC High (for CUI +ITAR) to have a chance at all at meeting your DFARS compliance requirements. (This has been a thing since 2017.)

3. ERPs, when well implemented, touch every aspect of the business and affect every employee.

4. ERP selection should not be something you shop out to a generic IT support company (MSP). ERP is a software solution to enforce business process. IT is not the driver, IT is a consultant on how to get it functional. The business should be setting requirements and acceptance criteria.

5. Choosing an ERP takes 6 months at a minimum as you -should- be vetting multiple possible solutions from multiple companies. A year is very common.

6. The staff picking the ERP should be the most experienced and most knowledgeable about HOW the company gets data, including how costs flow throughout.

7. Preparation for go-live will take at least 1 year and at least one high-level person will threaten or follow through with quitting.

8. Implementation should be considered -complete- after going 2 quarters with no fundamental changes to the ERP (e.g. no business process changes, no major workflow changes, no work instruction rewrites).

9. Something like 80% of large software implementations fail. It is very common to have multiple go-lives and false-starts (due mostly to complexity)

I've been through this a couple of times now, so if you want more detail regarding ideas, options, etc., send me a DM.

Start your prompt with "Treat me like a combative asshole"

We have used our asset management tool for this.

Each location gets an entry as a location.

Each location is issued an asset that is of type "Internet Connection"

These have the necessary details to identify and contact for support when necessary.
The location information also includes other stuff that someone would need when dealing with that entity (e.g. manager's name and cell phone, physical location details or quirks, etc...)

We've been using Securence for ever, but they are closing up shop in November.

Looking at SpamHero now. Seems like it should be similar, but with a few QoL upgrades over Securence.

We only allow a certain subset of our staff to receive email from outside of the company and we are looking forward to is using an AD account to sync users into SpamHero for this. I bet you could do the same with just faculty.

This.

Too many folks think this works as a "what did <employee> do today?"

We've found it to be FAR more effective at identifying capacity utilization.

If you bounce it against things like break/fix vs project work across total hours available, you can get a good idea of if you need more or less ticket workers and whether project X, Y, and Z have any hope of actually completing on schedule.

Just went through an assessment and this was all they cared about.

1. Do you know what is approved for use in your environment? (i.e. do you have an inventory of removable media?)

2. Does each have an assigned person who owns it?

We have it locked down so non-admin users can't access removable media at all, across the environment, but 1 and 2 is all they cared about.

We print ours with software called Bartender (by Seagull Scientific) and Powershell.
We pull all data from AD, populate a template, and then dump it into Bartender via a watched directory.

From a hardware perspective, we've been happy with the HID Fargo series.
We've had a couple of different models over about 12 years, each printing dang reliably before needing replaced/updated.

write when do

do thing? write.

do thing not write? bad

do thing before, time now? write now

I've learned a lot of this from a leadership position in a high-quality manufacturing company.

They tend to lean toward a no-fault but the company standpoint. If a mistake was made examine the process, tools, instruction, direction, or situation before blaming the person. We are geographically remote and, in order to gain access to the necessary skills, we've had to grow most of our staff in their expertise. From a PM perspective, we see blame nearly always come down to the setting and communication of expectations.

I'm in the IT side, and if there is a major outage, breach, or failed implementation that has real costs, we have to do a AAR. These are structured to be "Blameless" in that the focus is not on the failure of action, but the failures of communication, tools, expectations, direction, documentation, preparation, etc..

While YOU can adopt this ideology, the roughest/toughest part will be managing up and getting the leadership to accept (and eventually adopt) this mindset.

Do they need photos of the holder, or is it as simple as a green badge for employees and a red badge for visitors?

If so, you could likely get bulk PVC badges in different colors from Amazon for pennies each, then a punch for a loop-through hole and you're good.

If you wanted branding, I would check someone like 4imprint.

If photos of the holder are expected, I still think I'd print in house for ease of one-off, replacement, and new hire situations.

If your reception area is considered to be controlled space, then yes, they will need to be logged.
If not, then not.

You need to establish expectations from the system and THEN start shopping around.

Door Access can be simple or very, very complex depending on what your facility needs.

We've used Entrapass (from ADT), Isonas, and Infinias. Our needs are very, very simple and Entrapass was very much overkill, Isonas barely functional, and Infinias has it's warts, but is working.

The key is to understand the warts of any system you look at and figure out which ones you can live with.
For us, we required on-premises hosting and AD integration. These are all in line for Infinias. We accept some controller wonky-ness, support PITA, and limited documentation for self-implementation.

The key is to figure out what you need, then what you want, then find actual users to discover the warts. Assess from there for fit.
---
Also, printing 200 badges is nothing. We do all of ours onsite and kick them off with a powershell script. One ribbon for the badge printer does 250 (IIRC) and it takes about 30 seconds per badge.

This depends on IT's role in the company.

I've been in the MFG field for 10+ years and IT acts as a support and lubricant for the company at large. Our 3-year plans are built using this line of questioning:

1. What does the company need in the next 6 months?

2. What does the company need in the next 18 months?

3. What does the company need in the next 36 months?

4. What time is left over and potentially available for technical debt?

Based on the answers to the above, we build a timeline showing expected start and end dates (gross estimations) for any projects necessary for the company. This includes IT specific things like a network hardware refresh or a SAAS migration, as well as other department initiatives like Sales reporting solutions, HRIS reconfiguration, and new machine integration for production.

Part of the interrogation of any proposed plan includes a risk, capacity, and budget assessment so that any blockers or cash drains are identified and planned for.

You are an adult. If you writing is garbage, get better. It's a skill like every other.

I've been there.

When I started my current job, the previous person started the setup for WSUS and then never finished. Some of those machines hadn't seen an update for 2 years.

The key process is thus:
1. Do we need to patch? Patching for the sake of patching is often better than nothing, but also not that great. If the software doesn't have any outstanding issues and it will cause a production outage, why would you?

1. If the patch goes sideways, will I know about it ? If it's hard to detect failure, you need to figure out how to detect it before moving forward.

2. If the patch goes sideways, how do I recover? Can I take snapshot of the VM? is the backup of the machine tested? Can you test it before trying to patch? Is there support you can call beforehand or if it fails?

3. Can I do the patch without anyone knowing (no down time for production)? If not, can you get really, really close? (e.g. apply the patch, but reboot over lunch or at 0300)

4. Work within your change management and tracking systems. The only thing worse than handing someone a broken system with no clear history of change is being handing a broken system with no clear history of change.

Long term: Build systems that can be patched without downtime, using known, supported systems. DCs are a great example. Like Sith, there is never one, always two, so you can patch without downtime.

DFS file hosts, KeepAliveD, docker swarms, and VM clustering are all good tools to reduce the headache of patching and software updates.

1. does it work?

2. Is it documented?

3. Is it verified to match documentation?

4. What is the required infrastructure?

5. Is there an update/upgrade process verified?

6. Was is developed to match our required security standards?

Thanks random Redditor! Didn't know we could use that, but sure enough we can.

Maybe this means I can put off re-learning PKI for like the 3rd time.

This is what we do.

We do a very short term cert on a smart card for one-time authentication, then walk them through connecting a FIDO token.

Our users don't know their password. It's even randomly assigned when we create the account (and hidden from the technician creating it).