Windows GPO: Disable Adobe Updater for CS3 and CS4

We’ve known for a while that Adobe updates are too frequent and too large and annoying when you have a couple of hundred machines on the network with the Master Collection installed. Recently, we installed Viewpoint to give us reporting from our Sonicwall firewall, and we saw the impact that Adobe updates had on our internet connection and it was staggering. Adobe updates and Apple iTunes updates were the bulk of our traffic, which is no mean feat when we have 900 Students in the Senior School on Facebook.

Viewpoint_AdobeUsage 
Web Usage Report from Viewpoint

Luckily, Adobe have a registry key that can be used to enable/disable the Adobe Updater, and pushing the entry out to clients via Group Policy seems like the sensible option
http://kb2.adobe.com/cps/408/kb408711.html

On Windows XP or Windows Vista

  1. Using Regedit.exe, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe
  2. Create a new Key in this folder named "Updater"
  3. Create a new DWORD value within this Key named "Enterprise with a value of "1"

To try it out, I created the registry entries on my local machine and imported the entries into a new GPO with the Registry Wizard (Right Click on Registry in the Computer Configuration, and select New –> Registry Wizard)

AdobeGPO1 
Registry Keys imported into GPO

 
AdobeGPO2 
Registry Entries, Action set to Update

It’s important to remember to still update the Adobe applications, especially Acrobat and Flash. The Sophos Security Threat Report 2010 highlights the need to keep these two applications up to date. Malicious code can be executed from flash files embedded in PDF documents, Sebastian Porst has a superb write up on dissecting the Adobe/Flash exploit here, if you’ve got 10 minutes grab a coffee and read up.

You can download the Acrobat Updates manually from Adobe, and push them out to clients with msiexec.exe, check AppDeploy for specifics with your version of Acrobat, but something like this would do the trick

msiexec /p "%installdir%\AcroProStdUpd910_T1T2_incr.msp" /qn /norestart REINSTALL=ALL REINSTALLMODE=omus

msiexec /p "%installdir%\AcrobatUpd912_all_incr.msp" /qn /norestart REINSTALL=ALL REINSTALLMODE=omus

Which is from the Adobe forums and push it out with a script or via GPO

Random AD User Account Lockout

user-account-control-icon The last few weeks we’ve had a problem with one of our IT Staff user accounts where it would regularly get locked out during the day. We suspected some of the Students were trying to guess the password for the account and were probably hoping to get around our web content filter….

This made me realise, we’ve never really looked for account lockouts and and where/why/how they might be happening on the network. I wasn’t excited about scouring the security event logs on our domain controllers to find the info I needed. A quick search brought up the Account Lockout and Management Tools from Microsoft which has been around since 2003, but was new to me. I probably should have been a bit sharper on that one.

One of the applications in the download is that LockoutStatus. This app will take the AD username and return the lockout status and bad password count on each DC for that user.

lockoutstatus

After finding the lockout status if the user you then use the EventCombMT app to search the event logs of the domain controllers. EventCombMT can search the event logs for any event ID but to find events with login issues, I limited the search to the Security logs on the DC’s with event ID’s 529 644 675 676 and 681. More info on usage here

EventComb

EventCombMT produces a text file for each server with the results of the search:

644,AUDIT SUCCESS,Security,Wed Apr 14 10:21:08 2010,NT AUTHORITY\SYSTEM,User Account Locked Out:     Target Account Name: zdjb     Caller Machine Name: STNB4200ZKLC     Caller User Name: IDM$     Caller Domain: TEACH     Caller Logon ID: (0x0,0x3E7)   

644,AUDIT SUCCESS,Security,Wed Apr 14 10:08:14 2010,NT AUTHORITY\SYSTEM,User Account Locked Out:     Target Account Name: zdjb      Caller Machine Name: STTB2710ZJLW     Caller User Name: IDM$     Caller Domain: TEACH     Caller Logon ID: (0x0,0x3E7)  

Straight away I could see the two machines that were causing the account lockout and after calling them back into the Service Desk so we could see what was going on. We were able to work out that it was the Sophos Auto Update causing the problem because these machines had been using the credentials  of this account, with an old password, for receiving updates instead of the update account we normally use.

Solving the problem of the account lockout has prompted some new strategies for monitoring the network that we hadn’t considered before. Now that we have the tools, we can regularly search the event logs for bad passwords on Administrator accounts and follow up the results. Also, we may have started the ball rolling on a project to create more user accounts in AD for different network services. It was lucky that we’d found Sophos was the culprit, but next time it could be difficult to find old credentials being used in an Altiris job for example. By creating different user accounts for services like Sophos, Altiris Jobs, SQL, Exchange and Intranet applications it will help narrow down a search next time we have a password problem and will make it easier to change these passwords on a regular basis.