Monday, March 19, 2012

Integrated Security in a Workgroup?

The A\ASPNET and B\ASPNET machine accounts are created by IIS (I think) --
at least I know that I did NOT create them. These are the accounts used by
IIS when executing ASP pages. Since these accounts are not created by me I
don't know the passwords -- and I can't just change them in XP because then
IIS will likely fail due to using the old password. Perhaps I can change
the default ASP account used by IIS on both machines -- then I can create
local accounts with the same username and password.
Thanks for the suggestion.
Bill
"Stephen Dybing [MSFT]" <stephd@.online.microsoft.com> wrote in message
news:uOFYrdRuDHA.3144@.tk2msftngp13.phx.gbl...
quote:

> I believe that you do this without specifying the A\ or B\.
> --
> Sincerely,
> Stephen Dybing
> This posting is provided "AS IS" with no warranties, and confers no

rights.
quote:

> Please reply to the newsgroups only, thanks.
> "Bill Cohagan" <bill@.teraXNOSPAMXquest.com> wrote in message
> news:#aPrRKOuDHA.4056@.TK2MSFTNGP11.phx.gbl...
> A\ASPNET
the[QUOTE]
> A
and[QUOTE]
> an
only.[QUOTE]
the[QUOTE]
> SQL
> rights.
>
Kevin
Thanks for the response. Please see my reply to dybing regarding
passwords being problematic.
Bill
"Kevin McDonnell [MSFT]" <kevmc@.online.microsoft.com> wrote in message
news:uN4DrXRuDHA.1360@.cpmsftngxa06.phx.gbl...
quote:

> See if you can make a Trusted Connection using SQL. If the passwords are
> the same, then this should work.
> Use ISQL.exe
> ISQL -SSQLServerNameHere -E -Q"select @.@.version"
> This should return the version of SQL 2000.
> If this works then, we know the security is working, it may be a
> configuration issue with ASP.NET.
>
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>
|||No, sorry, what I meant was that when you set up the SQL Server permissions,
try it without including the A\ or B\.
Sincerely,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to the newsgroups only, thanks.
"Bill Cohagan" <bill@.teraXNOSPAMXquest.com> wrote in message
news:utxj$XduDHA.1596@.TK2MSFTNGP10.phx.gbl...
quote:

> The A\ASPNET and B\ASPNET machine accounts are created by IIS (I think) --
> at least I know that I did NOT create them. These are the accounts used by
> IIS when executing ASP pages. Since these accounts are not created by me I
> don't know the passwords -- and I can't just change them in XP because

then
quote:

> IIS will likely fail due to using the old password. Perhaps I can change
> the default ASP account used by IIS on both machines -- then I can create
> local accounts with the same username and password.
> Thanks for the suggestion.
> Bill
> "Stephen Dybing [MSFT]" <stephd@.online.microsoft.com> wrote in message
> news:uOFYrdRuDHA.3144@.tk2msftngp13.phx.gbl...
> rights.
> the
> and
> only.
> the
the[QUOTE]
>
|||Since I'm using integrated security I must select an existing NT user; thus
I can't specify a user, ASPNET (or whatever), unless that user exists as a
local user on the machine. I can of course create such a user, but then I've
got the password problem I already mentioned. Have I misunderstood your
suggestion?
Bill
"Stephen Dybing [MSFT]" <stephd@.online.microsoft.com> wrote in message
news:%23nPgnyduDHA.2148@.TK2MSFTNGP12.phx.gbl...
quote:

> No, sorry, what I meant was that when you set up the SQL Server

permissions,
quote:

> try it without including the A\ or B\.
> --
> Sincerely,
> Stephen Dybing
> This posting is provided "AS IS" with no warranties, and confers no

rights.
quote:

> Please reply to the newsgroups only, thanks.
> "Bill Cohagan" <bill@.teraXNOSPAMXquest.com> wrote in message
> news:utxj$XduDHA.1596@.TK2MSFTNGP10.phx.gbl...
think) --[QUOTE]
by[QUOTE]
I[QUOTE]
> then
change[QUOTE]
create[QUOTE]
that[QUOTE]
B[QUOTE]
message[QUOTE]
duplicate[QUOTE]
> the
>
|||Hmm, I had assumed, like Kevin mentioned earlier, that if you used those
workgroup users, where the only thing that changed was the name of the
workgroup, it would work. I've done similar sorts of things with accounts
crossing different domains before and figured this would work as well. If
not, then your problem is beyond what I can help with off the top of my
head, and I don't have workgroup machines here that I can test on. Sorry!
Sincerely,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to the newsgroups only, thanks.
"Bill Cohagan" <bill@.teraXNOSPAMXquest.com> wrote in message
news:eXwPQHeuDHA.1888@.TK2MSFTNGP10.phx.gbl...
quote:

> Since I'm using integrated security I must select an existing NT user;

thus
quote:

> I can't specify a user, ASPNET (or whatever), unless that user exists as a
> local user on the machine. I can of course create such a user, but then

I've
quote:

> got the password problem I already mentioned. Have I misunderstood your
> suggestion?
> Bill
> "Stephen Dybing [MSFT]" <stephd@.online.microsoft.com> wrote in message
> news:%23nPgnyduDHA.2148@.TK2MSFTNGP12.phx.gbl...
> permissions,
> rights.
> think) --
used[QUOTE]
> by
me[QUOTE]
> I
> change
> create
> that
machine[QUOTE]
> B
purposes[QUOTE]
> message
> duplicate
on[QUOTE]
no[QUOTE]
>
|||Please let me know if you're still having a problem with this and I'll
request a couple of workgroup machines from our lab this week and try it
myself. You can reach me directly by removing the "online." from my posting
address.
Sincerely,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to the newsgroups only, thanks.
"Bill Cohagan" <bill@.teraXNOSPAMXquest.com> wrote in message
news:eXwPQHeuDHA.1888@.TK2MSFTNGP10.phx.gbl...
quote:

> Since I'm using integrated security I must select an existing NT user;

thus
quote:

> I can't specify a user, ASPNET (or whatever), unless that user exists as a
> local user on the machine. I can of course create such a user, but then

I've
quote:

> got the password problem I already mentioned. Have I misunderstood your
> suggestion?
> Bill
> "Stephen Dybing [MSFT]" <stephd@.online.microsoft.com> wrote in message
> news:%23nPgnyduDHA.2148@.TK2MSFTNGP12.phx.gbl...
> permissions,
> rights.
> think) --
used[QUOTE]
> by
me[QUOTE]
> I
> change
> create
> that
machine[QUOTE]
> B
purposes[QUOTE]
> message
> duplicate
on[QUOTE]
no[QUOTE]
>
|||OK, I think I've got it working. I discovered (via KB #315158) how to
set the account and password used by IIS via attributes in the
processModel element of the machine.config file. All I needed to do was
1.) Reset the password of the <machine>\ASPNET account to a common value
on both machines.
2.) Edit the machine.config file on both machines to reflect the new
common password.
I'd already added the ASPNET account as a login on the SQL server. Since
now the A\ASPNET and B\ASPNET have common login names AND passwords I
can apparently access the SQL server on machine B via the A\ASPNET
account on machine A. This solves my problem.
Bill
"Bill Cohagan" <bill@.teraXNOSPAMXquest.com> wrote in message
news:eXwPQHeuDHA.1888@.TK2MSFTNGP10.phx.gbl...
quote:

> Since I'm using integrated security I must select an existing NT user;

thus
quote:

> I can't specify a user, ASPNET (or whatever), unless that user exists as a
> local user on the machine. I can of course create such a user, but then

I've
quote:

> got the password problem I already mentioned. Have I misunderstood your
> suggestion?
> Bill
> "Stephen Dybing [MSFT]" <stephd@.online.microsoft.com> wrote in message
> news:%23nPgnyduDHA.2148@.TK2MSFTNGP12.phx.gbl...
> permissions,
> rights.
> think) --
used[QUOTE]
> by
me[QUOTE]
> I
> change
> create
> that
machine[QUOTE]
> B
purposes[QUOTE]
> message
> duplicate
on[QUOTE]
no[QUOTE]
>

No comments:

Post a Comment