Протокол kerberos используется только в системах построенных на windows

From Wikipedia, the free encyclopedia

This article is about the protocol. For other uses, see Kerberos.

Kerberos

Developer(s)	Massachusetts Institute of Technology
Stable release	Version 5, Release 1.20 / 26 May 2022; 8 months ago^[1]
Written in	C
Operating system	Cross-platform
Size	8512k (source code)
Type	Authentication protocol
Website	web.mit.edu/kerberos/

Kerberos () is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed it primarily at a client–server model, and it provides mutual authentication—both the user and the server verify each other’s identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.

Kerberos builds on symmetric-key cryptography and requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication.^[2] Kerberos uses UDP port 88 by default.

The protocol was named after the character Kerberos (or Cerberus) from Greek mythology, the ferocious three-headed guard dog of Hades.^[3]

History and development[edit]

Massachusetts Institute of Technology (MIT) developed Kerberos in 1988 to protect network services provided by Project Athena.^[4]^[5] The protocol is based on the earlier Needham–Schroeder symmetric-key protocol. Several versions of the protocol exist; versions 1–3 occurred only internally at MIT.

Kerberos version 4 was primarily designed by Steve Miller and Clifford Neuman.^[6] Published in the late 1980s, version 4 was also targeted at Project Athena.

Neuman and John Kohl published version 5 in 1993 with the intention of overcoming existing limitations and security problems. Version 5 appeared as RFC 1510, which was then made obsolete by RFC 4120 in 2005.

Authorities in the United States classified Kerberos as «Auxiliary Military Equipment» on the US Munitions List and banned its export because it used the Data Encryption Standard (DES) encryption algorithm (with 56-bit keys). A Kerberos 4 implementation developed at the Royal Institute of Technology in Sweden named KTH-KRB (rebranded to Heimdal at version 5) made the system available outside the US before the US changed its cryptography export regulations (around 2000). The Swedish implementation was based on a limited version called eBones. eBones was based on the exported MIT Bones release (stripped of both the encryption functions and the calls to them) based on version Kerberos 4 patch-level 9.

In 2005, the Internet Engineering Task Force (IETF) Kerberos working group updated specifications. Updates included:

Encryption and Checksum Specifications (RFC 3961).
Advanced Encryption Standard (AES) Encryption for Kerberos 5 (RFC 3962).
A new edition of the Kerberos V5 specification «The Kerberos Network Authentication Service (V5)» (RFC 4120). This version obsoletes RFC 1510, clarifies aspects of the protocol and intended use in a more detailed and clearer explanation.
A new edition of the Generic Security Services Application Program Interface (GSS-API) specification «The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2» (RFC 4121).

MIT makes an implementation of Kerberos freely available, under copyright permissions similar to those used for BSD. In 2007, MIT formed the Kerberos Consortium to foster continued development. Founding sponsors include vendors such as Oracle, Apple Inc., Google, Microsoft, Centrify Corporation and TeamF1 Inc., and academic institutions such as the Royal Institute of Technology in Sweden, Stanford University, MIT, and vendors such as CyberSafe offering commercially supported versions.

Microsoft Windows[edit]

Windows 2000 and later versions use Kerberos as their default authentication method.^[7] Some Microsoft additions to the Kerberos suite of protocols are documented in RFC 3244 «Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols». RFC 4757 documents Microsoft’s use of the RC4 cipher. While Microsoft uses and extends the Kerberos protocol, it does not use the MIT software.

Kerberos is used as the preferred authentication method: in general, joining a client to a Windows domain means enabling Kerberos as the default protocol for authentications from that client to services in the Windows domain and all domains with trust relationships to that domain.^[7]

In contrast, when either client or server or both are not joined to a domain (or not part of the same trusted domain environment), Windows will instead use NTLM for authentication between client and server.^[7]

Internet web applications can enforce Kerberos as an authentication method for domain-joined clients by using APIs provided under SSPI.

Microsoft Windows and Windows Server include setspn, a command-line utility that can be used to read, modify, or delete the Service Principal Names (SPN) for an Active Directory service account.^[8]^[9]

Unix and other operating systems[edit]

Many Unix-like operating systems, including FreeBSD, OpenBSD, Apple’s macOS, Red Hat Enterprise Linux, Oracle’s Solaris, IBM’s AIX, HP-UX and others, include software for Kerberos authentication of users or services. A variety of non-Unix like operating systems such as z/OS, IBM i and OpenVMS also feature Kerberos support. Embedded implementation of the Kerberos V authentication protocol for client agents and network services running on embedded platforms is also available from companies.

Protocol[edit]

Description[edit]

The client authenticates itself to the Authentication Server (AS) which forwards the username to a key distribution center (KDC). The KDC issues a ticket-granting ticket (TGT), which is time stamped and encrypts it using the ticket-granting service’s (TGS) secret key and returns the encrypted result to the user’s workstation. This is done infrequently, typically at user logon; the TGT expires at some point although it may be transparently renewed by the user’s session manager while they are logged in.

When the client needs to communicate with a service on another node (a «principal», in Kerberos parlance), the client sends the TGT to the TGS, which usually shares the same host as the KDC. The service must have already been registered with the TGS with a Service Principal Name (SPN). The client uses the SPN to request access to this service. After verifying that the TGT is valid and that the user is permitted to access the requested service, the TGS issues ticket and session keys to the client. The client then sends the ticket to the service server (SS) along with its service request.

The protocol is described in detail below.

User Client-based Login without Kerberos[edit]

A user enters a username and password on the client machine(s). Other credential mechanisms like pkinit (RFC 4556) allow for the use of public keys in place of a password. The client transforms the password into the key of a symmetric cipher. This either uses the built-in key scheduling, or a one-way hash, depending on the cipher-suite used.
The server receives the username and symmetric cipher and compares it with the data from database. Login was a success if the cipher matches the cipher that is stored for the user.

Client Authentication[edit]

The client sends a cleartext message of the user ID to the AS (Authentication Server) requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.)
The AS checks to see whether the client is in its database. If it is, the AS generates the secret key by hashing the password of the user found at the database (e.g., Active Directory in Windows Server) and sends back the following two messages to the client:
- Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
- Message B: Ticket-Granting-Ticket (TGT, which includes the client ID, client network address, ticket validity period, and the Client/TGS Session Key) encrypted using the secret key of the TGS.
Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client’s secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS’s secret key.) At this point, the client has enough information to authenticate itself to the TGS.

[edit]

When requesting services, the client sends the following messages to the TGS:
- Message C: Composed of the message B (the encrypted TGT using the TGS secret key) and the ID of the requested service.
- Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.
Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the Client/TGS Session Key and the client ID (both are in the TGT). Using this Client/TGS Session Key, the TGS decrypts message D (Authenticator) and compares the client IDs from messages B and D; if they match, the server sends the following two messages to the client:
- Message E: Client-to-server ticket (which includes the client ID, client network address, validity period, and Client/Server Session Key) encrypted using the service’s secret key.
- Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.

Client Service Request[edit]

Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the Service Server (SS). The client connects to the SS and sends the following two messages:
- Message E: From the previous step (the Client-to-server ticket, encrypted using service’s secret key).
- Message G: A new Authenticator, which includes the client ID, timestamp and is encrypted using Client/Server Session Key.
The SS decrypts the ticket (message E) using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and compares client ID from messages E and G, if they match server sends the following message to the client to confirm its true identity and willingness to serve the client:
- Message H: The timestamp found in client’s Authenticator (plus 1 in version 4, but not necessary in version 5^[10]^[11]), encrypted using the Client/Server Session Key.
The client decrypts the confirmation (message H) using the Client/Server Session Key and checks whether the timestamp is correct. If so, then the client can trust the server and can start issuing service requests to the server.
The server provides the requested services to the client.

Drawbacks and limitations[edit]

Kerberos has strict time requirements, which means that the clocks of the involved hosts must be synchronized within configured limits. The tickets have a time availability period, and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail. The default configuration per MIT requires that clock times be no more than five minutes apart. In practice, Network Time Protocol daemons are usually used to keep the host clocks synchronized. Note that some servers (Microsoft’s implementation being one of them) may return a KRB_AP_ERR_SKEW result containing the encrypted server time if both clocks have an offset greater than the configured maximum value. In that case, the client could retry by calculating the time using the provided server time to find the offset. This behavior is documented in RFC 4430.
The administration protocol is not standardized and differs between server implementations. Password changes are described in RFC 3244.
In case of symmetric cryptography adoption (Kerberos can work using symmetric or asymmetric (public-key) cryptography), since all authentications are controlled by a centralized key distribution center (KDC), compromise of this authentication infrastructure will allow an attacker to impersonate any user.
Each network service that requires a different host name will need its own set of Kerberos keys. This complicates virtual hosting and clusters.
Kerberos requires user accounts and services to have a trusted relationship to the Kerberos token server.
The required client trust makes creating staged environments (e.g., separate domains for test environment, pre-production environment and production environment) difficult: Either domain trust relationships need to be created that prevent a strict separation of environment domains, or additional user clients need to be provided for each environment.

Vulnerabilities[edit]

The Data Encryption Standard (DES) cipher can be used in combination with Kerberos, but is no longer an Internet standard because it is weak.^[12] Security vulnerabilities exist in many legacy products that implement Kerberos because they have not been updated to use newer ciphers like AES instead of DES.

In November 2014, Microsoft released a patch (MS14-068) to rectify an exploitable vulnerability in Windows implementation of the Kerberos Key Distribution Center (KDC).^[13] The vulnerability purportedly allows users to «elevate» (and abuse) their privileges, up to Domain level.

References[edit]

^ «Kerberos 5 Release 1.20».
^ RFC 4556, abstract.
^ «Kerberos authentication». IONOS Digitalguide. Retrieved 2022-08-25.
^ Steiner, Jennifer G.; Geer, Daniel E. (21 July 1988). Network Services in the Athena Environment. Proceedings of the Winter 1988 Usenix Conference. CiteSeerX 10.1.1.31.8727.
^ Elizabeth D. Zwicky; Simon Cooper; D. Brent (26 Jun 2000). Building Internet Firewalls: Internet and Web Security. O’Reilly. ISBN 9781565928718.
^ Steiner, Jennifer G.; Neuman, Clifford; Schiller, Jeffrey I. (February 1988). Kerberos: An authentication service for open network systems. Proceedings of the Winter 1988 USENIX Conference. CiteSeerX 10.1.1.112.9002. S2CID 222257682.
^ ^a ^b ^c «What Is Kerberos Authentication?». Microsoft TechNet. Archived from the original on 2016-12-20.
^ Setspn — Windows CMD — SS64.com
^ Setspn | Microsoft Docs
^ C., Neuman; J., Kohl (1993). «The Kerberos Network Authentication Service (V5)». doi:10.17487/RFC1510. Archived from the original on 2016-08-21.
^ Clifford, Neuman; Sam, Hartman; Tom, Yu; Kenneth, Raeburn (2005). «The Kerberos Network Authentication Service (V5)». doi:10.17487/RFC4120. Archived from the original on 2016-08-21.
^ Tom, Yu; Love, Astrand (2012). «Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos». doi:10.17487/RFC6649. Archived from the original on 2015-10-27.
^ Seltzer, Larry. «Details emerge on Windows Kerberos vulnerability — ZDNet». ZDNet. Archived from the original on 2014-11-21.

General

Lynn Root (May 30, 2013) (2 April 2013). «Explain like I’m 5: Kerberos». Blog of Lynn Root.
Microsoft TechNet 2017. «Basic Concepts for the Kerberos Protocol». MSDN Library.
Resource Kit Team. «Microsoft Kerberos (Windows)». MSDN Library.
B. Clifford Neuman; Theodore Ts’o (September 1994). «Kerberos: An Authentication Service for Computer Networks». IEEE Communications. 32 (9): 33–8. doi:10.1109/35.312841. S2CID 45031265.
Kohl, John T.; Neuman, B. Clifford; Ts’o, Theodore Y. (1994). «The Evolution of the Kerberos Authentication System». In Brazier, F. M. T.; Johansen, D (eds.). Distributed open systems. IEEE Computer Society Press. pp. 78–94. CiteSeerX 10.1.1.120.944. ISBN 978-0-8186-4292-0. OCLC 1191406172.
«Kerberos Overview: An Authentication Service for Open Network Systems». Cisco Systems. 19 January 2006. Retrieved 15 August 2012.
«How Kerberos Authentication Works». learn-networking.com. 28 January 2008. Retrieved 15 August 2012.
«What is Kerberos Authentication?: Logon and Authentication». Microsoft TechNet. Retrieved 7 December 2016.

RFCs

RFC 1510 The Kerberos Network Authentication Service (V5) [Obsolete]
RFC 1964 The Kerberos Version 5 GSS-API Mechanism
RFC 3961 Encryption and Checksum Specifications for Kerberos 5
RFC 3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5
RFC 4120 The Kerberos Network Authentication Service (V5) [Current]
RFC 4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
RFC 4537 Kerberos Cryptosystem Negotiation Extension
RFC 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
RFC 4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
RFC 4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows [Obsolete]
RFC 5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP
RFC 5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
RFC 5868 Problem Statement on the Cross-Realm Operation of Kerberos
RFC 5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy
RFC 6111 Additional Kerberos Naming Constraints
RFC 6112 Anonymity Support for Kerberos
RFC 6113 A Generalized Framework for Kerberos Pre-Authentication
RFC 6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol
RFC 6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message
RFC 6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility
RFC 6560 One-Time Password (OTP) Pre-Authentication
RFC 6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos
RFC 6784 Kerberos Options for DHCPv6
RFC 6803 Camellia Encryption for Kerberos 5
RFC 6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals
RFC 6880 An Information Model for Kerberos Version 5
RFC 8009 AES Encryption with HMAC-SHA2 for Kerberos 5

External links[edit]

Wikimedia Commons has media related to Kerberos.

Kerberos Consortium
Kerberos page at MIT website
Kerberos Working Group at IETF website
Kerberos Sequence Diagram Archived 2015-03-26 at the Wayback Machine
Heimdal/Kerberos implementation

Источник

From Wikipedia, the free encyclopedia

This article is about the protocol. For other uses, see Kerberos.

Kerberos

Developer(s)	Massachusetts Institute of Technology
Stable release	Version 5, Release 1.20 / 26 May 2022; 8 months ago^[1]
Written in	C
Operating system	Cross-platform
Size	8512k (source code)
Type	Authentication protocol
Website	web.mit.edu/kerberos/

The protocol was named after the character Kerberos (or Cerberus) from Greek mythology, the ferocious three-headed guard dog of Hades.^[3]

History and development[edit]

Kerberos version 4 was primarily designed by Steve Miller and Clifford Neuman.^[6] Published in the late 1980s, version 4 was also targeted at Project Athena.

In 2005, the Internet Engineering Task Force (IETF) Kerberos working group updated specifications. Updates included:

Encryption and Checksum Specifications (RFC 3961).
Advanced Encryption Standard (AES) Encryption for Kerberos 5 (RFC 3962).
A new edition of the Kerberos V5 specification «The Kerberos Network Authentication Service (V5)» (RFC 4120). This version obsoletes RFC 1510, clarifies aspects of the protocol and intended use in a more detailed and clearer explanation.
A new edition of the Generic Security Services Application Program Interface (GSS-API) specification «The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2» (RFC 4121).

Microsoft Windows[edit]

Internet web applications can enforce Kerberos as an authentication method for domain-joined clients by using APIs provided under SSPI.

Unix and other operating systems[edit]

Protocol[edit]

Description[edit]

The protocol is described in detail below.

User Client-based Login without Kerberos[edit]

A user enters a username and password on the client machine(s). Other credential mechanisms like pkinit (RFC 4556) allow for the use of public keys in place of a password. The client transforms the password into the key of a symmetric cipher. This either uses the built-in key scheduling, or a one-way hash, depending on the cipher-suite used.
The server receives the username and symmetric cipher and compares it with the data from database. Login was a success if the cipher matches the cipher that is stored for the user.

Client Authentication[edit]

The client sends a cleartext message of the user ID to the AS (Authentication Server) requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.)
The AS checks to see whether the client is in its database. If it is, the AS generates the secret key by hashing the password of the user found at the database (e.g., Active Directory in Windows Server) and sends back the following two messages to the client:
- Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
- Message B: Ticket-Granting-Ticket (TGT, which includes the client ID, client network address, ticket validity period, and the Client/TGS Session Key) encrypted using the secret key of the TGS.
Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client’s secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS’s secret key.) At this point, the client has enough information to authenticate itself to the TGS.

[edit]

When requesting services, the client sends the following messages to the TGS:
- Message C: Composed of the message B (the encrypted TGT using the TGS secret key) and the ID of the requested service.
- Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.
Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the Client/TGS Session Key and the client ID (both are in the TGT). Using this Client/TGS Session Key, the TGS decrypts message D (Authenticator) and compares the client IDs from messages B and D; if they match, the server sends the following two messages to the client:
- Message E: Client-to-server ticket (which includes the client ID, client network address, validity period, and Client/Server Session Key) encrypted using the service’s secret key.
- Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.

Client Service Request[edit]

Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the Service Server (SS). The client connects to the SS and sends the following two messages:
- Message E: From the previous step (the Client-to-server ticket, encrypted using service’s secret key).
- Message G: A new Authenticator, which includes the client ID, timestamp and is encrypted using Client/Server Session Key.
The SS decrypts the ticket (message E) using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and compares client ID from messages E and G, if they match server sends the following message to the client to confirm its true identity and willingness to serve the client:
- Message H: The timestamp found in client’s Authenticator (plus 1 in version 4, but not necessary in version 5^[10]^[11]), encrypted using the Client/Server Session Key.
The client decrypts the confirmation (message H) using the Client/Server Session Key and checks whether the timestamp is correct. If so, then the client can trust the server and can start issuing service requests to the server.
The server provides the requested services to the client.

Drawbacks and limitations[edit]

Kerberos has strict time requirements, which means that the clocks of the involved hosts must be synchronized within configured limits. The tickets have a time availability period, and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail. The default configuration per MIT requires that clock times be no more than five minutes apart. In practice, Network Time Protocol daemons are usually used to keep the host clocks synchronized. Note that some servers (Microsoft’s implementation being one of them) may return a KRB_AP_ERR_SKEW result containing the encrypted server time if both clocks have an offset greater than the configured maximum value. In that case, the client could retry by calculating the time using the provided server time to find the offset. This behavior is documented in RFC 4430.
The administration protocol is not standardized and differs between server implementations. Password changes are described in RFC 3244.
In case of symmetric cryptography adoption (Kerberos can work using symmetric or asymmetric (public-key) cryptography), since all authentications are controlled by a centralized key distribution center (KDC), compromise of this authentication infrastructure will allow an attacker to impersonate any user.
Each network service that requires a different host name will need its own set of Kerberos keys. This complicates virtual hosting and clusters.
Kerberos requires user accounts and services to have a trusted relationship to the Kerberos token server.
The required client trust makes creating staged environments (e.g., separate domains for test environment, pre-production environment and production environment) difficult: Either domain trust relationships need to be created that prevent a strict separation of environment domains, or additional user clients need to be provided for each environment.

Vulnerabilities[edit]

References[edit]

^ «Kerberos 5 Release 1.20».
^ RFC 4556, abstract.
^ «Kerberos authentication». IONOS Digitalguide. Retrieved 2022-08-25.
^ Steiner, Jennifer G.; Geer, Daniel E. (21 July 1988). Network Services in the Athena Environment. Proceedings of the Winter 1988 Usenix Conference. CiteSeerX 10.1.1.31.8727.
^ Elizabeth D. Zwicky; Simon Cooper; D. Brent (26 Jun 2000). Building Internet Firewalls: Internet and Web Security. O’Reilly. ISBN 9781565928718.
^ Steiner, Jennifer G.; Neuman, Clifford; Schiller, Jeffrey I. (February 1988). Kerberos: An authentication service for open network systems. Proceedings of the Winter 1988 USENIX Conference. CiteSeerX 10.1.1.112.9002. S2CID 222257682.
^ ^a ^b ^c «What Is Kerberos Authentication?». Microsoft TechNet. Archived from the original on 2016-12-20.
^ Setspn — Windows CMD — SS64.com
^ Setspn | Microsoft Docs
^ C., Neuman; J., Kohl (1993). «The Kerberos Network Authentication Service (V5)». doi:10.17487/RFC1510. Archived from the original on 2016-08-21.
^ Clifford, Neuman; Sam, Hartman; Tom, Yu; Kenneth, Raeburn (2005). «The Kerberos Network Authentication Service (V5)». doi:10.17487/RFC4120. Archived from the original on 2016-08-21.
^ Tom, Yu; Love, Astrand (2012). «Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos». doi:10.17487/RFC6649. Archived from the original on 2015-10-27.
^ Seltzer, Larry. «Details emerge on Windows Kerberos vulnerability — ZDNet». ZDNet. Archived from the original on 2014-11-21.

General

Lynn Root (May 30, 2013) (2 April 2013). «Explain like I’m 5: Kerberos». Blog of Lynn Root.
Microsoft TechNet 2017. «Basic Concepts for the Kerberos Protocol». MSDN Library.
Resource Kit Team. «Microsoft Kerberos (Windows)». MSDN Library.
B. Clifford Neuman; Theodore Ts’o (September 1994). «Kerberos: An Authentication Service for Computer Networks». IEEE Communications. 32 (9): 33–8. doi:10.1109/35.312841. S2CID 45031265.
Kohl, John T.; Neuman, B. Clifford; Ts’o, Theodore Y. (1994). «The Evolution of the Kerberos Authentication System». In Brazier, F. M. T.; Johansen, D (eds.). Distributed open systems. IEEE Computer Society Press. pp. 78–94. CiteSeerX 10.1.1.120.944. ISBN 978-0-8186-4292-0. OCLC 1191406172.
«Kerberos Overview: An Authentication Service for Open Network Systems». Cisco Systems. 19 January 2006. Retrieved 15 August 2012.
«How Kerberos Authentication Works». learn-networking.com. 28 January 2008. Retrieved 15 August 2012.
«What is Kerberos Authentication?: Logon and Authentication». Microsoft TechNet. Retrieved 7 December 2016.

RFCs

RFC 1510 The Kerberos Network Authentication Service (V5) [Obsolete]
RFC 1964 The Kerberos Version 5 GSS-API Mechanism
RFC 3961 Encryption and Checksum Specifications for Kerberos 5
RFC 3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5
RFC 4120 The Kerberos Network Authentication Service (V5) [Current]
RFC 4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
RFC 4537 Kerberos Cryptosystem Negotiation Extension
RFC 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
RFC 4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
RFC 4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows [Obsolete]
RFC 5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP
RFC 5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
RFC 5868 Problem Statement on the Cross-Realm Operation of Kerberos
RFC 5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy
RFC 6111 Additional Kerberos Naming Constraints
RFC 6112 Anonymity Support for Kerberos
RFC 6113 A Generalized Framework for Kerberos Pre-Authentication
RFC 6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol
RFC 6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message
RFC 6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility
RFC 6560 One-Time Password (OTP) Pre-Authentication
RFC 6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos
RFC 6784 Kerberos Options for DHCPv6
RFC 6803 Camellia Encryption for Kerberos 5
RFC 6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals
RFC 6880 An Information Model for Kerberos Version 5
RFC 8009 AES Encryption with HMAC-SHA2 for Kerberos 5

External links[edit]

Wikimedia Commons has media related to Kerberos.

Kerberos Consortium
Kerberos page at MIT website
Kerberos Working Group at IETF website
Kerberos Sequence Diagram Archived 2015-03-26 at the Wayback Machine
Heimdal/Kerberos implementation

Источник

Аннотация: В данной лекции рассматриваются технические меры повышения защищенности систем.
В теоретической части изучаются методы, лежащие в основе соответствующих средств и механизмов в аспектах идентификации и аутентификации. Приводятся конкретные настройки операторов.

В данном разделе будут рассмотрены некоторые технические меры повышения защищенности систем. Выбор рассматриваемых мер обусловлен возможностью их реализации встроенными средствами операционных систем семейства Microsoft Windows. Соответственно, уровень защищенности может быть повышен без дополнительных затрат на специализированные средства защиты.

В теоретической части курса будут методы, лежащие в основе соответствующих средств и механизмов. В лабораторных работах рассматриваются конкретные настройки операционных систем.

Рассматриваемые вопросы можно разделить на две группы:

вопросы, связанные с идентификацией и аутентификацией пользователей;
защита передаваемых сообщений.

Идентификация и аутентификация

Идентификация — присвоение пользователям идентификаторов (уникальных имен или меток) под которыми система «знает» пользователя. Кроме идентификации пользователей, может проводиться идентификация групп пользователей, ресурсов ИС и т.д. Идентификация нужна и для других системных задач, например, для ведения журналов событий. В большинстве случаев идентификация сопровождается аутентификацией. Аутентификация — установление подлинности — проверка принадлежности пользователю предъявленного им идентификатора. Например, в начале сеанса работы в ИС пользователь вводит имя и пароль. На основании этих данных система проводит идентификацию (по имени пользователя) и аутентификацию (сопоставляя имя пользователя и введенный пароль).

Система идентификации и аутентификации является одним из ключевых элементов инфраструктуры защиты от несанкционированного доступа (НСД) любой информационной системы. В соответствии с рассмотренной ранее моделью многоуровневой защиты, аутентификация пользователя компьютера относится к уровню защиты узлов.

Обычно выделяют 3 группы методов аутентификации.

Аутентификация по наличию у пользователя уникального объекта заданного типа. Иногда этот класс методов аутентификации называют по-английски «I have» («у меня есть»). В качестве примера можно привести аутентификацию с помощью смарт-карт или электронных USB-ключей.
Аутентификация, основанная на том, что пользователю известна некоторая конфиденциальная информация — «I know» («я знаю»). Например, аутентификация по паролю. Более подробно парольные системы рассматриваются далее в этом разделе.
Аутентификация пользователя по его собственным уникальным характеристикам — «I am» («я есть»). Эти методы также называются биометрическими.

Нередко используются комбинированные схемы аутентификации, объединяющие методы разных классов. Например, двухфакторная аутентификация — пользователь предъявляет системе смарт-карту и вводит пин-код для ее активации.

Наиболее распространенными на данный момент являются парольные системы аутентификации. У пользователя есть идентификатор и пароль, т.е. секретная информация, известная только пользователю (и возможно — системе), которая используется для прохождения аутентификации.

В зависимости от реализации системы, пароль может быть одноразовым или многоразовым. Операционные системы, как правило, проводят аутентификацию с использованием многоразовых паролей. Совокупность идентификатора, пароля и, возможно, дополнительной информации, служащей для описания пользователя составляют учетную запись пользователя.

Если нарушитель узнал пароль легального пользователя, то он может, например, войти в систему под его учетной записью и получить доступ к конфиденциальным данным. Поэтому безопасности паролей следует уделять особой внимание.

Как отмечалось при рассмотрении стандарта ISO 17799, рекомендуется, чтобы пользователи системы подписывали документ о сохранении конфиденциальности пароля. Но нарушитель также может попытаться подобрать пароль, угадать его, перехватить и т.д. Рассмотрим некоторые рекомендации по администрированию парольной системы, позволяющие снизить вероятность реализации подобных угроз.

Задание минимальной длины используемых в системе паролей. Это усложняет атаку путем подбора паролей. Как правило, рекомендуют устанавливать минимальную длину в 6-8 символов.
Установка требования использовать в пароле разные группы символов — большие и маленькие буквы, цифры, специальные символы. Это также усложняет подбор.
Периодическая проверка администраторами безопасности качества используемых паролей путем имитации атак, таких как подбор паролей «по словарю» (т.е. проверка на использование в качестве пароля слов естественного языка и простых комбинаций символов, таких как «1234»).
Установка максимального и минимального сроков жизни пароля, использование механизма принудительной смены старых паролей.
Ограничение числа неудачных попыток ввода пароля (блокирование учетной записи после заданного числа неудачных попыток войти в систему).
Ведение журнала истории паролей, чтобы пользователи, после принудительной смены пароля, не могли вновь выбрать себе старый, возможно скомпрометированный пароль.

Современные операционные системы семейства Windows позволяют делать установки, автоматически контролирующие выполнение требований 1,2,4-6. При использовании домена Windows, эти требования можно распространить на все компьютеры, входящие в домен и таким образом повысить защищенность всей сети.

Но при внедрении новых механизмов защиты могут появиться и нежелательные последствия. Например, требования «сложности» паролей могут поставить в тупик недостаточно подготовленного пользователя. В данном случае потребуется объяснить, что с точки зрения операционной системы Windows надежный пароль содержит 3 из 4 групп символов (большие буквы, малые буквы, цифры, служебные знаки). Аналогичным образом, надо подготовить пользователей и к внедрению блокировки учетных записей после нескольких неудачных попыток ввода пароля. Требуется объяснить пользователям, что происходит, а сами правила блокировки должны быть хорошо продуманы. Например, если высока вероятность того, что пользователь заблокирует свою запись в период отсутствия администратора, лучше ставить блокировку не насовсем, а на какой-то срок (30 минут, час и т.д.).

Это приводит к тому, что должна быть разработана политика управления паролями, сопровождающие ее документы, а потом уже проведено внедрение.

При использовании ОС семейства Windows, выявить учетные записи со слабыми или отсутствующими паролями можно, например, с помощью утилиты Microsoft Baseline Security Analyzer. Она же позволяет выявить и другие ошибки администрирования. Вопросам использования этой утилиты, а также настройке политики паролей посвящена лабораторная работа № 3.

Протокол Kerberos

Протокол Kerberos был разработан в Массачусетском технологическом институте в середине 1980-х годов и сейчас является фактическим стандартом системы централизованной аутентификации и распределения ключей симметричного шифрования. Поддерживается операционными системами семейства Unix, Windows (начиная с Windows‘2000), есть реализации для Mac OS.

В сетях Windows (начиная с Windows‘2000 Serv.) аутентификация по протоколу Kerberos v.5 (RFC 1510) реализована на уровне доменов. Kerberos является основным протоколом аутентификации в домене, но в целях обеспечения совместимости c с предыдущими версиями, также поддерживается протокол NTLM.

Перед тем, как рассмотреть порядок работы Kerberos, разберем зачем он изначально разрабатывался. Централизованное распределение ключей симметричного шифрования подразумевает, что у каждого абонента сети есть только один основной ключ, который используется для взаимодействия с центром распределения ключей (сервером ключей). Чтобы получить ключ шифрования для защиты обмена данными с другим абонентом, пользователь обращается к серверу ключей, который назначает этому пользователю и соответствующему абоненту сеансовый симметричный ключ.

Протокол Kerberos обеспечивает распределение ключей симметричного шифрования и проверку подлинности пользователей, работающих в незащищенной сети. Реализация Kerberos — это программная система, построенная по архитектуре «клиент-сервер«. Клиентская часть устанавливается на все компьютеры защищаемой сети, кроме тех, на которые устанавливаются компоненты сервера Kerberos. В роли клиентов Kerberos могут, в частности, выступать и сетевые серверы (файловые серверы, серверы печати и т.д.).

Серверная часть Kerberos называется центром распределения ключей (англ. Key Distribution Center, сокр. KDC) и состоит из двух компонент:

сервер аутентификации (англ. Authentication Server, сокр. AS);
сервер выдачи разрешений (англ. Ticket Granting Server, сокр. TGS).

Каждому субъекту сети сервер Kerberos назначает разделяемый с ним ключ симметричного шифрования и поддерживает базу данных субъектов и их секретных ключей. Схема функционирования протокола Kerberos представлена на
рис.
5.1.

Рис.
5.1.
Протокол Kerberos

Пусть клиент C собирается начать взаимодействие с сервером SS (англ. Service Server — сервер, предоставляющий сетевые сервисы). В несколько упрощенном виде, протокол предполагает следующие шаги [19, 20]:

C->AS: {c}.

Клиент C посылает серверу аутентификации AS свой идентификатор c (идентификатор передается открытым текстом).
AS->C: {{TGT}K_{AS_TGS}, K_{C_TGS}}K_C,

где:
- K_C — основной ключ C ;
- K_{C_TGS} — ключ, выдаваемый C для доступа к серверу выдачи разрешений TGS ;
- {TGT} — Ticket Granting Ticket — билет на доступ к серверу выдачи разрешений
{TGT}={c,tgs,t₁,p₁, K_{C_TGS}}, где tgs — идентификатор сервера выдачи разрешений, t₁ — отметка времени, p₁ — период действия билета.

Запись ${ cdot } K_{X}$ здесь и далее означает, что содержимое фигурных скобок зашифровано на ключе K_X.

На этом шаге сервер аутентификации AS, проверив, что клиент C имеется в его базе, возвращает ему билет для доступа к серверу выдачи разрешений и ключ для взаимодействия с сервером выдачи разрешений. Вся посылка зашифрована на ключе клиента C. Таким образом, даже если на первом шаге взаимодействия идентификатор с послал не клиент С, а нарушитель X, то полученную от AS посылку X расшифровать не сможет.

Получить доступ к содержимому билета TGT не может не только нарушитель, но и клиент C, т.к. билет зашифрован на ключе, который распределили между собой сервер аутентификации и сервер выдачи разрешений.
C->TGS: {TGT}K_{AS_TGS}, {Aut₁} K_{C_TGS}, {ID}

где {Aut₁} — аутентификационный блок — Aut₁ = {с,t₂}, t₂ — метка времени; ID — идентификатор запрашиваемого сервиса (в частности, это может быть идентификатор сервера SS ).

Клиент C на этот раз обращается к серверу выдачи разрешений ТGS. Он пересылает полученный от AS билет, зашифрованный на ключе K_{AS_TGS}, и аутентификационный блок, содержащий идентификатор c и метку времени, показывающую, когда была сформирована посылка.Сервер выдачи разрешений расшифровывает билет TGT и получает из него информацию о том, кому был выдан билет, когда и на какой срок, ключ шифрования, сгенерированный сервером AS для взаимодействия между клиентом C и сервером TGS. С помощью этого ключа расшифровывается аутентификационный блок. Если метка в блоке совпадает с меткой в билете, это доказывает, что посылку сгенерировал на самом деле С (ведь только он знал ключ K_{C_TGS} и мог правильно зашифровать свой идентификатор). Далее делается проверка времени действия билета и времени отправления посылки 3 ).
Если проверка проходит и действующая в системе политика позволяет клиенту С обращаться к клиенту SS, тогда выполняется шаг 4 ).
TGS->C: {{TGS}K_{TGS_SS},K_{C_SS}}K_{C_TGS},

где K_{C_SS} — ключ для взаимодействия C и SS, {TGS} — Ticket Granting Service — билет для доступа к SS (обратите внимание, что такой же аббревиатурой в описании протокола обозначается и сервер выдачи разрешений). {TGS} ={с,ss,t₃,p₂, K_{C_SS} }.

Сейчас сервер выдачи разрешений TGS посылает клиенту C ключ шифрования и билет, необходимые для доступа к серверу SS. Структура билета такая же, как на шаге 2): идентификатор того, кому выдали билет; идентификатор того, для кого выдали билет; отметка времени; период действия; ключ шифрования.
C->SS: {TGS}K_{TGS_SS}, {Aut₂} K_{C_SS}

где Aut₂={c,t₄}.

Клиент C посылает билет, полученный от сервера выдачи разрешений, и свой аутентификационный блок серверу SS, с которым хочет установить сеанс защищенного взаимодействия. Предполагается, что SS уже зарегистрировался в системе и распределил с сервером TGS ключ шифрования K_{TGS_SS}. Имея этот ключ, он может расшифровать билет, получить ключ шифрования K_{C_SS} и проверить подлинность отправителя сообщения.
SS->C: {t₄+1}K_{C_SS}

Смысл последнего шага заключается в том, что теперь уже SS должен доказать C свою подлинность. Он может сделать это, показав, что правильно расшифровал предыдущее сообщение. Вот поэтому, SS берет отметку времени из аутентификационного блока C, изменяет ее заранее определенным образом (увеличивает на 1), шифрует на ключе K_{C_SS} и возвращает C.

Если все шаги выполнены правильно и все проверки прошли успешно, то стороны взаимодействия C и SS, во-первых, удостоверились в подлинности друг друга, а во-вторых, получили ключ шифрования для защиты сеанса связи — ключ K_{C_SS}.

Нужно отметить, что в процессе сеанса работы клиент проходит шаги 1) и 2) только один раз. Когда нужно получить билет на доступ к другому серверу (назовем его SS1 ), клиент С обращается к серверу выдачи разрешений TGS с уже имеющимся у него билетом, т.е. протокол выполняется начиная с шага 3).

При использовании протокола Kerberos компьютерная сеть логически делится на области действия серверов Kerberos. Kerberos-область — это участок сети, пользователи и серверы которого зарегистрированы в базе данных одного сервера Kerberos (или в одной базе, разделяемой несколькими серверами). Одна область может охватывать сегмент локальной сети, всю локальную сеть или объединять несколько связанных локальных сетей. Схема взаимодействия между Kerberos-областями представлена на
рис.
5.2.

Для взаимодействия между областями, должна быть осуществлена взаимная регистрация серверов Kerberos, в процессе которой сервер выдачи разрешений одной области регистрируется в качестве клиента в другой области (т.е. заносится в базу сервера аутентификации и разделяет с ним ключ).

После установки взаимных соглашений, клиент из области 1 (пусть это будет K₁₁ ) может установить сеанс взаимодействия с клиентом из области 2 (например, К₂₁ ). Для этого K₁₁ должен получить у своего сервера выдачи разрешений билет на доступ к Kerberos-серверу, с клиентом которого он хочет установить взаимодействие (т.е. серверу Kerberos KDC2). Полученный билет содержит отметку о том, в какой области зарегистрирован владелец билета. Билет шифруется на ключе, разделенном между серверами KDC1 и KDC2. При успешной расшифровке билета, удаленный Kerberos-сервер может быть уверен, что билет выдан клиенту Kerberos-области, с которой установлены доверительные отношения. Далее протокол работает как обычно.

Рис.
5.2.
Взаимодействие между Kerberos-областями

Кроме рассмотренных, Kerberos предоставляет еще ряд дополнительных возможностей. Например, указанный в структуре билета параметр p (период времени) задается парой значений «время начала действия» — «время окончания действия», что позволяет получать билеты отложенного действия.

Имеется тип билета «с правом передачи», что позволяет, например, серверу выполнять действия от имени обратившегося к нему клиента.

Два слова об аутентификации. Если Kerberos — протокол распределения ключей, корректно ли использовать его для аутентификации?! Но как отмечалось выше, если все стадии протокола прошли успешно, взаимодействующие стороны не только распределили ключ, но и убедились в подлинности друг друга, иными словами — аутентифицировали друг друга.

Что касается реализации протокола Kerberos в Windows, то надо отметить следующее.

Ключ пользователя генерируется на базе его пароля. Таким образом, при использовании слабых паролей эффект от надежной защиты процесса аутентификации будет сведен к нулю.
В роли Kerberos-серверов выступают контроллеры домена, на каждом из которых должна работать служба Kerberos Key Distribution Center (KDC). Роль хранилища информации о пользователях и паролях берет на себя служба каталога Active Directory. Ключ, который разделяют между собой сервер аутентификации и сервер выдачи разрешений формируется на основе пароля служебной учетной записи krbtgt — эта запись автоматически создается при организации домена и всегда заблокирована.
Microsoft в своих ОС использует расширение Kerberos для применения криптографии с открытым ключом. Это позволяет осуществлять регистрацию в домене и с помощью смарт-карт, хранящих ключевую информацию и цифровой сертификат пользователя.
Использование Kerberos требует синхронизации внутренних часов компьютеров, входящих в домен Windows.

Для увеличения уровня защищенности процесса аутентификации пользователей, рекомендуется отключить использование менее надежного протокола NTLM и оставить только Kerberos (если использования NTLM не требуют устаревшие клиентские ОС).

Кроме того, рекомендуется запретить администраторским учетным записям получать билеты «с правом передачи» (это убережет от некоторых угроз, связанных автоматическим запуском приложений от имени таких записей).

Источник

В прошлой части нашего цикла мы рассмотрели работу протоколов семейства NTLM, отметив ряд их существенных недостатков, которые невозможно решить в рамках протокола. Поэтому вместе с Active Directory на смену им пришел более совершенный протокол Kerberos, который продолжает успешно применяться до сих пор. В данном материале мы рассмотрим общие принципы функционирования данного протокола, что позволит получить начальные знания в этой области самым широким массам читателей.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.

Основным недостатком протокола NTLM служит то, что он не предусматривает взаимную аутентификацию клиента и сервера, это во многом обусловлено тем, что протокол изначально разрабатывался для небольших сетей, где все узлы считаются легитимными. Несмотря на то, что в последних версиях протокола сделаны серьезные улучшения безопасности, но направлены они в основном на усиление криптографической стойкости, не устраняя принципиальных недостатков.

В доменных сетях протоколы NTLM вызывают повышенную нагрузку на контроллеры домена, так как всегда обращаются к ним для аутентификации пользователя. При этом также отсутствует взаимная идентификация узлов и существует возможность накопления пакетов для последующего анализа и атаки с их помощью.

В отличии от NTLM Kerberos изначально разрабатывался с условием, что первичная передача информации будет производиться в открытых сетях, где она может быть перехвачена и модифицирована. Также протокол предусматривает обязательную взаимную аутентификацию клиента и сервера, а взаимное доверие обеспечивает единый удостоверяющий центр, который обеспечивает централизованную выдачу ключей.

Перед тем как продолжить, следует прийти к соглашению по поводу используемых в статье терминов. Так под термином клиент будет рассматриваться любой узел сети, обращающийся к любому иному узлу — серверу — с целью доступа к любому из его ресурсов.

Основой инфраструктуры Kerberos является Центр распространения ключей (Key Distribution Center, KDC), который является доверенным центром аутентификации для всех участников сети (принципалов). Область Kerberos (Realm) — пространство имен для которых данный KDC является доверенным, как правило это область ограниченная пространством имен домена DNS, в Active Directory область Kerberos совпадает с доменом AD. Область Kerberos записывается в виде соответствующего ему доменного имени DNS, но в верхнем регистре. Принципалом или учетной записью Kerberos является любой участник отношений безопасности: учетная запись пользователя, компьютер, сетевая служба и т.д.

Центр распространения ключей содержит долговременные ключи для всех принципалов, в большинстве практических реализаций Kerberos долговременные ключи формируются на основе пароля и являются так называемым «секретом для двоих». С помощью такого секрета каждый из его хранителей может легко удостовериться, что имеет дело со своим напарником. При этом долговременные ключи не при каких обстоятельствах не передаются по сети и располагаются в защищенных хранилищах (KDC), либо сохраняются только на время сеанса.

Для принципалов, которые не являются членами домена AD, могут использоваться специальные keytab-файлы, которые содержат сведения о клиенте, домене и его долговременный ключ. В целях безопасности keytab-файл нельзя передавать по незащищенным каналам, а также следует обеспечить его безопасное хранение у принципала.

В структуре Active Directory центр распространения ключей располагается на контроллере домена, но не следует путать эти две сущности, каждая из них является самостоятельной и выполняет свои функции. Так Kerberos отвечает только за аутентификацию клиентов, т.е. удостоверяет, что некто является именно тем, за кого себя выдает. Авторизацией, т.е. контролем прав доступа, занимается контроллер домена, в свою очередь разрешая или ограничивая доступ клиента к тому или иному ресурсу.

Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.

Желая пройти проверку подлинности в сети, клиент передает KDC открытым текстом свое имя, имя домена и метку времени (текущее время клиента), зашифрованное долговременным ключом клиента. Метка времени в данном случае выступает в роли аутентификатора — определенной последовательности данных, при помощи которой узлы могут подтвердить свою подлинность.

Получив эти данные KDC извлекает долговременный ключ данного пользователя и расшифровывает метку времени, которую сравнивает с собственным текущим временем, если оно отличается не более чем на 5 минут (значение по умолчанию), то метка считается действительной. Эта проверка является дополнительной защитой, так как не позволяет использовать для атаки перехваченные и сохраненные данные.

Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.

Клиент в первую очередь расшифровывает сеансовый ключ, затем при помощи этого ключа метку времени и сравнивает ее с той, что он отправил KDC, если метка совпала, значит KDC тот, за кого себя выдает, так как расшифровать метку времени мог только тот, кто обладает долговременным ключом. В этом случае клиент принимает TGT и помещает его в свое хранилище.

Чтобы лучше понять этот механизм приведем небольшой пример. Если злоумышленник перехватил посланный KDC запрос, то он может на основе открытых данных послать клиенту поддельный сеансовый ключ и TGT, но не сможет расшифровать метку времени, так как не обладает долговременным ключом. Точно также, он может перехватить отправленные клиенту TGT и сеансовый ключ, но также не сможет расшифровать последний, не имея долговременного ключа. Перехватить долговременный ключ он не может, так как они по сети не передаются.

Успешно пройдя аутентификацию, клиент будет располагать сеансовым ключом, которым впоследствии он будет шифровать все сообщения для KDC и билетом на получение билета (TGT).

Теперь рассмотрим ситуацию, когда клиент хочет обратиться к серверу.

Для этого он снова обращается к KDC и посылает ему билет на получение билета, зашифрованную сеансовым ключом метку времени и имя сервера. Прежде всего KDC расшифровывает предоставленный ему TGT и извлекает оттуда данные о клиенте и его сеансовый ключ, обратите внимание, что сам KDC сеансовые ключи не хранит. Затем сеансовым ключом он расшифровывает данные от клиента и сравнивает метку времени с текущим. Если расхождения нет, то KDC формирует общий сеансовый ключ для клиента и сервера.

Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.

Таким образом клиент получает сессионный ключ для работы с сервером и сессионный билет. Получить содержимое билета, как и TGT, он не может, так как не располагает нужными долговременными ключами.

Теперь, имея новый ключ и билет, клиент обращается непосредственно к серверу:

Он предъявляет ему сеансовый билет и метку времени, зашифрованную сессионным ключом. Сервер расшифровывает билет, извлекает оттуда свой экземпляр ключа и сведения о клиенте, затем расшифровывает метку времени и сравнивает ее с текущим. Если все нормально, то он шифрует полученную метку своим экземпляром сессионного ключа и посылает назад клиенту. Клиент расшифровывает ее своим сеансовым ключом и сравнивает с тем, что было послано серверу. Совпадение данных свидетельствует о том, что сервер тот, за кого себя выдает.

Как можно заметить, сеансовые ключи никогда не передаются по незащищенным каналам и не передаются узлам, с которыми нет доверительных отношений. У KDC нет доверительных отношений с сервером, и он не может передать ему сессионный ключ, так как нет уверенности, что ключ будет передан кому надо. Но у него есть долговременный ключ этого сервера, которым он шифрует билет, это гарантирует, что никто иной не прочитает его содержимое и не получит сессионный ключ.

Клиент имеет билет и свой экземпляр ключа, доступа к содержимому билета у него нет. Он передает билет серверу и ждет ответ в виде посланной метки времени. Сервера, как и KDC, не хранят сеансовые ключи, а, следовательно, расшифровать метку времени сервер может только в том случае, если сможет расшифровать билет и получить оттуда сеансовый ключ, для чего нужно обладать долговременным ключом. Получив ответ и расшифровав его, клиент может удостоверить подлинность сервера, так как прочитать аутентификатор и извлечь из него метку времени сервер сможет только при условии расшифровки билета и получения оттуда сеансового ключа.

Несмотря на то, что мы рассмотрели крайне упрощенную модель протокола Kerberos, надеемся, что данная статья поможет устранить пробелы и получить первоначальные знания, которые затем можно расширить и углубить уже осмысленно подойдя к прочтению более серьезных материалов.

Источник

Любому администратору Windows, разумеется, не раз приходилось иметь дело с двумя основными протоколами аутентификации в среде Windows: Kerberos и NTLM. Данная статья посвящена тому, как Kerberos и NTLM поддерживаются в системах Windows 7 и Windows Server 2008 R2. Но для начала я хотел бы остановиться на ключевых различиях между этими протоколами.

Разработчики Microsoft впервые реализовали протокол Kerberos в системе Windows 2000. Протокол NTLM вошел в употребление гораздо раньше, во времена Windows NT. Kerberos представляет собой протокол аутентификации, базирующийся на концепции доверенной третьей стороны trusted third party (TTP), тогда как в основу протокола NTLM положен механизм «запрос-ответ» (challenge/response). Более подробно различия между двумя протоколами описаны в таблице.

При обмене данными в ходе аутентификации с использованием протокола NTLM серверный ресурс (например, файл-сервер) генерирует запрос, который направляется клиенту. Клиент формирует NTLM-ответ, включающий хеш пароля пользователя, а сервер проверяет правильность этого ответа. Если клиент использует локальную учетную запись, сервер проверяет ответ пользователя с помощью хеша пароля пользователя, который хранится в локальной базе данных диспетчера учетных записей безопасности Security Account Manager (SAM). Если же клиент применяет доменную учетную запись, сервер передает ответ для проверки контроллеру домена, ибо только контроллеры доменов хранят в своих базах данных Active Directory (AD) копии хешей пользовательских паролей.

В системе Windows Kerberos доверенной третьей стороной является контроллер домена Windows 2000 или более поздней версии, на котором размещается служба центра распространения ключей Kerberos Key Distribution Center (KDC). Центр KDC облегчает процедуру аутентификации между оснащенным средствами Kerberos клиентом и сервером. Служба KDC автоматически устанавливается как компонент системы AD и состоит из двух подсистем: службы аутентификации Authentication Service (AS) и службы предоставления билетов Ticket-Granting Service (TGS).

Когда пользователь регистрируется в домене Windows с использованием протокола Kerberos, клиент Windows первым делом проверяет подлинность пользователя на контроллере домена с помощью пользовательского пароля. В то же время клиент запрашивает билет на выдачу билета Ticket Grant Ticket (TGT) в службу аутентификации. TGT можно рассматривать как временный пароль (по умолчанию время его жизни составляет 8 часов), который будет заменять пароль пользователя в последующих запросах на аутентификацию. Когда пользователю нужно будет обратиться к серверному ресурсу, клиент представит TGT на выдачу TGT для проверки подлинности на серверном ресурсе. Имейте в виду, что, в отличие от NTLM, протокол Kerberos не используется для локальной аутентификации в диспетчере учетных записей безопасности Windows; его сфера применения ограничивается доменной аутентификацией на контроллере домена.

Kerberos — стандартный протокол аутентификации в системе Windows 2000 и в более новых версиях Microsoft. В этих операционных системах протокол аутентификации определяется с использованием механизма согласования. Если предлагаемый по умолчанию протокол Kerberos не подходит или не поддерживается одним из клиентских либо серверных компонентов, принимающих участие в аутентификации, Windows переходит на использование NTLM.

Почему Kerberos?

Kerberos более эффективен, нежели NTLM, и тому есть несколько причин. При использовании протокола Kerberos хеш пользовательского пароля экспонируется намного реже, чем в случае применения NTLM. Хеш пароля экспонируется только в том случае, когда пользователь запрашивает TGT — в сущности, один раз каждые восемь часов. С другой стороны, в случае применения NTLM хеш пароля экспонируется всякий раз, когда клиент использует NTLM для аутентификации на сервере. В этом состоит важное преимущество протокола Kerberos перед протоколом NTLM; дело в том, что существуют специальные инструменты, проверяющие сетевой трафик на наличие хешей паролей. Эти инструменты захватывают обнаруженные хеши и методом подбора восстанавливают на их основе пароли пользователей.

Еще одно достоинство Kerberos состоит в том, что этот протокол предусматривает использование отметок времени для защиты от атак с повторной передачей пакетов. Вот почему так важно наличие службы синхронизации времени, безупречно функционирующей в Kerberos-центрической среде Windows. В Windows 2000 и более новых версиях системы службы времени работают без предварительной настройки. Если компьютерные часы на разных компьютерах не синхронизированы, это может обернуться дополнительным трафиком в процессе аутентификации по стандарту Kerberos или же — в худшем случае — такая ситуация может вызвать ошибку в процессе аутентификации.

В дополнение к сказанному протокол Kerberos реализует такие усовершенствованные функции аутентификации, как взаимная аутентификация и делегирование аутентификации. Взаимная аутентификация означает, что пользователь и служба проверяют подлинность друг друга, тогда как возможности NTLM ограничиваются проверкой подлинности пользователя. Без этой функции могут возникать ситуации, когда пользователи предоставляют свои учетные данные фиктивному серверу.

Служба может обращаться к удаленным ресурсам от имени пользователя с помощью механизма делегирования аутентификации. Иными словами, пользователь может предоставлять системе-посреднику право подтвердить от своего имени свою (пользователя) подлинность на сервере приложений. В результате сервер приложений получает возможность принимать решения по авторизации не на базе идентичности системы-посредника, а основываясь на идентичности пользователя. Функция делегирования проверки подлинности весьма полезна в многоуровневых приложениях, таких как доступ к базам данных с помощью внешнего интерфейса на базе Web.

Наконец, надо сказать, что, хотя специалисты Microsoft проделали большую работу по модернизации протокола NTLM, а именно создали версию NTLMv2, которая поддерживается в среде NT4 SP4 и более новых версиях, в продукте Microsoft Kerberos реализовано большее число современных алгоритмов шифрования. Я расскажу об этом подробнее в разделе, посвященном средствам шифрования протокола Kerberos

Ограничения протокола NTLM

Преимущества аутентификации средствами протокола Kerberos сомнения не вызывают. Но даже в среде AD Server 2008 Windows часто использует протокол NTLM, например, когда вы подключаетесь к системе Windows, выпущенной до появления Windows 2000, или при подключении к общедоступному ресурсу с помощью команды net use и IP-адреса (а не имени NetBIOS). Кроме того, приложения, у которых имена участников службы service principal names (SPN) не настроены должным образом, будут по-прежнему использовать протокол NTLM.

Чтобы узнать, каким протоколом — NTLM или Kerberos — вы пользуетесь в данный момент, можете визуализировать трафик NTLM с помощью утилиты netmon или другого трассировщика сети; альтернативный вариант — проверить содержимое кэша билетов Kerberos с помощью инструмента klist (который входит в комплекты поставки Windows 7 и Server 2008). В системах Windows 7 и Server 2008 специалисты Microsoft реализовали новые групповые политики, с помощью которых можно отслеживать, а также блокировать использование протокола NTLM вашими пользователями и приложениями. Всего таких политик три: одна для входящего трафика NTLM (для отслеживания и блокировки на уровне сервера), другая для исходящего трафика NTLM (для отслеживания и блокировки на уровне клиента) и третья для доменного трафика (для отслеживания и блокировки на уровне контроллера домена). Они размещаются в контейнере Security Options Group Policy Object (CPO), попасть в который можно, последовательно выбирая пункты Computer Configuration, Windows Settings, Security Settings, Local Policies (см. экран 1). Все они начинаются с элемента Network security: Restrict NTLM:.

Каждая настройка политики имеет параметры audit и block. Когда вы включаете функцию аудита NTLM, программа создает записи журнала событий с исходными данными NTLM и числами 8001, 8002, 8003 и 8004. Журнальные записи хранятся в контейнере Operational с путем доступа Event Viewer (Local), Applications And Services Logs, Microsoft, Windows, NTLM. Я рекомендую для начала провести аудит NTLM в тестовой среде и позаботиться о том, чтобы там были должным образом представлены все ваши приложения. Если начать произвольно блокировать использование протокола, скорее всего, некоторые приложения функционировать не будут. Чтобы не допустить потери событий, следует перед началом тестирования средств аудита NTLM установить решение для сбора событий аудита; можете воспользоваться встроенной службой Windows Event Collector, средствами Event Subscriptions или решением от независимого поставщика. Кроме того, я рекомендую первым делом начать мониторинг NTLM на серверах. Вы можете подключить клиенты для проведения детального анализа, после того как станет очевидно, что сервер использует протокол NTLM. Уяснив, какие приложения используют NTLM, вы можете разработать стратегию блокировки NTLM. Эта стратегия может включать в себя стратегию исключений для устаревших приложений, которые не могут быть переписаны или перенастроены и которые всегда будут требовать применения NTLM.

К сожалению, упомянутые настройки NTLM нельзя применять на старых системах Windows. Однако эти системы допускают возможность управления версиями протокола NTLM. Вы можете, например, отключить фрагмент LM протокола аутентификации NTLM (поскольку этот фрагмент слаб по самой своей природе) или задать принудительное применение протокола NTLMv2. Для этого следует воспользоваться настройкой Network Security: LAN Manager Authentication Level GPO, которая размещается в контейнере Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options GPO (см. экран 2).

Средства шифрования Kerberos

Криптографические протоколы, используемые протоколами аутентификации, играют важную роль в обеспечении безопасности последних. Как я уже отмечал, в этой области показатели Kerberos выше, чем у протокола NTLM. Алгоритм шифрования RC4 был впервые реализован в протоколе Windows Kerberos в версии Windows 2000 и по сей день поддерживается в системах Server 2008, а также Windows 7 (точнее говоря, поддерживается его версия RC4_HMAC_MD5). В системах Server 2008, Windows Vista и более новых версиях разработчики Microsoft добавили средства поддержки шифрования по стандарту Advanced Encryption Standard, AES, а системы Windows 7 и Server 2008 R2 поддерживают типы шифрования Kerberos AES (AES128_HMAC_SHA1 и AES256_HMAC_SHA1) без предварительной настройки. AES — более новый и мощный алгоритм шифрования, нежели DES. Логика Kerberos на контроллерах доменов перейдет на стандарт шифрования AES, когда вы модернизируете домен AD до уровня Windows 2008 Domain Functional Level (DFL).

В системах Windows 7 и Server 2008 R2 типы шифрования DES для протокола аутентификации Kerberos по умолчанию отключены. Из-за этого могут возникнуть проблемы совместимости, если одно из устаревших приложений жестко закодировано на шифрование только по стандарту DES или если учетная запись Windows, выполняющая ту или иную службу (учетная запись этой службы), настроена на использование только DES-шифрования. Эти службы или приложения выйдут из строя, если вы не сможете перенастроить соответствующую службу либо приложение на поддержку другого типа шифрования (RC4 или AES) либо не восстановите поддержку стандарта DES.

Чтобы выяснить, имеются ли у вас приложения либо службы, закодированные на шифрование исключительно по стандарту DES, можно запустить сетевой трассировщик при старте соответствующего приложения или службы и проверить содержимое полей Etype в заголовках аутентификации Kerberos. Чтобы определить, настроена ли учетная запись пользователя либо компьютера AD или учетная запись компьютера для применения исключительно типов шифрования DES, нужно проверить, выбран ли на вкладке Account свойств объекта параметр Use Kerberos DES encryption types for this account. К этим свойствам можно обратиться из оснастки AD Users and Computers консоли MMC.

Если вы выполните упомянутые выше проверки и окажется, что у вас возникла эта проблема, можете активировать DES-шифрование для аутентификации с помощью Kerberos на компьютерах, функционирующих под Windows 7 или Server 2008 R2, с помощью GPO настройки Network security: настройте типы шифрования, совместимые со стандартом Kerberos; эти настройки расположены в контейнере Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options GPO.

Итак, из двух протоколов аутентификации Windows предпочтительным является протокол Kerberos. Администраторам следует всегда настаивать на том, чтобы пользователи и приложения применяли именно Kerberos, а не NTLM. Новые ограничения по использованию NTLM, реализованные в системах Windows 7 и Server 2008 R2, открывают перед нами отличную возможность для достижения этой цели.

Жан де Клерк (jan.declercq@hp.com) — сотрудник Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft

Источник

Kerberos — это
программный продукт, разработанный в
середине 1980-х гг. в Массачусетсом
технологическом институте и претерпевший
с тех пор ряд принципиальны изменений.
Клиентские компоненты Kerberos присутствуют
в большинстве современных операционных
систем. Kerberos предназначен для решения
следующей задачи. Имеется открытая
(незащищенная) сеть, в узлах которой
сосредоточены субъекты — пользователи,
а также клиентские и серверные программные
системы. Каждый субъект обладает
секретным ключом. Чтобы субъект С мог
доказать свою подлинность субъекту S
(без этого S не станет обслуживать С), он
должен не только назвать себя но и
продемонстрировать знание секретного
ключа. С не может просто послать S свой
секретный ключ, во-первых, потому, что
сеть открыта (доступна для пассивного
и активного прослушивания), а, во-вторых,
потому, что S не знает (и не должен знать)
секретный ключ С. Требуется менее
прямолинейный способ демонстрации
знания секретного ключа.

Система Kerberos
представляет собой доверенную третью
сторону (т. е. сторону, которой доверяют
все), владеющую секретными ключами
обслуживаемых субъектов помогающую им
в попарной проверке подлинности.

Чтобы с помощью
Kerberos получить доступ к S (обычно это
сервер), С (как правило — клиент) посылает
Kerbero запрос, содержащий сведения о нем
(клиенте) и о запрашиваемой услуге. В
ответ Kerberos возвращает так называемый
билет, зашифрованный секретным ключом
сервера

и копию части информации из
билета, зашифрованную секретным ключом
клиента. Клиент должен расшифровать
вторую порцию данных и переслать ее
вместе с билетом серверу. Сервер,
расшифровав билет, может сравнить
его

содержимое с дополнительной
информацией, присланной клиентом.
Совпадение свидетельствует о том, что
клиент смог расшифровать предназначенные
ему данные (ведь содержимое билета
никому, кроме сервера и Kerberos, недоступно),
т. е. продемонстрировал знание секретного
ключа. Значит, клиент— именно тот, за
кого себя выдает.

Подчеркнем, что
секретные ключи в процессе проверки
подлинности не передавались по сети
(даже в зашифрованном виде) — они только
использовались для шифрования.

Как организован
первоначальный обмен ключами между
Kerberos и субъектами и как субъекты хранят
свои секретные ключи — вопрос отдельный.

Проиллюстрируем
описанную процедуру рис. 6 на котором
обозначено: С и S — сведения (например,
имя), соответственно, о клиенте и сервере;
d 1 и d2 — дополнительная (по отношению к
билету) информация; Tc.s— билет для клиента
С на обслуживание у сервера S; Кс и Ks —
секретные ключи клиента и сервера;
{info}K — информация info, зашифрованная
ключом К.

Рис. 6. Проверка
сервером S подлинности клиента С

Протокол
аутентификации Kerberos определяет
взаимодействие между клиентом и сетевым
сервисом аутентификации, известным как
KDC (Key Distribution Center). В Windows NT KDC используется
как сервис аутентификации на всех
контроллерах домена. Домен Windows NT
эквивалентен области Kerberos, но к ней
обращаются как к домену. Реализация
протокола Kerberos в Windows NT основана на
определении Kerberos в RFC 1510, клиент Kerberos
реализован в виде ПФБ (поставщика функций
безопасности) Windows NT, основанном на SSPI.
Начальная аутентификация Kerberos
интегрирована с процедурой WinLogon.

Сервер
Kerberos (KDC) интегрирован с существующими
службами безопасности Windows NT, исполняемыми
на контроллере домена. Для хранения
информации о пользователях и группах
он использует службу каталогов Active
Directory.

Протокол Kerberos
усиливает существующие функции

безопасности
Windows NT и добавляет новые:

повышенная скорость
аутентификации при установлении
начального соединения (сервер приложений
не обращается к контроллеру домена для
аутентификации клиента);

делегирование
аутентификации в многоярусных архитектурах
клиент-сервер (при подключении клиента
к серверу, последний имперсонирует
(олицетворяет) клиента в этой системе,
но если серверу для завершения транзакции
нужно выполнить сетевое подключение к
другому серверу, протокол Kerberos позволяет
делегировать аутентификацию первого
сервера и подключиться ко второму от
имени клиента);

транзитивные
доверительные отношения для междудоменной
аутентификации (т.е пользователь может
быть аутентифицирован в любом месте
дерева доменов) упрощают управление
доменами в больших сетях с несколькими
доменами.

Интеграция Kerberos.
Протокол Kerberos полностью интегрирован
с системой безопасности и контроля
доступа Windows NT. Начальная регистрация
в Windows NT обеспечивается процедурой
WinLogon, использующей ПФБ Kerberos для получения
начального билета TGT. Другие

компоненты
системы, например, Redirector, применяют
интерфейс SSPI к ПФБ Kerberos для получения
сеансового билета для удаленного доступа
к файлам сервера SMB.

Взаимодействие
Kerberos. Протокол Kerberos версии

5 реализован
в различных системах и используется
для единообразия аутентификации в
распределенной сети.

Под взаимодействием
Kerberos подразумевается общий протокол,
позволяющий учетным записям
аутентифицированных пользователей,
хранящимся в одной базе, осуществлять
доступ ко всем сервисам в гетерогенной
среде. Взаимодействие Kerberos основывается
на следующих характеристиках:

общий протокол
аутентификации пользователя или сервиса
по основному имени при сетевом подключении;

возможность
определения доверительных отношений
между областями Kerberos и создания ссылочных
запросов билетов между областями;

поддержка
определенных в RFC 1510 требований
к

взаимодействию, относящихся к
алгоритмам шифрования

контрольных сумм,
взаимной аутентификации и другим

возможностям
билетов;

поддержка форматов
маркера безопасности Kerberos

версии 5
для установления контекста и обмена
сообщениями.

Поддержка Kerberos
открытых ключей. В Windows

NT
также реализованы расширения протокола
Kerberos,

поддерживающие дополнительно
к аутентификации с совместно используемым
секретным ключом аутентификацию,
основанную на парах открытого (закрытого)
ключа. Поддержка открытых ключей
позволяет клиентам запрашивать начальный
ключ TGT с помощью закрытого ключа,

то
время как KDC проверяет запрос с помощью
открытого ключа, полученного из
сертификата Х.509 (хранится в

пользовательском
объекте в каталоге Active Directory),

Сертификат
пользователя может быть выдан как
сторонним

уполномоченным сертификации
(Certification Authority),

так и Microsoft Certificate
Server, входящим в Windows NT.

После начальной
аутентификации закрытым ключом
используются стандартные протоколы
Kerberos для получения сеансовых билетов
на доступ к сетевым службам.

Модель безопасности
Windows NT обеспечивает однородный и
унифицированный механизм контроля за
дотупом к ресурсам домена на основе
членства в группах. Компоненты безопасности
Windows NT доверяют хранимой в каталоге
информации о защите. Например, сервис
аутентификации Windows NT хранит зашифрованные
пароли

пользователей в безопасной
части каталога объектов пользователя.
По умолчанию операционная система
«считает», что правила безопасности
защищены и не могут быть изменены
кем-либо несанкционированно. Общая
политика безопасности домена также
хранится в каталоге Active Directory.

Делегирование
административных полномочий
— гибкий инструмент ограничения
административной деятельности рамками
части домена. Этот метод позволяет
предоставить отдельным сотрудникам
возможность управления пользователями
или группами в заданных пределах, и в
то же время, не дает им прав на управление
учетными записями, относящимися к другим
подразделениям.

Права на определение
новых пользователей или создание групп
пользователей делегируются на уровне
OU или контейнера, в котором создана
учетная запись.

Существует три
способа делегирования административных
полномочий:

на изменение
свойств определенного контейнера,
пример, LocalDomainPolicies самого домена;

на создание и
удаление дочерних объектов определенного
типа (пользователи, группы, принтеры и
пр.) внутри OU;

на обновление
определенных свойств некоторых дочерних
объектов внутри OU (например, право
устанавливать пароль для объектов типа
User).

Делегировать
полномочия просто. Достаточно выбрать

лицо,
которому будут делегированы полномочия,
и указать, какие именно полномочия
передаются. Интерфейс программы
администрирования Active Directory позволяет
без затруднений просматривать информацию
о делегировании, определенную для
контейнеров.

Наследование прав
доступа означает, что информация об
управлении доступом, определенная в
высших слоях контейнеров в каталоге,
распространяется ниже — на положенные
контейнеры и объекты-листья. Существуют
две модели наследования прав доступа:
динамическая и статическая.

При динамическом
наследовании права определяются путем
оценки разрешений на доступ, назначенных
непосредственно для объекта, а также
для всех родительских объектов в
каталоге. Это позволяет эффективно
управлять доступом к части дерева
каталога, внося изменения

в контейнер,
влияющий на все вложенные контейнеры
и

объекты-листья. Обратная сторона
такой гибкости — недостаточно высокая
производительность из-за времени
определения эффективных прав доступа
при запросе пользователя.

В Windows NT реализована
статическая форма наследования прав
доступа, иногда также называемая
наследованием в момент создания.
Информация об управлении доступом к
контейнеру распространяется на все
вложенные объекты контейнера. При
создании нового объекта наследуемые
права сливаются с правами доступа,
назначаемыми по умолчанию. Любые
изменения наследуемых прав доступа,
выполняемые в дальнейшем на высших
уровнях дерева, должны распространяться
на все дочерние объекты. Новые наследуемые
права доступа распространяются на
объекты Active Directory в соответствии с тем,
как эти новые права

определены.
Статическая модель наследования
позволяет увеличить производительность.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Источник

History and development[edit]

Microsoft Windows[edit]

Unix and other operating systems[edit]

Protocol[edit]

Description[edit]

User Client-based Login without Kerberos[edit]

Client Authentication[edit]

[edit]

Client Service Request[edit]

Drawbacks and limitations[edit]

Vulnerabilities[edit]

See also[edit]

References[edit]

Further reading[edit]

External links[edit]

History and development[edit]

Microsoft Windows[edit]

Unix and other operating systems[edit]

Protocol[edit]

Description[edit]

User Client-based Login without Kerberos[edit]

Client Authentication[edit]

[edit]

Client Service Request[edit]

Drawbacks and limitations[edit]

Vulnerabilities[edit]

See also[edit]

References[edit]

Further reading[edit]

External links[edit]

Идентификация и аутентификация

Протокол Kerberos

Почему Kerberos?

Ограничения протокола NTLM

Средства шифрования Kerberos