Hiya all,

Just lately I used to be troubleshooting using a customized characteristic for the shortname of a person with Jamf Attach Menu Bar app.

To be precise, this key:

<key>ShortNameAttribute</key>
<string>characteristic</string>

and Jamf Attach Menu Bar logs reporting:

"Not able to learn the customized shortname characteristic from OIDC"

This when attempting to make use of a customized characteristic synced from on-prem AD to Azure, or when you wish to have to outline the shortnameattribute in eventualities the place the Kerberos Realm does now not fit the area title of the UPN, and the sAMAccountName does now not fit the prefix of the UPN.

When all is matching defining the shortname to make use of must now not be wanted, for example:

UPN of the person in Azure: [email protected]

Shortname in AD: std_user

Kerberos Realm: TRAVELLINGTECHGUY.DEV

In such setups, utilizing Kerberos by means of Jamf Attach Menu Bar, or Kerberos typically must be good enough. When authenticating with the UPN, Kerberos must be capable to fetch the shortname with out a lot downside.

Then again, with other imaginable permutations like different REALM or sAMAccountName mismatch, issues damage and you wish to have to supply Kerberos with the actual shortname of the account.

To start with, extra possible for checking out than anything imo, it’s essential to hardcode the shortname within the JC Menu bar plist through defining it with the next key:

<key>ShortName</key>
<string>Joel</string>

Then again, that might then want a profile according to software, so principally for checking out simplest.

However, it’s essential to substitute that shortname with a JamfPro variable:

<key>ShortName</key>
<string>$USERNAME</string>

If the stock report of the software in Jamf Professional has the variable crammed in, the worth can be inserted upon set up of the profile. In order that works wonderful as smartly.

Now, for this to paintings with out an excessive amount of effort, you’d more than likely want LDAP to be built-in in Jamf Professional to fetch no matter characteristic you wish to have/want to use for the ShortName, and more than likely create an LDAP extension characteristic.

Both use the $USERNAME variable if this is mapped to the sAMAccountName:

Or if wanted create an LDAP extension characteristic:

Which will then be utilized in Jamf Attach plist by means of:

<key>ShortName</key>
<string>$EXTENSIONATTRIBUTE_X</string>

The place X is the ID of the Extension Characteristic in Jamf Professional:

The ID quantity is located within the extension characteristic URL. Within the instance URL under, “identity=2” signifies the extension characteristic ID quantity:
https://instancename.jamfcloud.com/mobileDeviceExtensionAttributes.html?identity=2&o=r

Should you do have LDAP built-in, I’d say, opt for this selection. No further configuration wanted, and it simply works.

Then again, there’s certainly an alternative choice to reach this, and that is through utilizing a customized characteristic by means of an extra declare added to the ID token in Azure.

To do that, you’ll to begin with want to upload the characteristic out of your on-prem AD as an extra declare to your ID token: https://medical doctors.microsoft.com/en-us/azure/active-directory/broaden/active-directory-claims-mapping#include-the-employeeid-and-tenantcountry-as-claims-in-tokens

NOTE: replace sixteenth FEB 2022 - relying your Azure AD Attach sync settings it's possible you'll want to reveal the samaccountname: https://medical doctors.microsoft.com/en-us/azure/active-directory/app-provisioning/user-provisioning-sync-attributes-for-mapping#create-an-extension-attribute-using-azure-ad-connect or use onpremisessamaccountname https://medical doctors.microsoft.com/en-us/solutions/questions/6472/inlcude-onpemise-samaccount-in-azure-ad-claims.html

Within the instance MS offers right here, they’re including ’employeeID’ as an extra declare, however so as to add the on-prem samaccountname characteristic to Azure for example, the powershell instructions I used have been:

Upload an extra Azure AD Coverage which provides the ‘samaccountname’ to the claims:

New-AzureADPolicy -Definition
>> @('{"ClaimsMappingPolicy":{"Model":1,"IncludeBasicClaimSet":"true", "ClaimsSchema":
>> [{"Source":"user","ID":"samaccountname","JwtClaimType":"samaccountname"}]}}') -DisplayName
>> "ExtraClaimSamaccountname" -Kind "ClaimsMappingPolicy"

Subsequent you’ll want to get the ObjectID of this new coverage by means of:

Get-AzureADPolicy

In addition to the ObjectID of the Jamf Attach App in Azure. One of the simplest ways to get that is to visit the ‘Undertaking app’ blade of Azure and in finding the Jamf Attach App you’re utilizing. The ‘Object ID’ of the undertaking app is what you wish to have:

With the Coverage and App object ID we will can then run the command under, with the ServicePrincipal being the Undertaking App Object ID and the opposite ID being the article ID of the coverage we created.

Upload-AzureADServicePrincipalPolicy -Identity <ObjectId of the ServicePrincipal> -RefObjectId <ObjectId of the Coverage>

Now, upon getting this configured, the one factor you’d want subsequent is to inform Jamf Attach to make use of the extra declare to fetch the customized characteristic for the shortname.

In my instance this is able to be:

<key>ShortNameAttribute</key>
<string>samaccountname</string>

Then again, something I’d like to focus on here’s that there’s a distinction between Jamf Attach Login, utilizing OIDC, and Jamf Attach Menu Bar, utilizing ROPG.

Therefore the keys for each are other. For Jamf Attach LOGIN, the important thing we’d like at the plist is “OIDCShortName”:

<key>OIDCShortName</key>
<string>samaccountname</string>

With out sidetracking an excessive amount of from the aim of this block, let me temporarily elaborate the adaptation of between options.

For Jamf Attach Login, the OIDCShortname secret is to outline the accountname of the native account which JC will create at the Mac.

When Jamf Attach Login creates a neighborhood account, it makes use of the pre-fix of the UPN to take action. For example, if my accountname is [email protected], then JCL will create a neighborhood account with ‘std_user’ as accountname.

Then again, if we upload the OIDCShortname key, we will inform JCL to make use of every other characteristic for the accountname, whilst nonetheless including the pre-fix of the UPN as an alias. In my instance under my shortname (fetched by means of the customized characteristic OIDCShortname is ‘standarduser’, whilst the prefix of the UPN is ‘std_user’:

This may also be to hand in scenario the place you wish to have to have the accountname set to another price than the pre-fix of the UPN for any authentication wishes.

Including the extra declare to Azure and utilizing the OIDCShortName keys completely works wonderful, like we will additionally verify within the Jamf Attach Configuration instrument. As you’ll be able to see, doing an OIDC take a look at returns the extra characteristic (in my case the samaccountname) within the token:

Then again, if we do take a look at ROPG, it sort of feels that issues have modified Azure-side. Previously, the extra claims have been additionally added to ROPG flows, however it sort of feels that this isn’t the case anymore. A minimum of now not by means of the V1 endpoints, whilst it does paintings by means of Azure V2 endpoints. No longer certain when this modified to be fair, however extra in regards to the V2 endpoint under.

To check this, we will’t use the config instrument to seize the token over ROPG (because it simplest returns tokens within the app for OIDC), however we will use ProxyMan to take action.

For this you wish to have to put in ProxyMan (or every other proxy instrument in a position to decrypting SSL/TLS) and run it whilst authenticating with Jamf Attach Menu Bar:

I’ll now not talk about utilizing ProxyMan an excessive amount of right here, however when you allow the JSON view (after enabling SSL/TLS decryption previous to connecting to Jamf Attach), it is possible for you to to seize the id_token and decode it for example by means of https://jwt.io/

That is the place you’ll see a distinction between the id_token you get by means of OIDC within the Jamf Attach Configuration instrument, and the only you intercept with ROPG by means of ProxyMan.

The adaptation appears to be associated with the adaptation in authentication drift utilized by OIDC and ROPG, and Azure V1 endpoints don’t appear to incorporate the customized claims in ROPG flows.

However what about that V1 and V2 endpoints? Neatly, Jamf Attach Menu Bar app (as according to design, together with model 2.5) through default makes use of the V1 endpoint whilst you configure it with Supplier set to “Azure”:

<key>Supplier</key>
<string>Azure</key>

So, it does now not paintings? No panic, there’s a workaround. Jamf Attach may also be configured to make use of various customized, much less primary flow, iDPs. For that we set the supplier key to Customized and we outline further keys just like the DiscoveryURL.

The trick to make Jamf Attach Menu Bar use the Azure V2 endpoint, and therefore to get an id_token which has the extra claims, is to configure it in a extra customized manner as a substitute of the default ‘Azure’ configuration.

Hereby an instance of a configuration plist to reach this:

<?xml model="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist model="1.0">
<dict>
	<key>IdPSettings</key>
	<dict>
		<key>Supplier</key>
		<string>Customized</string>
		<key>ROPGID</key>
		<string>1d884884-1111-2222-3333-71548a60aa76</string>
                <key>DiscoveryURL</key>
                <string>https://login.microsoftonline.com/af72a024-AAAA-BBBB-CCCC-fd66bf369fcc/v2.0/.well known/openid-configuration</string>
	</dict>
	<key>Kerberos</key>
	<dict>
		<key>AutoRenewTickets</key>
		<true/>
		<key>Realm</key>
		<string>DIDYOUTESTIT.COM</string>
                <key>ShortNameAttribute</key>
                <string>samaccountname</string>
	</dict>
	<key>SignIn</key>
	<dict>
		<key>AutoAuthenticate</key>
		<true/>
		<key>RequireSignIn</key>
		<true/>
	</dict>
</dict>
</plist>

The two vital keys listed here are:

<key>Supplier</key>
<string>Customized</string>

and

<key>DiscoveryURL</key>
<string>https://login.microsoftonline.com/af72a024-AAAA-BBBB-CCCC-fd66bf369fcc/v2.0/.well known/openid-configuration</string>

This with af72a024-AAAA-BBBB-CCCC-fd66bf369fcc’ set to the tenantID of your Azure tenant. Additionally be aware the v2.0 within the URL.

Moreover I added the Kerberos config within the plist, which permits me to get Kerberos tickets, mount stocks (by means of further configuration profile), and so forth… all according to the proper shortname I want for Kerberos to paintings. As mentioned above.

With this tradition setup, forcing Jamf Attach Menu Bar to make use of the V2 endpoints, you do get the customized characteristic within the ID Token by means of ROPG, identical to with OIDC:

{
  "..."
  "unique_name": "[email protected]",
  "upn": "[email protected]",
  "..."
  "samaccountname": "standarduser"
}

After effectively connecting to Jamf Attach Menu Bar with a V2 config like above, you’ll additionally see that the com.jamf.join.state.plist within the personal tastes of the macOS Consumer Library does include the customized characteristic:

<key>CustomShortName</key>
<string>standarduser</string>

And Kerberos price ticket are retrieved appropriately, according to the proper shortname.

Azure Glad, Jamf Attach Glad, Kerberos Glad, … all works!

That’s it! As at all times, when you preferred the submit, hit the like button, inform your pals about it and go away a remark down under!

Brgds,
TTG

https://macbookblackfriday.com/