Interview Bank
  • Interview Bank
  • Web
    • Persistent Connection and Non Persistent
    • CDN
    • Code Review
    • JWT
      • JWT vs Session Based Authentication
      • JWT Challenge
      • JWE
      • JWS
    • Content Security Policy (CSP)
    • Same-origin Policy (SOP)
    • Cross-Origin Resource Sharing (CORS)
      • Exploiting CORS
    • HTTP Strict Transport Security (HSTS)
    • SQL Injection (SQLi)
    • Password Encryption in Login APIs
    • API Security
      • API Principles
    • Simple bypass PHP
    • Server-side Template Injection (SSTI)
    • Javascript Object and Inheritance
    • HTTP/2
    • Cookie vs Local vs session Storage
    • XML External Entity (XXE)
    • What happened when enter domain name in browser
    • Prototype Pollution - Part 1
    • Prototype Pollution - Part 2
    • Nginx vs Apache
  • OT Security
    • Securing Operational Technology: Understanding OT Security
  • Quantum Computing
    • Quantum Computing: Unveiling the Cryptographic Paradigm Shift
    • Quantum Obfuscation: Shielding Code in the Quantum Era
  • DevSecOps
    • Continuous Integration/Continuous Deployment Pipeline Security
    • Chaos Engineering Overview
      • Security Chaos Engineering
    • Mysql VS redis
    • Kubernetes (k8s)
    • How MySQL executes query
    • REDIS
    • Difference between cache and buffer
  • Windows
    • Pentesting Active Directory - Active Directory 101
    • Pentesting Active Directory - Kerberos (Part 1)
    • Pentesting Active Directory - Kerberos (Part 2)
    • AD vs Kerberos vs LDAP
    • Active Directory Certificate Services Part 1
    • Unconstrained Delegation
    • AS-REP Roasting
    • NTLM Relay via SMB
    • LLMRN
    • Windows lateral movement
    • Constrained Delegation
    • Resource-Based Constrained Delegation
    • IFEO (lmage File Execution Options) Hijacking
  • UNIX
    • Setuid
  • Large Language Models (LLMs)
    • Tokens
    • LangChain
    • Integration and Security
  • Android
    • Keystore
  • Red team development
    • Secure C2 Infrastructure
    • P Invoke in c#
    • D Invoke
    • ExitProcess vs ExitThread
  • Blue Team
    • Indicators of Compromise
    • Methods to prevent Email domain spoofing
    • Windows Prefetching
  • CVE
    • XZ Outbreak CVE-2024-3094
    • Log4J Vulnerability (CVE-2021-44228)
    • SolarWinds Hack (CVE-2020-10148)
    • PHP CGI RCE (CVE-2024-4577)
    • Windows Recall
  • Software Architecture
    • Microservices
    • KVM
  • Docker
    • Overview
    • Daemon Socket
    • Tips to reduce docker size
  • Blockchain
    • Overview
    • Smart Contract
  • Business Acumen
    • Market Research Reports and Perception
    • Understanding Acquisitions
    • Cybersecurity as a Business Strategy
  • Cyber Teams
    • Introduction to Purple Teaming
  • Malware
    • Dynamic Sandbox Limitations
Powered by GitBook
On this page
  • S4u2self
  • S4u2proxy
  • Summary of extenstions
  • # Author
  1. Windows

Constrained Delegation

Microsoft release an update and safer version of kerberos delegation know as "Contrained Delegation"

The main goal of delegation is to solve the double hop issue, the previous solution of unconstrained Delegation allowed the service to perform authentication to anything in the domain, constrained delegation limit the scope to specific services.

The native kerberos protocol does not support constrained delegation by default, therefore microsoft release 2 extenstions for this feature:

S4u2self

  • Purpose: Allow a service to obtain a kerberos ticket for a user without requiring the user's password

  • How it works:

    • When a user connect to a service, the service can use s4u2self to request a kerberos ticket for the user directly from the KDC

    • The KDC verify the request and issue a ticket representing user's identy, but now allowing the service to use this ticket ACCESS other service yet

    • This ticket is known as "self-ticket" beacuse it represents the user's identiy but is only usable by the service itself that request it

S4u2proxy

  • Purpose: Allow a service to request access to another service on behalf of a user by using the ticket obtained via S4u2self

  • How it works:

    • After getting the "self-ticket", the service will uses s4u2proxy to reqest a forwardable ticket from the KDC that allow it to act on behalf of the user when accessing the proxy

    • The KDC will verify with the constain delegation policy to check if this user is allow to delegate to the service

Summary of extenstions

1) Step 1 (s4u2self): User authenticate to service A, the service A request a "self-ticket" from the KDC for user, without the need of user interaction of credentials

2) Step 2(s4u2proxy): The service A use this ticket and request permission from KDC to act on behalf of the user when accessing service B (database). If the constrain delegation policy allow this delegation, the KDC will then issue a service ticket for service A to access service B onbehalf of the user

# Author

Ik0nw

PreviousWindows lateral movementNextResource-Based Constrained Delegation

Last updated 7 months ago