-->
![Ticket Ticket](/uploads/1/2/6/0/126049444/649239015.jpg)
- Kerberos Key Distribution Center
- Kerberos Session Ticket
- __ Generates And Issues Session Keys In Kerberos 2017
- __ Generates And Issues Session Keys In Kerberos History
- Kerberos Session Denied
- __ Generates And Issues Session Keys In Kerberos 2016
This is a continuation post of part1 and part2 of my 'Integrated Windows Authentication blog series' and last one in this series where we are going to discuss about what we can do when Kerberos Authentication fails, how to detect it and correct it!
Let me start by mentioning this --> C:WindowsSystem32Wininet.dll file calls the InitializeSecurityContext function to build the Kerberos ticket.
- It also gives the attacker the keys that the KDC would normally generate to encrypt the service requests of this client, hence defeating confidentiality as well, In Section 7, I will discuss about the possible enhancement for scalability and reliability issues in Kerberos cross-realm operation, followed by in Section 9, I provide some.
- In Kerberos parlance, the former message is often called the user's credentials, the latter message is called the ticket, and the random key is called the session key. At this stage, only the user knows the session key (provided he really is the user and knows the appropriate long-term key).
Nov 12, 2019 Kerberos is an authentication mechanism that is used to verify user or host identity. Kerberos is the preferred authentication method for services in Windows. If you are running Windows, you can modify Kerberos parameters to help troubleshoot Kerberos authentication issues or to test the Kerberos protocol. Jul 01, 2019 The user cannot authenticate because the ticket that Kerberos builds to represent the user is not large enough to contain all of the user's group memberships. As part of the Kerberos authentication process, Windows builds a token to represent the user for purposes of authorization. This token (also called an authorization context) includes the.
The InitializeSecurityContext (Kerberos) function initiates the client side, outbound security context from a credential handle. The function is used to build a security context between the client application and a remote peer. InitializeSecurityContext (Kerberos) returns a token that the client must pass to the remote peer, which the peer in turn submits to the local security implementation through the AcceptSecurityContext (Kerberos) call. The token generated should be considered opaque by all callers.
Typically, the InitializeSecurityContext (Kerberos) function is called in a loop until a sufficient security context is established.
From <https://msdn.microsoft.com/en-us/library/aa375507(VS.85).aspx>
I have explained in my Part1 post about how the kerberos authentication works, I strongly recommend reading that first before troubleshooting so we know what we are doing.
So, when the Kerberos AUTHETICATION FAILS or maybe not yet, This is how you verify/check/resolve:
Firewall Configuration: |
Open firewall ports to allow HTTP traffic in on default and non-default ports. Ensure clients can connect to Kerberos Ports on the Active Directory. Before testing authentication, ensure clients can access the SharePoint Server web applications on the configured HTTP ports. In addition, ensure clients can authenticate with Active Directory and request Kerberos tickets from the KDC over the standard Kerberos ports. Open firewall ports to allow HTTP traffic in on default and non-default ports: Typically you have to configure the firewall on each front-end Web to allow incoming requests over ports TCP 80 and TCP 443. Open Windows Firewall with Advanced Security and browse to the following Inbound Rules:
Make sure the appropriate ports are open in your environment. In our example, we access SharePoint Server over HTTP (port 80), so this rule was enabled. In addition, we have to open the non-default port used in our example (TCP 5555). If you have web sites running on non-default ports, you also have to configure custom rules to allow HTTP traffic on those ports. Ensure that clients can connect to Kerberos ports on the Active Directory role To use Kerberos authentication, clients will have to request ticket granting tickets (TGT) and service tickets (ST) from the Key Distribution Center (KDC) over UDP or TCP port 88. By default, when you install the Active Directory Role in Windows Server 2008 and later, the role will configure the following incoming rules to allow this communication by default:
In your environment ensure these rules are enabled and that clients can connect to the KDC (domain controller) over port 88. From <https://technet.microsoft.com/en-us/library/gg502602(v=office.14).aspx> |
Test browser authentication:
After configuring Active Directory, DNS and SharePoint Server you can now test whether Kerberos authentication is configured correctly by browsing to your web applications. When testing in the browser, ensure the following conditions are met:
- The test user is logged into a Windows 7 or higher computer joined to the domain that SharePoint Server is installed in, or is logged into a domain trusted by the SharePoint Server domain.
- Integrated Windows authentication is enabled in the browser. Under Internet Options in the Advanced tab, make sure Enable Integrated Windows Authentication* is enabled in the Security section:
- Local intranet is configured to automatically logon clients. Under Internet explorer option, in the Security tab, select Local Intranet and click the Custom level button. Scroll down and make sure that Automatic logon only in Intranet zone is selected.
- Ensure that Automatically detect intranet network is selected in Internet options->Security->Intranet Zone->Sites.
- If you are using fully qualified domain names to access the SharePoint Server web applications, ensure that the FQDNs are included in the intranet zone, either explicitly or by wildcard inclusion (for example, '*.vmlab.local').
The easiest way to determine if Kerberos authentication is being used is by logging into a test workstation and navigating to the web site in question. If the user isn't prompted for credentials and the site is rendered correctly, you can assume Integrated Windows authentication is working.
From <https://technet.microsoft.com/en-us/library/gg502602(v=office.14).aspx>
If any of the above is not set properly, then Delegation fails even when Kerberos authentication works:
- Check Internet Explorer Zone used for the URL.Kerberos delegation is only allowed for the « Intranet » and « Trusted Sites » zones (in other words, IE sets the ISC_REQ_DELEGATE flag when it calls InitializeSecurityContext only if the zone computed is « Intranet » or « Trusted Sites » )
- The account used for the application pool identity must have the « Trusted for delegation » flag set
If delegation still fails, you may consider using DELEGCONFIG. This tool allows to diagnose - and resolve - dozens of issues preventing Kerberos authentication from working correctly. Check the following link for more details: http://blogs.iis.net/bretb/archive/2008/03/27/How-to-Use-DelegConfig.aspx
The next step is to determine if the negotiate protocol was used to negotiate Kerberos authentication as the authentication provider for the request. This can be done in the following ways:
SharePoint server Front-end Windows security logs
If Kerberos authentication is working correctly you will see Logon events in the security event logs on the front-end webs with event ID = 4624. In the general information for these events you should see the security ID being logged onto the computer and the Logon Process used, which should be Kerberos.
Event is here below:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 5/6/2018 10:27:48 PM
Event ID: 4624
Task Category: Logon
Level: Information
Keywords: Audit Success
User: N/A
Computer: SP.contoso.com
Description:
An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Impersonation Level: Impersonation
New Logon:
Security ID: contosospfarm
Account Name: spfarm
Account Domain: contoso
Logon ID: 0x15636
Logon GUID: {02398194-25d2-4852-4d60-026f36f6632a}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name:
Kerberos Key Distribution Center
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
Event Xml:
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-A5BA-3E3B0328C30D}' />
<EventID>4624</EventID>
<Version>1</Version>
<Level>0</Level>
<Task>12544</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime='2018-05-07T02:27:48.081988200Z' />
<EventRecordID>1044763</EventRecordID>
![Ticket Ticket](/uploads/1/2/6/0/126049444/649239015.jpg)
<Correlation />
<Execution ProcessID='620' ThreadID='3800' />
<Channel>Security</Channel>
<Computer>SP.contoso.com</Computer>
<Security />
</System>
<EventData>
<Data Name='SubjectUserSid'>S-1-0-0</Data>
<Data Name='SubjectUserName'>-</Data>
<Data Name='SubjectDomainName'>-</Data>
<Data Name='SubjectLogonId'>0x0</Data>
<Data Name='TargetUserSid'>S-1-5-21-2477750165-3421169653-395798871-1106</Data>
<Data Name='TargetUserName'>spfarm</Data>
<Data Name='TargetDomainName'>contoso</Data>
<Data Name='TargetLogonId'>0x15636</Data>
<Data Name='LogonType'>3</Data>
<Data Name='LogonProcessName'>Kerberos</Data>
<Data Name='AuthenticationPackageName'>Kerberos</Data>
<Data Name='WorkstationName'>
</Data>
<Data Name='LogonGuid'>{02398194-25D2-4852-4D60-026F36F6632A}</Data>
<Data Name='TransmittedServices'>-</Data>
<Data Name='LmPackageName'>-</Data>
<Data Name='KeyLength'>0</Data>
<Data Name='ProcessId'>0x0</Data>
<Data Name='ProcessName'>-</Data>
<Data Name='IpAddress'>-</Data>
<Data Name='IpPort'>-</Data>
<Data Name='ImpersonationLevel'>%%1833</Data>
</EventData>
</Event>
We should see same event on KDC (Domain controller) too:
Check if the IIS server is actually configured to send the WWW-Authenticate: Negotiate header:
If IIS doesn't send this header, you'll need to use ADSUTIL to set the Negotiate header though the NTAuthenticationProviders metabase property (see http://support.microsoft.com/kb/215383)
Note: by default, the NTAuthenticationProviders property is not set which causes IIS to send both Negotiate and NTLM headers:
Note: by default, the NTAuthenticationProviders property is not set which causes IIS to send both Negotiate and NTLM headers:
To check or set the property: Locate the directory that contains the Adsutil.vbs file. By default, this directory is C:InetpubAdminscripts.
Use the following command to retrieve the current values for the NTAuthenticationProviders metabase property:
cscript adsutil.vbs get w3svc/WebSite/root/NTAuthenticationProviders
In this command, WebSite is a placeholder for the Web site ID number. The Web site ID number of the default Web site is 1.
cscript adsutil.vbs get w3svc/WebSite/root/NTAuthenticationProviders
In this command, WebSite is a placeholder for the Web site ID number. The Web site ID number of the default Web site is 1.
For Example:
PS C:UsersAdministrator.contoso> cscript 'C:inetpubAdminScriptsadsutil.vbs' get w3svc/1834077867/root/NTAuthenticat
ionProviders
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
NTAuthenticationProviders : (STRING) 'Negotiate,NTLM'
If the command above does not return the string 'Negotiate,NTLM,' use the following command to enable the Negotiate process:
cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders 'Negotiate,NTLM'
cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders 'Negotiate,NTLM'
Example: cscript adsutil.vbs set w3svc/1834077867/root/NTAuthenticationProviders 'Negotiate,NTLM'
Warning: If you edit the metabase incorrectly, you can cause serious problems that may require that you reinstall any product that uses the metabase. Microsoft cannot guarantee that problems that result if you incorrectly edit the metabase can be solved. Edit the metabase at your own risk.
Note: Always back up the metabase before you edit it.
From <https://support.microsoft.com/en-us/help/215383/how-to-configure-iis-to-support-both-the-kerberos-protocol-and-the-ntl>
Check if the client and server are on the same machine:
Kerberos is not enabled in this configuration and a hard coded loopback check will always force usage of NTLM in this scenario. Note that NTLM may also not work in this configuration (see http://support.microsoft.com/kb/896861 for more details).
Workarounds:
Set DisableStrictNameChecking to 1 And
Either
[Preferred method if NTLM is needed]Create 'Multi-String Value' BackConnectionHostNames = 'HostName of the site' at location: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0
OR
Create Dword 'DisableLoopbackCheck' = 1 at location HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa
Duplicate or Wrong Service principal name set for Application Pool identity:
If a wrong SPN is set for the APP Pool identity or if there are Duplicate SPNs set, kerberos AUTHENTICATION fails because it cannot determine which account to use to Decrypt the Ticket.
We can use these SETSPN.EXE commands to check any SPN related issues:
SETSPN -L [Application Pool account] --> Will list all SPNs registered for that account.
SETSPN -X --> Will show any Duplicate SPNs
SETSPN -Q --> Can be used to Query for Specific or all SPNs.
SETSPN.EXE Usage: C:Windowssystem32setspn.exe [modifiers switch] [accountname]
Where 'accountname' can be the name or domainname
of the target computer or user account
Edit Mode Switches:
-R = reset HOST ServicePrincipalName
Usage: setspn -R accountname
-S = add arbitrary SPN after verifying no duplicates exist
Usage: setspn -S SPN accountname
-D = delete arbitrary SPN
Usage: setspn -D SPN accountname
-L = list SPNs registered to target account
Usage: setspn [-L] accountname
Query Mode Switches:
-Q = query for existence of SPN
Usage: setspn -Q SPN
-X = search for duplicate SPNs
Usage: setspn -X
Some Example commands with outputs are as below:
PS C:UsersAdministrator.contoso> SetSPN -S HTTP/Kerberos.contoso.com:9090 ContosoSPAppPool
Checking domain DC=contoso,DC=com
Registering ServicePrincipalNames for CN=SPAppPool,CN=Users,DC=contoso,DC=com
HTTP/Kerberos.contoso.com:9090
Updated object
PS C:UsersAdministrator.contoso> setspn -l contosoSPAppPool
Registered ServicePrincipalNames for CN=SPAppPool,CN=Users,DC=contoso,DC=com:
HTTP/Kerberos.contoso.com:9090
HTTP/Kerberos:9090
HTTP/Kerberos.contoso.com
HTTP/Kerberos
PS C:UsersAdministrator.contoso> SetSPN -S HTTP/Kerberos ContosoSPAppPool
Checking domain DC=contoso,DC=com
CN=SPAppPool,CN=Users,DC=contoso,DC=com
HTTP/Kerberos.contoso.com:9090
HTTP/Kerberos:9090
HTTP/Kerberos.contoso.com
HTTP/Kerberos
Duplicate SPN found, aborting operation!
PS C:UsersAdministrator.contoso> setspn -Q http/sp
Checking domain DC=contoso,DC=com
No such SPN found.
PS C:UsersAdministrator.contoso> setspn -Q */SQL
Kerberos Session Ticket
Checking domain DC=contoso,DC=com
CN=SQL,CN=Computers,DC=contoso,DC=com
MSSQLSvc/SQL.contoso.com:1433
MSSQLSvc/SQL.contoso.com
TERMSRV/SQL
TERMSRV/SQL.contoso.com
WSMAN/SQL
WSMAN/SQL.contoso.com
RestrictedKrbHost/SQL
HOST/SQL
RestrictedKrbHost/SQL.contoso.com
HOST/SQL.contoso.com
Existing SPN found!
PS C:UsersAdministrator.contoso> setspn -Q */sp
Checking domain DC=contoso,DC=com
CN=SP,CN=Computers,DC=contoso,DC=com
TERMSRV/SP
TERMSRV/SP.contoso.com
WSMAN/SP
WSMAN/SP.contoso.com
RestrictedKrbHost/SP
HOST/SP
RestrictedKrbHost/SP.contoso.com
HOST/SP.contoso.com
Existing SPN found!
PS C:UsersAdministrator.contoso> setspn -X
Checking domain DC=contoso,DC=com
__ Generates And Issues Session Keys In Kerberos 2017
Processing entry 0
found 0 group of duplicate SPNs.
So, for same Service there should not be 2 different Service accounts for which SPNs are registered otherwise IIS will not know which account to decrypt from.
Tools:
- Klist
- Kerberos Authentication tester
- Fiddler
- Microsoft network monitor
Klist.EXE:
this command-line tool helps you list and purge tickets on your client machine. You can list tickets to verify the validity of tickets. You can also check for other details, such as the permissible flags, SPN type, the client, and server details.
KLIST output (in this example, for a Site URL: http://kerberos:9090):
PS C:UsersAdministrator.contoso> klist
Current LogonId is 0:0x16958c
Cached Tickets: (2)
#0> Client: Administrator @ CONTOSO.COM
Server: krbtgt/CONTOSO.COM @ CONTOSO.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 5/6/2018 21:43:29 (local)
End Time: 5/7/2018 7:43:29 (local)
Renew Time: 5/13/2018 21:43:29 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: DC.contoso.com
#1> Client: Administrator @ CONTOSO.COM
Server: HTTP/kerberos @ CONTOSO.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 5/6/2018 21:43:29 (local)
End Time: 5/7/2018 7:43:29 (local)
Renew Time: 5/13/2018 21:43:29 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called: DC.contoso.com
So, if server does not have same Decryption mechanism (Say RC4) so it can't decrypt tickets. In that case, make sure you enable AES encryption for Service account properties.
Run these two commands below if you want to Purge user and System level Kerberos Tickets.
PS C:UsersAdministrator.contoso> klist purge
Current LogonId is 0:0x16958c
Deleting all tickets:
Ticket(s) purged!
PS C:UsersAdministrator.contoso> klist -li 0x3e7 purge
Current LogonId is 0:0x16958c
Targeted LogonId is 0:0x3e7
Deleting all tickets:
Ticket(s) purged!
Kerberos Authentication Tester (It can be found here: http://blog.michelbarneveld.nl/michel/archive/2009/12/05/kerberos-authentication-tester.aspx)
Kerberos Authentication Tester Features:
- It shows what authentication method is used in a web request: None, Basic, NTLM or Kerberos
- It shows the SPN used in case of Kerberos
- It shows the HTTP status
- It shows the HTTP Headers of the request.
- It shows the version of NTLM used (v1 or v2)
- It has a detailed view with a complete breakdown of the Authorization header. (Yep, went through all the RFCs to dissect the Kerberos and NTLM packages)
- It shows your current Kerberos tickets and allows you to remove them (like klist.exe)
The blue details link at the top right shows a new screen with the details of the request, including a breakdown of the Authorization HTTP Header. You can also save this XML.
It shows all kerb Tickets.
__ Generates And Issues Session Keys In Kerberos History
Network Monitor/WireShark: network trace capture and review tools. You can review trace to identify Kerberos errors.
Best way to get the network capture is:
1. To reduce the possibility of caching data, do one of the following:
•Close/Reopen client application
•Logoff/Logon client workstation
•Reboot client workstation
2. Start the network capture
3. Clear DNS cache using:
ipconfig /flushdns
4. Clear NetBIOS cache using:
nbtstat –RR
5. Clear user Kerberos tickets using:
klist purge
6. Clear system / computer Kerberos tickets using (Vista or higher only):
Klist –li 0x3e7 purge
7. Reproduce the authentication failure with the application in question
8. Stop the network capture
Now that you have the capture, you can filter the traffic using the string 'Kerberosv5' if you are using Network Monitor. If you are using Wireshark, you can filter using the string 'Kerberos'.
To be more thorough, load the Authentication Traffic filter that shows packets containing Kerberos tickets as well. You can do this by clicking the Load Filter button, choose Standard Filters, and then click Authentication Traffic.
OR add this Filter:
KerberosV5
OR KerberosV5.KrbError.Sname
OR KerberosV5.AsReq
OR KerberosV5.AsRep
OR KerberosV5.TgsReq
OR KerberosV5.TgsRep
Click 'Apply' to begin filtering…
In my Network trace examples below:
I am using SQL as my Client machine
192.168.2.50 is DC (KDC)
SP is SharePoint server
Analysing Network trace……………………….
First, we see AS (Authentication Server) request and response.
DC given AS response Ticket (TGT) to client.
(Service name) Sname requested and sent is krbtgt:
Sname: krbtgt/CONTOSO.COM
Then Client uses AS response Ticket to make TGS request (Service ticket) to KDC.
TGS Response ticket (Service Ticket) is sent to client by KDC.
(Service name) Sname requested and sent is HTTP:
Sname: HTTP/WebApp name
FIDDLER:
1st request will be anonymous if user is not authenticated.
401 is what we see first ……………..
Then we see 302 client Presenting kerberos Ticket to Server (SP) where server responds with a Kerberos Reply after decrypting the ticket with App Pool Identity.
If the Ticket presented by Client is valid then server moves request (302) to the page Client should be going to..
It could be home page of the Site, as in this example is:
Location: http://teams/_layouts/15/start.aspx#/SitePages/Home.aspx
In Next step, Client uses it's Original Kerberos ticket to obtain data.
SO, we see 200 …………….. And we get the page..
Then further, client uses same ticket to access the Site resources (pages, links, files etc.).
------------------------------------------------------------------------------------------------------------------------------------
And that's all you might need for almost all of your Kerberos related issues - Of Course, wrt SharePoint :)
Happy SharePointing !!
Check other Part links in this series too:
Additional References:
Kerberos RFC:
Kerberos can use a variety of cipher algorithms to protect data. AKerberos encryption type (also known as an enctype) is aspecific combination of a cipher algorithm with an integrity algorithmto provide both confidentiality and integrity to data.
Kerberos Session Denied
Enctypes in requests¶
Clients make two types of requests (KDC-REQ) to the KDC: AS-REQs andTGS-REQs. The client uses the AS-REQ to obtain initial tickets(typically a Ticket-Granting Ticket (TGT)), and uses the TGS-REQ toobtain service tickets.
The KDC uses three different keys when issuing a ticket to a client:
- The long-term key of the service: the KDC uses this to encrypt theactual service ticket. The KDC only uses the first long-term key inthe most recent kvno for this purpose.
- The session key: the KDC randomly chooses this key and places onecopy inside the ticket and the other copy inside the encrypted partof the reply.
- The reply-encrypting key: the KDC uses this to encrypt the reply itsends to the client. For AS replies, this is a long-term key of theclient principal. For TGS replies, this is either the session key of theauthenticating ticket, or a subsession key.
Each of these keys is of a specific enctype.
Each request type allows the client to submit a list of enctypes thatit is willing to accept. For the AS-REQ, this list affects both thesession key selection and the reply-encrypting key selection. For theTGS-REQ, this list only affects the session key selection.
Session key selection¶
The KDC chooses the session key enctype by taking the intersection ofits permitted_enctypes list, the list of long-term keys for themost recent kvno of the service, and the client’s requested list ofenctypes.
Starting in krb5-1.11, it is possible to set a string attribute on aservice principal to control what session key enctypes the KDC mayissue for service tickets for that principal. See set_stringin kadmin for details.
Choosing enctypes for a service¶
Generally, a service should have a key of the strongestenctype that both it and the KDC support. If the KDC is running arelease earlier than krb5-1.11, it is also useful to generate anadditional key for each enctype that the service can support. The KDCwill only use the first key in the list of long-term keys for encryptingthe service ticket, but the additional long-term keys indicate theother enctypes that the service supports.
As noted above, starting with release krb5-1.11, there are additionalconfiguration settings that control session key enctype selectionindependently of the set of long-term keys that the KDC has stored fora service principal.
Configuration variables¶
The following
[libdefaults]
settings in krb5.conf willaffect how enctypes are chosen.- allow_weak_crypto
- defaults to false starting with krb5-1.8. When false, removesweak enctypes from permitted_enctypes,default_tkt_enctypes, and default_tgs_enctypes. Do notset this to true unless the use of weak enctypes is anacceptable risk for your environment and the weak enctypes arerequired for backward compatibility.
- permitted_enctypes
- controls the set of enctypes that a service will permit forsession keys and for ticket and authenticator encryption. The KDCand other programs that access the Kerberos database will ignorekeys of non-permitted enctypes. Starting in release 1.18, thissetting also acts as the default for default_tkt_enctypes anddefaut_tgs_enctypes.
- default_tkt_enctypes
- controls the default set of enctypes that the Kerberos clientlibrary requests when making an AS-REQ. Do not set this unlessrequired for specific backward compatibility purposes; stalevalues of this setting can prevent clients from taking advantageof new stronger enctypes when the libraries are upgraded.
- default_tgs_enctypes
- controls the default set of enctypes that the Kerberos clientlibrary requests when making a TGS-REQ. Do not set this unlessrequired for specific backward compatibility purposes; stalevalues of this setting can prevent clients from taking advantageof new stronger enctypes when the libraries are upgraded.
The following per-realm setting in kdc.conf affects thegeneration of long-term keys.
- supported_enctypes
- controls the default set of enctype-salttype pairs that kadmindwill use for generating long-term keys, either randomly or frompasswords
Enctype compatibility¶
See Encryption types for additional information about enctypes.
enctype | weak? | krb5 | Windows |
---|---|---|---|
des-cbc-crc | weak | <1.18 | >=2000 |
des-cbc-md4 | weak | <1.18 | ? |
des-cbc-md5 | weak | <1.18 | >=2000 |
des3-cbc-sha1 | >=1.1 | none | |
arcfour-hmac | >=1.3 | >=2000 | |
arcfour-hmac-exp | weak | >=1.3 | >=2000 |
aes128-cts-hmac-sha1-96 | >=1.3 | >=Vista | |
aes256-cts-hmac-sha1-96 | >=1.3 | >=Vista | |
aes128-cts-hmac-sha256-128 | >=1.15 | none | |
aes256-cts-hmac-sha384-192 | >=1.15 | none | |
camellia128-cts-cmac | >=1.9 | none | |
camellia256-cts-cmac | >=1.9 | none |
__ Generates And Issues Session Keys In Kerberos 2016
krb5 releases 1.18 and later do not support single-DES. krb5 releases1.8 and later disable the single-DES enctypes by default. MicrosoftWindows releases Windows 7 and later disable single-DES enctypes bydefault.