STIG/CIS/Best Practices stops Acrobat loading PDFs from over the network

We’ve been running STIG configuration with Adobe Acrobat DC Classic & Continuous versions for a while with no issues until early 2019 when users started not being able to load PDFs from over the network anymore.  Acrobat would say it was blocking loading PDFs from the internet and then give the address it was blocking of SMB://FileServerName.Domain.Org/Path/EvilPDF.pdf which is clearly not on the internet.  It seems sometime in Feb 2019 an update to Acrobat altered this behavior.  The confusing part of this was that some users could continue to load PDFs from the same location while others could not.

  1. Firstly the reason for some being able to load them and others not being able to is because Acrobat is like Office in that it stores in the user’s registry trusted locations.  If a user added a document or location to their trusted locations prior to STIG/CIS/BP configuration being implemented on their system those allowances will continue to exist and be respected by Acrobat and Office in that user’s profile even though the usage of trust lists is disabled.
  2. Secondly the change in Acrobat that started this issue seems to only happen when the FQDN of a share server is used.  If you use \\ShortName\Path\EvilPDF.pdf or even \\IPAddress\Path\EvilPDF.pdf then Acrobat lets the file through without problem.  Once you use the FQDN Acrobat thinks you’re connecting to the internet.
The GPO is located at both of these locations depending on what version of Acrobat your support.
Computer Configuration -> Administrative Templates -> Adobe Acrobat Pro DC Classic -> Preferences -> Trust Manager
Computer Configuration -> Administrative Templates -> Adobe Acrobat Pro DC Continuous -> Preferences -> Trust Manager
The setting that causes the issue is this one;
Access to websites = Block PDF files access to all web sites
The problem is that now that this thinks FQDN shares are on the internet how do you allow them without allowing everything on the internet because there’s no GPO setting to designate between either.  Buried in the Adobe documentation is the registry configuration you can set to allow a white list of URLs in a REG_SZ called tHostPerms which has no corresponding GPO value.
The first step is to set the GPO value above Access to websites = Custom setting which tells Acrobat to then use the trust list we’re about to define.  The trust list lets you define allowed and blocked websites but when in Custom mode it will block everything except for what you place in the allow portion.  Then create a Computer Configuration -> Preferences -> Windows Settings -> Registry GPO entry for the following.
  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockdown\cDefaultLaunchURLPerms
    • REG_SZ = tHostPerms
    • Value = version:2|URL:#|URL:#|URL:#
      • # = behavior
      • 2 = allow
      • 3 = block
    • Example = version:2|FileServerName.Domain.Org:2||

Note 1: You have to leave the http(s):// off the front of the FQDN for it to work for SMB shares.  I tried using the smb:// notation but never got it to work in testing.

Note 2: the Adobe documentation states 1 is block but I found through actually creating block entries that 3 is what the latest Acrobat DC puts in the registry for that.

Once this populates out to your users they can once again open PDFs from the network shares when using FQDNs.

Active Directory user accounts keep losing inheritable permissions?

Do you have Active Directory accounts and use a password reset management tool like Thycotic’s Password Reset and out of the blue some accounts just stop being able to be managed?  We did and I stumbled across the solution while trying to resolve something else.  We were using another tool to discover “sensitive” accounts for targeting for other security changes and found this was returning accounts that were clearly not in any sensitive account groups.

Get-ADUser -Filter {AdminCount -eq 1} | Select-Object DistinguishedName

Well what exactly is AdminCount?

AdminCount: Indicates that a given object has had its ACLs changed to a more secure value by the system because it was a member of one of the administrative groups.

Further reading and comments on forums I found that if an account was ever in a domain administrative group the AdminCount is set to 1 in the attributes of the account.  Even after an account is removed from one of these groups the AdminCount is not set back to 0 but left at 1.  You can try setting it to 0 but if the account is still in one of those groups it’ll be reset back to 1 by the PDC every hour.

I then stumbled on a comment in a forum stating if an account has AdminCount = 1 then AD stops it from inheriting permissions.  Wait what, I have that issue too!  It clicked then that the accounts that we continued to have issues with the password reset tool were these same accounts.  In the past for whatever reason they had been in a privileged account group and no longer belonged to it and this AdminCount was still set to 1.  I edited these accounts in the Active Directory Users and Computers mmc on the Attribute Editor tab and just set the value to 0.  As I mentioned above the account will return to this being set to 1 if it is still in privileged account groups.  I then went to the Security tab and Advanced and ensured the Include inheritable permissions from this object’s parent was checked.  Now these accounts no longer have issues with the password reset tools!