Unable to connect to local file shares with Jamf Connect

[myu]

We were told that Jamf Connect is basically NoMAD rebranded (sales agent's words not mine) so I assumed it'll work exactly like NoMAD.

We used NoMAD in the past to authenticate to local AD and access to file shares was not a problem. With it now becoming unsupported, we decided to look at Jamf Connect.

Now, we're trialling Jamf Connect and for the life of me, I can't get it to authenticate to file shares. I suspect that it is passing incorrect credentials (i.e. just the ShortName value) because when I connect using Finder to an SMB share, if I use the default entry, it fails but when I add the AD domain part (@domain.local), it goes through.

So now I have 2 problems:

1. Some of our users will have a ShortName value of firstname.lastname (they auth to Entra ID using firstname.lastname@external.domain.com). How can I change this so that it uses the sAMAccountname? I've read that you can pass additional attributes but have not seen an example of how to properly do this.

2. Some of our users already authenticate to Entra ID using the sAMAccountname@external.domain.com login but even then, we will end up with the problem of Finder requiring us to log in with sAMAccountname@domain.local. We've never had to add the AD domain part in NoMAD before (it just automatically connected).

Is it possible we're looking at the problem incorrectly and shouldn't be using Jamf Connect to try and connect to local file shares? Should we be going with Kerberos SSO Extension instead? I tried to make it work last night but no luck but that's probably because I have not configured it properly in the short time I've tinkered with it (continuing to look at it today).

Any suggestions / recommendations?

[AJPinto]

I would wager you have some configurations not correct, which is very possible as a well working Jamf Connect can be a beast. Honestly, you are in a very unique position currently. Jamf has blood in the water (you are evaluating their product, and they want money), reach out to your sales team and ask for help. 

[myu]

I have reached out to them but no luck so far.

[myu]

So, anyway, while waiting to hear back from Jamf, I am pursuing things on my own. I found that:

1. If I go to Entra ID > App Registrations > Jamf Connect > Token Configuration > Add Optional Claim and select one of the pre-existing claims like Given_Name, that value is actually being passed to Jamf Connect (I can see it when testing with Jamf Connect Configuration). And if I configure Jamf Connect's config profile to use Given_Name as OIDCShortName, it creates the local user as john instead of the usual john.doe. So I know this path works.

2. However, the claim that I want (onpremisessamaccountname) does not appear under Token Configuration as a choice. So I poke further around after reading some MS articles on claims and if you go to Entra ID > Enterprise Applications > Jamf Connect > Single Sign On > Attributes & Claims, I can add that in. But contrary to the docs and what is expected, when I add that claim, Jamf Connect Configuration barfs out and says "Unable to load your Identity Provider". As soon as I remove that additional claim, it works again.

Anyone else went through this process and got it working?

[omgfast]

This is a very late answer, mainly posting it for the next person who runs into the "Unable to load your Identity Provider" error.

Within Entra, in the Manifest of the Jamf Connect App Registration, ensure that api.acceptMappedClaims is set to true. It's set to null by default, which causes the issue with the additional claim.