From: Tony Toews [MVP] on
"JeffP" <no-reply(a)asken.com.au> wrote:

>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>

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/
Granite Fleet Manager http://www.granitefleet.com/
From: Banana on
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. 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.
From: David W. Fenton on
Banana <Banana(a)Republic.com> wrote in
news:4C03C2CE.7040105(a)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.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/