亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

kerberos

系統 2133 0

今天聽了鑒權相關的課程,了解到了kerberos。下面這篇文章寫得還不錯。

Kerberos authentication explained

Authentication and authorisation are often thought of as a single process but the two are actually distinct operations that may even use separate storage locations for the authentication and authorisation data.

Authentication is about verifying identity, based on one or more factors, for example something that someone knows (e.g. a password), something that someone holds (e.g. a smart card), something that someone is (e.g. biometric information).? Obviously the use of? multiple-factor identification ?increases security.

Authorisation is about controlling access to a resource based on access control lists and other policies; however secure authorisation is dependant on authentication in order to ensure that the security principle requesting access is who they say they are.

Kerberos ?is the industry standard for authentication (not authorisation), featuring mutual authentication (cf. NTLM, which uses one-way authentication), faster connection times (session tickets are effectively pre-authentication) and delegation (e.g. one server accessing resources on another server on behalf of the original request).

For some reason, Kerberos has always seemed complicated to me, but over the last couple of months I've attended two events where the speakers ( John Howard ?from Microsoft, and John Craddock from? Kimberry Associates ) gave excellent explanations of the Kerberos authentication process, which I have attempted to repeat here for the benefit of others.

Even though it is not a Microsoft standard, Kerberos is the default authentication protocol in Windows 2000, XP and Server 2003, although these all support NTLM for legacy clients.?? RFC 1510 , which defines the Kerberos network authentication service (version 5) actually specifies six messages (five mandatory and one optional), grouped into three pairs of sub-protocols:

  • The authentication service (AS) exchange.
    • KRB_AS_REQ.
    • KRB_AS_REP.
  • The ticket granting service (TGS) exchange.
    • KRB_TGS_REQ.
    • KRB_TGS_REP.
  • The client/server (AP) exchange.
    • KRB_AP_REQ.
    • (KRB_AP_REP).

Central to the Kerberos process is the key distribution center (KDC), which in a Windows implementation is installed on all domain controllers.? All parties within the Kerberos transaction are said to be part of the same realm, which really means that they have a common shared secret in order to communicate with trust.? All messages are encrypted using keys (symmetric - not PKI).? A user key is generated from the logon password, a host key is generated when the computer joins the realm and the KDC is effectively a database of security principles.

The AS exchange takes place at logon and is concerned with giving clients the right to request tickets to access resources (avoiding the need to hold logon factors).? In this process, the client sends an KRB_AS_REQ request to the KDC and, if approved, the KDC will generate a ticket granting ticket (TGT) which is returned to the client as part of the KRB_AS_REP reply.? The TGT allows the client to request service tickets and is analogous to a passport - i.e. it is valid for a certain period after which it expires; however once the TGT has been issued, there is no further use of passwords or other logon factors.

When the client requires access to a resource, the TGS exchange will commence, whereby the client sends a KRB_TGS_REQ service ticket (ST) request to the KDC with the name of the service to which access is required.? The KDC will validate the authentication token within the TGT and if permitted, will return a service ticket which is valid for the requested service as part of the KRB_TGS_REP reply; however at this stage the client is still not authenticated.? The service ticket is only valid between the user and the service but provides mutual authentication and speeds up connection times by eliminating the need for the service to perform authentication.

Only after the client has sent a KRB_AP_REQ request to the service server and there is mutual authentication, will the client be authenticated and allowed access to the requested resource.? The service server may, or may not, send a KRB_AP_REP reply.

At all stages, only the KDC can read the TGT and only the service can read the ST.?

Kerberos

Looking in further detail at the AS exchange, the KRB_AS_REQ includes:

  • Client principal name.
  • Timestamp.
  • Kerberos target principle name (realm).
  • Requested lifetime.

The KDC checks for the existence of the user and constructs an encrypted reply, based on the user's password-based key so that only the real user will be able to decrypt it.? This KRB_AS_REP is in two portions:

  • The first part is encrypted using the user's key, containing:
    • User-TGS key (generated by the KDC).
    • Kerberos target principle name (realm).
    • Ticket lifetime.
  • The second part is the TGT, which is encrypted using a TGS key generated by the KDC so that only the server can open it (even though it is stored by the client for use during further transactions), containing:
    • User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
    • Client principal name.
    • Ticket lifetime.
    • KDC timestamp.
    • Client IP address (taken from the initial KRB_AS_REQ).

Because the KRB_AS_REQ is sent in clear text, pre-authentication may be required to stop spoofing of KRB_AS_REQs - this can be controlled on a per-user basis but is automatically enabled on Windows 2000/2003 KDCs.? Pre-authentication encrypts the KRB_AS_REQ with the user's password-based key and avoids offline dictionary and brute force attacks because the timestamp within the KRB_AS_REQ must match the current time (within an allowed skew, which is 5 minutes by default).

Moving on to the TGS exchange, the service ticket request (KRB_TGS_REQ) contains:

  • Service principal name.
  • Requested lifetime.
  • TGT? (still encrypted with the TGS key).
  • Authenticator (encrypted with the user-TGS key and containing a client timestamp)

The authenticator guarantees that the request originated from the client.

The KRB_TGS_REP service ticket reply is again in two parts:

  • Part one is encrypted with the user-TGS key (taken from the TGT by the KDC) and contains:
    • Service principal name.
    • Ticket lifetime.
    • User service key (encrypted with a user-TGS session key, generated by the KDC).
  • Part two is the service ticket, encrypted using the service-TGS key and contains:
    • User service key (encrypted with a user-TGS session key, generated by the KDC)..
    • Client principal name.
    • Ticket lifetime.
    • KDC timestamp.
    • Client IP address.

Finally, when the client requires access to the service, the AP exchange KRB_AP_REQ contains the service ticket (still encrypted using the service-TGS key) and an authenticator (encrypted with the user-service key).? Kerberos does not define an encryption protocol for the service request.

A client can forward its credentials to a service, forwarding a copy of its TGT so that the service can transparently authenticate on the user's behalf.

So that's how Kerberos works.? The key points to remember are that:

  • AS exchange?occurs at logon, providing the client with a TGT.
  • The TGT allows the client to enter the TGS exchange (which authenticates the client), returning an ST.
  • The ST identifies the authenticated client to a service following which the service will provide access (but only if the client passes the service's own authorisation criteria).
  • Because messages are encrypted, only the KDC can read the TGT and only the service can read the ST.

http://consultingblogs.emc.com/markwilson/archive/2005/06/06/1541.aspx

kerberos


更多文章、技術交流、商務合作、聯系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 欧美久久一区二区三区 | 国产精品精品视频 | 999热视频 | 国产精品无码久久综合网 | 国内在线播放 | 婷婷色吧| 国产成在线人视频免费视频 | 狠狠色噜噜狠狠狠狠888奇米 | 色综合视频一区二区三区 | 久久国产三级精品 | 日韩一级大毛片欧美一级 | 国产欧美成人免费观看视频 | 精品久久久久久久久久久久久久久 | 国产成人8x视频一区二区 | 影音先锋久草 | 国产精品嫩草影院99av视频 | 亚洲视频在线一区二区三区 | 久久精品国产一区二区三区肥胖 | 国产成人永久免费视 | 日韩小视频在线播放 | 国产性生活视频 | 久久精品视频免费播放 | 国产成人精品18 | sss欧美华人整片在线观看 | 天天躁日日躁狠狠躁中文字幕 | 美女超爽久久久久网站 | 日日噜噜夜夜狠狠视频无 | 老司机午夜精品视频在线观看免费 | 成人欧美一区二区三区视频xxx | 久久99精品久久久久久国产越南 | 久久精品中文字幕有码日本 | 在线看日本吃奶孕交 | 日本一级毛片毛片一级毛片 | 四虎在线网站 | 久久亚洲精品一区二区三区浴池 | 成年人性生活免费视频 | 四虎新地址4hu 你懂的 | 亚洲精品久久久中文字幕 | 亚洲欧美另类精品久久久 | 狠狠色综合久久婷婷 | 国产羞羞羞视频在线观看 |