Forum Discussion
SeanLyndersay-MS
Microsoft
MicrosoftEarly preview of Microsoft Edge group policies
Update July 22nd 2019:
Hey folks,
Thanks for all the great feedback! We announced last week that Edge is now ready for Enterprise evaluations.
You can find the latest ADMX files and MSIs/PKGs ...
Ruud van Velsen The policy wasn't ready when Sean shared the administrative template zip file. It will be in the next version we share.
SeanLyndersay-MSMicrosoft
MicrosoftP3c4s0 Yes, some of the policies have that restriction.
Generally, this restriction exists to limit the impact of policies that are often used by adware/grayware to make changes to the browser bypassing the usual protections against manipulating settings. Enforcing that the device is domain-joined makes it less likely that adware will use those particular settings (since they won't work on most machines). The current version of Edge has similar limitations on policies that impact homepages and search providers (the most commonly misused policies).
The particular policy you cited can be used to specify a specific set of URLs to open on startup, which can be misused to effectively do a homepage takeover, which is why the limitation exists.
Any way to configure edge://flags/#edge-windows-credentials-for-http-auth via GPO? That setting being Enabled disallows users from copying credentials from Password management extensions so we'd need a way to disable that.
Avi VaidJussi Palo We don't currently have a way to configure this setting using policy. Just wondering, since Windows hello lets users enter their pin or biometric identity instead of a password, why do you see the need to have copy/paste supported. Furthermore, if the user is signed into the browser profile (happens automatically), they'll benefit from ambient authentication and won't even need to see this dialog.
There are different customer/corporate systems requiring using credentials other than your personal ones you've used when logging into Windows, e.g., internal Microsoft SharePoint on-prem systems commonly using Windows authentication. That combined with dev/test/prod instances of said systems, and you suddenly have 30 different credentials you need to use - not feasible nor even possible to use browser profiles or anything else except copy pasting from browser password extension.
That does not work for users that have their own MS profile, which is not tied to our domain (we don't allow that).
- Avi Vaid
Keith Davis Thanks, that makes sense.
Two things that we're working on here:
1. We're working on a feature that will help users get back to their work profile from their personal MS profile when accessing these work sites.
2. We are considering revamping this HTTPAuth experience to avoid prompting users for creds. We will simply ask if we should release creds from the OS to auth users to the site. If the user then says yes, we will use ambient authentication to auth them to the website. Would love to hear your thoughts on this.
With these features coming, do you think you would still need the policy to use the username password field instead of windows hello?
