我想为一个软件实现kerberos身份验证，其中服务器和客户端都在Windows上运行，并且是用C语言实现的。当客户端和服务器都在同一个Windows域上时，可以直接使用SSPI，我认为这也适用于跨领域环境。
当服务器由于任何原因不能成为域的成员时，这种向前倾斜的方法将不起作用。如何针对非域成员的服务器实现Kerberos身份验证？
如果我的研究是正确的，java应用程序或linux使用keytab文件，而不是隐式地从ad中检索密钥。显然SSPI不支持keytab文件。在这种情况下，有没有办法使用keytab文件？
SSPI 不会“从 AD 检索密钥”——服务密钥始终存储在本地，但使用 SSPI，它是在 AD 加入过程中生成的计算机帐户密码（并上传到 AD 而不是从中检索）代替密钥表。Windows 将计算机密码存储在 LSA 中，并从内存中派生密钥，但它与密钥表文件的用途相同。
可能有一种方法可以将机器密码存储在非AD机器中(使用ksetup.exe ),但这在很大程度上是一种系统范围内的更改——它似乎会使Windows登录过程的某些部分像系统加入域一样工作——因此我不建议这样做，除非是在测试中
相反，您可以使用另一种Kerberos实现——MIT Kerberos和Heimdal是两种主要的非AD Kerberos实现，它们以C库的形式出现（两者都兼容Windows，尽管它们的重点是类似Linux/Unix的系统）。这两个库都提供类似于Windows SSPI的GSSAPI接口，并且都使用keytab文件作为服务凭据。
对于C#，Kerberos.NET可用。对于
大多数实现都支持相同的keytab格式，因为它们在某种程度上模仿了MIT Kerberos（这是最初的Kerberos
MIT Krb5和Heimdal不仅包括一个库，还包括一个KDC服务，尽管这部分不会在Windows上运行。（Kerby和 Kerberos.NET 也可以用来构建最小的KDC。
以上内容对于服务器来说更为重要；但是，客户端可以使用SSPI对Kerberos服务进行身份验证，而无需成为域成员。
对于基于 AD 的领域（无论是否加入域的特定服务器），向 SSPI 提供 UPN 格式的用户名（以 user@domain 的形式）和密码就足够了;它将自动发现 KDC 并获取票证。
只要通过注册表或使用ksetup/AddRealmFlags将领域标记为“MIT领域”，那么对于非基于AD的Kerberos领域也是如此。（委托人user@REALM在这种情况下，需要将指定为用户名。）与前面提到的情况不同，这种ksetup.exe的使用似乎没有负面副作用。
