[cifs-protocol] [REG:115012312316449] Re: Protocol changes in KB2992611 [115012312316449]

Edgar Olougouna edgaro at microsoft.com
Fri Mar 13 16:00:54 MDT 2015


I am concerned whether you observed any different behavior that this WBN. Are you saying that ClientWrap and ServerWrap appear to you as mandatory? 

3.2.4.1 Performing Client-Side Wrapping of Secrets

<18> Section 3.2.4.1: Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 fall back to server-side wrapping using BACKUPKEY_BACKUP_GUID when they fail to retrieve the server's public key using BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID.
In addition, as noted earlier, Windows clients always retry failing operations once. The resulting process is as follows: The client first tries the BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID operation and, if it fails, performs DC rediscovery and retries the same operation. If the retry fails, the client tries a BACKUPKEY_BACKUP_GUID operation. If this fails, the client performs DC rediscovery again and retries the BACKUPKEY_BACKUP_GUID operation. If this also fails, an error is returned to the caller.

<19> Section 3.2.4.1: Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 always use version 2. Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 use version 2 by default but can be configured to use version 3 by setting the DWORD registry value "HKLM\Software\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb\Recovery Version" to 3.

Thanks,
Edgar


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org] 
Sent: Wednesday, March 11, 2015 10:44 PM
To: Edgar Olougouna
Cc: MSSolve Case Email
Subject: Re: [REG:115012312316449] Re: [cifs-protocol] Protocol changes in KB2992611 [115012312316449]

On Sat, 2015-03-07 at 22:01 +1300, Andrew Bartlett wrote:
> On Sat, 2015-03-07 at 05:43 +0000, Edgar Olougouna wrote:
> > When you review the certificate produced for ClientWrap, can you double check the size of the certificate and the size of its signature, especially in case of X509 ECC or DSA signature?
> > I wonder whether there is any anomaly during certificate signature verification check.
> 
> A part of the history is that we started our effort to fix this by 
> doing two things:
>  - We took a patch from Arvid of Univention, who noticed 6 months ago 
> that another aspect of Windows (IE password save) wouldn't work until 
> the RSA Key for ClientWrap was corrected to be 2048 bits exactly.
>  - As that wasn't enough, we started an implementation of ServerWrap.
> 
> It certainly could be the key or certificate.  The library we use to 
> generate the certificate is unusual (Heimdal Kerberos).
> 
> We know the private key passes tests against OpenSSL (we had an error 
> during re-implementation that we had to debug), but I'll go over this 
> again.
> 
> I'll also give you the public and private keys it generates, perhaps 
> you can poke it at a validation tool in current and pre-patched 
> Windows and see if it shows errors.
> 
> All that said, how can we manually trigger or trace the ClientWrap 
> calls, and wow can we know if this was the issue?

I get these in the logs, at startup, and then no other BackupKey
traffic:

Client unknown requested certificate for client wrapped secret
(018FF48A-EABA-40C6-8F6D-72370240E967)
Client unknown requested a server wrapped secret
(7F752B10-178E-11D1-AB8F-00805F14DB40)

I'm presuming this second call is encrypting the local master key on the KDC, as described in the other references, but what I want to know is why does it do this, was the ClientWrap call not enough?

I checked with an un-patched Windows, and it also calls:

Client unknown requested certificate for client wrapped secret
(018FF48A-EABA-40C6-8F6D-72370240E967)
Client unknown requested a server wrapped secret
(7F752B10-178E-11D1-AB8F-00805F14DB40)

during the logon (and no additional calls during open of credentials manager).

This puts (mostly) to rest the idea that the ClientWrap call fails, but I would love a way to trace that for you, during the logon.  It then raises the question again of why ServerWrap went from optional to mandatory. 

Finally, can we put this back on cifs-protocol at lists.samba.org and into the public domain?

Thanks,

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba






More information about the cifs-protocol mailing list