Chromebook prevent local password

[jmak]

Hi

 

I'm just setting up my first Chromebook and it's mostly working...

 

Current issue is:

 

When a user signs on to the (enrolled) Chromebook they get the message:

 

Please create a password to protect your local data[/Quote]

 

If it's the first time they've logged in to that machine, they enter a password twice and then continue. On subsequent logins, they're asked to set a password again; the difference is that if it doesn't match what they used last time, they have to enter the old password before continuing.

 

I presume that this is to protect data when the Chromebook sleeps as opposed to when they sign out.

 

They're logging in with a Google (suite for education) account which is authenticated successfully.

 

I've currently got it set to "User Data = Erase all local user info, settings, and state after each sign out > Enabled" but I've also tried it with that setting disabled.

 

I've also got it set up to redirect users to our SSO provider (on login authenticates with Groupcall IDaaS instead of Google) but I don't think this makes a difference.

 

Please help [emoji51]

[robjduk]

Can you double check it's enrolled? Sounds to me like someone signed into it before it was enrolled.

[jmak]

Can you double check it's enrolled? Sounds to me like someone signed into it before it was enrolled.

Definitely enrolled - I can see its status in the console. Also it is taking policy updates when I change settings in the console and on the Chromebook some settings are marked as controlled by administrator.

 

I'm now fairly convinced it's something I've done in Manage Devices > User Settings as this problem only affects student users. I've created a new test staff account and that user is not asked to set a local password.

 

Can't work out which one it is though....

[cclaus1]

We are getting this EXACT same message "Please create a password to protect your local data." Our student and staff accounts work great on chromebooks using SAML SSO via our identity provider (OmnID). However, now we are trying to use QR codes to sign into the chromebook and our student/staff portal for the youngest students (grades K-2). The QR codes appear to work correctly with the camera, but instead of bringing up our district portal it now brings up this "Please create a password to protect your local data." screen and we can't figure out how to get rid of it. The QR code should include authentication info for the student's username and password, so why does it bring up this 'create password' screen? It's ironic because we are trying to use QR codes so the little kids won't have to type in their username and password, and now we get this screen where they have to type in their password twice. Our identity provider does not get this screen in his environment (it goes directly to the portal, as it should), so it must be something in our set up that is different.

 

So far we don't see anything in > User Settings or > Device Settings regarding this issue, but we would be very interested in any ideas or resolutions regarding it.

 

We have tried testing this with settings that clear local user data as well as settings that keep local user data on the chromebook. Both settings still get the same message.

 

Thanks much for any information!!

Edited February 1, 2018 by cclaus1

[jmak]

I've raised a case with Google - I'll let you know when I get a reply.

 

I don't understand why I get different results for users in different OUs...

[jmak]

I've had a reply from Google support:

 

I understand that when a student logs in with their GSuite account they are asked to set a password to protect your local data. I saw that you recently set the SSO, if this is the case the devices are just ensuring that the same user is trying to login and they can provide the information which is stored locally. With this in mind this will be a one time thing, after the user verifies that they are indeed that user the device will not ask for the password again.[/Quote]

 

Obviously this doesn't help, but from @cclaus1 's post, this also seems to be happening with Clever Badges. Is there anyone here using Clever Badges who can confirm whether this is what they see? i.e. when a user logs in with a Clever Badge they have to set a password before the session opens. This would seem to defeat the object of using QR logins...

 

Thanks

[ADMaster]

We use clever and no one has reported issues yet.

Although they have only ever used clever badges on those devices, the settings were not changed.

 

The only time I've seen anything similar is when we reset a password.

The Chromebook will ask the user to enter the old password. I tell users to just click forgot and proceed anyway. This erases any local data and resyncs from google. (there should not be any local data to worry about)

 

What version is everyone on, I'm still holding at 62.

Clever is only used in K-2, 3-12 get the standard sign in no SSO.

[cclaus1]

I think the version of Chrome on the Chromebook is significant. We did get our QR codes to work today on a Chromebook using version 63, but it did not work with 61 or 64. We'll do further testing to confirm what works or doesn't work...

 

Thanks jmak and ADMaster for your input. I feel like we are at least making progress!

[jmak]

I've now spoken to Google support and established what needs to happen that isn't. There's an api that isn't being used: https://www.chromium.org/administrators/advanced-integration-for-saml-sso-on-chrome-devices

 

The odd thing is why it's being used for staff, but not pupils, but that's down to my SSO provider.

[jmak]

Update, but no solution yet:

 

The same APIs are being used/passed for all users. However I am applying different complexity rules. Our pupils have 4 digit PINs which doesn't meet the minimum requirements for Google. Looking at this as a reason now....

[ADMaster]

Update, but no solution yet:

 

The same APIs are being used/passed for all users. However I am applying different complexity rules. Our pupils have 4 digit PINs which doesn't meet the minimum requirements for Google. Looking at this as a reason now....

 

That will probably do it.

When I first setup GAFE I had simple passwords for the younger students, they got a captcha nearly every time.

Once they met googles minimum things went a lot smoother.

[dmenges]

This is one of the reasons we are looking into dropping SSO and moving to G. Suite Password Sync instead. Has anyone found a solution yet to disabling local pw while keeping SSO? We also want to utilize Clever Badges on Chromebooks, and can't unless we drop SSO -at least, that is our understanding.

[cclaus1]

Yes, our identity provider (OmnID) was able to work with Google last spring to resolve this issue. Our QR codes now work great on both Chromebooks and iPads! We are using SSO and we are also using QR codes generated by OmnID (we are NOT using Clever badges). We do utilize Clever to sync rosters for several systems, and we also use Clever for SSO within our OmnID portal. But we just are not using the Clever badges, as we have no need for them since we are using badges generated by our own identity provider.