Question Enable all Macros Settings an evil must? (1 Viewer)

[IAccess]

Why does one have to enable all macros in the trust center in order for VBA to run?

I'm making front end applications with Access and having to allow ALL macros to make them user friendly makes a huge hole in general security. I don't use any macros - it's all done by VBA.

Users are on a plethora of different platforms so changing reg keys is out of the question. Is there some way of self sign an Access accde?

Is there some safe GENERAL approach (trusted sites is not good either) to allowing VBA from my applications ONLY?

 

[Pat Hartman]

I agree. This is a problem. I think it is caused because Word/Excel macros use VBA. Access macros don't use VBA but Access VBA gets wrapped up in the security around Word/Excel.

At some point, you could buy a certificate (annual fee) and use that to sign your Access databases. Then the user would get the prompt the first time but once he trusted your signature, then he wouldn't be bothered again and you didn't have to change the macro security level. I think I read somewhere that the certificate method no longer works but don't quote me on it.

 

[Galaxiom]

I think I read somewhere that the certificate method no longer works but don't quote me on it.

The use of Digital Signatures directly on a file was depecated in accd* files introduced in 2007.

It was a huge step backwards. Now anyone can simply put a file into a Trusted Location and it opens without warning. Previously domain group policies could be configured to completely control which files were allowed to run scripts by simply including a signature in the allowed files.

However it is still fully supported in md* files and they work fine up to at least Access 2010 including the runtime.

It is one of the reasons I still distribute mde files and will continue to do so for the forseeable future. (The other reason is that there are no features of any critical consequence added to the later format.)

Now a signature can only be used on a package. Apparently it allows the package to be unpacked into a Trusted Location.

In a domain environment there is no need to buy a certificate. Set up the Certificate Server on a Domain Controller and make your own.

 

[Pat Hartman]

Even databases running from trusted locations still put up a security warning when they open. The SageKey installer gets around this and databases packaged and installed with it open without the security warning but I don't know how they do it.

 

[IAccess]

In a domain environment there is no need to buy a certificate. Set up the Certificate Server on a Domain Controller and make your own.

Thanks! That seems like the approach I want to take.
In terms of implementing it - any advise?

 

[Galaxiom]

This thread is a start. Much of it equally applies to distributing SelfCert certificates but the CertSvr issued ones which are much better in the long run.

Setting up and using the Certificate Server is quite a learning curve. It is not installed on the server by default.

One gotcha I will repeat is that the time to certificate expiry must be set during the original installation. It defaults to one year and once it is installed this can't be changed. You have to reinstall to change it and connecting with previously issued certificates is complex and it is easy to lose them forever.

Requesting the right kind of certificate is also not exactly obvious. You need an Advanced Certificate and mark the key as exportable. Use a PKCS10 format.

Another thing I have learnt since is that the first certificate generated should be used only to certify another certificate which is the one then used to issue the certificates used on the files. This allows any subsequent certificates and all their downstream chains to be revoked without revoking everything issued by the cert server.