no azure tenant setup

[hdsreid]

I am in the process of migrating our Macs from InTune to Jamf, and then enrolling them in conditional access. After unenrolling from InTune, I enroll them in Jamf using a quickadd package. When using a self service InTune policy, it goes through with no errors, however nothing is registered with AAD. Further, if I run the JamfAAD gatherAADInfo command, I receive the error "no azure tenant setup". The Jamf preferences file is pointed to the correct azure tenant, and conditional access is working on other Macs.

Has anyone seen this error before? What is the easiest way to fix this? I am hoping to automate it, but I cannot find a way to point these Macs to my tenant.

[KyleEricson]

Do you have the Azure Tenant setup in Jamf Pro?

[hdsreid]

@kericson i do have the azure tenant set up. it works on most of my devices as well

[bryce]

@hdsreid you talk about the com.jamfsoftware.jamf.plist file having your tenant name in it on the client, but do you also have the key value of true for microsoftCAEnabled? /Library/Preferences/com.jamfsoftware.jamf.plist has key values set for the enablement of CA as well as the tenant info itself.

You could also check this via a defaults write command (1 = true):

sudo defaults read /Library/Preferences/com.jamfsoftware.jamf.plist microsoftCAEnabled

If it is not set to true as need not run a sudo jamf manage on the client with the issue and the value should update, and jamfAAD should use the tenant info then. If that does not work right away you may need to run a sudo killall jamf then the sudo jamf mange to get the framework to make the .plist changes ASAP.

[hdsreid]

@bryce thanks for the tip on the microsoftCAEnabled key. I have confirmed this is set to 0 on that device. I have tried the following:
sudo jamf manage - still set to 0
sudo defaults write /Library/Preferences/com.jamfsoftware.jamf.plist microsoftCAEnabled -bool TRUE - still set to 0
sudo killall jamf | sudo jamf manage still has it set to 0

not sure where to go from here, but you have me on the right track with the microsoftCAEnabled being set to false. now i just need to figure out a way to enable it

[bryce]

@hdsreid yeah if that is set to 0 and or false it is not going to use the tenant info in the .plist.

So right now your jssURL/ConditionalAccess.html read that it is enabled; correct? If you are doing a jamf manage command and that IS enabled you should be good.

As for the defaults write not working try the number value like so (should be no different with your BOOL flag, but worth a try quick):

sudo defaults write /Library/Preferences/com.jamfsoftware.jamf.plist microsoftCAEnabled 1

When you are checking this or editing it do you have local access to the client Mac or are you using ARD, SSH, or Jamf Remote to the client? I only ask because I have seen Jamf Remote cause a toggle in the .plist due to a refresh of the framework on the device at connection.

[hdsreid]

So if I navigate to jssurl/ConditionalAccess.html, it is enabled and the test is successful. I was trying to make the change using jamf remote, am I better off trying locally or via SSH then? I can give that a try and see if it makes a difference.

edit: so i did a defaults write via ssh and it updated. running gatherAADInfo now returns something other than no azure tenant setup! now to test if enrollment actually works now

[bryce]

@hdsreid Yeah I would go SSH over Jamf Remote. ARD would be fine by itself as well.

Re: Your edit:
Good deal! That said if you have a Jamf Remote log of when you were trying to make that change via remote make a support case and upload that file I want to check it out real quick. If it is what I think it is that would be your root cause and we can make sure of that. Thanks!

[hdsreid]

@bryce what exactly do you want a log of? the jamf remote session when writing the preferences or when trying to do the 'killall' command? i can recreate either scenario and submit a log for you

[bryce]

@hdsreid the Jamf Remote session please (if you sent the command or used screen sharing from it).
Thanks!

[hdsreid]

@bryce the case is JAMF-0692315. Let me know if there are any additional logs you would like to look at.

Thanks again for your help! :)

[bryce]

@hdsreid not a problem! I was just browsing Jamf Nation over the weekend and knew I probably had an answer for you!

[hdsreid]

@bryce now that I am aware of this plist key, I am noticing more of my devices have this set to 0, however I have not received any reports of conditional access not working on these devices. This could be due to lack of user awareness of course, but just curious if this is part of a known overall bug with conditional access integration. It would be nice if there was a way to mass update everyone's plist to say Enabled, but not really sure why they aren't saying it in the first place (we had conditional access configured prior to enrolling devices).

[bryce]

@hdsreid if they were registered before it flipped to 0 they may not know if you are not locking down stuff that they use via Conditional Access.

As for what is causing it. That could be the Jamf Remote issue I just e-mailed you on. Each connection toggled it in my tests and report. It sounds like you use Remote often so that could be the only cause feasibly.

[hdsreid]

@bryce hey just read the email: just to clarify, jamf remote resets that value anytime remote is ran, regardless of the reason/command being run? if so, i at least now know to alter my workflow to just use direct ssh instead of remote.

Do you think creating an ongoing policy that runs a script to enable the microsoftCAEnabled key that runs at every check in can help alleviate this situation? Or will running a policy in the that way also cause the plist to change?

Thanks again for all of your help in clarifying this issue!

[bryce]

@hdsreid Yes; that is correct. SSH direct or ARD will stop that from happening for now.

Yep; you could do that as well and have that do a defaults write to the key each day or something like that. It will not cause the reset like Jamf Remote does. It would behave just like a command run via SSH.

Not a problem! Happy to help!

[jameson]

Can just Add I just had a issue on a client I simply could not get added to azure. I tried with different accounts on same computer but it did not work.

The issue was solved by Sudo killall Jamf
Sudo jamf manage

The MicrosoftCAEnabled was set to 1 already before I did run these commands, but with the Manage commmand somehow things where fixed