By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,313 Members | 1,145 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,313 IT Pros & Developers. It's quick & easy.

ASP Cross server rights

P: n/a
HI Guys.

I hope you can help me out!

I'm writting a small app for my Intranet that allows me to see basic
information aount user accounts. Included in that information is disk quota
data such as QuotaLimit, QuotaUsed and such.

If the quota info is from a disk local to my IIS server, such as it's drive
C. Everything works fine. However, this is where the fun starts!

If I specify a remote disk (such as \\fileserver\d$), I almost always get an
access denied error. (returned from the "quotaObject.Initialize" statement)
The code works perfectly if I connect to IIS from IE running on the IIS
server.

I do not use "anonymous" access. The users connect using their windows
credentials. I connect as a member of the Administrators group. On a whim,
I gave the IWAM_server account admin previleges, and still no luck.

Since the page loads perfectly when I connect from the IIS server, this
indicates that the problem is not that the IIS server can't talk properly to
the file server. Rather it seems to indicate that the user account IIS uses
to retrieve the data is different if I'm using the console instead of a
client.

Note, I get a failure even if I use the file server as my client. Both
sverers are member of the same domain.

Any thoughts?

-Pauli
Jul 22 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"Paul J. Landry" wrote in message
news:23**********************************@microsof t.com...
I hope you can help me out!
:
: I'm writting a small app for my Intranet that allows me to see basic
: information aount user accounts. Included in that information is disk
quota
: data such as QuotaLimit, QuotaUsed and such.
:
: If the quota info is from a disk local to my IIS server, such as it's
drive
: C. Everything works fine. However, this is where the fun starts!
:
: If I specify a remote disk (such as \\fileserver\d$), I almost always get
an
: access denied error. (returned from the "quotaObject.Initialize"
statement)
: The code works perfectly if I connect to IIS from IE running on the IIS
: server.
:
: I do not use "anonymous" access. The users connect using their windows
: credentials. I connect as a member of the Administrators group. On a
whim,
: I gave the IWAM_server account admin previleges, and still no luck.
:
: Since the page loads perfectly when I connect from the IIS server, this
: indicates that the problem is not that the IIS server can't talk properly
to
: the file server. Rather it seems to indicate that the user account IIS
uses
: to retrieve the data is different if I'm using the console instead of a
: client.
:
: Note, I get a failure even if I use the file server as my client. Both
: sverers are member of the same domain.
:
: Any thoughts?

Just to confirm, these are both member servers or are they a mix or both
DCs?
How are you verifying the account being denied access?

With a remote UNC connection to an administrative share, three things are
required:
The account must have remote server admin privs or domain admin privs.
Domain Admin privs must have access to the path, meaning share AND NTFS
permissions.
3rd party participation should be removed. i.e. no script blocking,
personal firewall, IPSec, etc.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp
Jul 22 '05 #2

P: n/a
Hi Roland, thanks for the input.

Both servers are DCs of a single domain (in this case, although I've tried
with member servers, without any more success)

I'm connecting with a domain admin account. I'm using NTLM/NTFS permissions
on the actual web site. IIS seems to recognise the integrated Windows
authentication properly. Response.servervariable(remoteuser) returns the
accurate username.

However, I don't know what account the IIS server is attempting to use to
connect to the other server. I would hope it would use the user account used
to connect to IIS, since it uses those previleges for local tasks. Either
that or IWAM_server. Since I gave them both domain admin previleges, I
guesss not.

And again, it works perfectly if I use a browser on the IIS server, so I
don't understand why it would behave differently when I use any other
computer...

Thoughts?

-Paul Landry

"Roland Hall" wrote:

Just to confirm, these are both member servers or are they a mix or both
DCs?
How are you verifying the account being denied access?

With a remote UNC connection to an administrative share, three things are
required:
The account must have remote server admin privs or domain admin privs.
Domain Admin privs must have access to the path, meaning share AND NTFS
permissions.
3rd party participation should be removed. i.e. no script blocking,
personal firewall, IPSec, etc.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

Jul 22 '05 #3

P: n/a
"Paul J. Landry" wrote in message
news:79**********************************@microsof t.com...
: Hi Roland, thanks for the input.
:
: Both servers are DCs of a single domain (in this case, although I've tried
: with member servers, without any more success)
:
: I'm connecting with a domain admin account. I'm using NTLM/NTFS
permissions
: on the actual web site. IIS seems to recognise the integrated Windows
: authentication properly. Response.servervariable(remoteuser) returns the
: accurate username.
:
: However, I don't know what account the IIS server is attempting to use to
: connect to the other server. I would hope it would use the user account
used
: to connect to IIS, since it uses those previleges for local tasks. Either
: that or IWAM_server. Since I gave them both domain admin previleges, I
: guesss not.
:
: And again, it works perfectly if I use a browser on the IIS server, so I
: don't understand why it would behave differently when I use any other
: computer...

Hi Paul...

Let me explain my setup and tell you what I did to get this to work.

My setup:

XP client
W2K DC : FS1

The client is running IIS. I created a virtual directory called 'remote' to
a UNC path to \\xp\fp. I set the virtual path to use an account with domain
admin rights. FP is a share that points to c:\fp on XP.

I put a script in \\xp\fp called info.asp.

This is the source:

<%@ Language="VBScript" %>
<%
strComputer = "xp"
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colDiskQuotas = objWMIService.ExecQuery _
("Select * from Win32_DiskQuota")
response.write "<pre>"
For each objQuota in colDiskQuotas
response.write "Disk Space Used: " & vbTab & objQuota.DiskSpaceUsed &
vbCrLf
response.write "Limit: " & vbTab & objQuota.Limit & vbCrLf
response.write "Quota Volume: " & vbTab & objQuota.QuotaVolume & vbCrLf
response.write "Status: " & vbTab & objQuota.Status & vbCrLf
response.write "User: " & vbTab & objQuota.User & vbCrLf
response.write "Warning Limit: " & vbTab & objQuota.WarningLimit &
vbCrLf
Next
response.write "</pre>"
%>

Using IE I put in the address http://localhost/remote/info.asp

Note: My client is in a different domain than my DC so I have to use Basic
Authentication. I was prompted for credentials. Using Integrated, you
should not be prompted as you can add rights to the NTFS permissions of
\\xp\fp for the domain admin user. I set permissions (NTFS) to just
xp\administrator.

Here are my results:
Disk Space Used: 0
Limit: 18446744073709551615
Quota Volume: Win32_LogicalDisk.DeviceID="C:"
Status: 0
User: Win32_Account.Domain="XP",Name="Administrators"
Warning Limit: 18446744073709551615
Disk Space Used: 0
Limit: 18446744073709551615
Quota Volume: Win32_LogicalDisk.DeviceID="E:"
Status: 0
User: Win32_Account.Domain="XP",Name="Administrators"
Warning Limit: 18446744073709551615
I was not able to run this on FS1 as Win32_DiskQuota is not supported on
W2K. I believe it is just XP and W2K3 compatible.-- Roland Hall/* This
information is distributed in the hope that it will be useful, but without
any warranty; without even the implied warranty of merchantability or
fitness for a particular purpose. */Technet Script Center -
http://www.microsoft.com/technet/scriptcenter/WSH 5.6 Documentation -
http://msdn.microsoft.com/downloads/list/webdev.aspMSDN Library -
http://msdn.microsoft.com/library/default.asp
Jul 22 '05 #4

P: n/a

Hi Roland.

According to MS, "Win32_DiskQuota" is not compatible with 2000. Only 2k3
and XP.

Which is why I'm using the "Microsoft.DiskQuota.1" object.

Thanks.
Thoughts?
-Pauli
Jul 22 '05 #5

P: n/a
"Paul J. Landry" wrote in message
news:EF**********************************@microsof t.com...
: According to MS, "Win32_DiskQuota" is not compatible with 2000. Only 2k3
: and XP.
:
: Which is why I'm using the "Microsoft.DiskQuota.1" object.

Did you try Win32_DiskQuota.1 with the code I displayed? It should work the
same.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp
Jul 22 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.