Passcode session in Configuration Profile is invalid in 10.11.1

[Dalmatian]

Just upgraded to 10.11.1 from 10.11. I found something like below

1. Passcode complexity NOT working
2. Max Auto-Lock NOT working

So my configuration profile including passcode settings is gone !

I did a couple of tests, and draw a line that the profile WONT install on 10.11.1 as long as it contains passcode session. here is my test process

A. Deploy a test profile to 10.11.1 Mac with Passcode session

1. first create a test profile
2. Input passcode session, checked options like Require alphanumeric value, maximum auto-lock
3. scope to my mac el capitan 10.11.1 only
4. save and deploy

i found no new profile deployed on my mac. i did refresh all mdm profiles by running ‘jamf removemdmprofile and jamf mdm’, all the other profiles installed immediately, except the passcode test profile

then i did a 2nd test.

B. Deploy the same profile to my 10.11.1 mac with a random session excluding passcode, like Airplay

1. open the same profile, remove passcode session
2. create a airplay session
3. scope to my mac 10.11.1 only
4. save and deploy

now this test profile deployed immediately on my mac 10.11.1.

To double confirm with the passcode session, i did a 3rd test.

C. Deploy the same profile with both Airplay and Passcode sessions.

1. open the same profile, (the airplay session is there, stays the same)
2. add the passcode session like step no.2 in test A
3. scope to my mac only
4. save and deploy

i found the profile gone. i “refresh” the mdm profiles on my mac, all the profiles came back, except the test profile.
sh-3.2# jamf mdm -verbose
Getting management framework from the JSS...
Enabling MDM... verbose: Attempting to install the mdm profile at the computer level.
The computer was successfully enrolled in MDM with the JSS.

so apparently it’s the passcode session not working, as long as enable the passcode session in a profile, the profile won’t install on 10.11.1

i need the workaround of setting Max Auto-lock urgently!

[Dalmatian]

I also downloaded this profile and tried to install it manually. but it shows an error like attached

[gachowski]

@Dalmatian

I haven't tested the release version but in most of the betas the password profile was working fine... in fact Apple added a new pop up to verify and explain the password requirement when a local password is changed.

I don't use password profiles in production so I never followed up, but IBM is using password profiles so I would guess that it is working... and it might be something in your set up... just guessing : )

C

[troy]

We are having the same issue here with the same error message.

So far and profile deployed from the JSS with the Passcode payload enabled will fail on 10.11.1. Even trying to deploy the payload from a OSX server is failing for me...

Time to move to a Script based policy?

[merps]

Here's a functional pwpolicy command that can be run to set local password policies. This will apply to all accounts on your machine, so you might want to put in some logic to omit your mgmt account from getting the policies otherwise you'll be changing those passwords every 60 days.

I realize that most of the pwpolicy commands are marked DEPRECATED, but they still work. To use the new format, pwpolicy is expecting a plist that contains the policy settings. IIRC the example in "man pwpolicy" contains a reference to an invalid key.

pwpolicy -n /Local/Default -setglobalpolicy "minChars=12 requiresAlpha=1 requiresNumeric=1 requiresMixedCase=1 requiresSymbol=1 passwordCannotBeName=1 maxFailedLoginAttempts=7 notGuessablePattern=1 maxMinutesUntilChangePassword=86400"

[troy]

I finally got the Passcode policy to apply to 10.11.1 computers it turns out that if Maximum number of failed attempts or Delay after failed login attempts is left blank the profile will fail to install. Once I set those values the profile is deploying to 10.11.1 and 10.11.2 machines without issue.

[gachowski]

@troy

Thanks for following up I was going to start testing... : )

C

[jordanfleuriet]

I called my TAM about this and apparently this is a defect. The number is: D-009844

Even if you can get the Configuration Policy to load, the Delay after failed login attempts doesn't work. The account is disabled forever.

I've been trying to get around this by using account policies. Here is a resource I'm working from: http://rustyisageek.blogspot.com/2014/11/playing-with-pwpolicy.html

JF

[merps]

@jordanfleuriet We got this information from Apple Enterprise Support. I built a python LaunchDaemon that monitors the associated plists and performs logic when they're changed. If the failedLoginCount exceeds the set threshold I wait the appropriate amount of time, reset the count, and the user is able to log in.

I don't have El Cap here to verify against, but I would guess that the Yosemite commands would work.

########### Mountain Lion

dscl . readpl /Users/user PasswordPolicyOptions failedLoginCount
failedLoginCount: 4

dscl . deletepl /Users/user PasswordPolicyOptions failedLoginCount

dscl . createpl /Users/user PasswordPolicyOptions failedLoginCount 0
Changing a dictionary

dscl . readpl /Users/user PasswordPolicyOptions failedLoginCount
failedLoginCount: 0

########### Yosemite

dscl . readpl /Users/user accountPolicyData failedLoginCount

dscl . deletepl /Users/user accountPolicyData failedLoginCount

dscl . createpl /Users/user accountPolicyData failedLoginCount 0

[jordanfleuriet]

@merps that is great news! Anyway you could share the whole thing? Thanks!

[merps]

@jordanfleuriet I'll have to go through the code to make sure I can post it publicly - it's been about 7 months since I wrote it so I don't remember if there's anything that couldn't be shared.

I'll also have to come up with a good place to put it. Probably will set something up on GitHub, since I believe it's 2 or 3 python scripts and 2 plists.

If all goes well, I can get you something by this weekend.

[merps]

@jordanfleuriet I had some time to sanitize my method of unlocking accounts & put it up on GH.

I didn't have a chance to document it very well, but I did note where the files go.

Hope this helps: OSX LoginWatch

[jordanfleuriet]

@merps thanks! Haven't had a chance to test, but will do so in the coming weeks.