Prev: Splitting Access 2007 dB on Citrix network
Next: trying to put 2 lines into 1
From: JeffP on 26 May 2010 22:08
But for how long? Surely moving forward with the new format is better.

Anyway, I won't be going back and I need to find a reasonably good way of
doing this.

"David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message
news:Xns9D84AE0A6D5FFf99a49ed1d0c49c5bbb2(a)74.209.136.88...
> "JeffP" <no-reply(a)asken.com.au> wrote in
> news:0rmdndL1_OgaAmHWnZ2dnUVZ_tCdnZ2d(a)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/


From: Tom van Stiphout on 27 May 2010 00:31
On 26 May 2010 21:10:57 GMT, "David W. Fenton"
<XXXusenet(a)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


>Tom van Stiphout <tom7744.no.spam(a)cox.net> wrote in
>news:u3uov51sun9g2sh13lge6sog42qubeh286(a)4ax.com:
>
>> 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.
From: zuckermanf on 27 May 2010 01:59
On May 25, 4:44 pm, "JeffP" <no-re...(a)asken.com.au> wrote:
> I have a 2000 database that users ULS for restricting access to forms and
> reports.
>
> What is the best, or any, solution for restricting access to forms and
> reports in 2007 which doesn't support ULS?

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
From: David W. Fenton on 27 May 2010 12:45
"JeffP" <no-reply(a)asken.com.au> wrote in
news:Z-OdnaMIyshjTmDWnZ2dnUVZ_sydnZ2d(a)westnet.com.au:

> "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message
> news:Xns9D84AE0A6D5FFf99a49ed1d0c49c5bbb2(a)74.209.136.88...
>> "JeffP" <no-reply(a)asken.com.au> wrote in
>> news:0rmdndL1_OgaAmHWnZ2dnUVZ_tCdnZ2d(a)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 http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 27 May 2010 12:50
Tom van Stiphout <tom7744.no.spam(a)cox.net> wrote in
news:u5trv55aej1lfalgh4smocv79agi36s19f(a)4ax.com:

> On 26 May 2010 21:10:57 GMT, "David W. Fenton"
><XXXusenet(a)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.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Splitting Access 2007 dB on Citrix network
Next: trying to put 2 lines into 1