Token request fails with DeviceManagementScreenlockRequired

[mrjackv]

As the title states, when GmsAuthManagerSvc tries to make a request for a new token it fails.

This is the stacktrace:

W GmsAuthManagerSvc: 
W GmsAuthManagerSvc: java.io.IOException: Error=DeviceManagementScreenlockRequired
W GmsAuthManagerSvc:     at org.microg.gms.common.HttpFormClient.request(HttpFormClient.java:90)
W GmsAuthManagerSvc:     at org.microg.gms.auth.AuthRequest.getResponse(AuthRequest.java:194)
W GmsAuthManagerSvc:     at org.microg.gms.auth.AuthManager.requestAuth(AuthManager.java:226)
W GmsAuthManagerSvc:     at org.microg.gms.auth.AuthManagerServiceImpl.getToken(AuthManagerServiceImpl.java:95)
W GmsAuthManagerSvc:     at org.microg.gms.auth.AuthManagerServiceImpl.getTokenWithAccount(AuthManagerServiceImpl.java:160)
W GmsAuthManagerSvc:     at com.google.android.auth.IAuthManagerService$Stub.onTransact(IAuthManagerService.java:134)
W GmsAuthManagerSvc:     at org.microg.gms.auth.AuthManagerServiceImpl.onTransact(AuthManagerServiceImpl.java:175)
W GmsAuthManagerSvc:     at android.os.Binder.execTransact(Binder.java:731)

My first hunch was to check that I had my screen lock PIN enabled, and it was. Other than that I tried finding other issues/information but it seems that I'm the only one with this problem.

I am currently using LineageOS 16 with microg, and have manually updated GmsCore to version 0.2.8.17785-4 (06c8b76)

[benwaffle]

I am getting this same error with GMail and FairEmail, on GmsCore 0.2.10.19420

[Coo-ops]

Bump please, its a 4 year old bug that renders custom ROMs useless for Google Workspace businesses.

[alexwh]

Bump please, its a 4 year old bug that renders custom ROMs useless for Google Workspace businesses.

See https://old.reddit.com/r/Vanced/comments/kzqyww/question_cannot_sign_in_as_of_a_few_days_ago_and/hmzqd41/?context=3

[aximut]

Does anyone know where to look into? Is this just an argument missing (somewhere we need to pass something like ScreenLock=enabled) or is there some trusted signatures required that our device needs to respond with for device management to accept?

[Coo-ops]

Bump please, its a 4 year old bug that renders custom ROMs useless for Google Workspace businesses.

See https://old.reddit.com/r/Vanced/comments/kzqyww/question_cannot_sign_in_as_of_a_few_days_ago_and/hmzqd41/?context=3

Not a useful comment, I am not my company's Google admin.

This needs to be fixed, its a dumb issue.

Disabling screen lock checks is stupid, and your admin should scold you for even suggesting it.

[aximut]

Since nobody answered my questions above, I spent some time to see what is missing. Same as for #1726.
It is EXACTLY 2 requests.

The original GMS app also gets these mentioned DeviceManagementScreenlockRequired errors on requests to https://android.googleapis.com/auth, but in contrast to the microG implementation, it then does the following two requests and then the auth requests are repeated and everything regarding auth gets no more 403 errors, but works fine:

• First request:
  A gRPC POST request to
  https://cryptauthenrollment.googleapis.com/google.cryptauth.enrollment.v1.Enrollment/SyncKeys
  (the black parts are all signatures and tokens individual to the device/registration)
  I am assuming that one of these uint32 is telling whether the lockscreen is enabled or not
  
• Second request:
  A gRPC POST request to
  https://cryptauthenrollment.googleapis.com/google.cryptauth.enrollment.v1.Enrollment/EnrollKeys
  (All these b'\... messages are very long hex byte strings)
  

These requests repeat themselves more often afterwards with different data (always first SyncKeys, then EnrollKeys), but the two requests mentioned here are sufficient for the exception of this issue to disappear and for Goolge Workspace and all related apps (Chat, Docs, ...) to be fully working.
By the sheer amount of auth tokens and signatures that need to be generated and valid for these requests to succeed, I understand why this is not implemented yet. Also, the error messages you get from these gRPC endpoints are not helpful in debugging either. The source to look into how these signatures are generated is of course the official implementation.

What is also very interesting is that once these requests have been done for one Workspace account once on the device, they DO NOT need to be repeated. The account can be removed and a totally different Workspace account can be added. The requests above are not needed anymore. They are really only required once per device to register. That also makes debugging hard because you need to totally reset the device to provoke the error again.

[fynngodau]

Thanks a lot for having a look @aximut. I'm currently having a very intense look at resolving this issue; here's some information about the SyncKeys query you shared:

• grpc: to decode the raw query data manually, you can use https://gist.github.com/fynngodau/bba7b2d11a17d01f8439979f3cfe4fb9
• Relevant protobuf: https://github.com/chromium/chromium/blob/main/chromeos/ash/services/device_sync/proto/cryptauth_enrollment.proto#L31 leads to very reasonable results
• For client_app_metadata field, the relevant protobuf should be https://github.com/chromium/chromium/blob/main/chromeos/ash/services/device_sync/proto/cryptauth_client_app_metadata.proto#L16
• specifically in that protobuf (in your screenshot: 6.15), using_secure_screenlock looks very much like the field we need according to my tests

The above proto files are a bit hard to use because field 6 of SyncKeysRequest is bytes, not ClientAppMetadata. With this combined proto file, decoding the sync request works beautifully:

$ protoc --decode=cryptauthv2.SyncKeysRequest cryptauth_combined.proto < cryptauth-synckeys-with-screenlock.dec

[aximut]

Thanks for sharing and putting everything in a useful file! That is very interesting that the protobufs are part of the chromium repo. I did not find any references when I searched it back in the day.

In terms of complexity it is as I suspected, lot's of crypto going on. Especially parts like KeyStorageLevel and KeyAttestation probably require quite some dive into the Android Keystore and TEE storage to provide proper attestation to the backend, depending on the enforcement rules on the Google servers.

[fynngodau]

@aximut It's not really as complex, many of the intimidating fields can be removed and the EnrollKeys step is optional for us. If you know the Android ID that microG uses for you (you can sometimes see it in the queries it makes and logs to logcat) and insert it into a decoded query as above in message.txt (of course, using_secure_screenlock should be set to the correct value), you can use pack.py with the following to tell the Google server that your microG device has screenlock enabled:

protoc --encode=cryptauthv2.SyncKeysRequest cryptauth_combined.proto < message.txt > message.prot
python pack.py message.prot

With that, you have a file message.prot.pac that you can send as a request body for the same request as the one you intercepted. For example, you can upload this file in mitmproxy and click Replay. Afterwards, DeviceManagementScreenlockRequired error will no longer appear.

I'll be working on a microG implementation next.

[ale5000-git]

What is also very interesting is that once these requests have been done for one Workspace account once on the device, they DO NOT need to be repeated. The account can be removed and a totally different Workspace account can be added. The requests above are not needed anymore. They are really only required once per device to register. That also makes debugging hard because you need to totally reset the device to provoke the error again

Not necessarily.
Maybe only removing the account isn't enough but using my script in this way minutil.sh --remove-all-accounts will remove all account related things (need root) and may work.

The script is here: https://github.com/micro5k/microg-unofficial-installer/blob/HEAD/zip-content/origin/bin/minutil.sh

[fynngodau]

You can simply set using_secure_screenlock in above queries to false again for the Android ID in question, and the problem will reoccur (and, seemingly, the account deauthenticated such that it needs to be readded).

On Google Play services devices, the query does happen after each account setup.

[aximut]

It's not really as complex, many of the intimidating fields can be removed and the EnrollKeys step is optional for us.

That is good news. Didn't expect Google to be that lax on the requirements.

With that, you have a file message.prot.pac that you can send as a request body for the same request as the one you intercepted.

Ok, that means next to the Android ID we only need to get the other headers (authorization, x-goog-api-key, ...) right for it to succeed.

On Google Play services devices, the query does happen after each account setup.

Yes, I saw it but it stays already authenticated even before the call hits first time. The calls are going on in quite an async manner in the official implementation.