![]() through a service desk, through the "cloud," etc.) they must log into their Mac with their old password, then change the local password to match their IdP-stored password, or have a service like NoMAD that synchronizes the two. If a user has their password changed "off-system," (e.g. So far, in all my discussions with Apple and with Jamf, both have declared this as "not possible, no way, no how." Doesn't matter if you are using Platform SSO or Jamf Connect, it's just not possible. If so would password resets through azure work if they forgot their mac/azure password? The only other thing I could think which would suit your need to "have it feel just like windows" is to write a launchagent which does this checking and mounting at user login. We had no need to mount local network storage. I've never had it need to be run multiple times across multiple reboots, FWIW. ![]() If some users don't get the policy (which is extremely rare IME), is that not still a benefit to those users who update and their computers still pull down the policy? You're choosing not to handle a consistent pain point automatically because it might not work in some edge cases, just pointing that out. not having JC create local accounts and sync them? Isn't that the whole point? The only situation in which JC login not working should lock out a machine is if there is no usable local account. I am unfortunately not in a position to test this.Īre you. You may or may not have success with having the jamf connect app sync up with the kerberos realm and keep the login window sync'd with azure, because the desktop app is what pulls down smb share information. Remember also that the jamf connect login and the jamf connect app to synchronize accounts are separate, and read from separate configuration profiles. Your attempting to join both the kerberos realm and azure might make for some hinky weirdness. They want a Windows-like experience for network shares which I understand. Managers have shot down the idea of simply training members to manually mount drives. Dynamically mounting SMB shares is pretty important. I’m at a research institute with petabytes of data that users need from our big iron EMC and Isilon storage. JC Shares not working consistently is a deal breaker. We bought JC and got through the entire kickstart and training and then a few weeks later Jamf Connect team told me “oh yeah, forgot to mention that your login window will break all the time, check out this cool workaround- have a nice day, bye”. We have mobile users traveling all over the world and can’t risk a user in China or Spain or Canada or Europe unable to get into their laptop because the laptop didn’t get the policy or some other logistical issue. I have tested this on the major update from Big Sur to Monterey and every minor update from 12.0 to 12.1, 12.2, 12.3, and even small patches like 12.3.1, and so on. ![]() Also the documented fix via policy one-liner doesn’t work for us, it has to be ran 2 times and 2 reboots(!) to work. Too risky here until Jamf and Apple can provide a solution that doesn’t need hacks to fix it every few weeks. But there are situations in which a laptop might not get the policy and therefore be locked out. OS update break JC = I’m aware of the procedure and the one liner to remediate. Hell, I hate logging in over and over just testing it. Once we are 100% Azure we would effectively decrease auth prompts by at least 1. No way to bypass Azure and login locally with a local hidden admin account without tricking the Mac by unplugging Ethernet etc.Įxtra long prompt = I mean we have unwanted additional prompts to auth due to being hybrid and leveraging ADFS. Technicians aren’t knowledgeable, escalating cases takes a long time, even our “Success Manager” more or less blows us off when we try to get assistance and consulting on JC. Seems janky that Jamf can’t work with Apple to deal with this. Jamf has a doc on this but for some reason we have to run it two times (with a reboot) to get the login window back. ![]() Jamf Connect Shares doesn’t consistently talk to Kerberos realm and therefore the automounting of SMB Shares doesn’t work (but this same behavior is pretty solid in NoMAD which is supposed to be nearly identical in terms of the configuration etc)Įvery time Apple releases a OS update (major or minor) the authdb gets nuked and the JC login window disappears (in fact the entire macOS login window is gone), and we aren’t comfortable resetting it via policy/script) - too risky for mobile laptop users to get locked out of their computers. We are currently hybrid on-prem and AAD which adds extra long prompts (besides MFA etc) ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |