kerberos 身份验证的工作原理
How kerberos authentication works
我试图弄清楚 kerberos 身份验证是如何工作的，我发现的信息总是缺少一些东西，好像其中的一部分是理所当然的。我知道一般的过程，但缺少一些细节。
获取 TGT：
首先，用户应该从 KDC 获得 TGT（票证授予票证）- 用户发送仅包含其用户名 (UPN) 且 不包含其密码的请求。提供了一些额外信息以防止重新发送请求，例如 IP 地址和时间戳。
如果需要预身份验证，则时间将使用用户密码进行哈希处理。
KDC 正在向用户发回以下内容：
A. TGT - 带有时间戳、用户名、IP 地址和会话密钥 - TGT 使用只有 KDC 知道的秘密加密，因此任何人都无法更改。
B. 用户的会话密钥和 KDC 将在以后的通信中使用。
这些东西使用用户密码（KDC 和用户之间的基本共享秘密）加密。
如果使用预身份验证，服务器将在发回信息之前检查时间戳是否有效。
用户收到信息并使用密码对其进行解密 - 然后将其存储在内存中（kerberos 托盘）。
正在获取 TGS：
当用户被要求从服务中验证自己时，他向 KDC 发送请求以获得 TGS（票证授予服务），该请求包含 TGT、UPN 和 SPN（服务主体名称 - 例如，网页的 URI）。
然后 KDC 解密 TGT 并验证其真实性，它与 UPN 相对应，来自相同的 IP 地址并且仍然有效（票证具有有效时间段）。
KDC发送一个TGS给用服务密码加密的用户。
用户将 TGS 提交给服务 - 它使用自己的密码对其进行解密。
身份验证已完成，因为服务依赖于它的密码仅在它和 KDC 之间共享这一事实，因此它相信 KDC 早些时候对用户进行了身份验证。
几个问题：
我是不是漏掉了什么？
用户和 KDC 什么时候使用过会话密钥？在什么时候？为什么有必要？为什么用户密码不够？
用户和服务之间也应该有一个会话密钥（据我所知）-何时以及为什么使用它（与上一个问题相同）？
Kerberos 在各方之间有 5 分钟的间隔限制 - 我理解为什么保持时间同步很重要，因为它被用作我们加密和解密的东西，所以任何间隔都可以吗？为什么是 5 分钟？
如果您有任何更正，我将很高兴。
提前致谢，
汤姆
所以，我想我找到了答案。
我会做一些更正，因为这个问题有一些不准确的地方。
Getting TGT:
- First a user should get a TGT (Ticket Granting Tickets) from the KDC - the user sends a request with only it's user name (UPN) and without it's password. Some extra information is given to prevent a resent of the request such as ip address and a timestamp. If preauthentication is required then the time is hashed with the user's password.
- The KDC is sending the user back the following:
A. TGT - with a timestamp, user name, ip address and a session key - the TGT is encrypted with a secret only the KDC knows and therefore cannot be changed by anyone.
所有这些都简称为“验证器”。
B. Session key for the user and the KDC to be used in later communication.
Those things are encrypted using the users password (a basic shared secret amongst the KDC and the user). In case a preauthentication was used the server will check if the timestamp was valid before sending the information back.
TGT 本身仅由 KDC 的秘密进行哈希处理，而不是用户密码。
- The users receive the information and decrypt it using it's password - and then stores it in it's memory (kerberos tray).
Getting TGS:
- When the user is requested to authenticate itself from a service he sends a request to the KDC for a TGS (Ticket Granting Service), the request contains the TGT, UPN and the SPN
该请求还包括一个新的身份验证器（而不是提到的 UPN），KDC 将根据 TGT 中的身份验证器进行检查。使用用户的会话密钥和 KDC 对身份验证器进行加密。 KDC 将使用它的密码解密 TGT，然后从中提取会话密钥（它不保存其中的信息），然后使用会话密钥解密身份验证器。
(Service Principal Name - say, the URI of a webpage).
SPN 不包含 URI - 它包含主机、服务和端口 - 类似于：HTTP/localhost:80 或 ldap/localdc。
如果使用默认端口（例如 80 用于 HTTP 或 389 用于 ldap），则可以省略端口号。
- The KDC then decrypts the TGT and validate it's authenticity, that it is corresponds with the UPN, from the same IP address and still valid (the ticket has an effective time period).
3. The KDC sends a TGS to the user encrypted with the service password.
KDC 还会发送会话密钥供客户端和用户稍后使用。它使用 KDC 的会话密钥和早期的用户加密发送它 - 会话密钥的另一个副本（客户端和服务器）在 TGS 本身内部，TGS 内部还驻留了客户端的身份验证器。
- The user presents the TGS to the service - which decrypts it using it's own password.
5. The authentication is complete since the service counts on the fact that it's password is only shared between it and the KDC so it trusts that the KDC authenticated the user earlier.
用户还发送了一个用客户端和服务器的会话密钥加密的验证器。然后服务器使用它的密码解密 TGS - 从 TGS 中提取会话密钥并使用它来解密身份验证器并将其与 TGS 中的身份验证器进行比较。如果有效，则客户端的身份验证完成。 Kerberos 还为客户端提供了一个选项来对服务器进行身份验证（称为相互身份验证）- 如果客户端发送了相互身份验证的标志，那么还有另一个步骤。
- 服务器向客户端发送一个使用共享会话密钥加密的时间戳。服务器通过操纵客户端发送的数据（意味着它可以解密它）来证明它的真实性，所以这意味着它知道只有它和 KDC 应该知道的服务器密码。
A few questions:
- Am I missing something or that's it?
- When does the user and the KDC ever use the session key? At what point? Why is it necessary? Why does the user password isn't enough?
- There should also be a session key between the user and the service (to the best of my knowledge) - when and why is it used (same as the last question)?
- Kerberos has a 5 minute gap limitation between all parties - I understand why keeping the time in sync is important since it is used as something that we encrypt and decrypt so how come any gap is OK? Why 5 minutes?
- 是的。
- 关于何时回答，以及为什么 - 动机是为可选的攻击者提供更少的使用密码创建的数据样本，这样就更难从加密数据中破解密码。会话密钥一直在变化（每次登录或 TGT 到期后），当攻击者可以破解它时，它就没有用了。
- 已回答。
- 好吧，由于同步未完成，因此必须确定一些间隙。我在这里猜测 5 分钟 - KDC 和服务器应该在内存中保留最后 5 分钟的请求，以便攻击者不会重新发送有效请求并获得身份验证（称为重放攻击）。因此，每次发出请求时，服务器或 KDC 都必须在内存中查找它是否不是重新发送的请求。显然这是一个权衡，因为时间间隔越大，服务器需要分配给该任务的内存就越多。顺便说一句 - 默认时间段只有 5 分钟，并且是可配置的。
希望对您有所帮助。
所有的东西都在这个link中（如果一个人从头到尾阅读整个内容会非常重复 - 你应该只阅读你想理解的部分） - Https:/ /Technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx
我还阅读了一些 RFC - https://www.rfc-editor.org/rfc/rfc1510
还有两个不太详细的link：
https://technet.microsoft.com/en-us/library/cc961976.aspx
https://technet.microsoft.com/en-us/library/aa480475.aspx（处理 IIS 身份验证 - 有一部分提到了 kerberos 并做了一些解释）。
我试图弄清楚 kerberos 身份验证是如何工作的，我发现的信息总是缺少一些东西，好像其中的一部分是理所当然的。我知道一般的过程，但缺少一些细节。
获取 TGT：
首先，用户应该从 KDC 获得 TGT（票证授予票证）- 用户发送仅包含其用户名 (UPN) 且 不包含其密码的请求。提供了一些额外信息以防止重新发送请求，例如 IP 地址和时间戳。 如果需要预身份验证，则时间将使用用户密码进行哈希处理。
KDC 正在向用户发回以下内容： A. TGT - 带有时间戳、用户名、IP 地址和会话密钥 - TGT 使用只有 KDC 知道的秘密加密，因此任何人都无法更改。
B. 用户的会话密钥和 KDC 将在以后的通信中使用。
这些东西使用用户密码（KDC 和用户之间的基本共享秘密）加密。 如果使用预身份验证，服务器将在发回信息之前检查时间戳是否有效。用户收到信息并使用密码对其进行解密 - 然后将其存储在内存中（kerberos 托盘）。
正在获取 TGS：
当用户被要求从服务中验证自己时，他向 KDC 发送请求以获得 TGS（票证授予服务），该请求包含 TGT、UPN 和 SPN（服务主体名称 - 例如，网页的 URI）。
然后 KDC 解密 TGT 并验证其真实性，它与 UPN 相对应，来自相同的 IP 地址并且仍然有效（票证具有有效时间段）。
KDC发送一个TGS给用服务密码加密的用户。
用户将 TGS 提交给服务 - 它使用自己的密码对其进行解密。
身份验证已完成，因为服务依赖于它的密码仅在它和 KDC 之间共享这一事实，因此它相信 KDC 早些时候对用户进行了身份验证。
几个问题：
我是不是漏掉了什么？
用户和 KDC 什么时候使用过会话密钥？在什么时候？为什么有必要？为什么用户密码不够？
用户和服务之间也应该有一个会话密钥（据我所知）-何时以及为什么使用它（与上一个问题相同）？
Kerberos 在各方之间有 5 分钟的间隔限制 - 我理解为什么保持时间同步很重要，因为它被用作我们加密和解密的东西，所以任何间隔都可以吗？为什么是 5 分钟？
如果您有任何更正，我将很高兴。
提前致谢， 汤姆
所以，我想我找到了答案。
我会做一些更正，因为这个问题有一些不准确的地方。
Getting TGT:
- First a user should get a TGT (Ticket Granting Tickets) from the KDC - the user sends a request with only it's user name (UPN) and without it's password. Some extra information is given to prevent a resent of the request such as ip address and a timestamp. If preauthentication is required then the time is hashed with the user's password.
- The KDC is sending the user back the following:
A. TGT - with a timestamp, user name, ip address and a session key - the TGT is encrypted with a secret only the KDC knows and therefore cannot be changed by anyone.
所有这些都简称为“验证器”。
B. Session key for the user and the KDC to be used in later communication. Those things are encrypted using the users password (a basic shared secret amongst the KDC and the user). In case a preauthentication was used the server will check if the timestamp was valid before sending the information back.
TGT 本身仅由 KDC 的秘密进行哈希处理，而不是用户密码。
- The users receive the information and decrypt it using it's password - and then stores it in it's memory (kerberos tray).
Getting TGS:
- When the user is requested to authenticate itself from a service he sends a request to the KDC for a TGS (Ticket Granting Service), the request contains the TGT, UPN and the SPN
该请求还包括一个新的身份验证器（而不是提到的 UPN），KDC 将根据 TGT 中的身份验证器进行检查。使用用户的会话密钥和 KDC 对身份验证器进行加密。 KDC 将使用它的密码解密 TGT，然后从中提取会话密钥（它不保存其中的信息），然后使用会话密钥解密身份验证器。
(Service Principal Name - say, the URI of a webpage).
SPN 不包含 URI - 它包含主机、服务和端口 - 类似于：HTTP/localhost:80 或 ldap/localdc。 如果使用默认端口（例如 80 用于 HTTP 或 389 用于 ldap），则可以省略端口号。
- The KDC then decrypts the TGT and validate it's authenticity, that it is corresponds with the UPN, from the same IP address and still valid (the ticket has an effective time period). 3. The KDC sends a TGS to the user encrypted with the service password.
KDC 还会发送会话密钥供客户端和用户稍后使用。它使用 KDC 的会话密钥和早期的用户加密发送它 - 会话密钥的另一个副本（客户端和服务器）在 TGS 本身内部，TGS 内部还驻留了客户端的身份验证器。
- The user presents the TGS to the service - which decrypts it using it's own password. 5. The authentication is complete since the service counts on the fact that it's password is only shared between it and the KDC so it trusts that the KDC authenticated the user earlier.
用户还发送了一个用客户端和服务器的会话密钥加密的验证器。然后服务器使用它的密码解密 TGS - 从 TGS 中提取会话密钥并使用它来解密身份验证器并将其与 TGS 中的身份验证器进行比较。如果有效，则客户端的身份验证完成。 Kerberos 还为客户端提供了一个选项来对服务器进行身份验证（称为相互身份验证）- 如果客户端发送了相互身份验证的标志，那么还有另一个步骤。
- 服务器向客户端发送一个使用共享会话密钥加密的时间戳。服务器通过操纵客户端发送的数据（意味着它可以解密它）来证明它的真实性，所以这意味着它知道只有它和 KDC 应该知道的服务器密码。
A few questions:
- Am I missing something or that's it?
- When does the user and the KDC ever use the session key? At what point? Why is it necessary? Why does the user password isn't enough?
- There should also be a session key between the user and the service (to the best of my knowledge) - when and why is it used (same as the last question)?
- Kerberos has a 5 minute gap limitation between all parties - I understand why keeping the time in sync is important since it is used as something that we encrypt and decrypt so how come any gap is OK? Why 5 minutes?
- 是的。
- 关于何时回答，以及为什么 - 动机是为可选的攻击者提供更少的使用密码创建的数据样本，这样就更难从加密数据中破解密码。会话密钥一直在变化（每次登录或 TGT 到期后），当攻击者可以破解它时，它就没有用了。
- 已回答。
- 好吧，由于同步未完成，因此必须确定一些间隙。我在这里猜测 5 分钟 - KDC 和服务器应该在内存中保留最后 5 分钟的请求，以便攻击者不会重新发送有效请求并获得身份验证（称为重放攻击）。因此，每次发出请求时，服务器或 KDC 都必须在内存中查找它是否不是重新发送的请求。显然这是一个权衡，因为时间间隔越大，服务器需要分配给该任务的内存就越多。顺便说一句 - 默认时间段只有 5 分钟，并且是可配置的。
希望对您有所帮助。
所有的东西都在这个link中（如果一个人从头到尾阅读整个内容会非常重复 - 你应该只阅读你想理解的部分） - Https:/ /Technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx
我还阅读了一些 RFC - https://www.rfc-editor.org/rfc/rfc1510
还有两个不太详细的link：
https://technet.microsoft.com/en-us/library/cc961976.aspx
https://technet.microsoft.com/en-us/library/aa480475.aspx（处理 IIS 身份验证 - 有一部分提到了 kerberos 并做了一些解释）。