Adobe Reader Trust Manager Updates
I am trying to deploy Adobe Reader and I'm having some trouble with the "Load trused root certificates from an Adobe server" setting in Reader.
We have had some reports from users stating they had received a security update notification popup message in Adobe Reader with the option of downloading a new update. If the user selected the "ok" button the update appeared to install without issue. Upon researching this,
we found that the update was not an application upgrade but a certificate update for the Trust Manager in Adobe Reader. The Trust Manager will periodically check for updates and download certificates from a "Trusted Adobe Server" after notifying the user that a "Security Update" is available for download. We typically disable any update activity not handled by configuration management.
I downloaded the Adobe Customization Wizard and disabled this setting in the acroread.mst file. The setting I changed was the "Load trusted roots certificates from Adobe" dropdown box located in the "Online Features" section of the "Online and Acrobat.com Features" tab in the Customization Wizard. After the setting was disabled, the installation tested in our lab environment. Unfortunately, if this setting was previously enabled, in the earlier version of Adobe Reader, then it would remain enabled.
The installation script use, runs an uninstall of the previous version of Adobe Reader, installs the latest full version, and then applies patches to bring Adobe Reader to the currently required version. We do this to avoid conflicts caused by pre-existing installations and to consistently maintain desired application settings across our enterprise. We used this method successfully, in the past, for our deployments of the Adobe Reader 9.1.x series of version upgrades.
I have used RegMon to try to determine which keys are effected when the "Load trusted roots certificates from Adobe server" option is applied and disabled in the Configuration Preferences of Adobe Reader. I added those registry entries to the acroread.mst file via the Adobe Customization Wizard Registry Editor to try and turn off this feature directly within the mst file. I also located a security key for Adobe Reader in the .default key of HKey_Users and added a command to remove that key in our install script if it is detected before the updated application is installed, to prevent inheritance of the pre-existing setting. When the updated install package was tested it yielded the same results as before.
So, I'm looking for a collection of smart people to set me straight.
I have access to an older Admin Studion install so I can edit files if necessary. Is there a way make sure this setting stays unchecked during the install of Adobe Reader. I guess I could look at diabling the feature entirely, but I would like to keep my options open in case we need users to change the change in the future.
Thanks!
We have had some reports from users stating they had received a security update notification popup message in Adobe Reader with the option of downloading a new update. If the user selected the "ok" button the update appeared to install without issue. Upon researching this,
we found that the update was not an application upgrade but a certificate update for the Trust Manager in Adobe Reader. The Trust Manager will periodically check for updates and download certificates from a "Trusted Adobe Server" after notifying the user that a "Security Update" is available for download. We typically disable any update activity not handled by configuration management.
I downloaded the Adobe Customization Wizard and disabled this setting in the acroread.mst file. The setting I changed was the "Load trusted roots certificates from Adobe" dropdown box located in the "Online Features" section of the "Online and Acrobat.com Features" tab in the Customization Wizard. After the setting was disabled, the installation tested in our lab environment. Unfortunately, if this setting was previously enabled, in the earlier version of Adobe Reader, then it would remain enabled.
The installation script use, runs an uninstall of the previous version of Adobe Reader, installs the latest full version, and then applies patches to bring Adobe Reader to the currently required version. We do this to avoid conflicts caused by pre-existing installations and to consistently maintain desired application settings across our enterprise. We used this method successfully, in the past, for our deployments of the Adobe Reader 9.1.x series of version upgrades.
I have used RegMon to try to determine which keys are effected when the "Load trusted roots certificates from Adobe server" option is applied and disabled in the Configuration Preferences of Adobe Reader. I added those registry entries to the acroread.mst file via the Adobe Customization Wizard Registry Editor to try and turn off this feature directly within the mst file. I also located a security key for Adobe Reader in the .default key of HKey_Users and added a command to remove that key in our install script if it is detected before the updated application is installed, to prevent inheritance of the pre-existing setting. When the updated install package was tested it yielded the same results as before.
So, I'm looking for a collection of smart people to set me straight.
I have access to an older Admin Studion install so I can edit files if necessary. Is there a way make sure this setting stays unchecked during the install of Adobe Reader. I guess I could look at diabling the feature entirely, but I would like to keep my options open in case we need users to change the change in the future.
Thanks!
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
LoreHunter
14 years ago
After some hunting, we found that the key\DWORD that controls this behaior is:
HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\9.0\Security\cDigSig\cAdobeDownload\bLoadSettingsFromURL
If this value is set to "0" on all user profiles then our problem is solved.
I found a batch file that loads the user hive and makes a modification and then unloads the hive. It's a work in progress but it works in manual testing (pasted below):
===============================
@echo off
setlocal
set regcmd=%SystemRoot%\system32\reg.exe
set keypath=Software\Adobe\Acrobat Reader\9.0\Security\cDigSig\cAdobeDownload
set valuename=bLoadSettingsFromURL
:: update current user
set hive=HKCU
set key=%hive%\%keypath%
%regcmd% add "%key%" /v %valuename% /d 0x00000000 /t REG_DWORD /f >nul
:: update all other users on the computer, using a temporary hive
set hive=HKLM\TempHive
set key=%hive%\%keypath%
:: set current directory to "Documents and Settings"
cd /d %USERPROFILE%\..
:: enumerate all folders
for /f "tokens=*" %%i in ('dir /b /ad') do (
if exist ".\%%i\NTUSER.DAT" call :AddRegValue "%%i" ".\%%i\NTUSER.DAT"
)
endlocal
REM echo.
REM echo Finished...
REM echo.
REM pause
REM goto :EOF
EXIT
:AddRegValue
set upd=Y
if /I %1 equ "All Users" set upd=N
if /I %1 equ "LocalService" set upd=N
if /I %1 equ "NetworkService" set upd=N
if %upd% equ Y (
%regcmd% load %hive% %2 >nul 2>&1
%regcmd% add "%key%" /v %valuename% /d 0x00000000 /t REG_DWORD /f >nul 2>&1
%regcmd% unload %hive% >nul 2>&1
)
================================
When I run this file manually from an elevated account, it performs exactly as intended.
When I try to run it using SCCM downloaded from the distribution point, not only does it not work but it doesn't leave any indication that anything failed in the logs.
Any ideas on this one?
Thanks!
HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\9.0\Security\cDigSig\cAdobeDownload\bLoadSettingsFromURL
If this value is set to "0" on all user profiles then our problem is solved.
I found a batch file that loads the user hive and makes a modification and then unloads the hive. It's a work in progress but it works in manual testing (pasted below):
===============================
@echo off
setlocal
set regcmd=%SystemRoot%\system32\reg.exe
set keypath=Software\Adobe\Acrobat Reader\9.0\Security\cDigSig\cAdobeDownload
set valuename=bLoadSettingsFromURL
:: update current user
set hive=HKCU
set key=%hive%\%keypath%
%regcmd% add "%key%" /v %valuename% /d 0x00000000 /t REG_DWORD /f >nul
:: update all other users on the computer, using a temporary hive
set hive=HKLM\TempHive
set key=%hive%\%keypath%
:: set current directory to "Documents and Settings"
cd /d %USERPROFILE%\..
:: enumerate all folders
for /f "tokens=*" %%i in ('dir /b /ad') do (
if exist ".\%%i\NTUSER.DAT" call :AddRegValue "%%i" ".\%%i\NTUSER.DAT"
)
endlocal
REM echo.
REM echo Finished...
REM echo.
REM pause
REM goto :EOF
EXIT
:AddRegValue
set upd=Y
if /I %1 equ "All Users" set upd=N
if /I %1 equ "LocalService" set upd=N
if /I %1 equ "NetworkService" set upd=N
if %upd% equ Y (
%regcmd% load %hive% %2 >nul 2>&1
%regcmd% add "%key%" /v %valuename% /d 0x00000000 /t REG_DWORD /f >nul 2>&1
%regcmd% unload %hive% >nul 2>&1
)
================================
When I run this file manually from an elevated account, it performs exactly as intended.
When I try to run it using SCCM downloaded from the distribution point, not only does it not work but it doesn't leave any indication that anything failed in the logs.
Any ideas on this one?
Thanks!
Posted by:
MSIPackager
14 years ago
Seems like a hard way to get this to all users... Rather, you could use active setup to ensure this setting delivered - you only need to call this command line from and active setup routine:
C:\Windows\system32\reg.exe add "HKCU\Software\Adobe\Acrobat Reader\9.0\Security\cDigSig\cAdobeDownload " /v bLoadSettingsFromURL /d 0x00000000 /t REG_DWORD /f
There is loads of info on active setup on appdeploy, but you can start here: http://www.etlengineering.com/installer/activesetup.txt
You can then send this job out via SCCM to all affected workstations and rest assured that every user that logs on will get this applied.
Hope this helps,
Rob.
C:\Windows\system32\reg.exe add "HKCU\Software\Adobe\Acrobat Reader\9.0\Security\cDigSig\cAdobeDownload " /v bLoadSettingsFromURL /d 0x00000000 /t REG_DWORD /f
There is loads of info on active setup on appdeploy, but you can start here: http://www.etlengineering.com/installer/activesetup.txt
You can then send this job out via SCCM to all affected workstations and rest assured that every user that logs on will get this applied.
Hope this helps,
Rob.
Posted by:
anonymous_9363
14 years ago
Alternatively, have you tried whether the value works "globally" when moved to the HKLM hive?
BTW, the original setting would have worked, except that it would have been for the System user, since that's the account with which SCCM installs.
BTW, the original setting would have worked, except that it would have been for the System user, since that's the account with which SCCM installs.
Posted by:
LoreHunter
14 years ago
Yup I tried having the settings in HKLM during some of my earlier attempts. RegMon had shown that HKLM was the first place it looked for these settings. However, when I created the entry Reader ignored it it favor of whatever it could find in HKCU.
I did make one discovery, the batch file works if the user is in a logged off state or the file is run from an elevated account. I can only figure that the system account might trouble loading the user hive if a user is actively looged in. This might have more to do with our security settings than regular windows behavior.
I did make one discovery, the batch file works if the user is in a logged off state or the file is run from an elevated account. I can only figure that the system account might trouble loading the user hive if a user is actively looged in. This might have more to do with our security settings than regular windows behavior.
Posted by:
LoreHunter
14 years ago
MSIPackager,
I just did a quick browse and this looks like a pretty slick way to get the job done! I'll add the changes to my package and test it today.
I just did a quick browse and this looks like a pretty slick way to get the job done! I'll add the changes to my package and test it today.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.