Hi Owen,

Can you take a look at this when you have a chance?    Adding a new option to the policy for forced sign-in that allows pass-through of the current logged in windows user seems like a slick use-case for forced sign-in.

WDYT?

I think this FR makes sense. In order to that, we need to implement:
1) Create a shadow account for Windows AD userID.
2) Create a primary profile for Chrome.
3) Signin to the primary profile automatically.

For the new primary profile concept,
a) Are the policies of primary profile applied to other profiles?
b) Is deleting the primary profile forbidden?
c) Are there any other features we want to create based on the primary profile?

I think we could reuse some code from ChromeOS for 1) and 3) while 2) might be complicated
depends on the answers of three questions above.

+rogerta

This is something we'll look into down the line, but not immediately.

Chester, to clarify: C#2 is mentioning a larger undertaking to create shadow accounts for non-gsuite customers.

I may be off base, but IIUC, your request here for existing mapping of AD + GSuite users accounts.

eg, matt@company.com is my AD account or matt@corp.company.com is what I log into windows/AD and my gsuite account is matt@company.com. Is it correct to assume you want a policy to map the current windows/AD user to the gsuite account (eg, map 1:1  *@company.com  (AD) to *@company.com (GSUITE) )  OR (map *@corp.company.com (AD) to *@company.com (GSuite)?