Kerberos encryption types - an account persists in using RC4

Question

question

ZoranMarjanovic-4735 asked Jul 21, '20 ZoranMarjanovic-4735 answered Nov 27, '20

Kerberos encryption types - an account persists in using RC4

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

windows-server-security azure-sql-virtual-machines

· 2

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

FanFan-MSFT · Jul 22, 2020 at 05:40 AM

Hi,

In order to narrow down the issue, would you please help collect the information below?
What's the functional level for your domain?
Is it a single domain in your environment?
Any trust created for the domain?
What's the error when you connect to the SQL server?

Best Regards,

0 ·

ZoranMarjanovic-4735 · Jul 22, 2020 at 06:17 AM

FFL and DFL are Windows 2012 R2.
I have 4 forests, 2 with 2 domains and 2 with a single domain. The problem manifests in both cases.
There are no forest trusts, but there are domain trusts in the forests with multiple domains. Domain trusts are configured for RC4, AES128 and AES256 following the instructions from
https://support.microsoft.com/en-us/help/4492348/kerberos-unsupported-etype-error-when-authenticating-across-trust
I use udl file to test connection and, when SQL server is restricted to AES256, an error pops up: "Test connection failed because of an error in initializing provider. Cannot generate SSPI context".

Thanks

0 ·

Answer 1 · 2020-11-27T08:36:58.827Z

ZoranMarjanovic-4735 answered Nov 27, '20

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.

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Answer 2 · 2020-07-22T07:56:39.673Z

ZoranMarjanovic-4735 answered Jul 22, '20 FanFan-MSFT commented Jul 27, '20

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

· 2

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

FanFan-MSFT · Jul 23, 2020 at 01:53 AM

Hi,
From my side, i would try to capture a network package and check more details about the whole Kerberos processes.
And confirm the error happened on which process.

Best Regards,

0 ·

FanFan-MSFT · Jul 27, 2020 at 02:28 AM

Hi,
Welcome to share your current situation.
Please feel free to let us know if you need further assistance.

Best Regards,

0 ·

Answer 3 · 2020-11-26T14:50:58.623Z

SumanBhowmik answered Nov 26, '20

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.

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

question