#kandji

[lutumperfecta]

[theenterprisemac]

Kandji is now Iru

Iru: Identity, Endpoint & Compliance for IT & Security | Iru

Unify identity & access, device management, endpoint security, and compliance automation with Iru's AI-powered platform. Collapse the stack.

Well I guess the end is near at hand. Kandji is now becoming some sort of jumbled "AI" based all platform management tool. When companies do this sort of thing it's often a sign of desperation. They are trying to ride the wave of AI and open the platform to capture more customers being unable to draw that many away from Jamf despite what they may say.

I suspect this will go poorly. Adding LLMs to things rarely goes well for the companies that do this. The Kandji product is going to just end up doing even more things poorly. It was at least a competent Mac administration tool for the right businesses. Now it's trying to compete with Jamf, Mosyle, InTune, etc. It is also trying to compete with Okta and SentinelOne, CrowdStrike, Cylance, Microsoft Defender and many more.

I can't imagine a dumber battle to fight.

Just consider for a moment the task here:

Windows has a long time established process that it follows which isn’t that similar to the Mac.

Think about how large the vulnerability space becomes and it isn’t like they were plumbing new depths on the Mac.

Consider the types of organizations that use Windows in a big way with a few Macs. Why would that sort of org go for this?

What about a new org? Why would you pick this over InTune which competently does both?

Consider all the products that try to collapse the stack. How many of those become one stop shops and actually shave products off the stack?

These are just a few points to consider. Now ask yourself why would a company broaden out like this when they are is far from a competent solution on anything non Mac? Expanding the market segment makes sense, but it makes sense when you start. There is a reason why products like Hexnode are terrible. Hexnode is what I expect Iru to become.

Farewell Kandji. Don't expect to see you around Iru. Might make some other posts on this (especially as details emerge on the new look of their "security" and management tools), but this is dumb and that's the bottom line. Spend your time paying attention real players like InTune, Jamf, Okta, CrowdStrike, etc.

[theenterprisemac]

No more free trial of Kandji

It looks like around June of 2025 Kandji dropped their free trial. Interesting that the free trial and their pricing all have now been taken down. Makes you wonder where they are headed? To me that is a sign of trouble–getting their product out there with a free trial and open pricing was a good move. Makes me sad that they abandoned it.

[theenterprisemac]

🤣 A Little Late

Kandji Introduces Device Management for Apple Vision

Explore Kandji’s Device Management for Vision Pro—streamline deployment, enforce security, and optimize enterprise management effortlessly.

An awful lot of fanfare for bringing support to a device a full year after release. Also for a product with such an uncertain future it seems a bit late in the game. Jamf released support on day one with Vision OS 1.1.

I guess Kandji is just figuring better late than never.

[theenterprisemac]

2024 The Year of AI

The year of AI seems to have been the theme of 2024–well if you think LLMs are AI. So here is the question: how long will it be before we have a proper "AI" IT disaster? Do you think we've already had it, don't think we will, or is it still coming?

There are plenty of interesting things coming out of the 2024 LLM situation such as: OWASP taking a crack at it with a top 10 list. Even the federal government has started to look into it here. One thing is clear LLMs have thrown a spin on things, but what the result will be–is still unknown.

To take an example you have "AI" making its way into computer management. Looking at the Mac side you have LLMs creeping into Kandji, Jamf, Mosyle, InTune and there may be others.

The Great Irony

I think the great irony of AI/LLMs is that despite the highly unreliable results the enthusiasm and the expansion into new markets continues unabated. The advance of LLMs defies logic–rather than slowing down due to its unreliable results–the adoption has only sped up.

The good news is I don't suspect that we are at risk of creating a robot overlord here. LLMs are pattern engines and aren't likely to become more. Even the "best" reasoning models are still pretty poor overall and without robust symbolication it is unlikely that LLMs will ever achieve anything to spectacular.

Of course the limits of LLMs are precisely the thing that makes the impending IT catastrophe all the more likely. The more we surrender to LLMs the quicker our IT disaster approaches.

[theenterprisemac]

This video raises so many questions. I want to talk about the in theory linked segment starting at time code: 8:56 to 11:21. To put things in perspective Kandji was started in 2018.

This post is a follow on to my post previously looking at Kandji.

We will take the video point by point that I want to address:

9:17 Cloud Flare - what were they using before, or did they not have anything before? Also how many DDoS attacks did they get owned by?

9:49 Traefik - so again what were they using before this? Was this just all being manually done–or what was the reason to wait to use a competent networking solution on I guess a Kubernetes back-end.

9:54 Spreading Databases over multiple availability zones and moved to Aurora DB which begs the question of how did they survive with a product like this with no fail-over zone for 4 years?

10:21 Application Security: static code security testing, software composition analysis, and dependency vulnerability scans for the components of the application they write–this is shocking! For four years they haven't been doing any basic security measures, and I classify all of the above as basic measures, to secure their product. I wonder how many customers really listened to this?

10:41 Alerting at all levels for dozen plus AWS accounts and applied AWS CIS 140 which deals with account security–which begs the question just how gapping were things before this?

To be honest, this is not a video they should have made. Effectively this video is an admission that Kandji has been woefully lacking in their security and application development standards. If I were a customer frankly I'd be furious.

These admissions really beg the question: was the only thing keeping Kandji from just being owned on the regular the fact that its a SaaS product so its hard to see behind the curtain? As far as I know I haven't seen any CVEs for them. I think it is very possible that Kandji customers until about two years ago were protected by obscurity.

I know that a lot of startups do this sort of thing, but many don't admit to it. This is where having the option for an on-prem solution becomes so attractive–you can see all the dirty laundry the vendor might otherwise hide from you. You can perform your own evaluation–without having to hope that the vendor will come forward and admit that they have behaved in a shocking manner.

[theenterprisemac]

Different Approaches to App Installers

There is an interesting contrast in approach to third-party application installers between Kandji and Jamf NOW. Both products allow for the installation of curated third-party applications.

For the purposes of this post we will ignore everything besides the actual details of how the application is installed once it hits the endpoint.

This is based on a limited survey–so there may be exceptions to my findings.

Kandji

Kandji seems to prefer to take the route of re-packaging up anything they are installing and signing it with their own signing certificates. The installers leverage pre and post installation scripts to accomplish the job.

Essentially what you would imagine if someone took the AutoPKG with some custom builds approach to this problem. The package is named with what appears to be the hash of the package.

Jamf NOW

Jamf NOW uses a unique approach. The installer or application bundles are downloaded to /Library/Application Support/JamfAppInstallers. They then use a LaunchDaemon calling a custom script to execute the install. At the end the LaunchDaemon is removed. This allows them to avoid re-packaging any of the installers, or packaging up drag-and-drop installs.

The LaunchDaemon simply calls the script with a couple arguments for location of contents and destination of install. The scripts have varying complexities depending on the use case. It can be as simple as just run the install and exit to actually having user notification capabilities.

This approach provides Jamf with significantly more flexibility when building out install workflows. Essentially any situation can be handled because they simply include helper files and binaries as needed.

To be clear Jamf NOW still uses a package, but this is just to setup the above described situation. This is also where Jamf determines the CPU architecture etc to make sure the right version of the application is in the root folder. A good example of that is GitHub Desktop. Arm64 and X86_64 applications are included, but the installer puts the right application in the folder for the script to handle.

What about Jamf Pro?

Haven't looked at Jamf Pro application installers. I would assume they may vary significantly due to the extra capabilities provided by the Jamf binary on the local machine.

Analysis

Both approaches work, but the Jamf approach is more flexible–however it is also more likely to have issues, or potentially to be interfered with. It is very interesting to see these two companies taking two wildly different approaches to the same problem.

[theenterprisemac]

Kandji Attributes - Solve Idea

Problem

In my post discussing my thoughts on Kandji I mentioned that the lack of custom attributes (think Jamf extension attributes) is a problem. Actually it is really inexcusable given their ambitions. I wanted to outline a way around the issue that I thought of after the fact, and it helps to highlight the problem.

Possible Solve

We know that we can assign library items based on the presence or absence of a tag. We also know that tags can have up to 30 characters in the tag itself, and you can add at least 200 tags to a machine–if this truly scales I am not sure.

So here is the idea:

We can assign a tag to all machines that we want to run a for example a check against to determine if something should happen. Call this: "Possible-Assinged". We can either have a script do this or we can on mass assign to all machines.

We can then run a script from Kandji on a machine on an interval and then based on the results we can either remove the tag above only or remove and add a new tag such as: "State-Reached" via an API call in our script. The API syntax to add a tag is pretty simple: curl --location -g 'https://$your_instance.api.kandji.io/api/v1/tags' --header 'Authorization: Bearer $token' --header 'Content-Type: application/json' --data "{ \"name\": \"$tag_name\" }"

Based on how you filter things you can now have something happen based on the result of a state obtained by script.

You can even do this in a loop where you swap tags based on state using a script run on an interval. Sadly you can only do this either every 15 minutes or once per day, but this gets you close.

Ultimately the above would, not cleanly or quickly, allow you to trigger a self-service install where the applications PPPC profile comes down first, then the application. This gets icky especially depending on how Kandji deals with long running jobs.

Highlighting Problems

There may be a more elegant way to do the above, but I think this illustrates the issue. The above process is stupid for the following reasons:

It requires clients to be making API calls on a regular basis which means some sort of API Token is out in your fleet and potentially accessible. (If an attacker can access the script, then they can get the API Token. My recollection from testing is that you can get the scripts run on the machine, but I don't have good documentation for that.)

You can only run this in an automated way every 15 minutes or every 24 hours. You don't have sufficient granularity such as triggering it with an inventory cycle.

You are shuffling tags on your machines which may not prove scalable depending on how Kandji behaves when you get to hundreds or even thousands of devices with hundreds of potenital tags making API requests. (Kandji has an API rate limit of 10,000 API requests per hour per customer.) This may seem like a lot, but if you had a fleet of 3-5000 machines you could run into issues.

The workflow is not simple and is not easily tracked. Trying to chase down issues would be a nightmare given Kandji not providing full script output from stdout and stderr.