Blog - Title

August, 2013

  • Important Announcement: AD FS 2.0 and MS13-066

    Update (8/19/13):

    We have republished MS13-066 with a corrected version of the hotfixes that contributed to this problem.  If you had held off on installing the update, it should be safe to install on all of your ADFS servers now.

     

    The updated security bulletin is here: http://technet.microsoft.com/en-us/security/bulletin/MS13-066

     

    Thanks everyone for your patience with this one.  If anyone is still having trouble after installing the re-released update, please call us and open a support case so that our engineers can get you working again!

    ===============================================================

     

     

    Hi everyone, Adam and JR here with an important announcement.

    We’re tracking an important issue in support where some customers who have installed security update MS13-066 on their AD FS 2.0 servers are experiencing authentication outages.  This is due to a dependency within the security update on certain versions of the AD FS 2.0 binaries.  Customers who are already running ADFS 2.0 RU3 before installing the update should not experience any issues.

    We have temporarily suspended further downloads of this security update until we have resolved this issue for all ADFS 2.0 customers. 

    Our Security and AD FS product team are working together to resolve this with their highest priority.  We’ll have more news for you soon in a follow-up post.  In the meantime, here is what we can tell you right now.

     

    What to Watch For

    If you have installed KB 2843638 or KB 2843639 on your AD FS server, you may notice the following symptoms:

    1. Federated sign-in fails for clients.
    2. Event ID 111 in the AD FS 2.0/Admin event log:

    The Federation Service encountered an error while processing the WS-Trust request. 

    Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue 

    Additional Data 

    Exception details: 

    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Could not load
    type ‘Microsoft.IdentityModel.Protocols.XmlSignature.AsymmetricSignatureOperatorsDelegate' from assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.


       at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService..ctor(SecurityTokenServiceConfiguration securityTokenServiceConfiguration)

       --- End of inner exception stack trace ---

       at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)

       at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

       at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)

       at Microsoft.IdentityModel.Configuration.SecurityTokenServiceConfiguration.CreateSecurityTokenService()

       at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.CreateSTS()

       at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.CreateDispatchContext(Message requestMessage, String requestAction, String responseAction, String
    trustNamespace, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, WSTrustSerializationContext serializationContext)

       at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginProcessCore(Message requestMessage, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, String requestAction, String responseAction, String trustNamespace, AsyncCallback callback, Object state)

    System.TypeLoadException: Could not load type 'Microsoft.IdentityModel.Protocols.XmlSignature.AsymmetricSignatureOperatorsDelegate' from assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

       at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService..ctor(SecurityTokenServiceConfiguration securityTokenServiceConfiguration)

     

    What to do if the problem occurs:

    1. Uninstall the hotfixes from your AD FS servers.
    2. Reboot any system where the hotfixes were
      removed.
    3. Check back here for further updates.

    We’ll update this blog post with more information as it becomes available, including links to any followup posts about this problem.

  • MD5 Signature Hash Deprecation and Your Infrastructure

    Hi everyone, David here with a quick announcement.

    Yesterday, MSRC announced a timeframe for deprecation of built-in support for certificates that use the MD5 signature hash. You can find more information here:

    http://blogs.technet.com/b/srd/archive/2013/08/13/cryptographic-improvements-in-microsoft-windows.aspx

    Along with this announcement, we've released a framework which allows enterprises to test their environment for certificates that might be blocked as part of the upcoming changes (Microsoft Security Advisory 2862966). This framework also allows future deprecation of other weak cryptographic algorithm to be streamlined and managed via registry updates (pushed via Windows Update).

     

    Some Technical Specifics:

    This change affects certificates that are used for the following:

    • server authentication
    • code signing  
    • time stamping
    • Other certificate usages that used MD5 signature hash algorithm will NOT be blocked.

    For code signing certificates, we will allow signed binaries that were signed before March 2009 to continue to work, even if the signing cert used MD5 signature hash algorithm.

    Note:  Only certificates issued under a root CA in the Microsoft Root Certificate program are affected by this change.  Enterprise issued certificates are not affected (but should still be updated).

     

    What this means for you:

    1) If you're using certificates that have an MD5 signature hash (for example, if you have older web server certificates that used this hashing algorithm), you will need to update those certificates as soon as possible.  The update is planned to release in February 2014; make sure anything you have that is internet facing has been updated by then.

    You can find out what signature hash was used on a certificate by simply pulling up the details of that certificate's public key on any Windows 8 or Windows Server 2012 machine.  Look for the signature hash algorithm that was used. (The certificate in my screenshot uses sha1, but you will see md5 listed on certificates that use it).

    If you are on Server Core or have an older OS, you can see the signature hash algorithm by using certutil -v against the certificate.

    2) Start double-checking your internal applications and certificates to insure that you don't have something older that's using an MD5 hash.  If you find one, update it (or contact the vendor to have it updated).

    3) Deploy KB 2862966 in your test and QA environments and use it to test for weaker hashes (You are using test and QA environments for your major applications, right?).  The update allows you to implement logging to see what would be affected by restricting a hash.  It's designed to allow you to get ahead of the curve and find the potential weak spots in your environment.

    Sometimes security announcements like this can seem a little like overkill, but remember that your certificates are only as strong as the hashing algorithm used to generate the private key.  As computing power increases, older hashing algorithms become easier for attackers to crack, allowing them to more easily fool computers and applications into allowing them access or executing code.  We don't release updates like this lightly, so make sure you take the time to inspect your environments and fix the weak links, before some attacker out there tries to use them against you.

    --David "Security is everyone's business" Beach