Microsoft Edge Secure Password Deployment

-

I recently had a conversation around the configuration of shared windows devices with a customer and as part of the discussion, the customer showed interest in being able to login on web applications on Edge by multiple users in a secure manner. It immediately struck me that Microsoft recently released secure password deployment feature for enterprise customers. It had been recently moved into GA and I thought it was a legitimate option and possibly a right fit considering their specific requirement.

Microsoft Edge's Secure Password Deployment feature is a new enterprise-grade solution designed to enhance password security and simplify access for organizations. It allows administrators to securely share encrypted passwords with specific users or groups within an organization using Microsoft Edge for Business. This is especially useful in environments where shared credentials are needed but must be tightly controlled.

These passwords are encrypted using Microsoft Information Protection SDK, ensuring they are identity-bound and only accessible by authenticated users.
Once deployed, the passwords appear in the user's Edge password manager and are ready for autofill, but cannot be viewed, edited, or exported by the user. From a licensing perspective, you need Microsoft 365 Business Premium, E3 or E5.

While testing the feature, I felt that the configuration was not super obvious so thought of writing about my experience in this blog post.

Creating Cloud policy for Microsoft Edge Secure Password

The secure password deployment policy is created through Microsoft Edge service management. Here are the steps -

2. Then navigate to Settings -> Microsoft Edge -> Configuration Policies, as shown below.


3. Click on Create policy and give a name.


4. Select policy type as 'Cloud'. Note: Selecting 'Intune' does not enable the setting for secure password, therefore, for the feature to work, you will need to select 'Cloud'. This way the setting will roam with the user and not the device. However, there are some additional settings which we will configure using Intune as well.


5. Leave the settings blank for now. This is because it is only after the creation of the policy, secure password feature gets enabled. Weird as it may sound, at the time of writing this blog post, this is how the creation of the secure password policy currently works.

6. You can configure extension settings if need be, otherwise leave the defaults.


7. You can assign the policy now or later.

8. Review the policy and hit create.

9. After the policy is created, come back to it and click on 'Customized Settings'

10. Under 'Secure Password', click 'Add credentials'.


11. Enter the url for the website, username and password as part of shared credentials. Note: Make sure to enter the full url as part of the format.


10. As the last step, assign the policy to the intended list of users who are supposed to received the managed secure password policy. This step is only needed if you didn't assign the group earlier during the creation of the policy.



Edge Settings in Intune to support Secure Password deployment

While this is not a must, it is however highly recommended as it will make the whole secure password deployment a lot more efficient and a smooth end user experience.

2. Browse to Devices –> Configuration
3. Click Create Profile
4. Select Platform as Windows 10 and later
5. Select Profile type as Settings catalog
6. Provide a Name and hit next.
7. Click on Add settings.
8. Configure the following - 



End user experience

After the policies apply, the user must sign-in and a non-removable profile will be created with the user's work or school account on Windows and should be syncing. This profile can't be signed out or removed.


Both Edge cloud and Intune policies should report as enabled.


Clicking on SecureDeploymentPasswords, will show you specific details of the secure password.


Navigating to edge://wallet/passwords, should show the secure password deployment urls and passwords.



When the user tries to access the policy managed url, the autofill feature within Edge will offer secure password as well.


This is due to how we configured autofill settings earlier as part of the Intune policy.


Final thoughts

It is super important that one takes care of the url format. If the value is not in correct format, the policy will not apply. Also, for autofill functionality to work correctly, one needs to select the 'Fill website password and sign-in automatically.' If you select any of the other 2 options which requires a prompt, it is going to break the autofill functionality and will require the synced profile on edge to provide credentials before allowing access to the secure password. I faced some issues here and the brilliant folks at Microsoft, showed me where I was going wrong, so kudos to them!

Until next time..

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){              ...
Read more

Fixing Tamper Protection Blob Error 65000 using Microsoft Intune

-
Image
I recently encountered an issue with enabling Tamper protection as part of the implementation of Defender for Endpoint in one of customer's tenant and considering how unusual the behavior was and how I didn't encounter this before, I decide to blog my experience. If you have been battling with the same issue, then this blog may just help you. There are multiple ways to enable Tamper protection as part of MDE. One can enable at a tenant level using Defender portal or do it using Intune. I normally choose the Intune, especially when dealing with endpoints to maintain uniformity with other Defender policies being managed by Intune. However, in this particular instance, the issue started cropping randomly on some endpoints where tamper protection would not enable and throw an error code 65000, as show below. Additionally, the status in Defender will report as Unknown instead of reporting Active or something else like EDR in block mode to suggest that Defender Antimalware is running...
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from st...
Read more