user level security alternative in 2007
JeffP
reports.
What is the best, or any, solution for restricting access to forms and
reports in 2007 which doesn't support ULS?
![Tony Toews [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVFNFhAO8kxGtutFBSPYzx5Lbrrty7WRKPHNhjuWtTEHvsoQdk=s40-c)
Tony Toews [MVP]
A2007 still supports ULS in MDB file format. You do give up the user of the new
field types such as multi valued fields which are only available in ACCDB file
format.
T
--
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/
Granite Fleet Manager http://www.granitefleet.com/
Tom van Stiphout
wrote:
If you are on a domain, you can use the techniques discussed here:
http://www.accesssecurityblog.com/post/Securing-Access-databases-using-Active-Directory.aspx
-Tom.
Microsoft Access MVP
JeffP
"Tom van Stiphout" <tom7744...@cox.net> wrote in message
news:u3uov51sun9g2sh13...@4ax.com...
JeffP
"Tony Toews [MVP]" <tto...@telusplanet.net> wrote in message
news:2sqov5li5e4r6j75b...@4ax.com...
Tony Toews [MVP]
>It is already a 2007 format database Tony. No going back.
Are you using the new features though? If not sure you can go back.
Tony
JeffP
no going back. And in this case I don't think reverting back to a MDB format
is a good solution.
They will move with the versions so it will only be a matter of time.
"Tony Toews [MVP]" <tto...@telusplanet.net> wrote in message
news:cg7pv5p2tdj07r1r6...@4ax.com...
jwither
the only problem is that local groups aren't shared to
other computers. (the sharing is what the Active part
of Active Directory is).
On a single computer you wouldn't have to do that -
the groups are there, it's just not well known. They
are the local version of domain groups.
A user-level mdb "workgroup" is just a database
with a table listing groups and a table listing members.
The only magic about it is the ID's can be associated
with Forms and Tables in an MDB database. Since
Tom's techniques don't depend on that magic, Tom's
techniques, (although not the directory lookup code)
can be used with your any database, not just an AD
or LD database. That is, you can re-write his code to
use groups and users maintained in a 2007 database.
(david)
"JeffP" <no-r...@asken.com.au> wrote in message
news:1LudnbeNx5iBC2HW...@westnet.com.au...
David W. Fenton
news:0rmdndL1_OgaAmHW...@westnet.com.au:
> Not really at the moment, but the clients IT guys stipulated 2007
> format so no going back. And in this case I don't think reverting
> back to a MDB format is a good solution.
MDB is a native format for A2007. It's just not the *new* format.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
David W. Fenton
> If you are on a domain, you can use the techniques discussed here:
> http://www.accesssecurityblog.com/post/Securing-Access-databases-us
> ing-Active-Directory.aspx
Two comments on that:
1. why if it's a domain logon does it matter what the setup on the
workstation is? Aren't you getting the information from the domain
controller?
2. why use AD for simply working with NTFS security groups -- you
can already get group membership information without needing to
interface with AD. The only advantage I can see to AD is if your
domain uses Organizational Units. In 2004 I was in a situation where
I easily could have used Organization Units to control access to
data in an app that was hosted on Windows Terminal Server. But at
the time, nobody had done the work with AD code to make it easy in
Access.
JeffP
Anyway, I won't be going back and I need to find a reasonably good way of
doing this.
"David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
news:Xns9D84AE0A6D5FFf9...@74.209.136.88...
Tom van Stiphout
<XXXu...@dfenton.com.invalid> wrote:
Re 1: I don't understand your question. The workstation matters little
since the groups information comes from the AD computer (typically the
PDC).
Re 2: I see the benefits as:
* AD is a relatively well-known feature.
* It has a decent UI to create groups and assign people
* It is widely available (all domains)
* It is therefore pretty much idiot-proof
Hey David, the invitation is still open to write an article for this
blog. Maybe one about the intersection of Security and Replication?
-Tom.
Microsoft Access MVP
zucke...@gmail.com
You can restrict access to the navigation pane, the ribbon, and
disable the shift-bypass key. Then, make sure everything your users
need is accessible from buttons on your forms. Then, restrict access
to the buttons as you desire. I've only found one "hole" with this
security method. The method I use to grant myself acess to the
navigation pane & ribbon, is potentially "re-createable" by others.
But in my organization it's doubtful that anyone could figure it out.
It involves using a separate database that opens the application and
enables the navigation pane, the ribbon, and the shift-bypass key.
Good Luck,
Fred
David W. Fenton
news:Z-OdnaMIyshjTmDW...@westnet.com.au:
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
> news:Xns9D84AE0A6D5FFf9...@74.209.136.88...
>> "JeffP" <no-r...@asken.com.au> wrote in
>> news:0rmdndL1_OgaAmHW...@westnet.com.au:
>>
>>> Not really at the moment, but the clients IT guys stipulated
>>> 2007 format so no going back. And in this case I don't think
>>> reverting back to a MDB format is a good solution.
>>
>> MDB is a native format for A2007. It's just not the *new* format.
>
> But for how long? Surely moving forward with the new format is
> better.
That's a different question. I was only responding to what you
report as the reason IT is requiring it.
> Anyway, I won't be going back and I need to find a reasonably good
> way of doing this.
MS's philosophy is that if you need data security, you use a
different data store (i.e., not ACE/ACCDB).
But what MS forgets about is the aspects of ULS that allowed
developer control of access to objects in the front end. They offer
nothing to replace that, and code protection in a front end is
pretty problematic.
David W. Fenton
> On 26 May 2010 21:10:57 GMT, "David W. Fenton"
><XXXu...@dfenton.com.invalid> wrote:
>
> Re 1: I don't understand your question. The workstation matters
> little since the groups information comes from the AD computer
> (typically the PDC).
Then I don't understand this passage:
Own workstation and user account
The solution presented here depends on a Windows user's membership
in various Active Directory groups. We will ask Windows who is
logged in to the computer, and then ask Active Directory which
groups this user is a member of. If several users with different
security levels share the same computer in a common area, or if
several users with different security levels login on several
computers as the same Windows user, this solution is not for you.
I dont see how it's relevant if multiple users use the same
computer, as if you request info from AD, you'll get the correct
information regardless of who is logged on.
> Re 2: I see the benefits as:
> * AD is a relatively well-known feature.
So is NTFS security.
> * It has a decent UI to create groups and assign people
NTFS security groups are created/managed through the same UI. That
is, and AD group is just a representation of an NTFS group.
> * It is widely available (all domains)
So is NTFS security.
> * It is therefore pretty much idiot-proof
NTFS is moreso, because it's less elaborate.
You haven't provided a single justification for AD over use of NTFS
security via API calls in an Access app. Sure, LDAP queries and all
that are handy if you're working from a database that can't make API
calls, but that's not the case in an Access app.
As I said, the only reason I ever wanted to use AD was for something
that exists only in AD and not in NTFS security (i.e.,
Organizational Units, which indicated geographical location in the
domain I was working in).
> Hey David, the invitation is still open to write an article for
> this blog. Maybe one about the intersection of Security and
> Replication?
I wouldn't know what to say on that subject.
I also consider it moribund, though still quite useful for the
random travelling laptop user. In terms of security, it's the same
as security without replication, so I don't see any utility in
joining the two subjects.
Tom van Stiphout
<XXXu...@dfenton.com.invalid> wrote:
I meant: several users using the same computer in a common area AT THE
SAME TIME, i.e. the computer is logged in by some user, and several
others walk up there from time to time and do some work without
logging in as themselves.
-Tom.
Microsoft Access MVP
Tom van Stiphout
<XXXu...@dfenton.com.invalid> wrote:
Also, after reading all your "me too" answers: perhaps we are talking
about the same thing, and it is just a matter of semantics. If not,
post a link and maybe I can update the blog post.
-Tom.
Microsoft Access MVP
Arvin Meyer
support it, there would be millions (maybe as many as hundreds of millions)
of files that might not work. At any rate, Access 2010 definitely supports
the MDB format. If you want User Level Security, you have no choice
whatsoever. MDB is the ONLY file format that supports it.
IT had been traditionally ignorant of databases, and especially so of Access
databases. Their knowledge exists solely of hearsay, and the have no
documentation to back up their views.
In the end, you have a choice, if you want ULS, you must use the MDB format.
Of you want less security and require multi-value and attachment fields you
must use the ACCDB format. For me, it's a no-brainer. Under no condition
will I be using multi-value or attachment fields, so I almost always opt for
the MDB format. I use ACCDB only rarely.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.accessmvp.com
http://www.mvps.org/access
Co-author: "Access 2010 Solutions", published by Wiley
"JeffP" <no-r...@asken.com.au> wrote in message
news:Z-OdnaMIyshjTmDW...@westnet.com.au...
David W. Fenton
> I meant: several users using the same computer in a common area AT
> THE SAME TIME, i.e. the computer is logged in by some user, and
> several others walk up there from time to time and do some work
> without logging in as themselves.
Oh! Yes, of course that would be a problem. Perhaps you can edit
your blog to make that clearer?
David W. Fenton
> Also, after reading all your "me too" answers: perhaps we are
> talking about the same thing, and it is just a matter of
> semantics. If not, post a link and maybe I can update the blog
> post.
I don't deny that access to AD from Access is not useful, but if all
you're using via AD are the NTFS security groups, you could have
done that with API calls that did not need to involve AD.
No?
Tony Toews [MVP]
>Not really at the moment, but the clients IT guys stipulated 2007 format so
>no going back. And in this case I don't think reverting back to a MDB format
>is a good solution.
Convert the ACCDB file to an MDB file. Then rename the file as an ACCDB file and
continue to use ULS. (Note that I haven't tired this. )
<smirk>
Banana
> I don't deny that access to AD from Access is not useful, but if all
> you're using via AD are the NTFS security groups, you could have
> done that with API calls that did not need to involve AD.
>
> No?
I am no Windows security expert and would welcome any corrections.
I've been under the impression that there is a distinction between AD
and NTFS security in that AD is centrally administered by a Domain
Controller whereas NTFS settings is local to the computer and basically
works on a peer-to-peer basis. In practical terms, Local groups can be
trumped upon by any other administrators of the same computer whereas
the local administrator cannot supersede the AD's setting if the local
administrator isn't also the Domain Admin. Furthermore, I believe one
could create two local group with identical names on two computers but
they wouldn't be the same group as they would be under AD. All in all,
because this is a peer-to-peer environment, we're stuck "trusting" the
other peer to do good, and that's a bad thing in terms of security.
I _think_ it'll work OK as mean of sharing files on a share folder since
it would be dependent on that host computer which other local
administrator wouldn't be also the administrator and cannot supersede
the settings by that share folder's local administrator, but as an
access control, I'm not sure if it'll resist a privilege escalation,
especially for the front-end file that is stored on the local hard drive
and thus subject to the full jurisdiction of the local administrator.
So all in all, security using AD would be more effective than trusting
the peers, I'd think.
David W. Fenton
news:4C03C2CE...@Republic.com:
> On 5/28/10 4:24 PM, David W. Fenton wrote:
>> I don't deny that access to AD from Access is not useful, but if
>> all you're using via AD are the NTFS security groups, you could
>> have done that with API calls that did not need to involve AD.
>>
>> No?
>
> I am no Windows security expert and would welcome any corrections.
>
> I've been under the impression that there is a distinction between
> AD and NTFS security in that AD is centrally administered by a
> Domain Controller whereas NTFS settings is local to the computer
> and basically works on a peer-to-peer basis.
Yes and no. If a computer has joined a domain and you logged onto
the domain, the security is domain-based. If you logged onto the
local computer (instead of the domain, as would be the default for a
computer that's a member of a domain), you are not.
If you're logged onto the local computer instead of the domain, AD
won't be available.
> In practical terms, Local groups can be
> trumped upon by any other administrators of the same computer
> whereas the local administrator cannot supersede the AD's setting
> if the local administrator isn't also the Domain Admin.
> Furthermore, I believe one could create two local group with
> identical names on two computers but they wouldn't be the same
> group as they would be under AD. All in all, because this is a
> peer-to-peer environment, we're stuck "trusting" the other peer to
> do good, and that's a bad thing in terms of security.
I don't know what you're talking about, since it seems you have a
wrong model of NTFS security in regard to domain logons vs. local
logons.
> I _think_ it'll work OK as mean of sharing files on a share folder
> since it would be dependent on that host computer which other
> local administrator wouldn't be also the administrator and cannot
> supersede the settings by that share folder's local administrator,
> but as an access control, I'm not sure if it'll resist a privilege
> escalation, especially for the front-end file that is stored on
> the local hard drive and thus subject to the full jurisdiction of
> the local administrator.
>
> So all in all, security using AD would be more effective than
> trusting the peers, I'd think.
I was not comparing AD to logging onto a local machine and using
peer-to-peer networking, but to a domain logon. A domain logon gives
you access to the domain security groups, just as AD does. The only
difference between AD and a NTFS domain logon's security is that AD
offers some organizational tools that NTFS security by itself lacks,
and different interfaces.
This is all *really* basic NTFS security, and I'm surprised once
again that skilled Access developers seem to understand so little
about it.