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

Edgar Olougouna edgaro at microsoft.com
Mon Apr 6 15:57:10 MDT 2015


Andrew,

Your observation is correct, regarding this statement you initially made “It looks like it has gone from a soft to a hard error in the client code, essentially.” Please find the conclusion of the investigation as follows.
There is a Windows bug under investigation, and a document bug filed on MS-BKRP. Any document update will depend of what fix (if any) is made to Windows. 
Upon further investigation, this appears to be a bug introduced in Windows by KB2987135 (which is included in the KB299611 rollup). When retrieving the preferred master key, a change introduced a requirement for domain backup of the master key. Recall that if a preferred master key did not exist, the client creates a new one and sets it as preferred. 
With the fix installed, if the user is a domain user it will automatically attempt backing up the master key onto the DC. If the domain backup fails, it bails out the master key creation completely. 
Prior to the fix, domain backup is attempted and if it fails the client would continue and allow for the key to be created.
The same symptom has been observed with Windows-based RODC and various client applications including Credential Manager reporting error 0x80090345 SEC_E_DELEGATION_REQUIRED.

You cannot decrypt data after you encrypt it by using CredLocker in Windows 8.1 or Windows Server 2012 R2
https://support.microsoft.com/en-us/kb/2987135/

Thank you again for your patience.

Regards,
Edgar

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

On Fri, 2015-03-13 at 22:00 +0000, Edgar Olougouna wrote:
> I am concerned whether you observed any different behavior that this WBN. Are you saying that ClientWrap and ServerWrap appear to you as mandatory? 

Yes.

> 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.

This largely matches what we see, except that we don't understand what changed in this KB.  Before that KB the client did, as described, try both ClientWrap and ServerWrap calls, but credentials manager still worked if ServerWrap failed, after the KB it tries both and needs both calls. 

This brings us back to the 'how do we tell if the ClientWrap call failed (on the client side)' part of the question, and the trouble that the call happens once, and once only, during the first domain logon.

Andrew Bartlett

> 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
> 
> 
> 
> 
> 

-- 
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