none
Server 2019 DC - Kerberos RC4 Authentication RRS feed

  • Question

  • We have recently promoted a 2019 Server to be a domain controller but it won't authenticate access to our EMC VNX datastore which we believe only supports RC4 Kerberos - is there anyway to enable RC4 Kerberos in Server 2019 as it appears to have been removed?


    (Using the IIS Crypto tool we can see the 2019 server does not have any RC4 ciphers)


    Access to the EMC VNX datastore works from 2012 and 2016 DC's.

    Access from the 2019 server to all other devices on the network also work (we can see these using AES encryption via the klist utility)


    I can see no documentation suggesting any changes around Kerberos in server 2019

    Monday, June 3, 2019 6:28 PM

All replies

  • Hi,

    Have done some research about it ,for your reference:

    Enable RC4 Cipher on Server 2016 https://social.technet.microsoft.com/Forums/en-US/72eac68d-6ab4-4729-96c6-3aee5246d662/i-need-to-enable-rc4-cipher-on-server-2016?forum=winserversecurity

    https://support.microsoft.com/en-us/help/3151631/rc4-cipher-is-no-longer-supported-in-internet-explorer-11-or-microsoft

    Kerberos with Service Principal Name (SPN):                                                                 https://docs.microsoft.com/en-us/windows-server/networking/sdn/security/kerberos-with-spn

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, June 4, 2019 6:25 AM
  • Thank you, however;

    1. The issue is the Cipher does not appear in the list in 2019 - its not that is not enabled, it appears to not be there. (It is listed on 2016 servers)

    2. Nothing to do with internet explorer / browser - our issue is Windows AD Kerberos authentication

    3. We don't use SPN

    Tuesday, June 4, 2019 6:37 AM
  • Hi,

    Kerberos protocol registry entries and KDC configuration keys in Windows,

    Applies to: Windows Server, version 1903Windows Server 2019, all versionsMicrosoft Windows Server 2003 Datacenter Edition (32-bit x86)

    https://support.microsoft.com/en-us/help/837361/kerberos-protocol-registry-entries-and-kdc-configuration-keys

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, June 4, 2019 6:39 AM
  • Thanks for the information but it hasn't helped. Server 2019 DC will not authenticate with a RC4 Kerberos client...
    Wednesday, June 5, 2019 11:40 AM
  • Hi,

    Have you checked the registry? If the rc4 is not set in the registry, i think we may need to create it manually .

    Best Regards,

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, June 6, 2019 1:36 AM
  • I have tried adding it through the IISCrypto tool which I understand sets the registry. I also tried adding the cipher using gpedit Computer Configuration, Administrative Templates, Network, SSL Configuration Settings, SSL Cipher Suite Order

    Using klist I can see the Kerberos ticket is created and it shows RC4 however the connection fails and we get a "modified" error on the server and "failed to create kerbpac" error on the datastore, so one end or other is failing to decrypt the ticket.

    We have triple checked all the usual things like SPN records and we have no CNAME entries but this problem is specific to just the 2019 DC's (we have 4 all with the same issue), earlier DC's work fine.

    I have also seen https://social.technet.microsoft.com/Forums/en-US/05b74c9c-7a80-4a03-8136-455cba9f95cc/windows-xp-and-active-directory-2019 which I am assuming is the same issue relating to XP - obviously XP is not supported and you will not support our VNX datastore, but I can't see any documentation that highlights this significant change in 2019, and I was hoping that there would be a setting on 2019 that would allow us to use the older authentication method.

    I guess it could be a simple change in key length...

    Our datastore support company have promoted a 2019 server and confirmed the issue is reproducible unfortunately they cannot provide an update to the datastore to resolve the issue

    Happy to try something if you have any specific suggestions... really would appreciate any help you can give

    Friday, June 7, 2019 11:14 AM
  • Hi,

    I am sorry that this issue still hasn't been resolved.

    I have't heard there is any change for this either .

    If there is no progress, I would suggest you contact Microsoft Customer Services and Support to get an efficient solution:

    http://support.microsoft.com/contactus/?ln=en-au

    Have a nice day!

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, June 10, 2019 7:31 AM
  • Hello Andy,

    we seem to have the exact same problem. We recently deployed our first 2019 DC in a mixed domain that holds 2008R2 DCs and 2012R2 DCs. Our clients are mainly Windows 10 with some Windows 7 remaining. In general everything works fine, except when we try to connect to our older EMC VNX NAS servers. In the case where the client obtains a ticket for these systems from the new 2019 DC we receive an error on the client

    "\\blabla is not accessible.... The target account name is incorrect"

    and on the DC

    Event ID 4, Security-Kerberos "The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server CIFS/blabla...."

    The Kerberos ticket on the client looks just fine:

              Client: <user> @ <DOMAIN>
              Server: cifs/blabla.domain.com @ <DOMAIN>
              KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
              Ticket Flags 0xa10000 -> renewable pre_authent name_canonicalize
              Start Time: 11/12/2019 16:06:19 (local)
              End Time:   11/13/2019 2:04:38 (local)
              Renew Time: 11/19/2019 16:04:38 (local)
              Session Key Type: RSADSI RC4-HMAC(NT)
              Cache Flags: 0
              Kdc Called: <DCName>

    But access simply does not work. When the ticket is obtained from a 2012R2 DC it looks exactly the same in klist but works perfectly. And to make things even more complex we also run an EMC ISILON storage system. When connecting to this system we also receive a token looking like the one above (RC4-HMAC) from the 2019 DC. But this ticket works.

    Have you been able to solve this problem somehow?

    Thanks for your help (or anybody else's)

    HarryNew

    Tuesday, November 12, 2019 4:29 PM
  • No sadly we have no solution. We are looking at a work around to put in an intermediate server to share out our EMC block storage rather than using the EMC CIF shares but is far from ideal.

    I couldn't find any information as to the change introduced in 2019 that causes this.

    Let me know if you find a solution!!

    Tuesday, November 12, 2019 5:05 PM
  • Hello Andy,

    thanks for your answer. I will post findings here.

    Some more research seems to imply that the problem only occurs on writable DCs. We have deployed a number of RODCs and don't have any problems with the tickets issued by these.

    What type of DC are you using? Can you confirm this difference?

    Regards

    HarryNew

    Wednesday, November 13, 2019 9:04 AM
  • We don't have any RODCs - we've added 2019 in to our environment but due to this issue we have them shut down and just turning them on for 10 mins every couple of weeks so that they update and don't get too far behind. The issue only affects DC's, we have 2019 servers that are not DC's that work fine (presumably because they don't generate the Kerberos ticket. I'm convinced its something to do with RC4 but run out of ideas to investigate/try

    Andy

    Wednesday, November 13, 2019 10:13 AM
  • I've read through this article and see no answer provided.

    We have recently promoted new Windows Server 2019 servers to Domain Controllers and are running into the same issue.

    We have since enabled RC4 encryption on each DC, which now allows us to see a Kerberos Ticket request.

    We've enabled SMBv1 as a test, and modified the Security Policy 'Network Security: LAN Manager authentication level' to equal "Send LM & NTLM - use NTLMv2 session security if negotiated", and the default "Send NTLMv2 response only" to no success.

    We have not tried setting LAN Manager to NT & NTLM, and we have not modified any Cipher Suites.

    If no one has found a solution, I'll call in for support.

    Monday, December 16, 2019 9:38 PM
  • Hi,

    I am sorry that this issue still hasn't been resolved.

    If there is no progress, I would suggest you contact Microsoft Customer Services and Support to get an efficient solution:

    http://support.microsoft.com/contactus/?ln=en-au

    Have a nice day!

    Fan


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, December 17, 2019 1:31 AM
  • We have no solution yet - please post here if you get one :-)
    Tuesday, December 17, 2019 11:00 AM
  • Any chance there's an update to this issue, we have exactly the same problem, seeking answers!? ;)

    Thursday, July 23, 2020 1:05 PM