Forum Discussion
Does Windows Admin Center protect Domain Administrator passwords
I would like to manage my core Windows 2016 domain controllers using Windows Admin Center. As I can't install WAC on a domain controller, I must use my PC or a nearby server.
My question is whether I am exposing my domain admin credentials accessing these core domain controllers while using WAC? How is the password protected and disposed of after my WAC session ends?
Thanks for your advice.
LL10890 I asked the same question to Microsoft and below is their response, I hope it helps
Credentials are not stored - anywhere. They are ephemeral from the gateway’s perspective but may live encrypted within browser memory during the user’s current session.
The UI sends credentials by:
- Encrypting the text with the Json Web Key (JWK) specification using:
- RSA asymmetric encryption
- A 2,048 key size
- SHA-512 hash
The encrypted value is sent in a HTTP header which is further encrypted by TLS/SSL
The server decrypts the value, when present and stores it in memory using the Windows Data Protection API (DPAPI)
When connecting to a resource, the gateway uses one of the following methods:
- Uses a type of Windows logon that only allows the credentials to be used to authenticate against a remote target
Scenarios for this include non-PowerShell paths such as SMB operations such as file uploads or downloads
- WinRM calls for PowerShell/WMI to include the credentials explicitly in each connection
The connection protects the values using DPAPI on the client and target server
WinRM connections use their own compression and symmetric encryption by default
5 Replies
LL10890 Greetings, the question is? does MS Edge chrome or any browser leak your password if you save them in the browser? From what I can see when using WAC via Edge (MS Chrome version) at no point does it ask me to save my password to the browser so I assume it's a security function by default.
However, as WAC uses an SSL cert which is either self-signed or purchased your session is encrypted in any case. there is also the option to use InPrivate or application guard mode via the browser to add further security or you could use a sandbox version to windows 10 (if you use Win10 pro) to create a temp session for use when using WAC and once the container is closed all setting and history are reset to factory clean for next use. The sandbox option is overkill however I tested it and its all good. I have very paranoid friends.
If your on-prem then you can just use the internal IP and port which isn't exposing anything or if you have a work VPN then do the same, e.g. use internal IP and port for WAC. I assume you want to use the gateway so it can be used anywhere. I invested in a SSL cert to encrypt my WAC and use InPrivate mode in MS Edge when out and about.
However, there are times I don't have my laptop and need to access from another location so I trust in my SSL and redirected all traffic to HTTPS by default (and use incognito mode on whatever browser I'm using external which I have no control overkill as I have an SSL).
But to be honest an SSL is the way go for WAC especially in a gateway for more info google or bing "Install an SSL certificate in Windows Admin Center | 4sysops"
Hope this helps, Godspeed
- Thanks AvengeTheTECH. The SSL cert and sandbox are great suggestions.
LL10890 I asked the same question to Microsoft and below is their response, I hope it helps
Credentials are not stored - anywhere. They are ephemeral from the gateway’s perspective but may live encrypted within browser memory during the user’s current session.
The UI sends credentials by:
- Encrypting the text with the Json Web Key (JWK) specification using:
- RSA asymmetric encryption
- A 2,048 key size
- SHA-512 hash
The encrypted value is sent in a HTTP header which is further encrypted by TLS/SSL
The server decrypts the value, when present and stores it in memory using the Windows Data Protection API (DPAPI)
When connecting to a resource, the gateway uses one of the following methods:
- Uses a type of Windows logon that only allows the credentials to be used to authenticate against a remote target
Scenarios for this include non-PowerShell paths such as SMB operations such as file uploads or downloads
- WinRM calls for PowerShell/WMI to include the credentials explicitly in each connection
The connection protects the values using DPAPI on the client and target server
WinRM connections use their own compression and symmetric encryption by default
