Re: An NT Security Gotcha that looks like a Jet Security issue
- From: Steve Jorgensen <nospam@xxxxxxxxxxxxx>
- Date: Sat, 17 Sep 2005 20:11:03 -0700
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"
<dXXXfenton@xxxxxxxxxxxxxxxx> 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!
.
- Follow-Ups:
- Re: An NT Security Gotcha that looks like a Jet Security issue
- From: David W. Fenton
- Re: An NT Security Gotcha that looks like a Jet Security issue
- References:
- An NT Security Gotcha that looks like a Jet Security issue
- From: David W. Fenton
- An NT Security Gotcha that looks like a Jet Security issue
- Prev by Date: Re: lost mdb
- Next by Date: Re: How do I disable automatic save of my project as I build my database in access?
- Previous by thread: An NT Security Gotcha that looks like a Jet Security issue
- Next by thread: Re: An NT Security Gotcha that looks like a Jet Security issue
- Index(es):
Relevant Pages
|
