@
dgzting #10 是否有那个问题是数学决定的，不是 API 决定的。Windows 有一些自动加密的内容使用用户的密码导出的密钥，可以简单地理解为这样的模式：
1. 用户建立的时候生成 AES 密钥 K
2. 如果用户密码是 P ，则计算 S = MakeKeyFromPassword(P)，其中 S 是另一个 AES 密钥
3. 在硬盘上保存 AutoKey = AES.Enc(key=S, plaintext=K)
4. 如果用户设置文件 F 要加密，则在硬盘上保存 EncF = AES.Enc(key=K, plaintext=F)，解密的时候可以用 P 导出 S ，再用 S 解密 AutoKey 得到 K ，最后用 K 解密 EncF 得到 F
注意 K 是没有直接保存在硬盘上的。
5. 如果用户修改密码，那么先用旧密码 P 得到 S ，然后用 S 解密 AutoKey 还原 K ，再用新密码 P' 得到 S'，再设置 AutoKey 为 AES.Enc(key=S', plaintext=K)，这样每次修改密码的时候只需要重新加密少量数据，不需要把所有文件都解密再重新加密一次。
这个机制和 Windows 验证用户登录的机制是分开的，你可以认为 Windows 另外保存了密码 P 的 hash 值 H ，而 H 本身没有加密，登录时 Windows 只是计算用户尝试登录时输入的密码的 hash 并和 H 比较。可以简单认为登录成功的时候 Windows 重新见到了 P ，因此可以重新算出 S 、K 并在内存里缓存 P 、S 、K 。然而假设用户没有登录，比如操作系统刚启动的时候，此时 Windows 只知道 H ，不知道 P 、S 、K 。
如果修改密码的时候提供旧密码，那么 Windows （在操作人有合适的权限的情况下）当然可以修改它记住的 H ，允许用新密码通过 Windows 的登录逻辑。但是没有 P 的时候 S 、K 依然无法还原。
换言之，是否允许登录纯粹是操作系统想不想的问题，但是否能解密数据，是能不能的问题。
* * *
你在 lusrmgr.msc 和 compmgmt.msc 里面修改用户密码的时候会提示
Resetting this password will might cause irreversible loss of information for this account.
等等一大串，并且告诉你（作为用户而不是开发者时候）正确做法是按 Ctrl+Alt+Delete 打开“Windows 安全”对话框，选择 Change a Password ，然后输入用户名、旧密码、新密码（两次）。
net user 和 Set-LocalUser 都不需要旧密码，因此一定会导致密码学数据不再可用（除非你后来想起来旧密码并且旧的例如 AutoKey 和 EncF 还没有被删除，我不知道 Windows 会不会自动删除失效的 AutoKey ）。实际上它们和 lusrmgr.msc / compmgmt.msc 归结为同一个 API 。
而 NetUserChangePassword 需要旧密码，而且实际上 NetUserChangePassword 会类似之前提到的解密、重加密操作，所以不会有这个问题。它和 Ctrl+Alt+Delete 是一样的。
* * *
是否丢失密码学保护的数据和用户在本地还是域控制器上无关。在 Windows 提供的 API 下，丢失数据当且仅当修改密码不需要提供旧密码。