Making C:WINNTTemp a share point

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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