Tag Archive: kerberos

Reference articles to secure a Windows domain:


Microsoft audit Policy settings and recommendations:


Sysinternals sysmon:


On ADsecurity.org:

Beyond domain admins: https://adsecurity.org/?p=3700

Gathering AD data with PowerShell: https://adsecurity.org/?p=3719

Hardening Windows computers, secure Baseline check list: https://adsecurity.org/?p=3299

Hardening Windows domain, secure Baseline check list:

Securing Domain Controllers to Improve Active Directory Security

Domain hardening in general:

  • Implement 2 or 3 tier model against Pass the Hash threat
  • FGPP implementation
  • LAPS Implementation
  • Process for proper cleanup of unused AD accounts
  • Reset of krbtgt account,domain admins account,IT administrators account
  • Setting Up Jump servers for Tier0,1,2 users
  • Domain joining of all windows boxes
  • Proper account Management Based on privileges
  • Usage of service accounts to run application instead of local system accounts
  • Review of existing AD accounts/Deletion of Unnecessary Accounts/ Review Ou structuring/GPO etc
  • HoneyToken Account Creation in Local boxes as well domain
  • GPO changes for disabling guest accounts across system,restricted RDP mode,Password Policy changes,disabling internet in member servers
  • GPO for Jump server implementation based on PAW GPO settings
  • Rename existing builtin Administrator account and lockdown
  • Sysmon deployment and WEF setup (WEC for symon events)
  • Use Pingcastle www.pingcastle.com  review to assess the AD security
  • Use Bloodhound (https://github.com/BloodHoundAD/BloodHound) to assess the AD security
  • Use ADTimeline to assess the AD security


Some interesting sites:

Windows hardening: https://wp.me/p15Zft-Mr

Privilege admin workstation: https://wp.me/p15Zft-Mr

Delegate WMI access to domain controllers:

This post originally came about after several customers asked how to remove users accounts from Domain Admins and the Administrators group in the domain. These accounts are needed to monitor the systems, so we needed to find a way to get them to read the instrumentation of the system with non-elevated privilege.



When you connect to remote Server Message Block (SMB) services shares by using \\192.x.y.z\share name, Kerberos is not used, and the Internet Protocol (IP) SMB file share access does not use Kerberos. A network trace shows the following Kerberos error in the KRB_ERROR: Server not found in Kerberos database


By default, Microsoft Windows Server 2003 and Microsoft Windows 2000 try to use Kerberos as the security provider. When a client uses Kerberos to authenticate itself to a server, the client requests a session ticket for the Service Principal Name (SPN). IP addresses are not names, so Kerberos is not used. After this occurs, the server goes through the list of the other supported security providers.


This behavior is by design.
IP addresses typically change, and it is not workable to add these addresses as SPNs. An SPN can be one of the following:

•The DNS name for the domain.
•The DNS name of a host.
•The distinguished name of a service connection point object.

This might be very useful for certain situations where you want to update a user’s or computer’s group membership without the need to re-logon / restart. The whole magic is behind the issued kerberos tickets after you logged on to a machine or a machine has been started. The tool “klist.exe” cannot only be used for troubleshooting to display the current issued TGT / TGS, it is also capable to purge all current tickets. The purge command results in a re-issuance of the tickets, as soon as the next auth or service request is taking place.

Keep in mind that this method only works for services which authenticate via Kerberos.

NTLM based authentication still requires a fresh logon with updated group membership token.

To purge a user’s tickets: klist purge

To purge tickets of the local system account: Start a cmd or PoSH session with elevated privileges: klist -li 0:0x3e7 purge

klist is a tool that has been included by default since Vista/Server 2008 and above.

If you have a old version of Windows then you’re required to download klist here:

Be aware then the 2003/XP version of klist does not support purging directly the system accoun’s tickets. You can use psexec from sysinternals to launch an interactive command line as the system account (psexec -s -i cmd.exe) and then execute klist purge)

To generally control the lifetime of Kerberos tickets consider the following article: http://technet.microsoft.com/en-us/library/Dd277401.aspx

SSSD principle:

SSSD for SuSE (sles):






Troubleshooting SSSD:


Resolution:   id  <userid> ; getent passwd <userid>

Authentication: ssh <userid>@localhost


In addition to redhat guide, there are tones of interesting links:



Reference article: https://technet.microsoft.com/en-us/library/cc759300(v=ws.10).aspx

Kerberos uses SPNs extensively. When a Kerberos client uses its TGT to request a service ticket for a specific service, the service is actually identified by its SPN.  The KDC will grant the client a service ticket that is encrypted in part with a shared secret that the service account as identified by the AD account that matches the SPN has (basically the account password).

In the case of a duplicate SPN, what can happen is that the KDC will generate a service ticket that may be created based on the shared secret of the wrong account.  Then, when the client provides that ticket to the service during authentication, the service itself cannot decrypt it and the auth  fails.  The server will typically log an “AP Modified” error and the client will see a “wrong principal” error code.

So, duplicate SPNs are very bad, much in the same way that duplicate UPNs are bad.  Both can cause Kerb auth to break and Windows uses Kerb for auth everywhere it can.


To identify duplicated accounts:

you can use the command: setspn -q <service/server:port> ; to find SPN duplicate on the forest
orusing setspn -L <computername> ; to list the SPN associated to a computer AD object

or by looking Event ID 11, source KDC on Domain controllers event log

To configure IIS with Kerberos,

It is explained in the technet blog:


In short, you must follow the Technet blog, you  must configure your IIS to use Kerberos authentication (IIS manager option) and for constrained delegation (remove the default applicationpool where your web service is running) create a specific technical domain account ie. mydomain\acctiiskerb

Then assigned to this account, a SPN must be created (on our side only),
using the command like: Setspn -a HTTP/iisserver.mydomain.local acctiiskerb

and modify the acctiiskerb settings (using the ADUC: Delegation TAB for this user account must be also configured properly).


When Kerberos was chosen to be AD’s authentication protocol in the mid- to late-1990s, the World Wide Web was a shadow of what the Internet offers today. Although the Kerberos ticket contained an encrypted password hash that could be attacked, there wasn’t any substantial requirement to provide support outside the highly protected corporate firewall.

The rise of cloud services is changing many aspects of our lives, and these services don’t support external authentication via Kerberos because of that password vulnerability. If a web service uses standards, it handles claims-based authentication using SAML 2.0 or, increasingly, OAuth 2.0 and OpenID Connect. Microsoft’s own Azure Active Directory doesn’t use Kerberos; it supports SAML and OAuth 2.0 as its authentication protocols.


Comparing oauth with ws-fed and SAML: https://blogs.technet.microsoft.com/askpfeplat/2014/11/02/adfs-deep-dive-comparing-ws-fed-saml-and-oauth/



Wikipedia Article: OAuth



OAuth in details

OAuth is an authorization method to provide access to resources over the HTTP protocol.


OAuth2 can be used for authorization of various apps (server/browser/mobile)and desktop applications or manual user access.

The general way it works is allowing an application to have an access token (which represents a user’s permission for the client to access their data) which it can use to authenticate a request to an API endpoint.

Oauth 2 flow

A sample OAuth flow: Facebook

OAuth versions

There are two versions of OAuth authorization OAuth 1 (using HMAC-SHA signature strings) and OAuth 2 (using tokens over HTTPS).

Note: SoapUI currently only offers Oauth2 authorization.

OAuth 2 terms

Conceptually, OAuth2 haas a few components interacting: The resource server (the API server) contains the resources to be accessed. Access tokens are provided by the authorization server (which can be the same as the API server). The tokens are provided by the resource owner (the user) when accessing the resources. Similarly, an application using the credentials, and the API is called client.

End Points

The token Endpoint is used by clients to get an access token (and optionally refresh token) from the authorization server.

Note: When using implicit grant, this endpoint is not used. Instead the access token is sent from the authorization endpoint directly.


The two token types involved in OAuth 2 authentication are Access Token and Refresh Token.

Access Token

The access token is used to for authentication and authorization to get access to the resources from the resource server.

Refresh Token

The refresh token normally is sent together with the access token.

The refresh token is used to get a new access token, when the old one expires. Instead of the normal grant type, the client provides the refresh token, and receives a new access token.

Using refresh tokens allows for having a short expiration time for access token to the resource server, and a long expiration time for access to the authorization server.

Token Types

Access tokens have a type, which defines how they are constructed.

Bearer Tokens

The bearer tokens use HTTPS security, and the request is not signed or encrypted. Possession of the bearer token is considered authentication.

MAC Tokens

More secure than bearer tokens, MAC tokens are similar to signatures, in that they provide a way to have (partial) cryptographic verification of the request.


Methods to get access tokens from the authorization server are called grants. The same method used to request a token is also used by the resource server to validate a token.

The four basic grant types are Authorization Code, Implicit, Resource Owner Credentials and Client Credentials.

Note: SoapUI currently only offers the grant types Code Grant and Implicit.

Authorization Code

With authorization_code grant, the resource owner allows access. An authorization code is then sent to the client via browser redirect, and the authorization code is used in the background to get an access token. Optionally, a refresh token is also sent.


The implicit grant is similar to authorization code, but instead of using the code as an intermediary, the access token is sent directly through a browser redirect.

Not yet in SoapUI Resource Owner Credentials

The password/Resource Owner Credentials grant takes the uses the resource owner password to obtain the access token. Optionally, a refresh token is also sent. The password is then discarded.

Not yet in SoapUI Client Credentials

In client_credentials grant mode, the client’s credentials are used instead of the resource owner’s. The access token is associated either with the client itself, or delegated authorization from a resource owner.

Grant Type Extensions

OAuth has a mechanism for extending grant types as a bridge to other authorization frameworks, or for specialized clients.

Extension grants are used by clients through an absolute URI together with a grant_type parameter and by adding any additional parameters necessary to the end point.


In OAuth 2, the scope is a way to restrict access to specified areas. A common way of handling it is with a comma-separated or space-delimited list of strings, where each string indicates an areas of access.


ADFS 2016 and OAuth/OpenID connect:






400 error is seen by the end user when trying to access a IIS web site that has Windows Authentication enabled.  Not all users see this behavior.  The user might be a member of several Active Directory groups.


When a user logs into a workstation on the domain, a kerberos authentication ticket is created which contains the user’s Active Directory group information.  When the browser (i.e. IE) is performing pass through authentication (i.e. Windows Authentication aka IWA), it sends this kerberos ticket in the header of the request so that IIS can consume the user information.  If the user is a member of many AD groups, their kerberos ticket may exceed that allowable limit specified on the IIS server side (in this case, the ADFS signin page).

Company mergers and acquisitions often result in Active Directory domain migrations. My experience has been that in many cases, these migrations are done with limited time set aside for any type of cleanup of group memberships. Often you’re dealing with years of accumulation of groups and unfortunately it seems with little documentation on what groups may not be necessary anymore. Post-migration, you have Active Directory objects stamped with SID History and possibly hundreds of groups that may or may not be necessary but no one has the time to research them to find out.

The downside to ending your migration here is that the SID History and stale group memberships all roll up into the client’s Kerberos token size. When the Kerberos token becomes excessively large, it can start to produce one issue after another.


Issues start to arise once the user’s Kerberos token exceeds 12,000 bytes; the user will start to run into odd issues with authentication and possibly Group Policy. You’ll find some organizations work around this by setting the “MaxTokenSize” setting in the workstation’s registry to the maximum value of 48,000 bytes (the actual maximum is 65,535 but the recommended is 48,000 for reasons beyond the scope of this post).

Other reference: http://blogs.technet.com/b/surama/archive/2009/04/06/kerberos-authentication-problem-with-active-directory.aspx



The relevance to AD FS is that during the AD FS authentication, the HTTP request sent to IIS contains the Kerberos token in the HTTP header. IIS has a HTTP header size limit of 16,384 bytes by default; after you account for base64 conversion and overhead, you’re really looking at around 12,000 bytes available for your Kerberos token.

During AD FS authentication, users with tokens in the 12,000 bytes range will fail to authenticate. What the users will see, if they look closely enough, is an “HTTP 400 – Bad Request” response from the AD FS server.

Solution / Workarounds

Since the restriction here is the IIS header size, fixing just the AD FS servers may not be enough. You could certainly have other IIS-based applications in your environment that would experience the same error. The ideal solution would be to reduce the group memberships to the point that the Kerberos token size is in the allowable range. Unfortunately, this cleanup can’t always happen so the alternative is to increase the limits.

The keys “MaxFieldLength” and “MaxRequestBytes” can be added to the registry on the AD FS server and this will allow for a larger HTTP header to accommodate the large Kerberos token. Additional information on these values and their recommended maximums is available in Microsoft KB2020943. A reboot of the AD FS server after applying this change and the users with large Kerberos tokens should be able to authenticate successfully.

Token Calculation

Calculating the user’s token size is a somewhat complicated process. The token size will depend on the type of groups the user is a member of, the group nestings and the SID history in the environment. The Microsoft utility “Tokensz.exe” is probably your best estimate for the token size.

Additional Information

In Windows 7 and Server 2008 R2, the DES encryption types for the Kerberos authentication protocol are disabled by default.

This can cause compatibility problems if one of your legacy applications is hard-coded for only DES encryption or if the Windows account that runs a service (the service account) is configured to use only DES encryption. These services or applications will fail unless you reconfigure them to support another encryption type (RC4 or Advanced Encryption Standard, AES) or you enable DES support.

Impacted services/systems: spnego sourceforge, J2EE, java, Unix, Linux with Centrify v3.x or greater, CVS, Samba, Kerberos v5 on Linux …

typically for Centrify look the KB articles:




Out-of-the-box Windows 7 and Server 2008 R2 machines support the AES (to be more precise, AES128_HMAC_SHA1, AES256_HMAC_SHA1) and RC4 (RC4_HMAC_MD5) Kerberos encryption types. Microsoft only added support for the AES encryption type in Server 2008, Windows Vista, and later OSs. AES is newer and a stronger encryption algorithm than DES. The RC4 encryption algorithm has been supported by Windows Kerberos since the Windows 2000 release and is still supported in Windows 7 and Server 2008. The Kerberos logic on domain controllers will switch to AES encryption when you change your Active Directory (AD) domain to the Server 2008 domain functional level.

Encryption Key length MS OS Supported
AES256-CTS-HMAC-SHA1-96 256-bit Windows 7, Windows Server 2008 R2
AES128-CTS-HMAC-SHA1-96 128-bit Windows Vista, Windows Server 2008 and later
RC4-HMAC 128-bit Windows 2000 and later
DES-CBC-MD5 56-bit Windows 2000 and later, off by default in Win7/R2
DES-CBC-CRC 56-bit Windows 2000 and later, off by default in Win7/R2

To check whether one of your applications or services are hard-coded to use only DES encryption, you can run a network trace when the application or service starts and check the content of the Etype fields in the Kerberos authentication headers.

To determine whether an AD user or computer account is configured for only DES encryption, you must check whether the Use Kerberos DES encryption types for this account option is set on the Account tab in the object properties (which you can access from the AD Users and Computers MMC snap-in).

If you find that you’re affected by this problem, you can enable DES encryption for Kerberos authentication on Windows 7 or Server 2008 R2 using the Group Policy Object setting Network security: Configure encryption types allowed for Kerberos located in the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options GPO container.

Microsoft has documented explanations and examples with workaround in this reference web article: http://support.microsoft.com/kb/977321/en-us

User accounts that use DES encryption for Kerberos authentication types cannot be authenticated in a Windows Server 2003 domain after a Windows Server 2008 R2 domain controller joins the domain: http://support.microsoft.com/kb/978055

=> KDC Event ID 16 or 27 is logged if DES for Kerberos is disabled:

If you conclude that you are affected by this issue and that you have to turn on the DES encryption type for Kerberos authentication, enable the following Group Policies to apply the DES encryption type to all computers that are running Windows 7 or Windows Server 2008 R2:

  1. In the Group Policy Management Console (GPMC), locate the following location:
    Computer Configuration\ Windows Settings\ Security Settings\ Local Policies\ Security Options
  2. Click to select the Network security: Configure encryption types allowed for Kerberos option.
  3. Click to select Define these policy settings and all the six check boxes for the encryption types.
  4. Click OK. Close the GPMC.

Note The policy sets the SupportedEncryptionTypes registry entry to a value of 0x7FFFFFFF. The SupportedEncryptionTypesregistry entry is at the following location:


Depending on the scenario, you may have to set this policy at the domain level to apply the DES encryption type to all clients that are running Windows 7 or Windows Server 2008 R2. Or, you may have to set this policy at the organizational unit (OU) of the domain controller for the domain controllers that are running Windows Server 2008 R2.

Web resources:

Hunting DES on your network:

These auditing actions are part of the Account Logon category. For more details on these review these two KBs: