英文:
Kerberos authentication. Keytab and ticket
问题
-
使用Kerberos身份验证的每个服务，例如Postgres，是否都必须拥有由KDC生成的keytab文件？或者Kerberos身份验证的服务是否可以没有keytab文件？
-
keytab如何确定用户的新主体已被添加？我的意思是，我为Postgres生成了keytab并将其发送到Postgres服务，然后在postgresql.conf中匹配了keytab文件。然后，我在Postgres数据库中创建了角色Born（例如），并在KDC kadmin中添加了该主体。之后，从另一台计算机上，我可以连接到Postgres服务（在执行kinit Born后）。但是在添加新主体Born之前，我已经创建了keytab。Postgres的keytab是如何找到Born的？Kadmin中有关新添加用户的信息是如何存储到另一台服务器上的Postgres keytab中的？
英文:
I've got several question about Kerberos, how it work.
- Does every service, for example Postgres, which uses Kerberos authentication, must
have keytab, generated by KDC? Or maybe kerberos authentication on service can be without keytab file? - How does keytab determine, that new principal of user was added? I mean, I've generated keytab for Postgres and send it on service of Postgres and match the keytab file in postgresql.conf. Then I created role Born (for instance) in Postgres database and add it principal in KDC kadmin. After that, from another computer I can connect (after kinit Born) to Postgres service. But I've made keytab before adding new principal Born. How keytab of Postgres manage to find Born? How info about new added user from kadmin store to keytab Postgres on another server?
答案1
得分: 1
是的，每个服务都必须拥有自己的Kerberos身份，并且必须知道相应的密钥。这些密钥不一定需要存储在一个keytab文件中（例如，Windows AD机器使用密码），但通常是这样的。
对于Postgres，它只能使用keytab进行Kerberos身份验证。但也有一些服务不需要keytab。
所有服务都有自己的Kerberos主体和相应的密钥（如果您查看维基百科的图表，它是KS），只是这些密钥不一定以特定的keytab形式存储。
托管在Windows Server系统上的服务通常不使用keytab，因为它们通过Windows SSPI使用Kerberos，它使用服务用户帐户的密码或存储在LSASS中的“机器密码”，并从该密码派生KS（就像用户在kinit期间从密码派生密钥一样）。
但从根本上说，无论密钥是否从密码派生都是相同的。服务仍然有自己的身份和Kerberos密钥。（这也意味着客户端可能有一个keytab，并在kinit中使用它，而不是密码。）
keytab如何确定用户的新主体已经添加？
它并不确定。服务器的keytab完全不关心用户；它仅仅标识_服务器本身_。其作用有点类似于服务器的TLS证书和私钥（尽管机制完全不同）。
此外，Kerberos并不负责关心Postgres用户。将Kerberos主体映射到Postgres角色是在Kerberos身份验证完成之后进行的。
换句话说，Postgres不会直接从Kerberos接收角色名称，它只会接收一个Kerberos主体名称，并必须通过自己的方式将其映射到Postgres角色。Kerberos身份验证成功但角色映射（即授权）失败是完全有效的。
英文:
> Does every service, for example Postgres, which uses Kerberos authentication, must have keytab, generated by KDC? Or maybe kerberos authentication on service can be without keytab file?
Yes, every service must have its own Kerberos identity, and must know the keys for it. The keys might not necessarily be stored in a keytab file (e.g. Windows AD machines use a password), but they usually are.
> Postgres works with KErberos only using keytabs. But there are some that don't nead keytabs.
All services have their own Kerberos principal and their own key (the K<sub>S</sub> if you're looking at the Wikipedia diagram), it's just not always stored in the specific form of a keytab.
Services that are hosted on a Windows Server system often don't use a keytab because they use Kerberos through Windows SSPI, which uses either the service user account's password, or the "machine password" stored in LSASS, and derives K<sub>S</sub> from that password (exactly like how users derive their keys from password during kinit).
However, it is fundamentally the same thing, whether the key is derived from a password or not. The service still has its own identity and its own Kerberos keys. (It also means clients might have a keytab and use it with kinit instead of a password, too.)
> How does keytab determine, that new principal of user was added?
It doesn't. The server's keytab does not care about users at all; it identifies the server itself. Its purpose is a bit like the server's TLS certificate and private key (even though the mechanism is entirely different).
Additionally, it is not the job of Kerberos to care about Postgres users. The mapping of Kerberos principals to Postgres roles happens after Kerberos authentication has been done.
In other words, Postgres doesn't receive a role name from Kerberos directly, it only receives a Kerberos principal name and has to map it to a Postgres role by its own means. It is completely valid for Kerberos authentication succeed but for the role mapping (i.e. authorization) to fail.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论