none
Impersonation RRS feed

  • Question

  • Hello folks,

     I need a help here. I'm getting trouble to understand the Impersonation . If someone could help me.

    And If you guys let me...with Windows Authentication the user data is stored at the Active Directory , I read that it's bad to use the Windows Authentication with Internet solutions because it's bad to create a Windows Account for each user that signs up. Why is it bad?


    Very thanks and I'm sorry about my questions, I'm getting trouble to understand those subjects.



    Very Grate,
    Lucas.
    Tuesday, May 19, 2009 1:22 PM

Answers

  • Every executing windows program has a security account associated with it.  The process is restricted to the permissions of that account, except when it impersonates some other account; during which time, it is restricted to the permissions of the impersonated account.  It is possible for a very restricted account to run a program that then impersonates a much less restricted account as well as the other way around.  In Windows, permissions are applied at the thread level, so it's possible for a program to have independent threads running under different accounts.  See http://msdn.microsoft.com/en-us/library/aa376391(VS.85).aspx .

    If you create AD accounts for every internet user who requests one, then you open yourself up to denial of service attacks.  On any given hardware, AD will have a limit to the number of entries it can store as well as some limit to the number of entries it can efficiently process in some period of time.  Many tens of thousands of accounts will slow AD response times down appreciably.  An attacker could deploy thousands of bots to attempt creating millions of accounts on your system.  Eventually, your entire domain would be rendered useless (probably within tens of minutes to several hours) as authentication requests begin timing out and resends accumulate and compound the problem.

    Even if you code to limit the rate of account creation, you simply put the problem off to a later date.  AD is not optimized for that kind of use.  A good SQL server database is and if it does fall under stress it won't bring the rest of your network(s) down with it.  Securely acquiring a name and password from a user and authenticating them against a database will require fewer packet exchanges between your web server and the client and will exhibit far lower latency issues than if you used windows authentication for that purpose.  Windows authentication is not optimized for high latency networks like the internet and this results in far more retries of the authentication process, which further degrades performance. 
    Joseph w Donahue joseph@odonahue.com www.odonahue.com
    • Marked as answer by Rushwish Thursday, May 21, 2009 1:05 PM
    Wednesday, May 20, 2009 10:37 PM

All replies

  • Every executing windows program has a security account associated with it.  The process is restricted to the permissions of that account, except when it impersonates some other account; during which time, it is restricted to the permissions of the impersonated account.  It is possible for a very restricted account to run a program that then impersonates a much less restricted account as well as the other way around.  In Windows, permissions are applied at the thread level, so it's possible for a program to have independent threads running under different accounts.  See http://msdn.microsoft.com/en-us/library/aa376391(VS.85).aspx .

    If you create AD accounts for every internet user who requests one, then you open yourself up to denial of service attacks.  On any given hardware, AD will have a limit to the number of entries it can store as well as some limit to the number of entries it can efficiently process in some period of time.  Many tens of thousands of accounts will slow AD response times down appreciably.  An attacker could deploy thousands of bots to attempt creating millions of accounts on your system.  Eventually, your entire domain would be rendered useless (probably within tens of minutes to several hours) as authentication requests begin timing out and resends accumulate and compound the problem.

    Even if you code to limit the rate of account creation, you simply put the problem off to a later date.  AD is not optimized for that kind of use.  A good SQL server database is and if it does fall under stress it won't bring the rest of your network(s) down with it.  Securely acquiring a name and password from a user and authenticating them against a database will require fewer packet exchanges between your web server and the client and will exhibit far lower latency issues than if you used windows authentication for that purpose.  Windows authentication is not optimized for high latency networks like the internet and this results in far more retries of the authentication process, which further degrades performance. 
    Joseph w Donahue joseph@odonahue.com www.odonahue.com
    • Marked as answer by Rushwish Thursday, May 21, 2009 1:05 PM
    Wednesday, May 20, 2009 10:37 PM
  • Thanks a lot Joseph!
    Thursday, May 21, 2009 1:05 PM