Digital code signing certificates a waste of money for Access 2007

  • Thread starter Thread starter dbguyatlanta
  • Start date Start date
To be honest, I've always thought paying a CA to authenticate who you
are is a waste of money, and especially so for Access applications
except in very rare case where the application is marketed as a
shrink-wrapped applications. But most of Access applications out there
are used almost exclusively inhouse, either developed by an employee or
by a consultant whom the manager/owner knows/trust. Thus, SSL
certifications (which requires a CA authority to "work") makes no sense
in that context.

I agree totally, a digitial certificate is a complete waste of money for
most of us delivering custom apps to customers. We just don't need it.
However, Microsoft made such a horrific mess out of the whole VBA security
scheme, I was desperate to try anything that would prevent me from having to
analyze the specific security situation of every PC at every customer I work
with. The trouble with all the work arounds is they are highly specific to
what version of Windows, whether it's a runtime or not, the user's access
privledges, etc. My customers have a wide variety of situations as far as
OS, runtime vs full access, administrative rights on their PC etc. This is a
mess.

And sure, again, I could spend hundreds of dollars and hours of learning
time on the SageKey product (which I hear is a very good product for those
that need what it does) but, all of that time/effort/money would be expended
just to shut up Microsoft's security messages. I don't need an installation
script to install my databases.
 
I could be wrong on this, but is it not the case that My Documents
is a trusted location by default? I set up a new Win7 PC the other
day with Access 2007, and put the front end in the Documents folder,
and the code ran just fine without having to mark that as a trusted
location.

Am I wrong on this?

I think it depends on the OS. I have tried placing the database in various
locations, including the Access program folder, and I have yet to find a
location that solves the problem, at least consistantly across OS's. We're
back to customizing solutions for every user situation.
 
Banana said:
On my virtual machines, I've had to add My Documents (at least I'm
pretty sure I did but my memory could be lying) -- the only
trusted location installed by default is the path to the wizards.
Now, this may be a result of different OS, perhaps, as both
machines run Windows Server 2008 or Windows Server 2008 R2.

This was A2007 on Win7.
This link lists Predefined Trust Locations and My Documents isn't
one of them

I added the folder for this app to the trusted locations, and My
Documents was not listed there. But the app ran before I added the
path to the trusted locations.
and the next paragraph recommends against using My Documents so
I'm not sure if this has chnaged somehow on Win7 in your case.
Could it have been picked up by a existing group policy?

Standalone machine, no domain, no group policy.
 
I added the folder for this app to the trusted locations, and My
Documents was not listed there. But the app ran before I added the
path to the trusted locations.

Just because it's not listed in TC doesn't mean app won't run. What
should happen is that you'd open the app with that message bar saying
the macro has been disabled with a button for you to enable. Adding the
file to the TL will only mean that you don't have to click "Enable
Content" every time you open the file. Of course, if it happened that
the file had no macros to speak of, it'll run normally. I believe
embedded macros are also exempt as well.

You may know that already but that's what came out to me as an
explanation for this.

Beyond that, I'm not sure why you didn't encounter a security warning in
your scenario.
 
=?Utf-8?B?ZGJndXlhdGxhbnRh?=
I think it depends on the OS. I have tried placing the database in
various locations, including the Access program folder, and I have
yet to find a location that solves the problem, at least
consistantly across OS's. We're back to customizing solutions for
every user situation.

I don't think Access/Office trust locations are OS-specific at all.
There are certainly differences between Windows versions as to what
permissions/privileges non-admin users have in particular folders
(basically, if it's outside their user profile, they have only
limited access), but that's been the case since Windows 2000. Sure,
Vista/Win7 makes some alterations to the specifics, but the main
principle, if you want it read/write, put it somewhere in the user
profile, stands.

I'm pretty sure that issue is completely orthogonal to the subject
of Trusted Locations.
 
Banana said:
Just because it's not listed in TC doesn't mean app won't run.
What should happen is that you'd open the app with that message
bar saying the macro has been disabled with a button for you to
enable. Adding the file to the TL will only mean that you don't
have to click "Enable Content" every time you open the file. Of
course, if it happened that the file had no macros to speak of,
it'll run normally. I believe embedded macros are also exempt as
well.

You may know that already but that's what came out to me as an
explanation for this.

Beyond that, I'm not sure why you didn't encounter a security
warning in your scenario.

Thinking back on it, I can't quite remember. I recall dismissing the
security warning, and expecting it not to run (no macros, all VBA),
but it did. I perhaps then went immediately to add it to Trusted
Locations, so maybe I was running under the enabled content for the
session, rather than it being a second session.

It's just that I was expecting that to *not* enable the code.

Or maybe I'm just remembering everything improperly.

The point is the app runs now for the client, either because My
Documents is trusted (well, Documents, since it was Win7), or
because I added it to the Trusted Locations.

It's all "security theater" not real security, and I really wish MS
would apply some common sense to it. But I think that's hopeless,
given how much they are investing in making macros usable (and
making them runnable without being trusted, and thus removing access
in the macros to functionality that is dangerous; my guess is it
won't be long before someone figures out how to exploit the
remaining so-called "safe" macro commands).
 
It's just that I was expecting that to *not* enable the code.

It may be worthwhile to point out that TC is a feature of Office, not a
feature of Access and that is more likely that when it says 'macro', it
means 'macro' in the same sense as Word and Excel would treat it - VBA
codes.

So yes, enabling content also enables not only Access macros (? I'm not
100% sure on that point -- I earlier said embedded macros were trusted
by default but I can't remember/haven't tested if regular macros are
also trusted automatically) but also VBA codes.
It's all "security theater" not real security, and I really wish MS
would apply some common sense to it. But I think that's hopeless,
given how much they are investing in making macros usable (and
making them runnable without being trusted, and thus removing access
in the macros to functionality that is dangerous; my guess is it
won't be long before someone figures out how to exploit the
remaining so-called "safe" macro commands).

TC by itself does seem to be of little use and only slightly less
obnoxious than old security dialog we get in 2003. I understand it can
be controlled via group policy and thus deny the users ability to change
the TC settings but I've not investigated into whether this makes any
difference in real security.
 
the bottom line is, Access 2007 has removed digital signing feature for accdb and accde files.

the only way to silence Microsoft's security nagging is asking every user to go through a 5-step procedure to set up a trusted location, and then store the accdb file there.

I find it both annoying and amusing that a bunch of people calling themselves MVPs pretend to show their "expertise" in Access 2007 but have no idea what they're talking about, except regurgitating Microsoft's official propaganda.


I bought a Comodo code signing certificate thinking it would rid me of
Microsoft's security message mess once and for all. It seems that in Access
2007 the certificate only applies to the intermediate file (.accdc) created
by the package and sign feature and not the actual database (.accdb) that
gets extracted from the accdc file.

When users open the accdc file, they get a chance to accept the certificate
but once the accdb file is extracted behavior returns to the usual flurry of
useless security messages. In other words, it seems like the database is
signed only for as long as its in the 'wrapper' (the accdc file) and its no
longer signed once its extracted.

Am I missing something?
On Thursday, April 01, 2010 9:42 PM Arvin Meyer [MVP] wrote:
Lots of folks are unhappy with code signing certificates for different
reasons. Rather than try to diagnose the problem you can work around it by
building a trusted location:

http://office.microsoft.com/en-us/access/HA100319991033.aspx
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.accessmvp.com
http://www.mvps.org/access
 
the bottom line is, Access 2007 has removed digital signing
feature for accdb and accde files.

There was never any effective way to do that in previous versions of
Access.
the only way to silence Microsoft's security nagging is asking
every user to go through a 5-step procedure to set up a trusted
location, and then store the accdb file there.

Or to use group policies. If you've got enough users that it would
be a pain to do it manually (or by running a registry script), then
you're probably in a domain and should ask your sysadmin to push out
the change in group policy.
I find it both annoying and amusing that a bunch of people calling
themselves MVPs pretend to show their "expertise" in Access 2007
but have no idea what they're talking about, except regurgitating
Microsoft's official propaganda.

I consider all of these security "features" as implemented by MS
going back to A2003 (or was it 2002?) to be "security theater," so I
find it quite annoying myself. But MS does have procedures that it
has set up for handling all of this, so I don't really understand
why you would rag on "MVPs" about pointing to MS's instructions when
your beef is with MS, instead.

And who are you, for that matter? Why should we give the comments of
some random stranger any credence at all, as opposed to a proven
Access guru like Arvin Meyer, who has repeatedly shown himself able
to provide definitive help and answers for a wide variety of
questions going back more than a decade?
 
the bottom line is, Access 2007 has removed digital signing feature for accdb and accde files.

the only way to silence Microsoft's security nagging is asking every user to go through a 5-step procedure to set up a trusted location, and then store the accdb file there.

Or use the Auto FE Updater which sets the Trusted Location for you.
Or set the registry key for the user. Mind you the user will have to,
once, go through the nag screens. But then once the code is
successfully executing you can see if the registry key exists and if
not set it yourself.

Note that you do not need to use Location0, Location1, etc. in the
registry key. Instead you can use whatever you want in there so I'd
suggest using the name of your app. Using Location0, etc, also
means that you might wipe out a users Trusted Location setting.
I find it both annoying and amusing that a bunch of people calling themselves MVPs pretend to show their "expertise" in Access 2007 but have no idea what they're talking about, except regurgitating Microsoft's official propaganda.

It'd be nice if you'd trim the postings too.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
 
It'd be nice if you'd trim the postings too.

I'd be happy with word wrapping (which is actually required by the
standards for properly formatted Usenet posts, though most Microsoft
Usenet clients ignore this fact).
 
Back
Top