Windows 中用户配置文件的唯一标识符
对于客户端/服务器应用程序，我需要集中存储通常进入用户配置文件目录的部分配置信息。
客户端应用程序首先将带有 GUID 的文件或注册表项写入当前配置文件中。 该 GUID 随后将用作服务器上配置数据库中的密钥。
现在我想知道 Windows 用户配置文件是否已经具有我可以使用的唯一标识符，而不是生成自己的 GUID。
该用户名不起作用，因为用户可能有多个配置文件。 将其与计算机名称组合将不起作用，因为可能存在漫游配置文件。
更新：
我刚刚查看了同一域中两台计算机上的 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList 中的 SID。 未启用漫游，因此我的用户帐户在每台计算机上都有单独的配置文件。 两个配置文件均使用相同的 SID 列出。 这意味着我必须不断生成自己的 GUID。
For a client/server application I need to centrally store parts of the configuration information that usually goes into the users profile directory.
The client application would on first use write a file or registry entry with a GUID into the current profile. This GUID would subsequently be used as a key in the configuration database on the server.
Now I'm wondering if Windows user profiles already have unique identifiers I could use instead of generating my own GUIDs.
The username won't work because users might have multiple profiles. Combining it with the computer name won't work because there might be roaming profiles.
Update:
I just looked at the SIDs in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList on two computers in the same domain. Roaming is not enabled, so my user account has a separate profile on each machine. Both profiles are listed with the same SID. This means I have to keep generating my own GUIDs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Windows 用户和组使用安全标识符 (SID)。
Windows 内置了一个预定义 SID 列表。 其他 SID 是通过将当前计算机的（随机生成的，96 位）SID 与递增的数字组合来生成的。
在计算机上拥有帐户的用户的 SID 存储在注册表中的
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList示例 SID（取自 Microsoft 关于 Windows XP 安装的磁盘复制的策略）：
以下示例显示四个本地的 SID用户帐户。 请注意，随着新帐户的添加，只有最后四位数字会增加。
由于 SID 的生成方式，它们应该是唯一的。 由于它们是 Windows 配置文件系统的一部分，因此漫游配置文件在每个系统上都应具有相同的 SID。
Windows users and groups use security identifiers (SIDs).
There is a list of predefined SIDs that Windows has built-in. Other SIDs are generated by combining the current computer's (randomly generated, 96-bit) SID with an incremented number.
SIDs of users that have accounts on a computer are stored in the registry under
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileListSample SIDs (taken from The Microsoft policy concerning disk duplication of Windows XP installations):
The following example displays the SIDs for four local user accounts. Note that only the last four digits are incremented as new accounts are added.
Because of how SIDs are generated, they should be unique. Since they are part of the windows profile system, roaming profiles should have the same SID on every system.
您可以使用用户配置文件的安全标识符 (SID)。
LookupAccountName() Win32 API 接受用户名称和计算机名称作为输入，并返回关联的 SID。
You could use the user profile's security identifier (SID).
The LookupAccountName() Win32 API takes a user name and computer name as input and gives you back the associated SID.
R Bemrose 和 Snowccrash 是正确的，帐户 SID 正是您所请求的。 您是对的，为了使该解决方案发挥作用，您需要启用漫游配置文件； 这就是它们被称为漫游配置文件的原因。
如果您不想使用域身份验证来识别用户，那么您的另一个选择是 WAS（Windows 身份验证服务）。 这通常但不一定是在无处不在的 ASPNETDB 数据库中的 Microsoft SQL Server 上实现的。
WAS 是一个 dotnet 解决方案，对 ASP.NET 提供精心支持，也可用于桌面软件。 如果您也不喜欢这样，您可以自己推出，但在我看来，这似乎是资源的次优应用。 如果您不构建 dotnet 软件，您仍然可以利用 WAS，但不会那么方便。
R Bemrose and snowccrash are correct, the account SID is precisely what you have requested. You are correct that in order for this solution to work you much enable roaming profiles; that's why they're called roaming profiles.
If you don't want to use domain authentication to identify users then your other option is WAS (Windows Authentication Services). This is typically but not necessarily implemented atop Microsoft SQL Server in the ubiquitous ASPNETDB database.
WAS is a dotnet solution, with elaborate support for ASP.NET that is also available for desktop software. If you don't like that either, you can roll your own but this seems to me a suboptimal application of resources. If you aren't building dotnet software you could still exploit WAS but it won't be quite so convenient.
我可能会使用更以 LDAP 为中心的解决方案来解决此问题，但这可能会给您的应用程序带来更多工作量。
AD 中有一些供用户使用的独特字段。 您可以使用用户记录的整个 DN（即 DC=com、DC=example、CN=Users、DN=bob smith）。 这就是 AD 中记录的唯一标识。 然而，MS 还有一个名为 UPN 的字段，它看起来像电子邮件地址（有时确实如此），并采用 user@domain 的形式。
当然，此信息需要对 AD 的读取权限，这对于您的应用程序可能不实用。
I might use a more LDAP-centric solution to this problem, but it might be a lot more work for your app.
There are a few unique fields in AD for user. You could use the whole DN of a User record (i.e. DC=com,DC=example,CN=Users,DN=bob smith). That's what uniquely identifies a record in AD. However, MS also has a field called UPN, which looks like an email address (sometimes it is) and takes the form user@domain.
Of course, this information requires read access to AD and that may not be practical for your app.