Skip to content

NT4Crypto Settings in 2008R2 onwards


I am writing a doc for a client which is a questionnaire for their application teams to provide some information about how their applications interact with AD. This will help the client determine compatibility of their applications for a forthcoming 2003 > 2012 AD upgrade. Much of what they need to worry about is documented, but there still remained the question of the NT4.0 Cryptography settings. This KB article explains how to disable it, but not what it actually does, besides saying that it disallows ‘old’ or ‘weak’ or ‘NT4-style’ algorithms. Since the apps could be UNIX/Linux based using Samba or middleware platforms I needed to ask those teams exactly what their app was doing, not whether it was ‘using NT4-style algorithms’ (What are the algorithms? used for what?).

I decided to take a look through MS-NRPC (the netlogon remote specification) and it turns out that this controls the RejectDES parameter, which is used during secure channel creation (NetrServerAuthenticate3):

RejectDES SHOULD be initialized in an implementation-specific way and SHOULD default to TRUE. Implementations that use Windows registry to persistently store and retrieve the RejectDES variable SHOULD use the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Netlogon\Parameters registry path and AllowNT4Crypto key set to negation of the RejectDES variable.

RejectDES: A Boolean variable that indicates whether the server MUST reject incoming clients using DES encryption in ECB mode.

So that explains it. NT4 (and older versions of Samba) will attempt to create a secure channel with a DC using DES encryption. Prevention of this is analogous to the 2008R2 settings which disallow DES for Kerberos, and which are another key question on the questionnaire for any app support team.

There is also a RejectMD5Clients value listed in the MS-NRPC that isn’t really explained, apart from being able to deduce that it only apples to Win7/2008R2 and onwards. However I found this on a Samba forum, an explanation from a MSFT tech about how these two values are implemented:

So that even prevents 2000/XP/2003/Vista/2008 clients from establishing a secure channel, although I don’t think there is a corresponding GPO option for that (yet).

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: