How AD decides Kerberos encryption type per user/computer basis

Supposed that there is no GPO to enforce supported ciphers, on a per principal basis, it is determined as below:

If msDS-SupportedEncryptedTypes is populated, then use values defined in this attribute. It's a 5-bit flag

• bit 0   DES-CBC-CRC
• bit 1   DES-CBC-MD5
• bit 2   RC4-HMAC
• bit 3   AES128-CTS-HMAC-SHA1-96
• bit 4   AES256-CTS-HMAC-SHA1-96

If msDS-SupportedEncryptedTypes is NOT populated, then AD reads values in userAccoutControl. 

• if 0x200000 is set, DES will be used
• if 0x200000 is not set, default to RC4 for 2008/7 and later

Default behavior:

• Computer account: msDS-SupportedEncryptedTypes set. OS 2008/Win7 and newer: DES is disabled
• User account: msDS-SupportedEncryptedTypes is not set so RC4 is used see here, unless userAccountControl forces DES
• Referral Ticket/Trust object: higher of DES/RC4 that is mutually supported by client and authenticating domain. If both client and trust don't have any custom value set, cipher is RC4.
  
  NOTE/WARNING: If you enabled "AES" support on trust using GUI, only AES will be supported; RC4 will be disabled. If you want to add "AES" on top of RC4, use ksetup to change trust.

PS. Above behavior is always for Service Ticket.

    Since TGT is meant for DCs to read, it always uses what DC supports, and is irrelevant to what is defined on individual accounts.

Sample Script to find risky users

#Bitwise AND: 1.2.840.113556.1.4.803
#Bitwise OR : 1.2.840.113556.1.4.804
# 2097152 is 0x200000, bit mask for userAccountControl DES enforced
# 3 is 0b11, covers the last 2 bits of msDS-SupportedEncryptionTypes, which enables DES

# list users who
    # user object, and
    # enabled, and
        # supportedType set with DES, or
        # supportedTYpe not set but userAccountControl DES set
        
$ldapfilter=@("(&",`
    "(objectclass=user)",`                                                         # user Object
    "(!(userAccountControl:1.2.840.113556.1.4.803:=2))",`                          # enabled
    "(|",` 
        "(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=3)",`              # DES defined in supportedType
        "(&",`                                                                     # or DES not set in supported type but in userAccountControl
            "(!(msDS-SupportedEncryptionTypes=*))",`                                   
            "(userAccountControl:1.2.840.113556.1.4.803:=2097152)",`
        ")",`
     ")",`
")")
$ldapfilter = $ldapfilter -join ""

$u=get-aduser -ldapfilter $ldapfilter -server foo.bar -Properties msDS-SupportedEncryptionTypes,enabled,userAccountControl,UseDESKeyOnly

Decentralized Identity (DID) - Verifiable Credential - Microsoft Verified ID

Traditional IDs are issued/owned by IdPs. From user's perspective, these IDs among different IdPs can be inconsistent, hard to maintain, and there is no guarantee of privacy, control, etc.

Decentralized ID lets a user owns his/her ID. Any other entity can then add claims to DID. For example, an employer can add employment claim to its employees' DIDs. Therefore, traditional IdPs no longer own IDs, they either become irrelevant to a person (if they can't add/verify claims about the said person), or they transform themselves to be claim issuer (if they know something about the holder) /verifiers (in this case, the old IdP is just a consuming party of DID model).  

"Claims" here is called "Verifiable Credentials"(VCs) in DID context. It's verifiable because it's digitally signed. Entities that assign/sign VCs are called Issuer.

DID creation, change, as well as claim history, are stored in a public, decentralized network. It can be tracked and verified without a centralized IdP. Such network is called Trust Systems. Examples include ION (Identity Overley Network) and DID:web. Trust System can be built on top of existing blockchain network such as Bitcoin.

For the model to work, there are implicit trusts listed below:

• Issuer trusts holder
• Verifier trusts issuer
• Holder trusts verifier