MakeMeAdmin follow-up

[Update Aug 6 2012:  Attached the file to this blog post because the external hosting server is being decommissioned.]


Shortly after I first posted MakeMeAdmin, it was pointed out to me that it didn’t work correctly if the current user account had embedded spaces in the name.  I posted a correction in the comments of that post, but I never got around to updating the download version until now.


The updated contains three script files:  MakeMeAdmin.cmd and MakeMePU.cmd temporarily elevate to admin and to Power User, respectively, as before but now work correctly with embedded spaces in the user name.  The new script is MakeMeAdminSC.cmd.  MakeMeAdminSC works just like MakeMeAdmin but uses smart card authentication for the current user instead of password authentication, via the runas.exe /smartcard option.  Insert your smart card before running MakeMeAdminSC; it will prompt you for the admin password, then for your smart card PIN.  (In order to work, the smart card needs to be associated with the account you’re currently logged in under.)


More on “Default Owner”


In my first MakeMeAdmin post, there’s a section called “Objects created while running with elevated privilege,” the main parts of which I’ll recap here:


Normally, when a user creates a securable object, such as a file, folder, or registry key, that user becomes the “owner” of the object and by default is granted Full Control over it.  Prior to Windows XP, if the user was a member of the Administrators group, that group, rather than the user, would get ownership and full control….  Windows XP introduced a configurable option whether ownership and control of an object created by an administrator would be granted to the specific user or to the Administrators group.  The default on XP is to grant this to the object creator; the default on Windows Server 2003 is to grant it to the Administrators group….


If I use MakeMeAdmin to install programs, my normal account will be granted ownership and full control over the installation folder, the program executable files, and any registry keys the installation program creates.  Those access rights will remain even when I am no longer running with administrator privileges.  That’s not what I want at all.  I want to be able to run the app, create and modify my own data files, but not to retain full control over the program files after I have installed it.


I concluded by saying:


For this reason, I changed the “default owner” setting on my computer to “Administrators group”.


Today I would like to go further:  If you are going to use the same account for admin and non-admin activities (e.g., with MakeMeAdmin), I strongly recommend that you change the “Default owner” setting on your computer to “Administrators group”.


Why?  Well, the malware problem is not going away any time soon.  Running with limited privilege will not make the bad guys stop trying to own your computer – there is far too much profit on the line.  Today, running as a normal User instead of as an admin is tremendously effective against malware, because most malware is not designed for lower-privilege scenarios and it just fails.  But as more people begin running as non-admin, the miscreants will adjust accordingly.  Running as LUA, they will have to find new ways to hide their stuff and to get their stuff to run.  You don’t want to give them the ability to write to the folders containing the programs you run every day, especially if you also run the same programs as admin.


When setting up a new system, I would recommend changing the “default owner” setting as early as possible, and using the built-in Administrator account to install as much as possible.  Don’t create or log in with your normal account until after “default owner” has been changed.


Note that changing the security setting does not change the ownership or access control lists (ACLs) of existing objects, only objects created afterwards.  It might be wise to review the security attributes of folders, files and registry keys on your system, or even to consider wiping your system and starting over.  (Tip to get started:  “DIR /Q” displays the owner of listed files and folders.  Try this in your Program Files folder.)


For Windows XP Professional:


To change the setting on Windows XP Professional, open “Local Security Policy” in Administrative Tools, or run secpol.msc.  You need to be an admin to use this tool.  In the left pane, browse to Security Settings \ Local Policies \ Security Options.  The policy name is “System objects: Default owner for objects created by members of the Administrators group”.  The allowable settings are “Administrators group” or “Object creator”.  Change it to “Administrators group.”


For Windows XP Home Edition:


The “Local Security Policy” utility is not available on Windows XP Home Edition.  To change the setting on XP Home, you need to modify the Registry directly.  All caveats about mucking with the Registry apply here.  You need to make this change while running as admin, so if you mess up, you can really mess up!  In RegEdit, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.  Find the value called “nodefaultadminowner”.  The supported values are “0” for “Administrators group”, or “1” for “Object creator”.  Set the value to 0.

Comments (106)

  1. Mike Rickard says:

    We’ve been doing something like this at work for some time now. For pragmatic reasons we’ve found that in our scenario changing the default owner to administrators is counter-productive; I also argue that in Aaron’s scenario he should use "make me admin" in a more limited way, but retain ownership when he does.

    I’m from an academic scientific research department where users expect control of the specialist software that they need to install to do their work. Until recently this has been dealt with by giving admin rights to their normal user accounts. We were keen to get rid of this, but needed to do this without seeming to "break" their computers.

    What we have is a script that sits on our server, with a shortcut in each users "send to" menu. We describe this as "run with admin rights".

    To avoid the (to us) nightmare scenario of giving users the password for their local administrator account we create 2 domain security groups for each computer. One group is a member of the administrators group on the computer, the other group has "read and write member" permissions on the first group. Those who are allowed to use "run with admin rights" are added to the second group for their computer. A startup script checks the membership of the administrators group, and adds in the group to administer that computer, and removes groups or user accounts that should not be there.

    When a user sends some object to "run with admin rights" they are added to the administration group for their computer and a secondary logon starts whatever they have sent with a shellexecute utility. This allows them to send shortcuts, msi files, .ini files or anything else as well as executables. They are then removed from the administration group. This is equivalent to "make me admin". We decided to handle the issue with explorer by checking to see if that was what they wanted, and to launch IE with a command line to start in explorer mode rooted at "My Computer".

    Because we don’t give them a local admin account, we provide a related script "admin rights on-the-fly" which effectively runs a pause command rather than a secondary logon, so that if they plug in some USB device that pops up one of those authentication boxes asking for an admin level account, they can run that script, then authenticate as themselves. We also advise them that control panel access for administrative tasks is via this "explorer". They need this mainly for uninstalling software.

    This allows our users to perform most tasks that require administrative rights, without having them logon with administrative rights. There should be a "Hall of Great Shame" for those things that require administrative rights but won’t run from a secondary logon. We have to make ad-hoc arrangements for these. Fortunately we don’t want users running "Windows Update", so the fact that this is broken from a secondary logon in XP SP2 doesn’t bother us.

    There are still a number of other changes that are desirable to make, as Aaron has outlined, so that users don’t need administrative rights simply to change the power settings etc. One of the other things we do is to change the permissions on local printers to give interactive "manage Printer" rights. It seems reasonable for users to be able to change settings on personal printers under their physical control, and some multi-function devices need to brought on-line to work as printers, and by default users can’t do this.

    One of the issues we had to deal with in our system, is that users expect the software they have just installed to work. When we ran this system under windows 2000 problems arose, because the programs and their installation directories are owned by administrators, and we came up against the permissions issues that are raised in the regular "Hall(s) of Shame". (Plenty of specialist scientific software would qualify) Even if our users understood what was going on, they’d still have to deal with it by loosening permissions somewhere, and we’d rather they didn’t have to try and work out where, and how and how much. Our objective is to make things as secure as we can, but their objective is to get on with their work, and they will rightly think that security that breaks applications that they have just installed is unacceptable. (We think that fixing the problem by using the "compatible workstation" secedit templates provided by Microsoft is unacceptable. If you’ve not seen these, they give users modify rights to the Program files directory tree, the windows and windowssystem32 directories, and to the HKLMSoftware registry tree)

    Now, in our case, I think that Aaron would be right to say that this does make for an extra degree of risk that would be absent if we used the traditional windows 2000 default owner model. But by leaving the default owner, virtually every package works without intervention by us. In comparison with the alternative of permanent administrative rights, this is a tiny security hole. In partial mitigation I’d point out that OS upgrades are handled by SUS, and we use group policies to install and update key application software such as office and java runtime, so that this never becomes owned by the user. When software that we deploy requires security slackening to operate we make carefully targeted minimum changes.

    However, if you are in Aaron’s position of having a local administrator account, then there seems to be no point in doing what he advocates. If he is installing logo compliant software, then he can use runas as administrator with "runas netonly" to access network shares as himself. The only time he should need to use "make me admin" is for the kinds of reasons he originally set out, per user settings that require admin rights, the installation of software that won’t work without per-user installation, or perhaps the installation of software that won’t run for limited user accounts because of permissions issues. Obviously, if he wants to improve his security he can install that software as local administrator and use regmon and filemon from sysinternals to discover what would be the minimum security adjustments. If there is software that he needs to run via "make me admin" because it really won’t run without admin rights (or so much slackening of security as to be unacceptable) then if it creates documents then those files probably should be owned by Aaron.

  2. How to quickly and temporarily give your non-admin account administrator privileges, without having to log out.

  3. p.f. roberts says:

    Hey there. great blog and thanks for MakeMeAdmin. However, I was particularly struck by aaron’s comment that: "Note that changing the security setting does not change the ownership or access control lists (ACLs) of existing objects, only objects created afterwards. It might be wise to review the security attributes of folders, files and registry keys on your system, or even to consider wiping your system and starting over."

    this all seems like mind blowingly difficult — and of little use for anybody with an existing XP installation who wants to try to try to improve security by ratcheting down user permissions. I guess my question is: will there be features in Longhorn or some future release that makes it easier for folks who are upgrading (not starting clean) to change existing accounts to run as LUA without doing all the acrobatics you describe here?

  4. Denis St-Pierre says:

    I’ve been using runas knowing that the CU hive is always swapped with the Admin’s User hive. I’ve been using it with a freeware Windows Explorer.exe clone called 2xExplorer.

    I’ve combined both by changing one line:

    set _Prog_="c:Program Files2xExplorer.exe"

    and now I can do ANYTHING I want without having to swap back and forth. MakeMeAdmin has solved the "CU hive swap" issue fo installing those dumb-as-dirt setup.exe that plug only the CU hive.

    Thank you!!!

  5. Nik says:

    Is there a posibility to modify the script so that the password for the administrator is also included and you don’t need to enter it. E.g. we want to install automatically an application via a login script. It must be installed under the users-account (shortcuts,…) but the user need to be temporary local admin. The program to run field can it include unc names e.g. "\kemindataMovex Explorer v12JavaClientInstallWorkst Config v12Java.EXE" /S

  6. p.f. roberts – Yes, you absolutely do _improve_ security simply by removing yourself from the Administrators group. However, "security" is not a simple "on/off" setting. No matter what you do, there are always additional risks to consider. Whether you choose to live with the risk identified in this post or not is up to you. I’m just pointing out that it’s there.

    Nik – runas.exe accepts passwords and smartcard PINs only through keyboard input. I’m not on the Windows team and never have been so I don’t know for sure, but I suspect the reason for this is to discourage people from putting plaintext passwords in plaintext script files!

  7. Les Caudle says:

    The ability to use your script with a smart card sounds intriguing.

    What is a good source for a small developer to purchase a smart card and card reader/programmer?

  8. Les Caudle says:

    What is a good source doc for understanding & writing cmd scripts?

    There are many character combinations in MakeMeAdmin.cmd that are not obvious to me.


  9. Les, my main reference for command scripting is: %windir%Helpntcmds.chm. It’s surprisingly powerful – they added a lot of functionality circa Windows 2000.

  10. Les Caudle says:

    Aaron – I’m running W2k Server. When I double click on the ntcmds.chm, I get a msg of:

    This Help file contains topics integrated into the main Windows 2000 Help and is not meant for browsing. For overviews of features and help with specific tasks, click Start, and then click Help.

    The commands, such as "net localgroup", I can figure out.

    I’m mostly interested in the syntax of the special chars such as:


    I can see that it translates to the current program being called – but I’d love to see all this syntax spelled out in a help file or web page.


  11. Yeah, not as much fun on Win2k – if you can get on an XP or 2003 box, you can browse ntcmds.chm directly. On Win2k, bring up Help, go to Index, go to "% (replaceable parameters)" and select the "in batch files" entry immediately beneath it. That’s where all those % terms are defined. Also, go to "cmd command"; in Related Topics at the bottom of the page, click on Windows 2000 Command Reference Main Page.

  12. Les Caudle says:

    Aaron – Do you think it would be possible to create a .NET app that could duplicate the functionality of MakeMeAdmin, and yet not require typing in passwords – and also verify that the local user has been removed from Administrators group?

    For example, could

    be used to start a process as admin, then add the local user to Admin group (using other code), then start a process as the local user, and then remove the loca user from Admins group?

    The code could obtain encrypted passwords from some location (USB thumb drive, easy and cheap) and decrypt them, so as not to be so much of a security risk.

    Could you point me in the right direction on this – or put me in touch with someone who might find this interesting to code?

  13. Complete list of Aaron Margosis’ non-admin / least privilege posts, for easy lookup.

  14. Anonymous says:

    Just so you know, there’s a simple and free tool that solves just about every one of the issues I’ve seen raised here. PolicyMaker Application Security can make any change to a process token (add and/or remove any group and/or modify any privilge) on the fly as processes are launched. It can be targeted to specific users, computers, command lines, application hashes, etc. This solves just about every concern I’ve seen raised here and it’s completely transparent to users. It doesn’t use passwords or seperate user accounts. It’s a group policy extension that’s free when managed from Local GPO. No kiddng – it’s listed on the wiki site.

  15. depeters says:

    As mentioned above PolicyMaker and its Registry Extension are FREE and work GREAT. I had an application that would not run under anything but Local/Domain Admin and the developers would not help with the issue. I installed PolicyMaker and now it works fine with the user logged in with normal User permissions. Thanks for all the info on this site, its a great help for getting applications to work in today’s security context even though some developer’s still think we’re running Win98!!!!

  16. Les Caudle says:

    I set up a new XP Pro SP2 box, and running as a non-admin is going well.

    One quirk I’d like to fix is: when I run Explorer with an Administrator token and add a new folder – it does not not appear unless I refresh Explorer.

    I can run a non-admin Explorer at the same time and see the folder appear immediately when I create it in the admin Explorer.

    Is there a work-around for this?

  17. Les Caudle says:

    I’m having a problem where VS 2003 run using MakeMeAdmin (xp pro sp2 all sec fixes) can single step an ASP.NET fine – but refuses to open IE when I hit continue.

    It also refuses to open IE when run from MakeMeAdmin if I tell it to ‘start without debugging’.

    I can see an iexplorer.exe task getting created in the task manager.

    If I use RunAs Administrator, VS 2003 also refuses to start IE.

    If I log off and log in as Administrator – then VS 2003 will start IE.

    If I add my NonAdmin user to Administrators group (log off and log back in), then VS 2003 will start IE.

    How can I resolve this issue?

  18. tonyso says:

    Get your friends and family, all those folks that come to you for computer help once their machines have…

  19. Shame on me that I forgot last week to mention Robert Hurlbut’s excellent Birds of a Feather session…

  20. dhf says:

    <p>Now I know that it was a stupid thing to do, but I jumped in without applying sufficient thought!<br/>So, whatever you do, <b>DO NOT RUN</b> MakeMeAdmin from an Admin account. ESPECIALLY if there is only one Admin account on your system!<br/>Aaron’s advice page states:


    <i>The bit that runs as local administrator does the following:<br/>

    <ol><li>Adds your current account to the local Administrators group (using NET LOCALGROUP, avoiding the problem of needing network credentials to resolve names);</li>

    <li>Invokes RunAs to start a new instance of cmd.exe using your current account, which is at this instant a member of Administrators;</li>

    <li>Removes your current account from the local Administrators group.</li></ol></i>

    <p>Unfortunately, what is missing is a stage that determines if the current account is a member of the Administrators group in the first place and a condition on the removal from that group at the end of the process.<br/>Aaron, please save others the stress and embarrassment that I have just been through.</p>

  21. dhf – good catch. Here’s the fix:

    After this line in the script:

    if "%1"=="" (

    and before this one:

    runas /u:%_Admin_% "%~s0 %_User_%"

    Add this code:

    if /i %_Admin_%==%_User_% (

    echo Already using the admin account

    goto :EOF


    This does a case-insensitive comparison of the admin account with the account you’re using. If they match, it exits the script right away.


  22. OK, the last entry was a teaser for a blog entry or two on what developers can and IMHO should do regarding…

  23. Dan Harkless says:

    Mike Rickard writes:

    ‘Fortunately we don’t want users running "Windows Update", so the fact that this is broken from a secondary logon in XP SP2 doesn’t bother us.’

    Despite much searching, I have found very little mention of this (including on this blog) and no working solutions. I was hoping MakeMeAdmin might fix the problem, but reading the above comment makes me understand why it doesn’t, since MakeMeAdmin depends on the Secondary Logon service even though you’re re-logging-in as yourself. Windows Update is the final thing I’m forced to log out and re-log-in as Administrator for.

    Aaron, any insights on this one?

  24. Anthony Frazier says:

    If your user account has a blank password, MakeMeAdmin won’t work with the default security settings in XP.

    Below is an update for the code to allow for that. It replaces the contents of the else ( ) block in the script, which is most of the body.

    What it does is toggle the security setting "Accounts: Limit local account use of blank passwords to console logon only" to Disabled right before running the program. Then it switches the value back to Enabled right after running the program.

    ) else (

    echo Adding user %* to group %_Group_%…

    net localgroup %_Group_% "%*" /ADD

    if ERRORLEVEL 1 echo. && pause


    echo Allowing for blank passwords…

    reg ADD HKLMSYSTEMCurrentControlSetControlLsa /v limitblankpassworduse /t REG_DWORD /d 0 /f

    if ERRORLEVEL 1 echo. && pause


    echo Starting program in new logon session…

    runas /u:"%*" %_Prog_%

    if ERRORLEVEL 1 echo. && pause


    echo Limiting blank passwords…

    reg ADD HKLMSYSTEMCurrentControlSetControlLsa /v limitblankpassworduse /t REG_DWORD /d 1 /f

    if ERRORLEVEL 1 echo. && pause


    echo Removing user %* from group %_Group_%…

    net localgroup %_Group_% "%*" /DELETE

    if ERRORLEVEL 1 echo. && pause


  25. Thomas Ludwig says:

    Aaaron, it might be of interest to you that the respected German computer magazine c’t published an enhanced version of MakeMeAdmin. It’s available on

  26. scerazy says:

    Anybody has English transation of this?

    I do not speak German & online translation is useless for this kind of docs

  27. master says:

    maybe you should ask the author: (Mr. Johannes Endres)

  28. master says:

    maybe you should ask the author: (Mr. Johannes Endres)

  29. Dan Kahler says:

    I’ve incorporated a small tweak related to Aaron’s "don’t remove the original admin from the admins group" fix. It casts a slightly wider safety net.

    After this line in the script:

    if "%1"=="" (

    and before this one:

    runas /u:%_Admin_% "%~s0 %_User_%"

    I use this little code segment:

    net localgroup %_Group_% | findstr /I /C:%_user_%

    if ERRORLEVEL 0 (

    echo This account is already in the %_Group_% group


    goto :EOF


    This does a case-insensitive comparison of the admin group membership with the account you’re using. If they match, it displays the message and pauses before exiting.

  30. scerazy says:

    That is the answer I had from Johannes Endres

    about his version:

    One main enhancements is that my version accepts programs and files on the command line (and via drag and drop). The other is the use of /savecred in Windows XP Pro and Server 2003, by which you only have to type one password in stead of two. Third is a check, if you are already in the admin group. The original script would then make you a limited user anyway, which my script doesn’t. Other chnges are minor compared to these.


  31. allank says:

    WARNING: If you (accidentally!) run this command as the same user that is already admin that the script is trying to change to (%_ADMIN_%) then that user is REMOVED from the users allowed to log on. I’m not sure how to restore this yet. Fortunately I have another admin user on this pc so can still logon etc.

  32. allank says:

    The solution is to logon as another administrator user (but NOT in safe mode) and execute this command or similar (where the %% values are the ones from the MakeMeAdmin script):

    net localgroup %_Group_% %_Admin%_/ADD

    eg net localgroup Administrators %USERDOMAIN%myuser /ADD

    This does not work in safe mode because it requires the Workstation service, which does not start in safe mode.

    If edit the MakeMeAdmin script with these changes it will avoid this problem happening to you:

    if "%1"=="" (

    if "%_Admin_%" == "%_User_%" (

    echo You are already logged on as the admin user: %_Admin_%


    ) else (

    runas /u:%_Admin_% "%~s0 %_User_%"

    if ERRORLEVEL 1 echo. && pause


    ) else (

    …same text…not changed…


  33. allank says:

    Final post! The solution is only a partial solution. The issue is MakeMeAdmin removes the _Admin_ user from the Administrators group. So if that user is only a member of the Administrators group, and then the user is removed, they cannot log on. I’m not sure how to test if a user is already a member of the Administrators group, but at least the solution avoid one common problem.

  34. allank – Good catch, and already caught earlier (see earlier comments to this post). See also in an earlier comment the use of the /i switch when making the admin/user comparison — /i makes it a case-insensitive comparison.


  35. TerDale says:

    Dan Kahler: though I like your proposition to cope with all cases, it won’t work as is,because the way errorlevel is handled will lead the script to exit in all cases.

    Moreover, if the current user is locally logged on, and is member of the Administrators group, then "net localgroup %_Group_%" won’t return "%_User_%", but "%USERNAME%" instead 😉

    Thus, here is a new proposition, derived from yours:


    net localgroup %_Group_% | findstr /i /x "%USERNAME%"

    ) else (

    net localgroup %_Group_% | findstr /i /x "%_User_%"


    if ERRORLEVEL 1 (

    goto Continue


    echo Account "%_User_%" is already member of the "%_Group_%" group, aborting…


    goto Exit


    [… unchanged code]



  36. Daniel says:

    For anyone having problems getting Visual Studio 2003 to debug ASP.NET these documents will help you out:

    That article explains how to run ASP.NET with your own account instead of the ASPNET account. It explains what folderpermissions to set and how to adjust machine.config. The username and password are in plain text through (see the second link for a solution to that)

    And for the encryption in machine.config:;EN-US;329290

    It works like a charm now. Thanks for the excelent script!

  37. TomekP says:

    I’m using makemeadmin script together with FreeCommander file manager (in place of CMD window ). It has great features (f.e. fast and easy Control Panel access and many others!) and is free. You can get it here:

    I’ve made for myself installer which statically copies all files to


    so path to FreeCommander is always the same and changed _Prog_ line to following:

    set _Prog_="C:programsmmewfcfreeCommander.exe"

    Try it and enjoy!

  38. Dennis L. says:

    Has anyone else recently noticed that MakeMeAdmin is not working on Windows XP Pro? I have had problems escalating privileges using this tool just within the past two weeks, on machines that I could previously use the tool on. I am thinking that a lately released Microsoft patch has rendered the program inoperable?

  39. Dennis L – I haven’t seen that problem, and my machine is fully up-to-date.  What error is it reporting?

  40. Dennis L says:

    Hi Aaron- The error I am getting is shown below. I am getting this on WinXP Pro with all Microsoft patches installed:

    Attempting to start C:DOCUME~1DENNIS~1DesktopMAKEME~1MAKEME~1.CMD OFFICEde

    nnis as user "OFFICEAdministrator" …



    5: Access is denied.

  41. Dennis L – try putting the CMD file in a location that is readable to all users rather than on one account’s Desktop.  I created a "Utils" folder (as admin) under %ProgramFiles%, and have a shortcut to it on my Desktop.

  42. Dennis L says:

    Aaron – putting the files in c:program filesmakemeadmin (with execute permissions for users) fixed the problem. Thank you!

    What we used to do (and what worked up til a few weeks ago)… Remote Assist a restricted user with Windows Messenger, download your scripts to the desktop, extract them and then login as admin from the command prompt. We had done this with many, many people; I am not sure what happened recently, but this doesn’t work anymore. Regardless, we will set up directories on our user computers as described above and use that method from now on.

    Thank you for such a great tool and your help! This has saved us a ton of trouble and helps our administrators keep the admin passwords under wraps.

  43. coley says:

    Mike Rickard wrote :

    Because we don’t give them a local admin account, we provide a related script "admin rights on-the-fly" which effectively runs a pause command rather than a secondary logon, so that if they plug in some USB device that pops up one of those authentication boxes asking for an admin level account, they can run that script, then authenticate as themselves. We also advise them that control panel access for administrative tasks is via this "explorer". They need this mainly for uninstalling software.

    My request : more info on how I achieve thsi please!

    Some background :

    I work for a university, and all of our student accounts are simply ‘users’ and I definatly do not want to change this, but … we are encouraging them to use usb pens, usb hard drives etc, to carry personal audio/video files around that they are working on, but .. a majority will not install as a user, and we have to log out the student, log in as an admin, connect their device and then they can log back in.

    have you any ideas how I can make a script to help this situation? makemeadmin, looks good, but I dont know how I can apply this to a usb device that they are plugging in?

    All of the web searches, seem to come up with lots of ways to stop usb, but none to allow??

    any ideas?

    many thanks

  44. scerazy says:

    How about autoadmin logon with read admin account with something like Driveshield (now Cornerstone Compuguard)

    Costs extra, but works in excellent way

  45. scerazy says:

    Mike, did you try something like: cpau


  46. Jai says:

    Has anyone found a solution to Les’ problem detailed above?


    "I’m having a problem where VS 2003 run using MakeMeAdmin (xp pro sp2 all sec fixes) can single step an ASP.NET fine – but refuses to open IE when I hit continue.

    It also refuses to open IE when run from MakeMeAdmin if I tell it to ‘start without debugging’.

    I can see an iexplorer.exe task getting created in the task manager.

    If I use RunAs Administrator, VS 2003 also refuses to start IE.

    If I log off and log in as Administrator – then VS 2003 will start IE.

    If I add my NonAdmin user to Administrators group (log off and log back in), then VS 2003 will start IE."

  47. In today’s Webcast we first started off with a continuation from last week. &amp;nbsp;Last week we explored…

  48. A systematic approach for working around LUA bugs that avoids unnecessary exposure – &quot;the rest of the story&quot;

  49. Blue Bearr says:

    I tried to implement the check for the user already being an admin as suggested by Terdale, but had trouble with nested IF statements – in the outer IF, the ELSE statement was always run.  I finally gave up and broke out the extra commands to a Goto statement.  A little messier, but effective. I list them here in case anyone else is trying to get this to work.

    All this comes after the line "set _User_=%USERDOMAIN%%USERNAME%":

    if "%1"=="" (

    Goto UserTest

    ) ELSE (

    echo Adding user %* to group %_Group_%…

    net localgroup %_Group_% "%*" /ADD

    if ERRORLEVEL 1 echo. && pause


    echo Starting program in new logon session…

    runas /u:"%*" %_Prog_%

    if ERRORLEVEL 1 echo. && pause


    echo Removing user %* from group %_Group_%…

    net localgroup %_Group_% "%*" /DELETE

    if ERRORLEVEL 1 echo. && pause


    goto End


    if /i ‘%USERDOMAIN%’==’%COMPUTERNAME%’ (

    net localgroup %_Group_% | findstr /i /x "%USERNAME%"

    ) else (

    net localgroup %_Group_% | findstr /i /x "%_User_%"


    if ERRORLEVEL 1 goto Continue

    echo Account "%_User_%" is already member of the "%_Group_%" group, aborting…


    goto :End


    runas /u:%_Admin_% "%~s0 %_User_%"

    if ERRORLEVEL 1 echo. && pause


  50. Mike says:

    Pretty neat tool…  I am looking for a way to keep a group from running as admin, but also have the ability to run IIS as an admin.  The main limitation is that I cannot give these developers any passwords or use the "RunAs" command.  I’ve been told by Microsoft that this is not possible, but would like to know if you’ve ever explored doing this.

  51. Mike – so you want to enable an otherwise unprivileged group to administer IIS – and inetinfo.exe runs as LocalSystem?  In other words – give an unprivileged group complete control over a process running as LocalSystem?  (Do you see the inherent contradiction?)

    Suggestion:  give the developers computers with Virtual PC (or Virtual Server), on an isolated network.  They can then run guest machines however they need to without putting your enterprise at risk.

  52. Hi Aaron,

    I have written a tool called "Launch Admin". It is designed to be used in conjuction with MakeMeAdmin. It adds an icon to the system tray and allows Administrative tasks to preformed quickly. I wrote the program because of my habit of closing open windows (in this case the admin command prompt). The tool can be downloaded from

    Best Regards,


  53. Brian Williams says:

    Note for W2K users: you can decompile ntcmds.chm and recompile it with auto generate table of contents. The resulting help file no longer refuses access.

    Brian Williams

  54. Alex says:


    I’m not very comfortable with batch files that make global changes.

    Consider a situation when an unsophisticated user invokes MakeMeAdmin to run an app (that requires admin privilges) and a power interruption causes the computer to reboot.

    That user account will be left in the admin group.  Not a good idea.

    Is there a programmatic solution on a per-process basis?



  55. Patrick Rynhart says:

    Hi Alex,

    Another situation which causes a problem is if the user closes the command prompt window *after* they have entered the administrator’s password but *before* they have entered their own password (i.e. they click the cross in the right-hand corner of the cmd.exe shell). In this case, the "net localgroup /DELETE" command is not executed and the user remains (forever) in the administrators group. Such a situation can occur if the user simply changes their mind "halfway" through the MakeMeAdmin process. A possible fix is to issue a soon.exe command directly after the "net localgroup /ADD command" to execute "net localgroup /DELETE" after (say) one minute. The existing net localgroup /DELETE line in the script should remain, with the soon.exe line operating as a backup.

    However, this doesn’t solve the problem of a power interruption/log off/reboot occurring. Ideally, the time between the "net localgroup /ADD" and "net localgroup /DELETE" commands needs to be minimised. At the moment, however, it depends on the time required for the user to enter their own password and then press enter.

    If the user doesn’t mind their own password being stored somewhere (e.g. in their %userprofile% directory), this problem could be addressed by creating an app that completes the same steps as MakeMeAdmin but doesn’t prompt for the users password – instead it reads the user’s password from the file and uses the CreateProcessAsUser API.

    The steps required would be:

    Create a console app to be invoked using runas /u:Administrator. Query winsta0default to find the name of the logged in user.  Use the NetLocalGroupAddMembers() API to add this user to the Administrators group. Then adjust the DACL’s for the window station and desktop using Q165194 at (for the secondary logon of the logged in user). Read in the users password and use CreateProcessAsUser() to run the required admin app. Then use NetLocalGroupDelMembers() to remove the user from the Administrators group. With this approach, the user is only is a member of the administrator’s group for a (very) short period of time. The user is still required to know the administrator’s password, and this is not stored on the hard drive.



  56. Alex & Patrick Ryhnart – there is some risk that those scenarios could happen.  If power fails at that stage, though, you could always log in as local admin at next startup and fix the Administrators membership.  (You could also do it while logged on with your erstwhile non-admin account, but you may have some apps running at startup – like IM – that you don’t want running with admin privs.)

    Re KB 165194, that’s obsoleted in XPSP2 if you use the CreateProcessWithLogonW API.  The resulting token shares the same Logon SID as the caller, so DACLs don’t need to be adjusted.

    Personally, I’d feel a lot more uncomfortable about having my password in a plain text file on my hard drive.

  57. Patrick Rynhart says:

    Thanks Aaron – Good point about the DACLs 🙂

    What if the password on the hard drive was encrypted ? This could be used to prevent other LUA users from decrypting the password.

    (Administrator’s would be able to attach a debugger and see the CreateProcessAsUser() call and password however.)

  58. Patrick Rynhart says:

    If an encrypted password was to be stored, prehaps the safest place to do so would be in HKEY_CURRENT_USER of the nominated administrator account (i.e. the account that calls the NetLocalGroupAddMembers()/NetLocalGroupDelMembers() API). This would protect the hash using the NT security model – as only the administator user can access it. (This is better than having a file on the hard drive – encrypted or not.) It would also allow a means for allowing only “authorised” users to run an elevated app.



    You could, I guess.  Keeping that password file updated would cost a bit of aspirin, IMHO.  — Aaron

  59. Patrick Rynhart says:

    Sorry – not "hash" in the previous post, I mean encrypted password.

  60. Patrick Rynhart says:

    Hi Aaron,

    There’s a better way to prevent a LUA user from remaining a member of the administrators group which doesn’t involve obfuscating passwords.

    The solution is to write an application to be invoked (as before) via runas /u:Administrator

    The application:

    1) Determines the LUA user on winsta0default
    2) Prompts for their password (to be supplied using the keyboard – not read from a file)
    3) Promotes the LUA user to the administrators group
    4) Executes the required app with elevated privileges using the CreateProcessAsUser() API
    5) Removes the LUA user from the administrators group

    In other words, the application performs the same steps as MakeMeAdmin, except that (in the case of MakeMeAdmin) steps 2 and 3 are reversed. Since steps 3-5, above, are completed almost instantaneously, the likelihood of a LUA user remaining a member of the administrators group, in the event of a problem, is significantly reduced.



    Pretty close to how I’d do it if I wrote it as an exe instead of a cmd:  Prompt for the name of the admin account that you’ll use to do the group manipulations, the password for that admin account, and the password for the non-admin account you’re logged in with (I wouldn’t get it from winsta0default – just get the current context).  Call LogonUser with the local admin creds and ImpersonateLoggedOnUser with the resulting token to get admin privs.  Add the user to admins.  RevertToSelf and then launch the target app with CreateProcessWithLogonW (not CreateProcessAsUser for reasons mentioned in an earlier comment-reply).  Impersonate again to local admin, remove the current user from the admins group and RevertToSelf again.

    The hinted-at LUA Buglight (coming soon!) does something very similar to this to get the “this-user-as-admin” context to get through LUA bugs during app analysis.  Lots more on that soon…

    — Aaron

  61. Patrick Rynhart says:

    Thanks for that Aaron – I’ve coded your suggestion up and it works fine!



  62. afw27 says:


    First of all thank you so much for making this i love the idea but how it works thats a problem for me… when i open up the MakeMeAdmin file it comes into a cmd.exe type window and then asks for the admin password…the problem is idk it thats why i got it so i could bypass that… how do i do this? email me at if anyone has an answer.


    Well, yeah, MakeMeAdmin doesn’t allow arbitrary elevation of privilege by unauthorized users.  You need to have admin credentials in order to use it.

    — Aaron

  63. afw27 says:

    Hey agian,

    Ok. So I figured out something. For those of you like me looking for a way to bypass the admin and unlock a website from your routers. All you have to do is restart in Safe Mode by pressing F8 and hiting the Safe Mode then just continue through the restart as normal. When you get to the login stage click on the Administrator account that doesnt have to have a password. From there go to My Computer then to your C Drive. From there click on the “WINDOWS” folder and then click “System32” folder, “drivers” folder and finaly the “etc” folder. Then finaly open the “Hosts” file with wordpad or notepad just some text editor. Then take off the IP address and the website and save. WALA! You have done it!…gotta love determined 15 year olds huh!


    Having a blank password for the admin account makes sense only if you trust everything who has physical access to the console.  Gotta love sysadmins who misconfigure a system that way when the users aren’t supposed to be able to have admin privileges.  BTW – if you can log in to Safe mode with a blank-pwd admin account, then you can do that from the normal logon screen as well.  (Precisely how is left as an exercise for determined 15 year olds.)

    — Aaron

  64. tas says:

    I use the fingerprint reader in my laptop to log onto Windows (by way of third-party software from Wave Systems, which was included it), and I’d prefer to use it for elevation as well, rather than having to fall back to typing the password. Is this possible, or is a smartcard the only alternative to a password?

    I’m pretty sure that RUNAS.EXE is unaware of that fingerprint reader as an authentication mechanism.  If you can replace “RUNAS.EXE” in MakeMeAdmin with an equivalent that uses the reader, it might work.

    — Aaron

  65. Spiral says:

    This is all very good information thank you, and that application “PolicyMaker Application Security” is very good.  I have been fighting all these issues you discuss here, and this application seems to do the trick.  It was mentioned in earlier post here.  What do you think about this app Aaron?

    I’ve written a number of posts (and an article) about approaches to fixing “LUA bugs”, including using the PMAS approach, which is referenced in this post.  IMHO, it should be a last resort.  See this TOC for links to the rest of the Identifying and Fixing LUA Bugs series.

    — Aaron

  66. John McDonnell says:

    I’ve been using MakeMeAdmin with:

    set _Prog_=”C:Progra~1Intern~1iexplore.exe file:///c:/”

    to start regular Windows Explorer as an administrator. This allows me to run setup programs, the Control Panel, etc. Under Windows XP SP2 Home and IE 6, everything works great. But I upgraded to IE 7 and IE refused to be launched this way; I think it just displayed my home page. The release notes for IE 7 mention the removal of the telnet and gopher protocols, but no mention of the file protocol. Any ideas on how to restore this functionality?

    John:  With IE7, iexplore.exe no longer browses the file system.  If you direct it to, iexplore.exe will send a DDE message to the desktop shell, which then opens an explorer.exe window for the requested folder.  See the blog post RunAs with Explorer for another way to browse the file system in a different security context.


    — Aaron

  67. I’ve been somewhat remiss of late in my focus on what I consider to be a very important aspect of the

  68. Lionheart says:

    Most of our machines have two smart card readers.  I tried MakeMeAdminSC and it failed.  There was a message about ‘no card in sc reader x’ then it prompted me for a pin anyway…then I don’t think it could resolve the credentials.  

    (WinXP Pro on domain)

  69. dexter_m says:

    As Aaron mentions in his follow-up blog:

    "Note that changing the security setting does not change the ownership or access control lists (ACLs) of existing objects, only objects created afterwards.  It might be wise to review the security attributes of folders, files and registry keys on your system, or even to consider wiping your system and starting over.  (Tip to get started:  “DIR /Q” displays the owner of listed files and folders.  Try this in your Program Files folder.)"

    So going a step further from “DIR /Q”, here are a few tools that can be used as an alternative to wiping and starting over afresh.

    • SubInACL:

    "SubInACL is a command-line tool that enables administrators to obtain security information about files, registry keys, and services and transfer this information from user to user, from local or global group to group, and from domain to domain."

    SubInACL is included in the Windows Server 2003 Resource Kit Tools.

    • Cacls:

    "Cacls is a command-line tool that displays or modifies discretionary access control lists (DACLs) on specified files."

    • Show ACLs:

    "Show ACLs (ShowACLs) is a command-line tool that enumerates access rights for files, folders, and trees. It allows masking so that you can enumerate only specific ACLs. ShowACLs works on NTFS partitions only."

    More information regarding the above tools over here:

    Sysinternals has a couple of utilities that’s helpful too:

    • AccessChk

    "This tool shows you the accesses the user or group you specify has to files, Registry keys or Windows services."

    • AccessEnum

    "This simple yet powerful security tool shows you who has what access to directories, files and Registry keys on your systems."

  70. Paul says:

    Im having problem with this. My father having a pc for office. One of the staff had make the PC admin with her user name n others user name is not an admin. How to go about this.

  71. dexter_m says:

    Paul, you cannot use this without knowing the admin password. I suggest you read the preceding blog for better understaning of MakeMeAdmin:

  72. Mischa Kroon says:

    Viruses and Spyware are annoying to deal with that’s why the following is a bit of a guide to make sure

  73. From the "doesn’t just saying it make it true?" department: I was reading the March 2008 issue of Maximum

  74. 2wThank’s.6q I compleatly agree with last post.  jwh

    <a href="">ламинат и паркет</a> 7o

  75. Peter Liepmann says:

    I’ve found a new way to break MakeMeAdmin.  To keep it from being used for smart malware, after creating another account with administrative privileges, I deleted the original “Administrator” account.  

    Now when I try to run MakeMeAdmin, it wants the password for a nonexistent “Administrator” account.  

    I figured, OK, I’ll create a new “Administrator” account.

    Oops.  In XP home, I can’t create another “Administrator” or “administrator” account: I get “An account named ‘Administrator’ already exists.   Type a different name.”

    This was possible in NT4, though it was a different account from the original “Administrator” account, FWIW.  

    IS there an easy way to change the default name for the local “Administrator” account??

    Thanks for creating and updating this!

    [Aaron Margosis]  Edit MakeMeAdmin.cmd and change the _Admin_ variable to reference the available admin account instead of “Administrator”.

  76. Fern says:

    Hi all. These days, I don’t have the time to add code for all the great fixes (+ revisions) to MakeMeAdmin v2.0 that have been suggested here. But the added security I’d get via this script is just too good to pass up.

    So I was wondering if anyone (Aaron?) who has kept up with all of the *important* changes to this script would be willing to zip up their complete code and share it with the class.

    Feel free to remove or disable any extra script tweaks (geared toward *your* network/setup needs) that you’ve added into the code. By all means, leave them in if you think they’re brilliant, might be useful to others, or just can’t be bothered to cut out all that text. I’d just ask that you please mark (or hint at) where & what they are so those of us who are already wasting (ahem) far too much of our lives solving other people’s problems aren’t forced to read through the entire script, line by line, in search of unique or non-vital chunks of code.

    So would anyone be kind enough to help your pale & forlorn colleagues with this??

    Thanks in advance and thanks for being patient enough to read my long post 😀

    [Aaron Margosis]  I just run Vista these days, which completely removes the need for MakeMeAdmin.  UAC elevation does basically the same thing (its design was strongly influenced by MakeMeAdmin), but it’s much more graceful and usable than MakeMeAdmin, and has security features (e.g., Mandatory Integrity Control and UIPI) that XP+MakeMeAdmin can’t offer.

  77. Fern says:

    Ah yes, but the glaring drawback to your current solution is its inherent reliance on Vista & users willing to battle that particular OS.

    Oh well, I guess I’ll have to consider pummelling one of my friends until they help me with this. I may be pale & forlorn but I can still pack a punch (or a free meal). And, until then, I’ll hold out hope that, after reading your blog on the interweeb, someone will take pity on a fellow cave-dweller by graciously allowing me to copy off their answer sheet.

    Thanks nonetheless Aaron!

  78. Ihab Moneer says:

    I have a problem with Visual studio 2003.

    i am trying to debug a source code located on visual source safe.

    if i am running as a local admin it works. but when i used the makemeadmin tool – debug is finished but the IE windows won’t show-up in order for you to debug.

    i even tried Sudowin and runas admin all with the same result.

    if i open the page i am debugging manually it opens. but this is frustrating.

    Help please


  79. Chris says:


    This is funny to have all those posts for an essential feature “become a temporary admin” Windows should have for a longtime now.

    [Aaron Margosis] And it has had it ever since Windows Vista shipped.  The UAC “Protected Admin” same-user elevation feature is essentially MakeMeAdmin, but better.

    Anyway, here is my problem, how can I launch a new system tray with makemeadmin ? I need to control parameters for system tray apps and it’s not possible without admin privileges.

    Thank you


  80. gideon says:

    pls you put one video for this.

    other country people can't understand this

  81. gui says:

    hi. I've got an issue with the MakeMeAdmin. The cmd prompt asks for the administrator password, and i'm just no t able to type anything, my keyboard simply doesn't work in this (only in the prompt). What should I do?

    [Aaron Margosis] First of all, are you still running XP?  UAC (Vista/2008 and newer) gets rid of the need for MakeMeAdmin.  You shouldn't be running XP anymore.

    Second, if for some reason you still need to run XP or Server 2003, runas.exe does not echo the password characters that you type into the console.  Most utilities don't.  E.g., if you run NET USE … and it prompts for a password, it doesn't echo the characters you type to the console either.

  82. Iain Waddell says:

    Whenever I use UAC to elevate a command prompt, I always end up with a command prompt with the administrator account, not an elevated LUA.

    What am I doing wrong?

    It seems the only way to get my account as an administrator is to add it to the administrator group, log out, log in, do the elevated work, remove myself from the administrator account and log out and in again. I'd hoped MakeMeAdmin would help but the script failed giving an Access Denied error message, so I assume it's not allowed in Windows 7.

  83. Iain Waddell says:

    Thanks for the info. I'd not realised how UAC worked until I tried adding my LUA to the administrator account. Now I can do things properly.

Skip to main content