通过 T-SQL 唯一标识 SQL Server 计算机
我们正在开发一个客户端-服务器应用程序的许可系统，其中唯一的服务器组件是数据库（无应用程序服务器）。我们希望向特定服务器颁发许可证，该服务器不能安装在任何其他服务器上或通过备份/恢复进行传输。这个想法是通过 T-SQL 查询生成一个唯一的标识符，然后使用公共/私有签名返回仅适用于该标识符的激活令牌。
有没有一种方法可以仅使用 T-SQL（没有 CLR 存储过程或函数）以可重复的方式唯一标识 SQL Server？例如，安装实例时是否创建了一些可检索的唯一值？
编辑：也许NEWSEQUENTIALID()的MAC部分可以工作（参见此方法）。如果系统在群集/故障转移设置中进行故障转移，或者主 LAN 适配器发生更改，则它可能会进入“宽限期”，在此期间它将继续运行，直到在新硬件上重新激活。问题是这是否“足够独特”。
We are working on a licensing system for a client-server application where the only server component is a database (no application server). We would like to issue licenses to a particular server that cannot be installed on any other server or transferred via backup/restore. The idea is to generate a unqiue identifier via a T-SQL query and then use public/private signing to return an activation token that works only for that identifier.
Is there a way to uniquely identify a SQL Server, in a repeatable way, using only T-SQL (without a CLR stored proc or function)? For example, is there some retrievable, unique value that is created when the instance is installed?
Edit: Maybe the MAC part of NEWSEQUENTIALID() would work (see this method). If the system fails over in a cluster/failover setup, or if the primary LAN adapter is changed, it could enter a "grace period" during which it will continue to operate until re-activated on the new hardware. The question is whether this is "unique enough."
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
即使您获得了唯一的 ID，T-SQL 验证也存在潜在问题。数据库未经过验证。如果他们破解 T-SQL 并删除激活部分怎么办？客户是直接使用 T-SQL 还是您有客户端应用程序。如果您有客户端应用程序，那么为什么 CLR 不是一个选项。它是可以破解的，但我使用了一个应用程序，该应用程序在安装时生成服务器名称的哈希值并将其存储在数据库中。然后客户端会将存储的哈希值与动态哈希值进行比较，以确定它是否在另一台服务器上。问题是，如果服务器名称相同，那么它可能会被击败，并且哈希算法位于客户端应用程序上，因此只要努力它就可能会被暴露。
阿迪安 我希望我能感谢您回答我的问题。
如果您查看 sysObjects 和其他系统表/视图，我认为您可以找到唯一标识服务器和数据库的内容。就像恢复到另一台服务器一样，即使名称相同但内部 ID 不同，您也必须删除用户并重新创建用户。如果他们恢复主数据库和应用程序数据库，他们可能能够使所有内容都相同，但他们必须知道如何做到这一点。在基本安装上，SQL 可能会在某处生成一个唯一的 ID，因为 Microsoft 需要一个用于复制、其他功能和许可的唯一 ID，这是有道理的。
Even if you get a unique ID a potential problem is validation at T-SQL. The database is not validated. What if they hack the T-SQL and remove the activation part. Does the customer use T-SQL directly or do you have a client application. If you have a client application then why is CLR not an option. It was crack-able but I worked with an application that generated a hash of server name on the install and stored it in the database. Then the client would compare the stored hash to the dynamic hash to determine if it was on another server. Problem was if the server name was the same then it could be beat and the hash algorithm was on the client application so with effort it could be exposed.
Adian I wish I could thank you for answering my questions.
If you look in sysObjects and other systems tables/views I think you can find something to uniquely identify a server and database. Like on a restore to another server you have to delete the user and and recreate the user even though the name is the same the internal id is different. If they restored the master and application database they might be able to make everything identical but they would have to know to do that. On the base install SQL may generate a unique id somewhere as it makes sense Microsoft would want a unique id for replication, other features, and licensing.