Share via

Kerberos encryption types - an account persists in using RC4

Zoran Marjanovic 96 Reputation points
2020-07-21T14:14:33.943+00:00

I enabled RC4, AES128 and AES256 across all enabled computers and users in a domain/forest and now all tickets are encrypted with AES256, except those issued for SQL access. SQL 2016 servers run on Windows 2019 and SQL compatibility level is set to 130. I tried disabling RC4 for accounts running SQL service and SQL reporting service, but the end users kept receiving RC4 tickets and connecting successfully. When I disabled RC4 for the SQL computer, the end users were unable to connect to the SQL server.

Is there something in SQL that needs to be configured for AES to be used for Kerberos ticket encryption?

Thanks
Zoran

SQL Server on Azure Virtual Machines
Windows for business | Windows Server | Devices and deployment | Configure application groups

Answer accepted by question author

Zoran Marjanovic 96 Reputation points
2020-11-27T08:36:58.827+00:00

The problem was related to old user accounts created in pre-AES AD whose passwords were never reset. 2 password resets, with full AD replication in between, enables AES support.

Was this answer helpful?

0 comments

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Suman Bhowmik 76 Reputation points
    2020-11-26T14:50:58.623+00:00

    Hi,
    First and foremost, if the server and the computers are in different domain, this behavior is expected as trust by default supports RC4.
    If that is the case, you may need to enable AES from trust properties.

    Was this answer helpful?

    0 comments
  2. Zoran Marjanovic 96 Reputation points
    2020-07-22T07:56:39.673+00:00

    I did some more testing and managed to eliminate SQL as a possible cause. I created a new gMSA account, registered SQL SPN and used it to run SQL service and SQL agent on a test server. Now when I restricted both gMSA and the server account to AES256, it still worked. So it seems it's something with the old SQL service account which has been around probably since Windows 2000, but it's not the only one from that time, but it's the only one causing this issue.

    Replacing this account across the domain is a bit tricky as it has 1000+ SPNs registered, configured Kerberos delegation for dozens of apps etc, so preferred way would be to fix it at this stage.

    Is there something in the account's setting that could prevent it from using AES for Kerberos encryption?

    Thanks

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.