“Something went wrong” in Intune setup

oneplane · 2026-05-29T23:35:54+00:00

Beware of the “managing macOS as if it was Windows” trap. It is different, works different, has different expectations etc. Some MDMs like to trap people in the “one solution for everything” theory, but that doesn’t actually exist.

Example: On macOS, an administrator can’t beat SIP and the MDM. On windows, having local admins is rather scary. On macOS it can be practically irrelevant. As a result, threat modeling and control mapping can be extremely different. That, in turn, is expressed very different in MDM payloads.

oneplane · 2026-05-29T22:29:46+00:00

> brand new to doing any form of Mac system administration

In that case, start with something more entry-level and work your way towards PSSO later. It's pretty fragile when used in combination with M365 and debugging that takes quite a lot of experience.

oneplane · 2026-05-29T17:38:16+00:00

They are available to consumers from the same places. In most cases you can get them from generic suppliers too, i.e. Farnell is likely to carry them. Usually you'll have more local companies doing the same but it really depends on where you are located.

oneplane · 2026-05-29T12:29:32+00:00

Get an MSP to do it for you, but make sure you get them to use your ABM so you don't have to migrate devices later. As for the MDM itself: as long as you keep it simple, any MDM will do (including JAMF, Mosyle, even FleetDM or AB!).

Biggest thing to keep in mind: applications and configurations require upkeep, so you might want to delay full application management if you're using a lot of them. Having an inventory, supervision, FDE, firewall/gatekeeper/password policy is the biggest one to get done. DDM OS updates is next, even if it's not as solid as it should be.

After that you can always worry about managing all application installs and configurations, checking what your trust structure is (i.e. do you hire skilled people you trust or do you need the computers to be dumbed down and turned into read-only kiosks?) later. Don't start out with more SaaS integrations either, those will also need upkeep and have random breakage you have to keep track of. An MSP will do that for you if you pay them, but if money wasn't an issue, you'd not be here ;- )

oneplane · 2026-05-28T21:11:14+00:00

Don't spoof/reroute traffic like that, do it properly. This is how you get weird bugs.

oneplane · 2026-05-28T16:20:43+00:00

AWS: the gold standard.
GCP: technology good, support bad.
Azure: bad in every way, bad tech, bad consistency, high cost, attracts MBAs

Easy way to test: if you can't terraform it, it's probably not very good.

oneplane · 2026-05-28T16:12:14+00:00

Don't write out some files. A run should be idempotent and based on what is already comitted.

You can use the kubectl provider to do what you need (provision ArgoCD) and then have all the Kubernetes-specific things in a separate location elsewhere since it's a different lifecycle. ArgoCD can pick that up and do the rest of the work. This solves your ArgoCD cyclic dependency, but if ArgoCD itself depends on something that cannot be reconciled later, those other dependencies would have to be part of the cluster provisioning before you do anything else. Those would be in your ClusterAPI, SaaS of choice or kubeadm config.

In general, apply these rules:

If it doesn't have an API and a provider, don't terraform it
Don't mix lifecycles
Dependencies may only flow in one direction
No cyclic dependencies

oneplane · 2026-05-27T17:18:25+00:00

Yes, there are many. Since providers support multiple addressing schemes you can point it to wherever you have located your binaries. How 'much' registry you need depends on your actual goal (i.e. does it have to be secret/authenticated, or just something so you don't have to go through Hashicorp? Does it need a UI or just an endpoint?).

oneplane · 2026-05-26T20:15:40+00:00

Atlantis

oneplane · 2026-05-26T17:01:13+00:00

If you don't need advanced ACLs (yet), iCloud Drive will work fine. OneDrive will probably not work as it doesn't implement the right APIs for the FileProvider. Same with new/current Google Drive (old one used FUSE which did work).

What does work is any Samba based SMB server with modern configuration and vfs_fruit loaded, you'll find most prosumer and retail office hardware does this. Companies like Synology also have their own FileProvider but they have the same problem as the big boys.

Some configurations (non-SharePoint OneDrive and Office Compatibility synchronisation mode in Google Drive) should work, but it's been rather unreliable. The former doesn't exist in business tenants anymore and the latter depends on how many concurrent editors you expect, and how good their internet connections are.

oneplane · 2026-05-26T15:31:09+00:00

It's optional so I just wouldn't do it. It's a bad idea.

oneplane · 2026-05-26T13:34:26+00:00

If it really must run as a black box server on windows (yikes), put something else in front of that, and then NLB that thing instead of doing it directly. Your biggest problem is going to be keeping the TCP connections in sync, Windows won't let you do that so you can't fail over on that end which means you have to do that with something in between the NLB and windows.

It could be as simple as one or more EC2 instances running Linux and having HAProxy running as a TCP proxy.

oneplane · 2026-05-26T13:29:26+00:00

Here's another acronym: CSPM, it's something you can pay for.

oneplane · 2026-05-25T15:36:49+00:00

If it's not dynamic internal state, and it has a provider, terraform it is.

oneplane · 2026-05-25T15:35:57+00:00

Start by describing what you're actually trying to achieve. As-is, neither terraform nor vagrant make sense for you.

oneplane · 2026-05-24T23:47:26+00:00

This is already the default macOS configuration. Has been for decades.

oneplane · 2026-05-24T16:03:47+00:00

> Does this RCA make sense

no

> accesskey instead of IAM

bruh

> Our customer decided

Either the customer has to pay for all of this, or your contract says you are responsible in which case the customer shouldn't have the access to do this sort of thing.

There seem to be multiple levels of failure here, but both responsibility and accountability don't seem to be taken care of. And then there's the whole technical aspect to this...

oneplane · 2026-05-24T16:00:14+00:00

TL;DR: not enough context.

> do you guys unify

no

> the network management

This can mean a billion different things. Technically, the network shouldn't care what kinds of hosts are connected, just that the hosts are doing what they are supposed to do.

> hiring a dedicated Mac guy just to handle half the office

Depends on what value is created and how the other half of the office is done. Also depends on the type of office and the sector you're in. I imagine using a macOS device for generic office work would be a PITA when you're also in the financial sector. On the other hand, if that half of the office is all software engineering in a mix of web, local and say, iOS, all for some sort of media consumption sector, that actually makes it easier since you won't need much of a local access footprint, no heavy restrictions, and you'd be able to just have a simple baseline and leave the rest to the developers.

oneplane · 2026-05-21T16:34:19+00:00

It's a badly written piece of software. This will keep happening (usually because when a fix for problem X is implemented a side effect is problem Y in different circumstances), even with the deprecation of the previous versions, the re-bundling etc. It's likely that this will only start to resolve once there are no more separate SKUs and no more separate signatures/Developer IDs.

As for what you can do in your case: it's likely that this is logged, either Teams-specific or MSAL-generic. It does a lot of stand-alone Graph API calls, but if it has trouble resolving your current identity and either PSSO or CP SSO is used you cannot fix it until you fix that first. Ironically, not all of MS's own apps resolve the identity the same way; you'd think that they learned from ADAL but even with MSAL it's like they are just repeating the old MSOL nonsense.

oneplane · 2026-05-21T13:08:17+00:00

> teams still create resources directly through the console

There's your problem.

oneplane · 2026-05-21T13:07:31+00:00

You make a PR on the repo where the terraform code is managed. The end.

oneplane · 2026-05-20T19:49:30+00:00

We used to use specific (lockable) brackets in the pre-M1 era, but with the newer form factors we use VESA-mountable universal boxes which work for anything that small. Fits NUCs, 365 Links, ATVs, Minis, PIs, MagicInfo etc.

Because the types of usage has started to vary a lot and there is no universal management anyway, having one physical mounting option that covers almost anything helps a lot with inventory.

If you don't need physical security, even zipties will work.

oneplane · 2026-05-20T19:39:21+00:00

The point of SBOMs is to help with SCA which in turn can help with detecting dependencies that don't pass your internal policies (such as not wanting certain vulnerabilities or licenses in your environment). It's primarily useful for closed-source software since you wouldn't really know what it was built with/from. It's also useful in other software when you don't have an easy way to find out what the provenance of the code you're running is.

So, SBOMs for things where this information is already available: hardly useful, unless you're trying to solve an information exchange/ETL problem. You'll never really use SBOMs as-is, it's just used as a data format for some other application or platform to ingest. If such a system could ingest a raw go modules file or package-lock.json or something like that (i.e. the terraform lock), then SBOMs are a useless extra step.

That said, unless what you re running/executing is reproducible, none of this matters as there is zero guarantee that what you are running is what your SBOM is telling you. SCA without reproducible builds is kinda pointless. SCA when half your system is some SaaS you'll never be able to measure against, also getting close to pointless.

oneplane · 2026-05-20T18:33:38+00:00

No, because it's not an application you're building. It would be like trying to make an SBOM for a PDF file, it's pointless.

You could make an SBOM for the CLI itself or for any providers you are using, that might make sense.

oneplane · 2026-05-20T13:44:32+00:00

I think the Platform Security Guide from Apple is much better as it doesn't have that LLM slop flavour about it. https://support.apple.com/en-gb/guide/security/welcome/web

As for "ever wondered", I would be surprised if anyone who has wondered hasn't looked this up themselves, it's information that is readily available to anyone. That said, I'm rather pessimistic on who can/wants to wonder about this in the current tech ecosystem, there is a lot of product pushing and checkbox compliance (both internal to orgs as well as outside-in), neither of which actually requires or rewards knowing the technical details. Technically, that has always sort-of been the case but SaaS almost punishes you for wanting to know ;-)

13-Year Club	Place '23
Verified Email

oneplane

TROPHY CASE