Amit/Kiran, can you give a try in the GPO environment?

Tried with below steps -

1. Enabled the policy and provided 'ettestchrome@gmail.com' (any test account) in Citrix server
2. In Client machine, try to login with other gmail ids (eg: testlaab@gmail.com or any other gmail id.)

Expected : It should accept and show the gmail inbox for testlaab@gmail.com

Actual : It is showing error message 'can't log in error and that it only accepts @gmail.com'

Note: Tried with gmail.com, xxxx@gmail.com and *@gmail.com - for all these options it is blocking all the gmail accounts.
Env: Chrome Stable # 57.0.2987.133, Win 7 (Client), Citrix server (Server machine)

pastarmovj@, could you please check this issue..

Blumberg for triage.

I was just wondering if there is any update for this just yet. I wanted to add that it still happens with the latest version

Chrome version: 61.0.3163.100  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 27.0.0.130

+Owen who is working on this and may be able to offer guidance

I just tried "*@gmail.com" and "*@chromium.org" and both worked as intended. Make sure to add the * (star) before the @.

I'm closing this, please reopen if it's still not working.

still doesn't work, here is the message I get. Screenshot attached.

Deleted: not-working.PNG 193 KB

	not-working.PNG 193 KB View Download

If this can be reopened, that would be appreciated.

From your screenshot, this is not about signing into Chrome, but into Docs/Drive.

What policy are you setting exactly? I'm not aware of how that works, I was testing with RestrictSigninToPattern, which affects Chrome sign in only.

That was never the issue. The issue that I reported was for signing into Google Apps not Google Chrome. This is the policy in question since I reported the issue: AllowedDomainsForApps

Understood, thanks for the clarification. I was not aware of that policy.

Reopening this bug and assigning it to igorcov@, who added this policy.

weaver.jarod0312, could you please specify what is showing when you access chrome://policy for the policy name: AllowedDomainsForApps?

I just checked with value = managedchrome.com accessing Google docs and had access as expected.

Details on how it is expected to work:
https://support.google.com/a/answer/1668854?hl=en

I also checked the option @managedchrome.com and *@managedchrome.com both being denied. Seems like it needs to be only the domain name without any prefix.

georgesak@ Do you know who implemented this on server side? Would like to check if this is working as expected.

Not sure, no.

Adding rogerta@, as he might know.

Agree with comment #14. According to the docs for this policy:

http://www.chromium.org/administrators/policy-list-3#AllowedDomainsForApps

The value should be a domain name.  So you don't need the * or the @ prefix.

Looking at the server side code, gmail.com should work.  Can you provide a network trace captured from chrome://net-internals ?

The domain I have set is gmail.com and I still get the error.

Also added from my chrome://net-internals in a txt file

Deleted: error.PNG 80.8 KB

	error.PNG 80.8 KB View Download

Deleted: net-internals.txt 153 KB

net-internals.txt 153 KB View Download

It seems that only gmail.com doesn't work on this policy for some reason. It looks any other domain works with this policy.

Thanks for the trace. This definitely looks like a bug on the server end.

I've forwarded this to the right team internally.

Will follow up here when I have more news.

Thanks.

I have confirmation that this is working as intended. That policy is only valid for G-Suite domains, and will not work for gmail.com.

I will update the documentation to reflect that.

Ok. If one were to request that get changed as a feature request, where would I go to request that feature change to allow it to work for gmail.com?

If you don't mind me asking, what's the use case for allowing only gmail accounts to login?

I'm trying to understand why this is useful/desirable and then I can relay that feature request to the right team.

Thanks.

Though I agree with georgesak, I would point out that the example on https://www.chromium.org/administrators/policy-list-3#AllowedDomainsForApps lists gmail.com as an example.

Deleted: Screenshot 2017-10-13 at 12.05.24.png 63.4 KB

	Screenshot 2017-10-13 at 12.05.24.png 63.4 KB View Download

Yes, and I'm planning on fixing this documentation error.

Personally, I have people complain to me that their google account domain blocks certain google apps and allow certain ones and I tell those people to either request for the app to be unblocked or to just use gmail account. People don't listen and they keep complaining about it which is why I want to turn around and only allow Gmail accounts so that people stop complaining to me about their domains when I tell them to just use Gmail account to not have basic app restrictions.

@25

Understood. However, I just validated with the backend folks and this is really working as intended and there are no plans to change the behavior, unfortunately.

I'm not closing this yet, as I still need to  change the documentation to remove the gmail.com reference.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4f650e95b5e0526f0aa39800b1fa729af15b002e

commit 4f650e95b5e0526f0aa39800b1fa729af15b002e
Author: Georges Khalil <georgesak@chromium.org>
Date: Wed Oct 18 14:34:27 2017

Fix AllowedDomainsForApps documentation.

AllowedDomainsForApps documentation incorrectly stated that this policy would work for gmail.com, which is untrue.

Bug:  707825 
Change-Id: I1e0d415bd3ff0915628bd211ffa0a1561353b167
Reviewed-on: https://chromium-review.googlesource.com/723127
Commit-Queue: Georges Khalil <georgesak@chromium.org>
Reviewed-by: Julian Pastarmov <pastarmovj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509765}
[modify] https://crrev.com/4f650e95b5e0526f0aa39800b1fa729af15b002e/components/policy/resources/policy_templates.json

georgesak@ Could you please help us the repro steps to verify the fix from TE- end 


Thank You...

crrev.com/4f650e95 is a documentation fix. There is no code behavior change.