Month: May 2015

Write Conflict

Aaron Croasmun is a epic level contributor to the Service Manager forums, and he’s helped me personally out on several occasions.

Now, much like Prometheus (the allegory, not the terrible film), he has gifted for us something that will change the very nature of humanity. Ok, well, just the people who use service manager anyways.

Aaron has single-handedly solved the “This item cannot be updated because it has been changed by another user or process” write conflict error.

<pause for the shocked murmur of disbelief in the audience to die down>

Anyone who wishes to leave now and secure a copy from Technet Galleries may be excused. (more…)


ADFS CNG Certificates

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


Running LAPS around local admin credentials

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.