Making C:WINNTTemp a share point

Archived from groups: microsoft.public.win2000.security (More info?)

Our company is using a financial package that is running in a
client/server fashion. Unfortunately, the software is designed so that
the contents of C:\WINNT\Temp on the server must be accessible as a
network drive (T:) on the client workstations. It's stupid, I know, but
it's the only way the software will work.

On our Win2K Advanced Server, I enabled sharing on C:\WINNT\Temp and set
permissions so that the "Accounting" group (those users who use the
financial package) had full read/write privileges. However, Windows
seems to ignore my permission settings -- Accounting users receive a
"T:\ is not accessible. Access is denied" message when they attempt to
mount \\TheServer\Temp. Apparently, C:\WINNT\Temp is handled in a
special manner by Win2K Advanced Server.

The only workaround we have at present is to make our Accounting users
also Domain Users. When we do this, they are able to properly mount and
read/write to \\TheServer\Temp via T:. However, this obviously opens up
a gaping security hole, as our users can trash our domain and systems in
substantial ways.

Is there another way to make C:\WINNT\Temp visible as the T: drive on
our client stations, but not be forced to make our Accounting users
Domain Admins? I'm stumped. Any help would be appreciated.


----
Bert Sierra, IT Manager + (928) 778-0170 x130
Fann Contracting, Inc. + 1403 Industrial Way + Prescott, AZ 86301
6 answers Last reply
More about making winnttemp share point
  1. Archived from groups: microsoft.public.win2000.security (More info?)

    "Bert Sierra" <bsierra@nospam-cableone.net> wrote in message
    news:bsierra-87FB1E.14311925022005@corp.supernews.com...
    > Our company is using a financial package that is running in a
    > client/server fashion. Unfortunately, the software is designed so that
    > the contents of C:\WINNT\Temp on the server must be accessible as a
    > network drive (T:) on the client workstations. It's stupid, I know, but
    > it's the only way the software will work.

    Yes, it is, in fact it is beyond stupid.

    But there are a couple of things you can do (if
    the app doesn't care):

    subst T: "%temp%"

    Or...(if you need to have the dir temp below the root)

    subst T: C:\

    You could also just make a T: volume and linkd.exe
    the T:\Temp to the real Temp.

    > On our Win2K Advanced Server, I enabled sharing on C:\WINNT\Temp and set
    > permissions so that the "Accounting" group (those users who use the
    > financial package) had full read/write privileges. However, Windows
    > seems to ignore my permission settings -- Accounting users receive a
    > "T:\ is not accessible. Access is denied" message when they attempt to
    > mount \\TheServer\Temp. Apparently, C:\WINNT\Temp is handled in a
    > special manner by Win2K Advanced Server.
    >
    > The only workaround we have at present is to make our Accounting users
    > also Domain Users. When we do this, they are able to properly mount and
    > read/write to \\TheServer\Temp via T:. However, this obviously opens up
    > a gaping security hole, as our users can trash our domain and systems in
    > substantial ways.
    >
    > Is there another way to make C:\WINNT\Temp visible as the T: drive on
    > our client stations, but not be forced to make our Accounting users
    > Domain Admins? I'm stumped. Any help would be appreciated.
    >
    >
    > ----
    > Bert Sierra, IT Manager + (928) 778-0170 x130
    > Fann Contracting, Inc. + 1403 Industrial Way + Prescott, AZ 86301
  2. Archived from groups: microsoft.public.win2000.security (More info?)

    I am a bit confused as you first say that they must be domain users and then
    say they must be domain admins?? I assume you mean domain admins because
    being domain users should not be that big of a deal. Do they have share and
    ntfs permissions for this share?? Check to make sure that the permissions
    are in place in case a security template or such is changing permissions
    back to a defined level. Is this a domain controller or domain member
    server? -- Steve


    "Bert Sierra" <bsierra@nospam-cableone.net> wrote in message
    news:bsierra-87FB1E.14311925022005@corp.supernews.com...
    > Our company is using a financial package that is running in a
    > client/server fashion. Unfortunately, the software is designed so that
    > the contents of C:\WINNT\Temp on the server must be accessible as a
    > network drive (T:) on the client workstations. It's stupid, I know, but
    > it's the only way the software will work.
    >
    > On our Win2K Advanced Server, I enabled sharing on C:\WINNT\Temp and set
    > permissions so that the "Accounting" group (those users who use the
    > financial package) had full read/write privileges. However, Windows
    > seems to ignore my permission settings -- Accounting users receive a
    > "T:\ is not accessible. Access is denied" message when they attempt to
    > mount \\TheServer\Temp. Apparently, C:\WINNT\Temp is handled in a
    > special manner by Win2K Advanced Server.
    >
    > The only workaround we have at present is to make our Accounting users
    > also Domain Users. When we do this, they are able to properly mount and
    > read/write to \\TheServer\Temp via T:. However, this obviously opens up
    > a gaping security hole, as our users can trash our domain and systems in
    > substantial ways.
    >
    > Is there another way to make C:\WINNT\Temp visible as the T: drive on
    > our client stations, but not be forced to make our Accounting users
    > Domain Admins? I'm stumped. Any help would be appreciated.
    >
    >
    > ----
    > Bert Sierra, IT Manager + (928) 778-0170 x130
    > Fann Contracting, Inc. + 1403 Industrial Way + Prescott, AZ 86301
  3. Archived from groups: microsoft.public.win2000.security (More info?)

    In article <ORNnJ#7GFHA.3648@TK2MSFTNGP09.phx.gbl>,
    "Steven L Umbach" <n9rou@nospam-comcast.net> wrote:
    > I am a bit confused as you first say that they must be domain users and then
    > say they must be domain admins?? I assume you mean domain admins because
    > being domain users should not be that big of a deal. Do they have share and
    > ntfs permissions for this share?? Check to make sure that the permissions
    > are in place in case a security template or such is changing permissions
    > back to a defined level. Is this a domain controller or domain member
    > server? -- Steve

    Yes, that was a typo. I meant to say that our users must be Domain
    Admins in order to be able to access \\TheServer\Temp.

    I think I was able to resolve the problem. I had enabled Sharing and
    set Sharing Permissions so Accounting users could read/write to Temp.
    However, I didn't realize that in addition you needed to enable access
    via the Security panel in Properties. I think that's what you might
    mean by ntfs permissions. Once I did that, the Accounting group could
    read/write to Temp without having to be Domain Admins. Now they're just
    part of the Accounting and Domain Users groups, as it should be, and the
    security hole should be largely patched up.

    FYI -- The server in question was a computer joined to our domain, but
    not a domain controller or domain backup controller. It is running
    Terminal Services for use only by system administrators. [We're
    primarily a Mac shop, so Terminal Services support is critical.]


    ----
    Bert Sierra, IT Manager + (928) 778-0170 x130
    Fann Contracting, Inc. + 1403 Industrial Way + Prescott, AZ 86301
  4. Archived from groups: microsoft.public.win2000.security (More info?)

    In article <u7lHD57GFHA.3216@tk2msftngp13.phx.gbl>,
    "Herb Martin" <news@LearnQuick.com> wrote:

    > "Bert Sierra" <bsierra@nospam-cableone.net> wrote in message
    > news:bsierra-87FB1E.14311925022005@corp.supernews.com...
    > > Our company is using a financial package that is running in a
    > > client/server fashion. Unfortunately, the software is designed so that
    > > the contents of C:\WINNT\Temp on the server must be accessible as a
    > > network drive (T:) on the client workstations. It's stupid, I know, but
    > > it's the only way the software will work.
    >
    > Yes, it is, in fact it is beyond stupid.
    >
    > But there are a couple of things you can do (if
    > the app doesn't care):
    >
    > subst T: "%temp%"
    >
    > Or...(if you need to have the dir temp below the root)
    >
    > subst T: C:\
    >
    > You could also just make a T: volume and linkd.exe
    > the T:\Temp to the real Temp.

    Thanks for the help, but unless I'm mistaken 'subst' will only map local
    folders and drives to drive letters -- it's not capable of mounting
    network shares, which is what we needed to do. I needed to mount
    \\TheServer\Temp as T: on the system in question.

    It turns out the problem was on the server side. I didn't have
    Properties > Security enabled for Accounting users to access the Temp
    share.


    ----
    Bert Sierra, IT Manager + (928) 778-0170 x130
    Fann Contracting, Inc. + 1403 Industrial Way + Prescott, AZ 86301
  5. Archived from groups: microsoft.public.win2000.security (More info?)

    OK. Yes that is what I meant by ntfs permissions. I should have been more
    specific. Share permissions apply only to network access while ntfs folder
    permissions apply to any user trying to access the share. The user's
    effective permission will be the most restrictive of the two permissions
    types. In other words if a user has full control share permissions and only
    read ntfs permissions, the user's effective permission to the share will be
    read permission. Glad you got it sorted out. --- Steve


    "Bert Sierra" <bsierra@nospam-cableone.net> wrote in message
    news:bsierra-7F8F7C.10231628022005@corp.supernews.com...
    > In article <ORNnJ#7GFHA.3648@TK2MSFTNGP09.phx.gbl>,
    > "Steven L Umbach" <n9rou@nospam-comcast.net> wrote:
    >> I am a bit confused as you first say that they must be domain users and
    >> then
    >> say they must be domain admins?? I assume you mean domain admins because
    >> being domain users should not be that big of a deal. Do they have share
    >> and
    >> ntfs permissions for this share?? Check to make sure that the permissions
    >> are in place in case a security template or such is changing permissions
    >> back to a defined level. Is this a domain controller or domain member
    >> server? -- Steve
    >
    > Yes, that was a typo. I meant to say that our users must be Domain
    > Admins in order to be able to access \\TheServer\Temp.
    >
    > I think I was able to resolve the problem. I had enabled Sharing and
    > set Sharing Permissions so Accounting users could read/write to Temp.
    > However, I didn't realize that in addition you needed to enable access
    > via the Security panel in Properties. I think that's what you might
    > mean by ntfs permissions. Once I did that, the Accounting group could
    > read/write to Temp without having to be Domain Admins. Now they're just
    > part of the Accounting and Domain Users groups, as it should be, and the
    > security hole should be largely patched up.
    >
    > FYI -- The server in question was a computer joined to our domain, but
    > not a domain controller or domain backup controller. It is running
    > Terminal Services for use only by system administrators. [We're
    > primarily a Mac shop, so Terminal Services support is critical.]
    >
    >
    > ----
    > Bert Sierra, IT Manager + (928) 778-0170 x130
    > Fann Contracting, Inc. + 1403 Industrial Way + Prescott, AZ 86301
  6. Archived from groups: microsoft.public.win2000.security (More info?)

    "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
    news:OPUpTZfHFHA.3624@tk2msftngp13.phx.gbl...
    > OK. Yes that is what I meant by ntfs permissions. I should have been more
    > specific. Share permissions apply only to network access while ntfs folder
    > permissions apply to any user trying to access the share. The user's
    > effective permission will be the most restrictive of the two permissions
    > types.

    > In other words if a user has full control share permissions and only
    > read ntfs permissions, the user's effective permission to the share will
    be
    > read permission.

    Slight correction: "only read NTFS on the file(s) the users effective
    access for the FILE(s) will be Read".

    Permission at the share would not be (effectively)
    changed, and in fact some files (not included in the read)
    might be inaccessible.)


    --
    Herb Martin


    >
    >
    > "Bert Sierra" <bsierra@nospam-cableone.net> wrote in message
    > news:bsierra-7F8F7C.10231628022005@corp.supernews.com...
    > > In article <ORNnJ#7GFHA.3648@TK2MSFTNGP09.phx.gbl>,
    > > "Steven L Umbach" <n9rou@nospam-comcast.net> wrote:
    > >> I am a bit confused as you first say that they must be domain users and
    > >> then
    > >> say they must be domain admins?? I assume you mean domain admins
    because
    > >> being domain users should not be that big of a deal. Do they have share
    > >> and
    > >> ntfs permissions for this share?? Check to make sure that the
    permissions
    > >> are in place in case a security template or such is changing
    permissions
    > >> back to a defined level. Is this a domain controller or domain member
    > >> server? -- Steve
    > >
    > > Yes, that was a typo. I meant to say that our users must be Domain
    > > Admins in order to be able to access \\TheServer\Temp.
    > >
    > > I think I was able to resolve the problem. I had enabled Sharing and
    > > set Sharing Permissions so Accounting users could read/write to Temp.
    > > However, I didn't realize that in addition you needed to enable access
    > > via the Security panel in Properties. I think that's what you might
    > > mean by ntfs permissions. Once I did that, the Accounting group could
    > > read/write to Temp without having to be Domain Admins. Now they're just
    > > part of the Accounting and Domain Users groups, as it should be, and the
    > > security hole should be largely patched up.
    > >
    > > FYI -- The server in question was a computer joined to our domain, but
    > > not a domain controller or domain backup controller. It is running
    > > Terminal Services for use only by system administrators. [We're
    > > primarily a Mac shop, so Terminal Services support is critical.]
    > >
    > >
    > > ----
    > > Bert Sierra, IT Manager + (928) 778-0170 x130
    > > Fann Contracting, Inc. + 1403 Industrial Way + Prescott, AZ 86301
    >
    >
Ask a new question

Read More

Servers Windows