Tuesday 17 June 2008

Using Impersonation Batch Files and RunAs to Assist Web Application Testing

The current ASP.NET 3.5 Web application I am working on uses Integrated Windows Authentication to determine group membership and their associated user permissions. While this is great as the users don't have to ever enter login details, the issue is that it is difficult for UAT testers to test functionality under different roles. Never fear... to facilitate ease of testing, you can use the "runas" functionality in Windows 2000/2003/2008/XP/Vista to allow users to impersonate different test users in Active Directory.

For example, you can use the following "PP_Test_ImpersonateSuperUser.bat" file to impersonate a Super User without logging off and logging in as that user. It will also open up IE for the http://pp-test web site (an intranet site).

@ECHO ******Running as SUPER USER (IMTEST11); password is SuperUsersPassWord



runas /user:APAC\imtest11 /savecred "%ProgramFiles%/Internet Explorer/iexplore.exe \"pp-test\""


You can now test to your hearts content without having to log off your normal Windows account or logging on into Terminal Services on another machine as a different user.


mac said...

it would be really great if you could expand on this. ie explain why you need a superUserPassword in the first place etc. Many people like myself are mystified right now in how to support our windows authentication asp.net apps.
I am desperately trying to find a methood that will allow my support people to open a batch file, enter the caller's username, enter their pass, and launch a session as that user. that would be fantastic.
you know.. in your spare time of course.

David Klein said...

Hi Mac. We are using Windows authentication and WindowsTokenRoleProvider in our application. User's roles consequently are based on their active directory groups. We don't want to have to go to active directory and constantly change our group membership in Active Directory as we are testing different parts of the application as different users (it typically takes 24 hours for support to change active directory membership). It is much simpler for us to log in as a user who has predefined roles (e.g. "SuperUser", "FundManagerUser") so we can test accessibility and visibility of role-specific functionality.

The batch file I've provided does exactly as you say. I just run a batch file and it opens up the application as the impersonated user (e.g. "FundManagerUser"). It even caches the password after it has been entered once - so it becomes a one click operation to impersonate different users.

mac said...

hi. thanks for the feedback and ideas. I will be implementing this idea into my online application in the same manner.

Dutch said...

Perfect! Just what I wanted for testing our web apps!