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

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條評論
主站蜘蛛池模板: 欧美亚洲精品一区二三 | 久久久噜久噜久久gif动图 | 亚洲国产天堂 | 91九色精品国产免费 | 一区二区三区免费精品视频 | 精品国产自在久久 | 天天干天天拍天天射 | 日韩精品一区二区三区乱码 | 久久永久免费视频 | 亚洲欧美一区二区三区在线 | 天天操天天干天天摸 | 久草在线视频精品 | 中文字幕五月天 | 天天操人人干 | 成人毛片18女人毛片免费96 | 久久久久久久91精品免费观看 | 奇米网狠狠网 | 激情网站视频 | 亚洲第一页在线播放 | 九九影院最新理论片 | 四虎影院观看视频在线观看 | 免费国产97久久青草 | 深夜影院深a久久 | 羞羞网页 | 精品一区二区三区在线播放 | 久久精品亚洲精品国产色婷 | 久久青草免费91观看 | 99国产成人高清在线视频 | 久久视屏这里只有精品6国产 | 欧美亚洲国产日韩一区二区三区 | 欧美日韩麻豆 | a国产精品 | 日本一级高清片免费 | 偷偷狠狠的日日2020 | 狠狠色噜噜狠狠狠狠98 | 天天干网站 | 成人激情小视频 | 日干夜操 | 四虎免费影院在线播放 | 亚洲欧美另类图片 | 色综合久久综合网欧美综合网 |