Making C:\WINNT\Temp a share point

  • Thread starter Thread starter Bert Sierra
  • Start date Start date
B

Bert Sierra

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 said:
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.
Click to expand...

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.
 
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
 
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
Click to expand...

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.]
 
Herb Martin said:
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.
Click to expand...

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.
 
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 said:
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
Click to expand...

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.]
Click to expand...
 
Steven L Umbach said:
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.
Click to expand...
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.
Click to expand...

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 said:
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
Click to expand...

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.]
Click to expand...
Click to expand...
 
Back
Top