Skip to main content

Good Day!

I am testing Platform SSO out in our environment and so far it is working great! 

We are pushing out MSCP via the Jamf Mac Apps. We’re using “Password” as our authentication type. Setup with Entra. And we do not currently have any custom config, just out of the box setup. 

Our machines are NOT Bound to AD,  and we use local standard user accounts to start off with. then register and sync passwords. 

I have 2 major issues that I would love to hear from the hivemind:

  1. We are seeing that we can put in many bad passwords at the login screen without any repurcussions. If the machine was compromised, what is stopping someone from brute forcing the correct password? Is there a way to set password attempts?

 

  1. When a user’s password changes they can obviously go re-authenticate and sync their password again, but what if a user just ignores this and never syncs their password? Meaning whatever their password WAS is what they are using to Log In and then use a different password for their AD Account info such as M365 apps. Is there anything that can “auto sync” the password? Is there anything that can “force” the user to stop what they’re doing and do the sync?

Excited to hear from yall! Thanks in advance!

 

​@JMontey1 thanks for testing this out. I’m very curious on what they reply. I would recommend also filing a report/bug with Apple to see what they suggest as well.

For number 1, could you implement a CIS Control to prevent brute attacks?

• 5.2.1 Ensure Password Account Lockout Threshold Is Configured

Here are screenshots (2) of the CIS Control from the CIS Benchmark Sequoia. The last screenshot is what we are using from the Jamf Compliance Editor.

 

 

 

 

​@mvu Thanks you for that suggestion! This works great for local accounts. However, after registering with Microsoft and syncing the password, the password policy, set by Jamf Config Profile, does NOT affect the login issue (brute forcing).

So what happened was:

  • we registered with Microsoft,
  • synced the pasword,
  • locked the machine,
  • input 4 bad passwords (Profile is set to max 3 bad attempts),
  • input my correct password 
  • was able to login 

I wonder if it’s because there are two payloads fighting with each other. If you remove the others, and let your Microsoft win out because it’s the only config, does it behave better?

​@mvu Removing the password policy will lead back to my original issue, that I can enter x amount of bad passwords until I get the right one. Unfortunately, I’m finding that all these bad attempts do not get reported in our Entra Sign In logs. 

In case I'm in your shoe ​@JMontey1 I will be trying to use custom config from Intune. Attached sample configuration screenshot..

 

Good Day!

I am testing Platform SSO out in our environment and so far it is working great! 

We are pushing out MSCP via the Jamf Mac Apps. We’re using “Password” as our authentication type. Setup with Entra. And we do not currently have any custom config, just out of the box setup. 

Our machines are NOT Bound to AD,  and we use local standard user accounts to start off with. then register and sync passwords. 

I have 2 major issues that I would love to hear from the hivemind:

  1. We are seeing that we can put in many bad passwords at the login screen without any repurcussions. If the machine was compromised, what is stopping someone from brute forcing the correct password? Is there a way to set password attempts?

 

  1. When a user’s password changes they can obviously go re-authenticate and sync their password again, but what if a user just ignores this and never syncs their password? Meaning whatever their password WAS is what they are using to Log In and then use a different password for their AD Account info such as M365 apps. Is there anything that can “auto sync” the password? Is there anything that can “force” the user to stop what they’re doing and do the sync?

Excited to hear from yall! Thanks in advance!

 

So far, auto-syncing is not possible yet using Jamf Connect. (I know this used to be due to platform SSO limitations, but I am not sure if this is still the case) This is a major blocker for us, since this reduces the value of platform SSO significantly, and leads to a lot of confusion with end-users. Hopefully this changes one-day. 

​@_Daley Thanks for that bit! We do not currently use Jamf Connect. Rather solely looking at PSSO by itself. It seems like the user experience can be wonderful but there are some security risks as well. 

Terms & ConditionsCookie settings