General documentation: Article directory Github: github.com/black-ant

  • Pure constraint protocols: OAuth, SAML, OIDC, CAS,LTPA
  • Server protocols: RADIUS, Kerberos, and ADFS
  • Authentication mode: OTP, biometric authentication (face, voice print, fingerprint)
  • Authentication server (shipped) : AD, LDAP, ADFS

This article will talk about Kerberos protocol, already based on Kerberos AD domain single point

A. The preface

Originally developed at the Massachusetts institute of technology (MIT) as part of projectathena, Kerberos provides a centralized authentication server that functions as user-to-server authentication and user-to-server authentication. In Kerberos authentication, the server and database are used for client authentication. Kerberos runs as a third-party trusted server called a Key Distribution Center (KDC). Every user and service on the network is a principal.

Kerberos advantages

  1. The password is never sent over the network, because only the key is sent in encrypted form;
  2. Authentication is mutual, so the client and server authenticate in the same steps, and both are confident that they are communicating with the correct counterpart;
  3. Authentication is reusable and does not expire;
  4. Kerberos is based entirely on open Internet standards
  5. Kerberos is adopted by many industries, so any new flaws in its security protocol or underlying modules are quickly corrected

Kerberos shortcomings

  1. If unauthorized users can access the key distribution center, the entire authentication system is compromised
  2. Kerberos can only be adopted by kerberos-supported applications. Rewriting the code for some applications to be Kerberos aware can be a problem

The Kerberos key words

  • Security Authentication Protocol
  • The tickets to verify
  • Password protection (local not saved, link not transmitted)
  • Symmetric encryption
  • Server – client can authenticate with each other
  • Have a trusted third party

2. Basic Kerberos essentials

2.1 the Kerberos members

Member of certification System

  • Members of the Client
  • ApplicationServer (AP, ApplicationServer, Resource)
  • Key Distribution Center (KDC) :AS + TGS + DB
    • Trusted third party of the invoice. In the active directory, each domain controller acts as a KDC.
    • KDC provides two core services:
      • The authentication service (AS) authenticates the client and issues a ticket to it;
      • The Ticket Granting Service (TGS) accepts authenticated clients and issues tickets to them to access other resources
    • KDC has a Database (DB)

2.2 the Kerberos architecture

Architecture features:

  • Message = decoded part + undecoded part
  • The server does not communicate directly with the KDC
  • All users and passwords are available in the KDC

Concepts involved:

  • Principal: Authentication principal, similar to a user name
  • Realm: Scope, where a principal only works for the specified realm
  • Password: user password, corresponding to kerberos master_key, can exist in the keytab file
  • Credential: a credential that verifies the validity of a user/action (password/ticket)
  • Long-term Key/Master Key: indicates a long-term Key that cannot be transmitted over the network
  • Short-term Key/Session Key: a Key that can be transmitted over the network. This Key has timeliness

The difference between TGT and TGS

  • TGT KDC encryption part (unreadable) : Name /ID + TGS name/ID + time stamp + IP address + TGT life cycle + TGS session key
  • TGT personal encryption part (readable) : TGS name/ID + time error + lifecycle + TGS Session key

2.3 Kerberos Request Process

The Kerberos protocol process consists of two phases. The first phase is the authentication of the Client by KDC, and the second phase is the authentication of the Client by Service.

  • First time: The client enters the login information, and the Kerberos client creates an encryption key and sends a message to the Authentication server (AS)
  • Second time: THE AS uses this key to create a temporary session key and sends a message to the Ticket Granting Service (TGS)
  • Third time: TGS grants a ticket and server session key to the client, which the client uses to authenticate with the server and gain access

Here are the Kerberos access details:

  1. KRB_AS_REQ: Requests the TGT from the authentication service (AS)
    • The client’s request includes the user’s user principal name (UPN) and the timestamp. It is encrypted using the user’s password hash
  2. KRB_AS_REP: Receives the TGT from the authentication service
    • The KDC uses UPN to look up the client in its database and tries to decrypt the message using the user’s password, Hashto
    • If the KDC successfully decrypts the TGT request and the timestamp is within the time offset configured by the KDC, authentication succeeds
    • After the authentication is successful, the KDC connects the TGT toTGS Session keyIs sent back to the client. The TGS session key is used to encrypt subsequent requests
  3. KRB_TGS_REQ: Send the current TGT and request the TGS
    • The client displays its TGT and a request, including the Service Principal Name (SPN) of the Service it wants to access
    • The TGS request is encrypted using the TGS session key
  4. KRB_TGS_REP: receives TGS from KDC
    • The KDC validates the TGT and, if successful, generates the TGS. The TGS contains information about the requester, such as the requester’s SID and group membership, and is encrypted using the service’s password hash
    • The TGS and the service session key are encrypted using the TGS session key and then sent back to the client
  5. KRB_TGS_REP: Submit the TGS to the application server for authorization
    • The client sends the TGS received from the KDC to the application server along with the verifier message, which is encrypted using the service session key (the App then takes the TGS to the KDC for authentication).
  6. KRB_AP_REP: grants the client access to the service
    • The client receives the message and decrypts it with the service session key
    • The application server extracts the privilege attribute certificate (PAC) from the service ticket and verifies its contents with the domain controller
    • The ticket /PAC is validated only if the ticket grants the ticket (TGT) for more than 20 minutes

2.5 KDC process details

Basic members:

- > KDC: Key Distributed Center Provides the ticket generation management service for the whole security authentication process, including AS and TGS > AD: Account Database, storing the whitelist of all clients - Major Roles > C: Client > AS: Authentication Server, user Authentication completed > TGS: Ticket Granting Server Credential Server > ST: Http Service Ticket > SS : Service Server > RS : Resource serverCopy the code

KRB_AS_REQ Apply for a TGT for the first time

  • Request C->SS: cleartext access (Name/ identity information, IP/client message, TGT validity time) (can also be encrypted with Master key, AD has Master key)
  • Processing IN SS: SS determines whether the object exists IN the AD and generates a Session Key for communication between TGS
  • Return SS->C: return TGT (TGT server part + TGT personal part)

Step 2: KRB_TGS_REQ generates TGS for the second time

> request C -> TGS: -> TGS Session key encryption part (Name/ID+ timestamp + Client Info), clear text (service Name/ID+ lifecycle), TGT > process IN TGS (decrypt TGT part 1) : ->1.User name comparison (TGT <-> authenticator) ->2.Timestamp comparison ->3.Expired or Not ->4.IP Is consistent ->5.Does the authenticator already exist in the cache ->6.Add Permission and Authentication services ->7.Http Service Session Key ->8.Prepare ST > return TGS -> C: -> ST (encrypted Http Service password) = Personal name/ ID + Http Service name/ ID + IP + timestamp + ST life cycle + Http Service Session Key -> TGS Session Key Encryption part = Http Service name/ID + timestamp + ST life cycle + Http Service Session KeyCopy the code

Step 3: Resource server processing

> request C -> RS: -> Http Service Session Key1.Compare user names ->2.Compare timestamp ->3.Check whether it is expired ->4.Check the IP address ->5.Whether it already exists in the cacheCopy the code

2.5KDC prerequisites

  1. Replication between domain controllers:

    • If multiple domain controllers (that is, multiple KDCS) are deployed, you must enable replication and recycle in a timely manner.
    • If replication fails or reclamation is delayed, authentication is possible when the user changes the password

  2. The client and the KDC must synchronize their clocks

    • In Kerberos, accurate measurement of time is important to prevent replay attacks.
    • Kerberos supports a configurable time offset (5 minutes by default) beyond which authentication will fail

  3. The client and the KDC must be able to communicate over the network

    • Kerberos traffic occurs on TCP and UDP ports 88 and all clients must be able to access at least one KDC (network domain controller)

  4. Clients, users, and services must have unique names

    • Duplicate names of computer, user, or service principal names can cause authentication to fail

  5. The client and KDC must use NETBIOS and DNS name resolution

    • The client and KDC must use NETBIOS and DNS name resolution

    • Kerberos service principal names typically include NETBIOS and DNS addresses, which means that the KDC and the Client must be able to resolve these names in the same way

    • In some cases, an IP address can also be used as a service principal name

Configure the Kerberos AD domain

3.1 Configuring the KDC DB

Step 1: Create a Kerberos SPN user

Step 2: Configure user attributes so that authentication is not required and the password does not expire

Step 3: Generate Kerberos.keytab

ktpass.exe /out c:\kerberos.keytab /princ HTTP/antblack.com@ADSERVER.COM.CN /pass zzy19950810 /mapuser kerberos@ADSERVER.COM.CN /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT

ADSERVER.COM.CN 
    //- The current domain name
antblack.com 
    // -kdc Client domain name (that is, the application server domain name)
kerberos@ADSERVER.COM.CN 
    //- Bound user
zzy19950810
    //- The bound password
RC4-HMAC-NT
    // - Encryption mode

Copy the code

Step 4: After the generation, the user will delegate attributes and select trust

At the same time, you can see that the user has multiple bindings.

3.2 configure KDC

If klist does not exist, run the yum install krb5-server krb5-libs krb5-auth-dialog command

Modify/etc/krb5. Conf

# Configuration snippets may be placed in this directory as well includedir /etc/krb5.conf.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = false ticket_lifetime = 24h default_realm = ADSERVER.COM.CN default_keytab_name = /opt/kerberos.keytab default_tkt_enctypes = rc4-hmac default_tgs_enctypes = rc4-hmac [realms] ADSERVER.COM.CN= { kdc = 192.168.158.9} [domain_realm].adserver.com.cn = adserver.com.cn adserver.com.cn = adserver.com.cnCopy the code
  • /opt/ Kerberos. keytab: generated before Windows AD. Drag it to the application server
  • 192.168.158.9: INDICATES the KDC DB address
  • ADSERVER.COM.CN: KDC AD domain information
  • Rc4-hmac: indicates the encryption mode

Step 3: Test the KDC

klist -k    
[root@localhost ~]# klist -k
Keytab name: FILE:/opt/kerberos.keytab
KVNO Principal
---- --------------------------------------------------------------------------
	3 HTTP/antblack.com@ADSERVER.COM.CN

// Test whether KeyTab is connected
// Antblack. CN queries a realm in kerb5.conf and authenticates it to the KDC it is configured with
kinit -k HTTP/antblack.cn@ANTBLACK.CN
klist -k
// After execution, a ticket will appear


// PS: Run klist tickets in AD>>>>>>>>>>>>>>>> The current login ID is yes0:0x12de650Cached tickets: (2)
#0> client: administrator @wdhacpoc.com.cn server: krbtgt/WDHACPOC.COM.CN @wdhacpoc.com.cn Kerberos ticket encryption type: AES-256-CTS-HMAC-SHA1-96Ticket symbol0x40e10000Forwardable renewable renewable initial pre_authent name_canonicalize3/30/2021 16:35:39(Local) End time:3/31/2021 2:35:39(Local) Renewal time:4/6/2021 16:35:39(Local) Session key type: AES-256-CTS-HMAC-SHA1-96Cache flag:0x1-> Trigger (KDC: WIN- 28-28)1> client: administrator @ WDHACPOC.COM.CN server: host/win-u76bkiqfggj.wdhacpoc.com.cn @ WDHACPOC.COM.CN Kerberos ticket encryption type: AES -256-CTS-HMAC-SHA1-96Ticket symbol0x40a50000-> forwardable renewable pre_authent OK_as_delegate name_canonicalize3/30/2021 16:35:39(Local) End time:3/31/2021 2:35:39(Local) Renewal time:4/6/2021 16:35:39(Local) Session key type: AES-256-CTS-HMAC-SHA1-96Cache flag:0The KDC that is invoked is huawei@CLOUD8Copy the code

4. Java implementation

// TODO: Industry code is not easy to sort out, we will do a simplified demo later

conclusion

Kerberos mainly promotes security, which is also a common but rarely used protocol. Some vendors are involved in the AD domain single point protocol.