Re: ASP.NET Impersonation / delegation

Discussion in 'ASP .Net' started by bruce barker, Apr 28, 2004.

  1. bruce barker

    bruce barker Guest

    you are on the right track. ntlm will not delegate even if your security
    team allowed delegation, only digest allows delegation.

    on win2k you have no choice but to set SE_TCB_NAME (this is removed in xp).
    its a fairly safe priviledge. its original intent was to control Trojan
    horses (programs that pretended to be the login program).

    -- bruce (sqlwork.com)



    "Magdelin" <> wrote in message
    news:...
    > Hi all,
    >
    > I am trying to implement ASP.NET impersonation/delegation in an intranet

    application in C#. The presentation layer developed in ASP.NET accesses the
    business logic via .net remoting. The business logic in-turn accesses the
    other network resources such as the SQL Server and the Active Directory.
    > Both the business logic and the web application are deployed in IIS

    installed on two separate Win2k servers. Since, the application requires
    "Windows Authentication" in order to implement the declarative Role-based
    security, both business and presentation layers are configured for
    impersonation, by including the <identity impersonate="true"/> tag in their
    respective web.config files. The directory security of business and web
    applications hosted in IIS is configured for "Integrated Windows
    Authentication". The anonymous, digest and basic authentication options are
    not selected.
    >
    > With the above mentioned configuration, if the business logic tries to

    access the active directory, a COMexception occurs with the error message
    "An operation error has occurred". I believe this error has occurred because
    the impersonated account and the computer on which the business logic runs
    are not trusted for delegation by the Domain controller. The following links
    explains the reason for such an error.
    >
    > http://support.microsoft.com/default.aspx?scid=kb;en-us;810572
    > http://support.microsoft.com/default.aspx?kbid=325894
    > http://support.microsoft.com/default.aspx?kbid=264921
    >
    > Link to the newsgroup search
    >

    http://msdn.microsoft.com/newsgroups/managed/default.aspx?query=double hop&d
    g=&cat=en-us-msdnman&lang=en&cr=US&pt=&catlist=&dglist=&ptlist=
    >
    > Since our security team considers trusting win2k server for delegation to

    be a major security risk, I haven't had the opportunity, to test the
    business logic with the trusted configuration myself. From the trace log it
    is clear that the authentication type is NTLM and the account used to test
    the business logic has sufficient privileges to query the Active Directory
    (AD). The application is successful in querying the AD when account
    properties (userName and password) are included in the <Identity> tag.
    >
    > Fortunately, I found few delegation alternatives in MSDN at

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html
    /vxconaspnetdelegation.asp
    >
    > The WindowsImpersonationContext.Impersonate() is now considered as the

    best alternative for impersonating an account that is specially created for
    this purpose. The role based security will be implemented as before but for
    accessing resources such as AD and SQL Server the new helper account will be
    used. The account that currently runs the process will be impersonated with
    a special helper account which will have sufficient privileges to
    impersonate as well as query the AD. Once the task with the AD is completed,
    the windows identity will revert back to its original credentials. The
    following link details how to make such impersonation, possible.
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
    l/cpconImpersonatingReverting.asp
    >
    > When the impersonation and reversion is tried on the win2k server, I

    receive the error message "1314: The required privilege is not held by
    client". I know that the LogonUser API requires "Act as part of the
    operating system (SE_TCB_NAME)" privilege. But, I would like to grant the
    helper account with least possible privilege.
    >
    > Is there a privilege other than the "SE_TCB_NAME" that has fewer

    privileges but can still make the LogonUser API work? Is there a better
    alternative for ASP.NET impersonation/delegation?
    >
    > Any ideas or pointers to articles would be greatly appreciated.
    >
    > Thanks in advance.
    > Magdelin
     
    bruce barker, Apr 28, 2004
    #1
    1. Advertising

  2. bruce barker

    Ken Schaefer Guest

    Hi,

    Unless you are running a Windows 2003 network, neither Digest nor NTLM are
    delegatable. Only Kerberos auth is delegatable. Windows 2003 introduces
    protocol transition, which allows the original user to use any
    authentication mechanism, and IIS 6.0 can get a Kerberos token to access a
    remote resource.

    SE_TCB_NAME is a significant user right as I understand it. Certainly more
    than trusting a computer for delegation IMHO.

    Cheers
    Ken


    "bruce barker" <> wrote in message
    news:...
    : you are on the right track. ntlm will not delegate even if your security
    : team allowed delegation, only digest allows delegation.
    :
    : on win2k you have no choice but to set SE_TCB_NAME (this is removed in
    xp).
    : its a fairly safe priviledge. its original intent was to control Trojan
    : horses (programs that pretended to be the login program).
    :
    : -- bruce (sqlwork.com)
    :
    :
    :
    : "Magdelin" <> wrote in message
    : news:...
    : > Hi all,
    : >
    : > I am trying to implement ASP.NET impersonation/delegation in an intranet
    : application in C#. The presentation layer developed in ASP.NET accesses
    the
    : business logic via .net remoting. The business logic in-turn accesses the
    : other network resources such as the SQL Server and the Active Directory.
    : > Both the business logic and the web application are deployed in IIS
    : installed on two separate Win2k servers. Since, the application requires
    : "Windows Authentication" in order to implement the declarative Role-based
    : security, both business and presentation layers are configured for
    : impersonation, by including the <identity impersonate="true"/> tag in
    their
    : respective web.config files. The directory security of business and web
    : applications hosted in IIS is configured for "Integrated Windows
    : Authentication". The anonymous, digest and basic authentication options
    are
    : not selected.
    : >
    : > With the above mentioned configuration, if the business logic tries to
    : access the active directory, a COMexception occurs with the error message
    : "An operation error has occurred". I believe this error has occurred
    because
    : the impersonated account and the computer on which the business logic runs
    : are not trusted for delegation by the Domain controller. The following
    links
    : explains the reason for such an error.
    : >
    : > http://support.microsoft.com/default.aspx?scid=kb;en-us;810572
    : > http://support.microsoft.com/default.aspx?kbid=325894
    : > http://support.microsoft.com/default.aspx?kbid=264921
    : >
    : > Link to the newsgroup search
    : >
    :
    http://msdn.microsoft.com/newsgroups/managed/default.aspx?query=double hop&d
    : g=&cat=en-us-msdnman&lang=en&cr=US&pt=&catlist=&dglist=&ptlist=
    : >
    : > Since our security team considers trusting win2k server for delegation
    to
    : be a major security risk, I haven't had the opportunity, to test the
    : business logic with the trusted configuration myself. From the trace log
    it
    : is clear that the authentication type is NTLM and the account used to test
    : the business logic has sufficient privileges to query the Active Directory
    : (AD). The application is successful in querying the AD when account
    : properties (userName and password) are included in the <Identity> tag.
    : >
    : > Fortunately, I found few delegation alternatives in MSDN at
    :
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html
    : /vxconaspnetdelegation.asp
    : >
    : > The WindowsImpersonationContext.Impersonate() is now considered as the
    : best alternative for impersonating an account that is specially created
    for
    : this purpose. The role based security will be implemented as before but
    for
    : accessing resources such as AD and SQL Server the new helper account will
    be
    : used. The account that currently runs the process will be impersonated
    with
    : a special helper account which will have sufficient privileges to
    : impersonate as well as query the AD. Once the task with the AD is
    completed,
    : the windows identity will revert back to its original credentials. The
    : following link details how to make such impersonation, possible.
    :
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
    : l/cpconImpersonatingReverting.asp
    : >
    : > When the impersonation and reversion is tried on the win2k server, I
    : receive the error message "1314: The required privilege is not held by
    : client". I know that the LogonUser API requires "Act as part of the
    : operating system (SE_TCB_NAME)" privilege. But, I would like to grant the
    : helper account with least possible privilege.
    : >
    : > Is there a privilege other than the "SE_TCB_NAME" that has fewer
    : privileges but can still make the LogonUser API work? Is there a better
    : alternative for ASP.NET impersonation/delegation?
    : >
    : > Any ideas or pointers to articles would be greatly appreciated.
    : >
    : > Thanks in advance.
    : > Magdelin
    :
    :
     
    Ken Schaefer, Apr 29, 2004
    #2
    1. Advertising

  3. bruce barker

    Ken Schaefer Guest

    If your security guys will not even allow delegation, then I don't think
    they will grant "Act as Part of the Operating System". I do not agree with
    Bruce - I think this is a major right to grant to the ASPNet account.

    Have you considered using a trusted-subsystem approach?

    Cheers
    Ken


    "Magdelin" <> wrote in message
    news:...
    : Thanks Bruce for your inputs.
    :
    : I have included a description on SE_TCB_NAME privilege from one of the MS
    help documents.
    :
    :
    ****************************************************************************
    *************
    : Act as part of the operating system
    : Computer Configuration\Windows Settings\Security Settings\Local
    Policies\User Rights Assignment
    :
    : Description
    : This policy allows a process to authenticate as any user, and therefore
    gain access to the same resources as any user. Only low-level authentication
    services should require this privilege.
    :
    : The potential access is not limited to what is associated with the user by
    default, because the calling process may request that arbitrary additional
    accesses be put in the access token. Of even more concern is that the
    calling process can build an anonymous token that can provide any and all
    accesses. Additionally, the anonymous token does not provide a primary
    identity for tracking events in the audit log.
    :
    : Processes that require this privilege should use the LocalSystem account,
    which already includes this privilege, rather than using a separate user
    account with this privilege specially assigned.
    :
    : By default, only the LocalSystem account has the privilege to act as part
    of the operating system.
    :
    :
    ****************************************************************************
    *************
    :
    : So, I am not sure if my security team will consider SE_TCB_NAME as a safe
    privilege. How about passing the credentials of the helper account directly
    to the System.DirectoryServices.DirectoryEntry constructor? Would that help
    me query as well as manage set of users and groups in AD?
    :
    : Regards,
    : Magdelin
    :
    : ----- bruce barker wrote: -----
    :
    : you are on the right track. ntlm will not delegate even if your
    security
    : team allowed delegation, only digest allows delegation.
    :
    : on win2k you have no choice but to set SE_TCB_NAME (this is removed
    in xp).
    : its a fairly safe priviledge. its original intent was to control
    Trojan
    : horses (programs that pretended to be the login program).
    :
    : -- bruce (sqlwork.com)
    :
    :
    :
    : "Magdelin" <> wrote in message
    : news:...
    : > Hi all,
    : >> I am trying to implement ASP.NET impersonation/delegation in an
    intranet
    : application in C#. The presentation layer developed in ASP.NET
    accesses the
    : business logic via .net remoting. The business logic in-turn accesses
    the
    : other network resources such as the SQL Server and the Active
    Directory.
    : > Both the business logic and the web application are deployed in IIS
    : installed on two separate Win2k servers. Since, the application
    requires
    : "Windows Authentication" in order to implement the declarative
    Role-based
    : security, both business and presentation layers are configured for
    : impersonation, by including the <identity impersonate="true"/> tag in
    their
    : respective web.config files. The directory security of business and
    web
    : applications hosted in IIS is configured for "Integrated Windows
    : Authentication". The anonymous, digest and basic authentication
    options are
    : not selected.
    : >> With the above mentioned configuration, if the business logic
    tries to
    : access the active directory, a COMexception occurs with the error
    message
    : "An operation error has occurred". I believe this error has occurred
    because
    : the impersonated account and the computer on which the business logic
    runs
    : are not trusted for delegation by the Domain controller. The
    following links
    : explains the reason for such an error.
    : >> http://support.microsoft.com/default.aspx?scid=kb;en-us;810572
    : > http://support.microsoft.com/default.aspx?kbid=325894
    : > http://support.microsoft.com/default.aspx?kbid=264921
    : >> Link to the newsgroup search
    : >
    :
    http://msdn.microsoft.com/newsgroups/managed/default.aspx?query=double hop&d
    : g=&cat=en-us-msdnman&lang=en&cr=US&pt=&catlist=&dglist=&ptlist=
    : >> Since our security team considers trusting win2k server for
    delegation to
    : be a major security risk, I haven't had the opportunity, to test the
    : business logic with the trusted configuration myself. From the trace
    log it
    : is clear that the authentication type is NTLM and the account used to
    test
    : the business logic has sufficient privileges to query the Active
    Directory
    : (AD). The application is successful in querying the AD when account
    : properties (userName and password) are included in the <Identity>
    tag.
    : >> Fortunately, I found few delegation alternatives in MSDN at
    :
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html
    : /vxconaspnetdelegation.asp
    : >> The WindowsImpersonationContext.Impersonate() is now considered as
    the
    : best alternative for impersonating an account that is specially
    created for
    : this purpose. The role based security will be implemented as before
    but for
    : accessing resources such as AD and SQL Server the new helper account
    will be
    : used. The account that currently runs the process will be
    impersonated with
    : a special helper account which will have sufficient privileges to
    : impersonate as well as query the AD. Once the task with the AD is
    completed,
    : the windows identity will revert back to its original credentials.
    The
    : following link details how to make such impersonation, possible.
    :
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
    : l/cpconImpersonatingReverting.asp
    : >> When the impersonation and reversion is tried on the win2k server,
    I
    : receive the error message "1314: The required privilege is not held
    by
    : client". I know that the LogonUser API requires "Act as part of the
    : operating system (SE_TCB_NAME)" privilege. But, I would like to grant
    the
    : helper account with least possible privilege.
    : >> Is there a privilege other than the "SE_TCB_NAME" that has fewer
    : privileges but can still make the LogonUser API work? Is there a
    better
    : alternative for ASP.NET impersonation/delegation?
    : >> Any ideas or pointers to articles would be greatly appreciated.
    : >> Thanks in advance.
    : > Magdelin
    :
    :
    :
     
    Ken Schaefer, Apr 30, 2004
    #3
  4. Hi Magdelin,

    According to my understanding, you need to implement the following function:

    User logon one ASP.NET web application. In the web application, we will
    access the business logic. The business logic will access other resources
    that request authentication.

    If I have misunderstood, please don't hesitate to let me know.

    Magdelin, as you know, under this scenario, we can perform the following
    steps to transfer the user authentication:

    1. Enable "Basic Authentication" on the web application and the business
    logic, which will pass the user authentication information to the third
    resources.

    2. If the authentication on the web application is "Windows Integrated
    Authentication", enable "delegate", which will also pass the authentication
    with Kerberos authentication.

    3. Directly Impersonate in the code.

    However, on Windows 2000, if we want to directly Impersonate with
    LogonUser, we need to grant ASPNET with the SE_TCB_NAME user right. This is
    by design. For more information, please check the following article:

    810204 PRB: Per Request Impersonation Does Not Work on Windows 2000 with
    ASP.NET
    http://support.microsoft.com/?id=810204

    Suggestion:
    ===========

    Magdelin, according to above analysis, I suggest that we perform the
    following methods:

    Method 1:
    ----------

    Enable "Basic" authentication for the web application and the business
    logic. This will pass the user authentication to the SQL server or AD.

    Method 2:
    ----------

    Add SE_TCB_NAME user right to the ASPNET account or replace "machine" in
    <processmodel> with another user account, who has the "SE_TCB_NAME" user
    right.


    Method 3:
    Another suggestion: perform access check at middle-tier/COM+, and then use
    a fixed identity to access the backend resources. Something like the
    trusted subsystem as ken mentioned.

    COM+ and Windows 2000: Ten Tips and Tricks for Maximizing COM+ Performance
    http://msdn.microsoft.com/msdnmag/issues/1200/comtips/default.aspx


    If there is any unclear, feel free to let me know. Thanks!

    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)

    Get Preview at ASP.NET whidbey
    http://msdn.microsoft.com/asp.net/whidbey/default.aspx
     
    Steven Cheng[MSFT], Apr 30, 2004
    #4
  5. Thanks Ken. I totally agree with you regd. the SE_TCB_NAME privilege. Even though, I know it is impossible for me to implement trusted delegation, for knowledge purpose I need to clarify this with you. The following link details how delegation can be configured on Win 2000 n/w. http://support.microsoft.com/default.aspx?scid=kb;en-us;810572 . Is it true or am I missing something

    Regards
    Magdeli

    ----- Ken Schaefer wrote: ----

    If your security guys will not even allow delegation, then I don't thin
    they will grant "Act as Part of the Operating System". I do not agree wit
    Bruce - I think this is a major right to grant to the ASPNet account

    Have you considered using a trusted-subsystem approach

    Cheer
    Ke


    "Magdelin" <> wrote in messag
    news:..
    : Thanks Bruce for your inputs

    : I have included a description on SE_TCB_NAME privilege from one of the M
    help documents


    ***************************************************************************
    ************
    : Act as part of the operating syste
    : Computer Configuration\Windows Settings\Security Settings\Loca
    Policies\User Rights Assignmen

    : Descriptio
    : This policy allows a process to authenticate as any user, and therefor
    gain access to the same resources as any user. Only low-level authenticatio
    services should require this privilege

    : The potential access is not limited to what is associated with the user b
    default, because the calling process may request that arbitrary additiona
    accesses be put in the access token. Of even more concern is that th
    calling process can build an anonymous token that can provide any and al
    accesses. Additionally, the anonymous token does not provide a primar
    identity for tracking events in the audit log

    : Processes that require this privilege should use the LocalSystem account
    which already includes this privilege, rather than using a separate use
    account with this privilege specially assigned

    : By default, only the LocalSystem account has the privilege to act as par
    of the operating system


    ***************************************************************************
    ************

    : So, I am not sure if my security team will consider SE_TCB_NAME as a saf
    privilege. How about passing the credentials of the helper account directl
    to the System.DirectoryServices.DirectoryEntry constructor? Would that hel
    me query as well as manage set of users and groups in AD

    : Regards
    : Magdeli

    : ----- bruce barker wrote: ----

    : you are on the right track. ntlm will not delegate even if you
    securit
    : team allowed delegation, only digest allows delegation

    : on win2k you have no choice but to set SE_TCB_NAME (this is remove
    in xp)
    : its a fairly safe priviledge. its original intent was to contro
    Troja
    : horses (programs that pretended to be the login program)

    : -- bruce (sqlwork.com



    : "Magdelin" <> wrote in messag
    : news:..
    : > Hi all
    : >> I am trying to implement ASP.NET impersonation/delegation in a
    intrane
    : application in C#. The presentation layer developed in ASP.NE
    accesses th
    : business logic via .net remoting. The business logic in-turn accesse
    th
    : other network resources such as the SQL Server and the Activ
    Directory
    : > Both the business logic and the web application are deployed in II
    : installed on two separate Win2k servers. Since, the applicatio
    require
    : "Windows Authentication" in order to implement the declarativ
    Role-based
    : security, both business and presentation layers are configured for
    : impersonation, by including the <identity impersonate="true"/> tag in
    their
    : respective web.config files. The directory security of business and
    web
    : applications hosted in IIS is configured for "Integrated Windows
    : Authentication". The anonymous, digest and basic authentication
    options are
    : not selected.
    : >> With the above mentioned configuration, if the business logic
    tries to
    : access the active directory, a COMexception occurs with the error
    message
    : "An operation error has occurred". I believe this error has occurred
    because
    : the impersonated account and the computer on which the business logic
    runs
    : are not trusted for delegation by the Domain controller. The
    following links
    : explains the reason for such an error.
    : >> http://support.microsoft.com/default.aspx?scid=kb;en-us;810572
    : > http://support.microsoft.com/default.aspx?kbid=325894
    : > http://support.microsoft.com/default.aspx?kbid=264921
    : >> Link to the newsgroup search
    : >
    :
    http://msdn.microsoft.com/newsgroups/managed/default.aspx?query=double hop&d
    : g=&cat=en-us-msdnman&lang=en&cr=US&pt=&catlist=&dglist=&ptlist=
    : >> Since our security team considers trusting win2k server for
    delegation to
    : be a major security risk, I haven't had the opportunity, to test the
    : business logic with the trusted configuration myself. From the trace
    log it
    : is clear that the authentication type is NTLM and the account used to
    test
    : the business logic has sufficient privileges to query the Active
    Directory
    : (AD). The application is successful in querying the AD when account
    : properties (userName and password) are included in the <Identity>
    tag.
    : >> Fortunately, I found few delegation alternatives in MSDN at
    :
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html
    : /vxconaspnetdelegation.asp
    : >> The WindowsImpersonationContext.Impersonate() is now considered as
    the
    : best alternative for impersonating an account that is specially
    created for
    : this purpose. The role based security will be implemented as before
    but for
    : accessing resources such as AD and SQL Server the new helper account
    will be
    : used. The account that currently runs the process will be
    impersonated with
    : a special helper account which will have sufficient privileges to
    : impersonate as well as query the AD. Once the task with the AD is
    completed,
    : the windows identity will revert back to its original credentials.
    The
    : following link details how to make such impersonation, possible.
    :
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
    : l/cpconImpersonatingReverting.asp
    : >> When the impersonation and reversion is tried on the win2k server,
    I
    : receive the error message "1314: The required privilege is not held
    by
    : client". I know that the LogonUser API requires "Act as part of the
    : operating system (SE_TCB_NAME)" privilege. But, I would like to grant
    the
    : helper account with least possible privilege.
    : >> Is there a privilege other than the "SE_TCB_NAME" that has fewer
    : privileges but can still make the LogonUser API work? Is there a
    better
    : alternative for ASP.NET impersonation/delegation?
    : >> Any ideas or pointers to articles would be greatly appreciated.
    : >> Thanks in advance.
    : > Magdelin
    :
    :
    :
     
    =?Utf-8?B?TWFnZGVsaW4=?=, Apr 30, 2004
    #5
  6. Thanks Steven for your suggestions.

    The chapter intranet security at
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp
    provides configuration steps excatly like yours for delegation in ASP.NET. I understand that I have to use Basic authentication over SSL in order to enable delegation with NTLM authentication. But, clients
    want the logon to be transparent. Users will be unhappy to re-enter the domain login name and
    password every time they access this intranet application. Using COM+ enterprise services introduces
    additional maintenance efforts. So, I want to keep service components as the last option.
    BTW, I am using SQL authentication to access the database. I am having trouble only while accessing AD. So, I
    guess I am really left with only two options for accessing remote resources from application server

    1. Enable trusted for delegation in order to use the original caller context with Kerberos
    authenticatio
    2. Use the LogonUser API and impersonate a specific windows identity (which obviously will require
    SE_TCB_NAME privilege

    I think I will have to convince my security group to approve one of the configurations listed above

    I haven't implemented role-based security in the business logic yet. I just beleived that if I initiate impersonation on web server and application server, I will be able to implement declarative or imperative role-based security at all layers. But, I am not sure if it really depends on Kerberos/NTLM. Can I implement declarative/imperative role based security in the business logic, if I choose integrated windows authentication(NTLM) on both web and application server

    Regards
    Magdeli


    ----- Steven Cheng[MSFT] wrote: ----

    Hi Magdelin,

    According to my understanding, you need to implement the following function

    User logon one ASP.NET web application. In the web application, we will
    access the business logic. The business logic will access other resources
    that request authentication.

    If I have misunderstood, please don't hesitate to let me know.

    Magdelin, as you know, under this scenario, we can perform the following
    steps to transfer the user authentication:

    1. Enable "Basic Authentication" on the web application and the business
    logic, which will pass the user authentication information to the third
    resources.

    2. If the authentication on the web application is "Windows Integrated
    Authentication", enable "delegate", which will also pass the authentication
    with Kerberos authentication.

    3. Directly Impersonate in the code.

    However, on Windows 2000, if we want to directly Impersonate with
    LogonUser, we need to grant ASPNET with the SE_TCB_NAME user right. This is
    by design. For more information, please check the following article:

    810204 PRB: Per Request Impersonation Does Not Work on Windows 2000 with
    ASP.NE
    http://support.microsoft.com/?id=81020

    Suggestion
    ==========

    Magdelin, according to above analysis, I suggest that we perform the
    following methods:

    Method 1
    ---------

    Enable "Basic" authentication for the web application and the business
    logic. This will pass the user authentication to the SQL server or AD.

    Method 2
    ---------

    Add SE_TCB_NAME user right to the ASPNET account or replace "machine" in
    <processmodel> with another user account, who has the "SE_TCB_NAME" user
    right.


    Method 3
    Another suggestion: perform access check at middle-tier/COM+, and then use
    a fixed identity to access the backend resources. Something like the
    trusted subsystem as ken mentioned

    COM+ and Windows 2000: Ten Tips and Tricks for Maximizing COM+ Performanc
    http://msdn.microsoft.com/msdnmag/issues/1200/comtips/default.asp


    If there is any unclear, feel free to let me know. Thanks!

    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)

    Get Preview at ASP.NET whidbey
    http://msdn.microsoft.com/asp.net/whidbey/default.aspx
     
    =?Utf-8?B?TWFnZGVsaW4=?=, Apr 30, 2004
    #6
  7. Hi Magdelin,

    As for the Role-based rules, this is a certain features of the .net
    application. In fact the roles should be the customer business rules you
    defined which has not buildin relation with the machine or domain's
    account. For example, we have many different account and groups in a domain
    or machine. Then in our application, we can define our own roles and bind
    some certan roles with a certain account. When we got the current User's
    Impersonate Account(machine or domain account), we should lookup our custom
    tables and query out the certain account's roles. This is all defined by
    ourself according to our actual business rules.
    And the buildin things we should care about is just how to pass the user
    account info(credentail) between the different layers (web presentation to
    business or business to data persitence). And the impersonate /delegate is
    just focus on this, rather than roles. Do you think so?

    If there is still anything we can help, please feel free to post here.

    Regards,

    Steven Cheng
    Microsoft Online Support

    Get Secure! www.microsoft.com/security
    (This posting is provided "AS IS", with no warranties, and confers no
    rights.)

    Get Preview at ASP.NET whidbey
    http://msdn.microsoft.com/asp.net/whidbey/default.aspx
     
    Steven Cheng[MSFT], May 4, 2004
    #7
  8. Thanks Steven.
     
    =?Utf-8?B?TWFnZGVsaW4=?=, May 4, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kelly D. Jones

    Problem with impersonation and delegation

    Kelly D. Jones, Sep 4, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    1,826
  2. jm
    Replies:
    1
    Views:
    1,936
    bruce barker
    Dec 20, 2003
  3. Patrick
    Replies:
    3
    Views:
    524
    David Wang
    Nov 16, 2006
  4. Brian

    ASP.NET Impersonation & Delegation

    Brian, Dec 31, 2003, in forum: ASP .Net Security
    Replies:
    1
    Views:
    179
    Jim Cheshire [MSFT]
    Dec 31, 2003
  5. Sam Roberts
    Replies:
    4
    Views:
    318
    Sam Roberts
    May 7, 2008
Loading...

Share This Page