An NT Security Gotcha that looks like a Jet Security issue

[David W. Fenton]

I am posting this to the newsgroup because I wasted some time on
Friday troubleshooting a problem of my own making. Other people
might benefit from hearing about it.

I'm working on the final touches to an app that's going to be run by
3 people in an office from their workstations, and about 10 other
people remotely via Windows Terminal Server. The TS is set up and
operating beautifully (I'm not the client's sysadmin, but I
*trained* the guy who is, so I've been given full administrative
control).

I had done all my testing via the Terminal Server and had forgotten
that I couldn't use the TS's local drive letters (LAN users do have
a drive mapped to the TS, but it's not the same as the drive letter
when run locally). So, when this was pointed out to me, I slapped my
forehead and changed to UNC paths.

In all my testing, everything worked fine.

When the client tester tried it, the app was read-only. Well, it
turns out that we'd replaced the testing back end with the real back
end and loaded some archived data, and it looked like the security
was not set up right. Also, I'd added some back-end link checking,
as there actually 3 distinct versions of the front end that need to
be linked to three different back ends (a testing version, a
training version and the production version, linked (respectively)
to a testing back end, a training back end and the production back
end), and thought that something was going wrong with the relinking
code when it was run by a user that didn't have full permissions on
the tables.

To make a long story short, it turned out that the problem had
nothing to do with Jet security, but was caused by my using the
wrong UNC path.

The app is physically located on the data drive of the terminal
server, which is D:. There's a top-level DATA folder, which is
shared, and in that folder is the folder for this app, called
ApplicantsDB. That, too, is shared. So, when you browse the Terminal
Server via My Network Places, you see three shares, Data,
ApplicantsDB and Quickbooks (which is another top-level share).

My intention was that all back end links woul use the UNC path
through the ApplicantsDB *share*, as in:

\\TerminalServer\ApplicantsDB

But I mistakenly set them all up as:

\\TerminalServer\Data\ApplicantsDB

That means going through the DATA share. As it turns out, the user
group defined for this Access application has no permissions set at
all on the DATA share (or folder), and has MODIFY permission on the
ApplicantsDB folder and share. The Domain Users group has READ-ONLY
access on the DATA folder and share, so the result was that nobody
but domain adminirators (which included *me*) had write permission
on \\TerminalServer\Data\ApplicantsDB because I was getting to the
ApplicantsDB *folder* via the Data *share*, instead of getting to
the same dsetination through the ApplicantsDB share.

So, if you're ever in a situation where you are getting read-only
access (or none at all) to data on a server, be sure to check that
the permissions are set correctly on it and that you're accessing it
through the right path.

I knew all of this, of course (I was the one who set it up!), and
was just not paying attention.

But I thought I'd post about it because most people who do Access
development don't have the NT adminstration experience that I have,
so might have much more trouble figuring out a problem like this.

It gave *me* enough difficulty, and I'm supposed to *know* what I'm
doing in this area!

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

I had a couple of long debugging sessions similar to what you're describing on
a project of mine a while back. I'm in the mode now that when it's possible
to repeat a mistake that's hard to diagnose, I try to add some kind of
automation that makes the mistake harder to make.

In my case (though I think it wouldn't have worked for yours), I added
constants to the code for the development, production, and testing back-end
paths. When the code starts up, it checks the links, and if they point to
anything other then the production path, a warning pops up saying the
Development, Testing, or an Unknown back-end path is being used. When running
the re-link operation, I also can pass one of the constant names as the path
argument, so I can't accidentally mis-type it.

Since there are long periods between work sessions with the client in
question, I'm sure without the link checking code, I'd have made the same
mistake again more than once and spent quite a while debugging each time
before saying "doh!"
On Sat, 17 Sep 2005 13:28:31 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

I am posting this to the newsgroup because I wasted some time on
Friday troubleshooting a problem of my own making. Other people
might benefit from hearing about it.

I'm working on the final touches to an app that's going to be run by
3 people in an office from their workstations, and about 10 other
people remotely via Windows Terminal Server. The TS is set up and
operating beautifully (I'm not the client's sysadmin, but I
*trained* the guy who is, so I've been given full administrative
control).

I had done all my testing via the Terminal Server and had forgotten
that I couldn't use the TS's local drive letters (LAN users do have
a drive mapped to the TS, but it's not the same as the drive letter
when run locally). So, when this was pointed out to me, I slapped my
forehead and changed to UNC paths.

In all my testing, everything worked fine.

When the client tester tried it, the app was read-only. Well, it
turns out that we'd replaced the testing back end with the real back
end and loaded some archived data, and it looked like the security
was not set up right. Also, I'd added some back-end link checking,
as there actually 3 distinct versions of the front end that need to
be linked to three different back ends (a testing version, a
training version and the production version, linked (respectively)
to a testing back end, a training back end and the production back
end), and thought that something was going wrong with the relinking
code when it was run by a user that didn't have full permissions on
the tables.

To make a long story short, it turned out that the problem had
nothing to do with Jet security, but was caused by my using the
wrong UNC path.

The app is physically located on the data drive of the terminal
server, which is D:. There's a top-level DATA folder, which is
shared, and in that folder is the folder for this app, called
ApplicantsDB. That, too, is shared. So, when you browse the Terminal
Server via My Network Places, you see three shares, Data,
ApplicantsDB and Quickbooks (which is another top-level share).

My intention was that all back end links woul use the UNC path
through the ApplicantsDB *share*, as in:

\\TerminalServer\ApplicantsDB

But I mistakenly set them all up as:

\\TerminalServer\Data\ApplicantsDB

That means going through the DATA share. As it turns out, the user
group defined for this Access application has no permissions set at
all on the DATA share (or folder), and has MODIFY permission on the
ApplicantsDB folder and share. The Domain Users group has READ-ONLY
access on the DATA folder and share, so the result was that nobody
but domain adminirators (which included *me*) had write permission
on \\TerminalServer\Data\ApplicantsDB because I was getting to the
ApplicantsDB *folder* via the Data *share*, instead of getting to
the same dsetination through the ApplicantsDB share.

So, if you're ever in a situation where you are getting read-only
access (or none at all) to data on a server, be sure to check that
the permissions are set correctly on it and that you're accessing it
through the right path.

I knew all of this, of course (I was the one who set it up!), and
was just not paying attention.

But I thought I'd post about it because most people who do Access
development don't have the NT adminstration experience that I have,
so might have much more trouble figuring out a problem like this.

It gave *me* enough difficulty, and I'm supposed to *know* what I'm
doing in this area!

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:qt********************************@4ax.com:

I had a couple of long debugging sessions similar to what you're
describing on a project of mine a while back. I'm in the mode now
that when it's possible to repeat a mistake that's hard to
diagnose, I try to add some kind of automation that makes the
mistake harder to make.

In my case (though I think it wouldn't have worked for yours), I
added constants to the code for the development, production, and
testing back-end paths. . . .
Well, that's precisely what I'd done, but I'd copied the *wrong*
paths into the constants, because I'd picked them up from
CurrentDB.Name, and I'd opened the database from
\\TerminalServer\Data\ApplicantsDB instead of from
\\TerminalServer\ApplicantsDB!
. . . When the code starts up, it checks the
links, and if they point to anything other then the production
path, a warning pops up saying the Development, Testing, or an
Unknown back-end path is being used. When running the re-link
operation, I also can pass one of the constant names as the path
argument, so I can't accidentally mis-type it.
Well, this was exactly the task that the code I was writing was
performing, and it was because I'd used constants in the code that
it ran into the problem.
Since there are long periods between work sessions with the client
in question, I'm sure without the link checking code, I'd have
made the same mistake again more than once and spent quite a while
debugging each time before saying "doh!"

Well, nothing can protect you or me from putting the wrong values in
the constants!

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Sun, 18 Sep 2005 16:23:33 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

....

. . . When the code starts up, it checks the
links, and if they point to anything other then the production
path, a warning pops up saying the Development, Testing, or an
Unknown back-end path is being used. When running the re-link
operation, I also can pass one of the constant names as the path
argument, so I can't accidentally mis-type it.

Well, this was exactly the task that the code I was writing was
performing, and it was because I'd used constants in the code that
it ran into the problem.

Since there are long periods between work sessions with the client
in question, I'm sure without the link checking code, I'd have
made the same mistake again more than once and spent quite a while
debugging each time before saying "doh!"

Well, nothing can protect you or me from putting the wrong values in
the constants!

No - I guess not. In my case, since I'd just been debugging the same kind of
mystery when I implemented the constants as a fix, I think I'd have seen/fixed
the problem with the constants right away. Without that, I could well have
had the same kind of problem you did.

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:ra********************************@4ax.com:

On Sun, 18 Sep 2005 16:23:33 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

...

. . . When the code starts up, it checks the
links, and if they point to anything other then the production
path, a warning pops up saying the Development, Testing, or an
Unknown back-end path is being used. When running the re-link
operation, I also can pass one of the constant names as the path
argument, so I can't accidentally mis-type it.

Well, this was exactly the task that the code I was writing was
performing, and it was because I'd used constants in the code that
it ran into the problem.

Since there are long periods between work sessions with the
client in question, I'm sure without the link checking code, I'd
have made the same mistake again more than once and spent quite
a while debugging each time before saying "doh!"

Well, nothing can protect you or me from putting the wrong values
in the constants!

No - I guess not. In my case, since I'd just been debugging the
same kind of mystery when I implemented the constants as a fix, I
think I'd have seen/fixed the problem with the constants right
away. Without that, I could well have had the same kind of
problem you did.

I still don't understand your point. I was using constants. And I
was checking the back end links. And I was relinking to the values
in the constants.

And those values were the WRONG ONES.

So, setting constants doesn't help unless you are setting the right
constants.

Indeed, the constants didn't *cause* the problem, either. Whatever
method I'd have used for getting the back end names would have been
subject to the same human error.

But the problem was one that I hadn't really encountered before,
because I normally am on the ball with defining my UNC paths.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Mon, 19 Sep 2005 20:37:31 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:ra********************************@4ax.com :

On Sun, 18 Sep 2005 16:23:33 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

...

. . . When the code starts up, it checks the
links, and if they point to anything other then the production
path, a warning pops up saying the Development, Testing, or an
Unknown back-end path is being used. When running the re-link
operation, I also can pass one of the constant names as the path
argument, so I can't accidentally mis-type it.

Well, this was exactly the task that the code I was writing was
performing, and it was because I'd used constants in the code that
it ran into the problem.

Since there are long periods between work sessions with the
client in question, I'm sure without the link checking code, I'd
have made the same mistake again more than once and spent quite
a while debugging each time before saying "doh!"

Well, nothing can protect you or me from putting the wrong values
in the constants!

No - I guess not. In my case, since I'd just been debugging the
same kind of mystery when I implemented the constants as a fix, I
think I'd have seen/fixed the problem with the constants right
away. Without that, I could well have had the same kind of
problem you did.

I still don't understand your point. I was using constants. And I
was checking the back end links. And I was relinking to the values
in the constants.

And those values were the WRONG ONES.

So, setting constants doesn't help unless you are setting the right
constants.

Indeed, the constants didn't *cause* the problem, either. Whatever
method I'd have used for getting the back end names would have been
subject to the same human error.

But the problem was one that I hadn't really encountered before,
because I normally am on the ball with defining my UNC paths.

I was agreeing with you.

I'm saying the only reason I avoided the same problem is that I was dealing
with similar symptoms right -before- I created the constants and was using the
constants as a fix. If I had just implemented the constants up-front, there
would have been nothing to prevent me having a similar problem to yours.