Re: Howto refresh IIS 6 Application pool identity credential info

Peter,

I probably didn't get the exact requirement that took you to change the
group membership of the Pool account, or why you're not using kerberos
delegation for your needs. But I'd set the process identity with least
previledge (NETWORK_SERVICE or a simple domain account). Create the needed
Aliases/SPNs/HostHeaders. I'd then delegate the identity with Kerberos from
the UI to the application layer (WebService). The application layer
(WebService/BAL/DAL) again authenticates and authorizes the account as
needed. The Pool identity is the one accessing the backend resources like
DBs, etc...

U = User Identity
P = Pool Identity

U => (U) UI (U) => (U) WebService/BAL/DAL (P) => (P) DB

Where doesn't this scenario fit?

Tiago Halm

"Peke" <peke@xxxxxxxxxxxxx> wrote in message
news:345B6F2C-93B2-4184-839E-29132BDBCD38@xxxxxxxxxxxxxxxx
Hello again David,

We are 'investigating' the impersonation alternative.

What is your suggestion for Application pool identity ? "preconfigured
network service account" or a domain user ? (for a clustered environment).

Our applications are developed in .NET.

How can we protect the impersonation information ?
We've been checking 'protected sections' in web.config and the
aspnet_setreg.exe utility, but in both cases it's really easy to get the
impersonation info with a few lines of code (see below).

And since we would use just one account, it would have access to the
impersonation info of ALL the applications.

Other pitfalls :
- what if an async call is made ? --> by default the process Id would be
used.
- what if a developer removes the section from the config file ?

Seems to me that you have to trust the developer a lot. I know that a
developer can do anything he likes in his code, but as long as it's just
his
own application, I don't care.
But in your scenario, he could get access to other applications by reading
the impersonation info using the process account and so have access to
the
backend systems of other applications. This seems very dangerous to me.

Any suggestions on how to close that security gap ?

Kind regards,

Peter





---------------------------------------

Imports System.Security.Cryptography

Public Class Form1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

TextBox1.Clear()

TextBox1.AppendText("userName : " & GetValue("userName") &
vbNewLine)
TextBox1.AppendText("password : " & GetValue("password"))

End Sub


Private Function GetValue(ByVal key As String) As String

Dim readValue As Byte()

readValue = My.Computer.Registry.GetValue _

("HKEY_LOCAL_MACHINE\Software\Digipolis\PekeApp\Identity\ASPNET_SETREG",
key,
Nothing)

readValue = ProtectedData.Unprotect(readValue, Nothing,
DataProtectionScope.LocalMachine)

Return System.Text.Encoding.Unicode.GetString(readValue)

End Function

End Class

------------------------------

"David Wang" wrote:

I'm sorry, but I do not have any suggestions. I understand what you
are doing and it is pretty clever to a degree, but I believe there are
fundamental problems with your design beyond just incompatibility with
IIS6 that you must choose another design.

IIS is being consistent with security while what you are doing is not
consistent with security (but I do admit it is clever and can be
convenient in some contexts), so it is unlikely IIS will change. I
understand that you have an existing codebase that is being migrated,
so it is really not going to change. So the design has to change.

For example, your design either serializes access to the webserver to
one user at a time, or it is insecure. How? Proof by contradiction --
assume two different users belong to two different user groups have
authorized access overlapping in time. User1 comes in and the AppPool
identity changes group membership to have Group1 and accesses data.
While this is happening, User2 comes in and the AppPool identity
*needs* to change group membership to have Group2 and access data.
What if the two groups are different or conflicting in access
privileges -- you certainly do not want User1 to temporarily have
access to files of User2 simply because your AppPool Identity
momentarily has group membership in both Group1 and Group2 while both
users are accessing different resources through the same system at
overlapping times. Thus, to be secure, the process identity must be in
only one Group at a time, which means that only one user can be
actively using the web server at a time --> this is serialization. Or
if you allow multiple users simultaneously it means that User1 will
temporarily run with a process identity that is in both Group1 and
Group2, thus have additional and/or contradicting privileges --> this
is insecure.

Also, what if the action triggered by the user is asynchronous? How do
you ensure that the user group membership of the Process Identity on
the async callback is the same one as when the call was first made?
Remember, the async callback can happen at any time.

The only secure way to use your authorization scheme using Group
Membership is to make everything synchronous and single user, which
works but will never scale.

Basically, your design looks clever and avoids passwords, but it is
really not feasible when you look at the details. You basically mapped
Roles to Group Membership and to avoid passwords you chose the Process
Identity. However, this fails for all the reasons I stated above, so
IIS never allowed such behavior in Application Pool Identity (let's
not even get into how your scheme plays havoc with Web Garden, or Skip
Process Recycle on Config Change).

Impersonation with user identities and having delegation enabled on
credentials with static and diverse Group Membership flowing through
the system is really the built-in option of how to be secure and
scalable. AzMan approach is a suitable alternative where the Roles are
dynamically bound.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//





On Mar 4, 11:08 pm, Peke <p...@xxxxxxxxxxxxx> wrote:
Hello David,

Sorry for the delay.

I'll try to explain how our applications work.

We develop .NET application using multitier-layer (UI, Webservice,
...).
We've build our own application security, comparable to AzMan, which
wasn't
available at that time (Windows 2000 Active Directory) ; it is based on
roles
and privileges.

IIS (6) is configured to use 'Integrated Security'.

Basically : users are put in a group (or removed from if they no longer
need
access) that has Read rights on the filesystem where the IIS virtual
directory (or IIS virtual server) is pointing to.

The user's privileges are checked in the business part (Business
Facade),
and from that point de application pool identity (a domain user) is
used to
access the data store(s).
That 'data store' can also be another WebService (Service Agent).
--> this is where the problem is : the application pool identity is
becoming
a member of another group to get access to the other application. But
the
security context is only 'refreshed' after IISRESET.

A few reasons why we do it that way :
- Easy security maintenance on the data store (only the application
pool
account needs the necessary rights).
- A developer doesn't have to do anything special in code.
- Application pool identity password is not available in code (and
can't be
mis-used; if we would use impersonation -using config file or in code -
then
the password would be available).

I hope this makes any sense.

Do you have any suggestions ?

Kind regards,

Peter

P.S. You mentioned something about 'lazy read', no recycle on config
change,
how is this done ?



"David Wang" wrote:
Can you explain why you want to dynamically change the security
permissions on the Application Pool Identity user?

The reason why SetSPN is failing is the same sort of logic behind why
you cannot dynamically change the security permissions on the
Application Pool Identity.

Imagine this scenario -- you have a web garden with lazy read (i.e.
don't recycle on config change) enabled, and you change permissions
on
Application Pool Identity. *IF* things changed immediately, you end
up
with w3wp.exe each with different security permissions and further
security implications.

Or in your scenario, what happens if two users which required
different permissions on the Application Pool Identity try to use the
same application served by the same application pool. The w3wp.exe
can
only have one process identity, so one of those two users must wait
until the other is done -- not a good user experience.

Basically, we did not design for Process Identity changing on the fly
like that - we designed for thread impersonation to be changing on
the
fly like that. The Process Identity is the base unit of isolation.
Impersonation is the base unit of functionality.

Is there anything that prevents you from using a single domain
account
as Application Pool identity, and you dynamically impersonate
(depending on your application framework layer, this may be easy).
Because when you do that, SetSPN will also work against your single
fixed Application Pool identity, and I believe impersonation flows
outward on your next hop to the DB, FileSystem, etc.

//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

On Feb 25, 11:28 pm, Peke <p...@xxxxxxxxxxxxx> wrote:
Hello WenJun,

Thx for all the information.

Kind regards,

Peter

""WenJun Zhang[msft]"" wrote:
Hi Peter,

Definitely this has been out of the scope of IIS newsgroup..
Probably it
has something to do with the WM_QUERYENDSESSION and WM_ENDSESSION
Windows
messages. You may take a look at:

Logging Off
http://msdn2.microsoft.com/en-us/library/aa376876(VS.85).aspx

Have a nice week.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.asp....
ications.

Note: The MSDN Managed Newsgroup support offering is for
non-urgent issues
where an initial response from the community or a Microsoft
Support
Engineer within 1 business day is acceptable. Please note that
each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to
reach the
most efficient resolution. The offering is not appropriate for
situations
that require urgent, real-time or phone-based interactions or
complex
project analysis and dump analysis issues. Issues of this nature
are best
handled working with a dedicated Microsoft Support Engineer by
contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers
no rights.- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -




.