For those of you that deal with Active Directory Federation Services regularly, you’re probably aware that ADFS does not now and has not ever supported Cryptography Next Generation (CNG) certificates. ADFS 3.0 is EXCEPTIONALLY sensitive about this, and won’t even install if any of the certificate you are using are using CNG keys, and you’ll end up with the following lovely error:
Install-AdfsFarm : The certificate with the specified thumbprint <REDACTED>; has a Cryptography
Next Generation (CNG) private key. The certificates with the CNG private key are not supported. Use a
certificate based on a key pair generated by a legacy Cryptographic Service Provider.
At line:1 char:1
+ Install-AdfsFarm `
+ CategoryInfo : NotSpecified: (:) [Install-AdfsFarm], DisplayableArgumentException
+ FullyQualifiedErrorId : PrerequisiteTest,Microsoft.IdentityServer.Deployment.Commands.InstallFarmCommand
In case you didn’t hear about it†, Microsoft released a new tool for management of the Local Administrator passwords for domain joined machines, Local Administrator Password Solution (LAPS) (Support KB, Download page).
This solution is configured via GPO, and causes EACH MACHINE to check the local admin account’s password expiration, and if it’s expired the machine will randomize its own password, and then store the new password in AD! Quoted from the Technet release page:
LAPS stores the password for each computer’s local administrator account in Active Directory, in a confidential attribute in the computer’s corresponding Active Directory object. The computer is allowed to update its own password data in Active Directory, and domain administrators can grant read access to authorized users or groups, such as workstation helpdesk administrators.
After years of telling us to simply disable the local admin account, and pretending domain trust failures didn’t happen, they’ve finally bit the bullet and are now offering a way to simply and easily automate local admin password management. In a single stroke, this solves three or four major security risks for domain joined machines, and automatically handles the largest source of panic admin credentials, the management of which is normally a giant manual hassle for IT departments.
†MS seems to be keeping this quiet. I heard about it from the SANS Internet Storm Center Daily Stormcast podcast this morning, who apparently found it 4 days after release by trolling new articles in the Microsoft Security TechCenter.
If you are not aware, the SANS Internet Storm Center took the unusual step yesterday to raise the internet threat level from Green to Yellow in response to the Windows HTTP service vulnerability (https://isc.sans.edu/forums/diary/MS15034+HTTPsys+IIS+DoS+And+Possible+Remote+Code+Execution+PATCH+NOW/19583/, or https://technet.microsoft.com/library/security/MS15-034 edit: fixed link to point to the correct vuln).
This vulnerability was originally published as a denial of service request; it can be used to blue screen servers with a single request. however, since it was released, it’s been discovered that this vulnerability can be used to read kernel memory, and suspicion is mounting that this could be used to exploit a server remotely with a well-crafted series of requests. Denial of service attacks ARE HAPPENING IN THE WILD RIGHT NOW.
The vulnerable component is part of the kernel library for processing HTTP request. this library is used for IIS and lots of other windows based services, for example, Exchange, Lync, and ADFS all rely on IIS for this behavior. Even some clients apps use this library for http communications.
“Heartbleed for windows” is a rough analogy, but probably more accurate than not.
This is a good opportunity to talk to your clients; First to make sure they are aware and reacting to this critical vulnerability, and if they need any help getting their security feet under them, and Second to talk about planning for the general case with patch management over the long term so this type of issue doesn’t take them by surprise in the future.