Re: Windows Domain Groups in Authorization section sans AD

From: Mike Moore [MS] (michmo@online.microsoft.com)
Date: 01/22/03


From: michmo@online.microsoft.com ("Mike Moore [MS]")
Date: Wed, 22 Jan 2003 01:57:55 GMT


Hi Greg,

You're sure right on what I was doing wrong: I should have used "roles="
instead of "users=". I just couldn't see my own mistake. Thanks for
catching it.

Duplicating the same user name and password is one correct technique for
gaining access to another machine without creating a domain account. If you
want to go back to having a domain account, there's an article that lists
all the permissions that are initially setup for the ASPNET account. You
just need to replicate these for the new domain account (plus any
additional privileges you've given to your current ASPNET account).

* INFO: Process and Request Identity in ASP.NET
http://support.microsoft.com/?id=317012
Section: Default Permissions for the ASPNET Account

I don't see any "red flags".

Thank you, Mike Moore
Microsoft, ASP.NET

This posting is provided "AS IS", with no warranties, and confers no rights.

--------------------
>From: "Greg Burns" <greg_burns@hotmail.com>
>References: <#qKgANLvCHA.1636@TK2MSFTNGP12>
<xugkLsTvCHA.1488@cpmsftngxa06> <eA6O2TWvCHA.2396@TK2MSFTNGP10>
<#b4iL2WvCHA.2060@TK2MSFTNGP11> <vDKY#FJwCHA.1844@cpmsftngxa09>
<O0V1TGQwCHA.648@cpmsftngxa06>
>Subject: Re: Windows Domain Groups in Authorization section sans AD
>Date: Tue, 21 Jan 2003 10:00:57 -0500
>Lines: 118
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
>X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
>Message-ID: <u#Jec3VwCHA.1644@TK2MSFTNGP09>
>Newsgroups:
microsoft.public.dotnet.framework.aspnet,microsoft.public.dotnet.framework.a
spnet.security
>NNTP-Posting-Host: 64.238.9.94
>Path: cpmsftngxa06!TK2MSFTNGP08!TK2MSFTNGP09
>Xref: cpmsftngxa06 microsoft.public.dotnet.framework.aspnet.security:3701
microsoft.public.dotnet.framework.aspnet:115878
>X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.security
>
>Sorry Mike, I just noticed that too. I should have said something.
>
>BTW, your test:
>
><allow users="BUILTIN\Administrators" />
>
>should fail. Administrators is a group. Shouldn't this be...
>
><allow roles="BUILTIN\Administrators" />
>
>Anyways, I am not sure what I did, but everything is working fine now.
>
>Let me tell you the changes I made and see if anything sets off a red flag.
>:^)
>
>While trying to solve another problem (connecting to a SQL server on a box
>other than the web server), I followed the advice in the article link you
>sent
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/h
t
>ml/SecNetch08.asp
>
>Under the section, "Using the ASP.NET Process Identity", I set up a mirror
>ASPNET account on my SQL server.
>
>I chose not to create a domain ASPNET account, because when I tried that in
>my machine.config nothing would run. The domain user, ASPNET, didn't have
>the same rights as the local ASPNET user ("machine"). (I sure there is a
>way to deal with this, but seems like a lot of work!)
>
>Surprisingly I can now use Integrated Security=SSPI in my connection
>strings. Web apps connect to SQL with the SQL box's own local ASPNET
>account, not the web server's local ASPNET account! This really surprised
>me, I didn't think this would work this way.
>
>Anyways that solved my connecting to SQL problem. Next, I needed to read a
>directory which happened to reside on a DC. Since you cannot create local
>accounts on DC, I went ahead and created a domain user called "ASPNET" with
>the same password that I set on the Web server and SQL server.
>
>Surprisingly, this worked to. Now I can read files off of my DC.
>
>I just tried deleting the domain ASPNET account I had created, thinking
this
>had something to do with the groups thing starting to work. But this did
>not change anything, using <allow roles="MYDOMAIN\group" /> continues to
>work. I guess that is a good thing :^)
>
>I have no idea what specifically made the difference.
>
>Thanks for your time and interest,
>Greg
>
>
>
>""Mike Moore [Microsoft]"" <michmo@online.microsoft.com> wrote in message
>news:O0V1TGQwCHA.648@cpmsftngxa06...
>> Hi Greg,
>>
>> I just noticed that both Luke and I are working on your issue, but in
>> different newsgroups.
>>
>> As I wrote on Friday, I've reproduced your problem here and I'm
>> investigating. I thought I would have more for you today, but I will have
>> to get back to you tomorrow.
>>
>> ---
>> Here is what I have reproduced:
>>
>> I tried using User.IsInRole in the code-behind for an ASPX page:
>> This returns true: User.IsInRole("BUILTIN\Administrators")
>> This returns false: User.IsInRole("MyMachine1\Administrators")
>> [MyMachine1 is the machine name for the ASP.NET server I'm using]
>>
>> Then I set authorization as follows and it failed:
>> <allow users="BUILTIN\Administrators" />
>>
>> Thank you, Mike Moore
>> Microsoft, ASP.NET
>>
>> This posting is provided "AS IS", with no warranties, and confers no
>rights.
>>
>> --------------------
>> >X-Tomcat-ID: 292229791
>> >References: <#qKgANLvCHA.1636@TK2MSFTNGP12>
>> <xugkLsTvCHA.1488@cpmsftngxa06> <eA6O2TWvCHA.2396@TK2MSFTNGP10>
>> <#b4iL2WvCHA.2060@TK2MSFTNGP11>
>> >MIME-Version: 1.0
>> >Content-Type: text/plain
>> >Content-Transfer-Encoding: 7bit
>> >From: lukezhan@online.microsoft.com (Luke Zhang [MS])
>> >Organization: Microsoft
>> >Date: Mon, 20 Jan 2003 14:37:49 GMT
>> >Subject: Re: Windows Domain Groups in Authorization section sans AD
>> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
>> >Message-ID: <vDKY#FJwCHA.1844@cpmsftngxa09>
>> >Newsgroups: microsoft.public.dotnet.framework.aspnet
>> >Lines: 11
>> >NNTP-Posting-Host: TOMCATIMPORT1 10.201.218.122
>> >Path: cpmsftngxa06!TK2MSFTNGP08!cpmsftngxa09
>> >Xref: cpmsftngxa06 microsoft.public.dotnet.framework.aspnet:115505
>> >
>> >I performed a quick test and I found I get same result. After this, I
>> >changed the virtual folder's Directory Security in IIS manager: Disable
>> >Anonymous access and only select Basic Authentication, after this it
>seems
>> >to work in the way. When you test this, it is recommeded to reboot your
>> >server after all modification.
>> >
>> >
>> >Luke
>> >
>> >(This posting is provided "AS IS", with no warranties, and confers no
>> >rights.)
>> >
>> >
>>
>
>
>