none
Run non-elevated process from elevated Powershell script

    คำถาม

  • Hello everyone,

    I got some trouble with the login script at a customer. He wants to map network drives under Microsoft Windows 7 through a script, because of some neat logic used in it. However, some user do not see the network drives, because they have admin priviledges and UAC is enabled. Since login script run with the highest possible priviledge level, network drives are in that case mapped to the full admin token of the user and not to the user's normal session - resulting in missing drives in the Windows Explorer. This article here describes the problem in detail: http://technet.microsoft.com/en-us/library/cc766208(WS.10).aspx

    At the moment I am aware of two possible solutions, but both have weak spots. The first involves enabling linked connections between the full admin token and the normal user token. The solution is considered a security risks and is deprecated by Microsoft. The other solution involves the use of a launcher scripts (e.g. launchapp.wsf), which creates a scheduled tasks running in the normal user context. While this may work, it does not seem to be very professional.

    Now the question is: Can I launch a non-elevated process from an elevated powershell-based login script?

    While I found this post (http://stackoverflow.com/questions/196949/how-to-run-not-elevated-in-vista-net) detailing how to do it in C#, I have not found an elegend solution in Powershell yet.

    Does anybody have an idea???


    ----------------------- Greetings from Germany, Martin

    20 มีนาคม 2555 7:55

คำตอบ

  • Hi,

    I think the short answer to the question might be to use the EnableLinkedConnections registry setting.

    Bill

    20 มีนาคม 2555 15:18
  • I am aware of this registry setting, but as stated in the linked article (http://support.microsoft.com/kb/937624/en-us):
    Important This workaround may make your system unsafe. Microsoft does not support this workaround. Use this workaround at your own risk.
    Since the customer works with security relavant data, this is not an option.

    Hi,

    The best reference I have found yet about this specific issue (other than the mostly useless caveat you pointed out in the knowledge base article) is this blog response. (I say mostly useless because they give a warning without any context or support.) In other words, the "attack surface" that is potentially exposed by enabling this setting is extremely small.

    Of course you are welcome not to use EnableLinkedConnections, but in my experience is 1) there is no known exploit that takes advantage of this setting, and 2) it solves the problem.

    Also: I would point out that the registry setting is not needed when the users that are logging on are not members of the local Administrators group, as there is no split token in this case. If security is the real concern then you should not have users logging on as Administrators in the first place.

    Bill

    21 มีนาคม 2555 17:45

ตอบทั้งหมด

  • First of all, have you considered using Group Policy Preferences to map the drives instead of a login script? GPP's can be used to present users with mapped drives as well. If you have not had a look at this option yet here are some articles describing the process:

    Configure a Mapped Drive Item  

    Using Group Policy Preferences to Map Drives Based on Group Membership 

    20 มีนาคม 2555 8:23
  • Hi Japp,

    thanks for the fast reply. Yeah, I had already look at it - and using it at another customer. The problem here is, that I have 80 locations with local file servers. Therefore I would need a policy with 3 rules per location, 80 locations total meaning more than 240 lines. Or I have 80 policies all linked to the same OU filtered by a security group. Both options are not really viable.

    If it would be possible to get a custom variable in the processing for the group policy preference extention for network drives, that would really help me. Specificly I need to get the name of the server hosting the home share of a user, because the other 3 mapping go to that same server. Unfortunately, it is NOT the logon server - at least not in all cases.


    ----------------------- Greetings from Germany, Martin


    • แก้ไขโดย Rabbit_at_Net 20 มีนาคม 2555 9:42 typo / additional information
    20 มีนาคม 2555 9:16
  • Hi Japp,

    thanks for the fast reply. Yeah, I had already look at it - and using it at another customer. The problem here is, that I have 80 locations with local file servers. Therefore I would need a policy with 3 rules per location, 80 locations total meaning more than 240 lines. Or I have 80 policies all linked to the same OU filtered by a security group. Both options are not really viable.

    If it would be possible to get a custom variable in the processing for the group policy preference extention for network drives, that would really help me. Specificly I need to get the name of the server hosting the home share of a user, because the other 3 mapping go to that same server. Unfortunately, it is NOT the logon server - at least not in all cases.


    ----------------------- Greetings from Germany, Martin


    From your statements I don't think you understand Group Policy.

    How can you get a login script to run as an administrator.  YOu can't.  A login script does NOT run as an administrator or with elevated privileges.  Drive mapping does not require UAC.  Perhaps the drive are using NET USE with credentials.

    Without a copy or sample of the script this discussion is ambiguous.  Please supply the script.

    Login scripts should be narrowly targeted.  Group Policy preferences should be narrowly targeted.  A GPP can be devised per OU, per SITE or filtered by group.  ALl of this allows for very narrowly targeted GP processing.  There is no need for extensive logic in a script to get granular application of mapping of drive, printers or almost any other adjustments to th session or files.


    ¯\_(ツ)_/¯

    20 มีนาคม 2555 13:58
  • Hi,

    I think the short answer to the question might be to use the EnableLinkedConnections registry setting.

    Bill

    20 มีนาคม 2555 15:18
  • Hi,

    I think the short answer to the question might be to use the EnableLinkedConnections registry setting.

    Bill

    Hi Bill,

    thanks for the input. I am aware of this registry setting, but as stated in the linked article (http://support.microsoft.com/kb/937624/en-us):

    Important This workaround may make your system unsafe. Microsoft does not support this workaround. Use this workaround at your own risk.

    Since the customer works with security relavant data, this is not an option.

    @jrv: I am aware of how group policy preferences and login scripts work. I know, that I do not need admin rights to map network drives. But: If a user has admin rights and UAC is enabled, the login scripts runs with elevated rights mapping the network drives to the elevated user context. As a result, non-elevated process do not see those drives and cannot access them.
    See also http://technet.microsoft.com/en-us/library/cc766208(WS.10).aspx:

    UAC may prevent Group Policy logon scripts from appearing to work properly.
    For example, a domain environment contains a GPO that includes a logon script
    to map network drives. A nonadministrative user logs on to the domain from
    a Windows Vista computer. After Windows Vista loads the desktop, the
    nonadministrative user starts Windows Explorer. The user sees their mapped
    drives. Under the same environment, an administrative user logs on to the
    domain from a Windows Vista computer. After Windows Vista loads the desktop,
    the administrative user starts Windows Explorer. The user does not see their
    mapped drives.

    Hence the original question: How do I always start a script in non-elevated user context?


    ----------------------- Greetings from Germany, Martin


    • แก้ไขโดย Rabbit_at_Net 21 มีนาคม 2555 6:41 Formatting
    21 มีนาคม 2555 6:40
  • Unfortunately that issue was anold one that afected early Vista users and has been fixed.

    Mappping a drive does not require elevation and logon scripts do not run elevated.  Whatever you r issue it appears that yuo are misisng some piece of information.

    I havve systems I log into daily that map drives frm both GP and loginscrpts.  The account I use is an admino account.  I do not have problems.

    If the account is using a login script that is stored on the local machine - if the admin account is a local account, then you may have an issue on Vista.

    The question you have asked is,  :How do I always start a script in non-elevated user context?" is simple to answer.  Scripts alwasy start in non-elevated mode. You have to take specific steps to elevate a script.

    We really need to see you exact script to determine what your issue is.


    ¯\_(ツ)_/¯

    21 มีนาคม 2555 8:56
  • Just to be certain I went back and tested a logon scrpt on Win 7.  I can easily map any resource with no issues.  I cannot test against Vista as we have no Vista machines anymore  Only Ws2008(R2) and Win7.

    I tested on WS2008 and R2.  There is no issue with elevation.  drives map correctly.

    If you are in a non-domain environment such as a home network an are trying to use credentials to a share then yuo may have an issue if you are mapping back to the machine you ar e logging into (EventID 3019).  That is because this is, according to Microsoft support, an unsupported way of mapping a drive.  This has been true since early Windows for some reason.  It will throw all kinds of errors although I have never tested this on Vista or later systems.  In the past I have just ignored the errors.

     Ireread the article you posted again and did a little more research.  The issue affected Vista only and does not affect Windows 7.  If yuo have an issue with Windows 7 then you should open a support incident with Microsoft to determine what is misconfigured.

    I have been  mapping drives on WINdows 7 to aadmin accounts for over a year on numerous sites and have nover seen this happen so, if it is happening to you, it is likely something else is a problem.

    There is no way to remedy yuor issue in a script.  The workaround for Vista may help you but it should never be required for WIndows 7 and later systems.  Windows 7 does not run logon scripts elevated from what I can see.

    The article posted does not have an equivalent for WIndows 7 or WS2008.  I have also not seen this on Vista systems.  I think i was remedied at SP1.


    ¯\_(ツ)_/¯


    • แก้ไขโดย jrv 21 มีนาคม 2555 9:20
    21 มีนาคม 2555 9:18
  • A little more research seems to point to the problem being created in Visra SP1 and fixed at Windows 7 Sp1 and Vista Sp2.

    I would absolutely check with Microsoft support as you may have missed a service pack or something may have caused an issue with teh fix.


    ¯\_(ツ)_/¯

    21 มีนาคม 2555 9:25
  • Hi jrv,

    thanks for the input. Can you provide me with a link to the KB article pointing out the fix?


    ----------------------- Greetings from Germany, Martin

    21 มีนาคม 2555 15:34
  • Hi jrv,

    thanks for the input. Can you provide me with a link to the KB article pointing out the fix?


    ----------------------- Greetings from Germany, Martin

    I don't have it.  The problem has not been reported since teh release off Win7 SP1 and Vista SP2.  All articles you have are posted for Vista and are older.  The WIN7 issue was reported after the initial release.

    There is no workaround for the issue except what Microsoft has noted in the article you posted.

    This is not a scripting issue and ther eis no solution with scripting.  YOu will need to troubleshoot your systems to find out what is missing.  Sometime installing third party software overwrites a systm module. Only Microsoft can fix this with you.

    Before contacting Microsoft you should run SFC to be sure all OS system files are intact.


    ¯\_(ツ)_/¯

    21 มีนาคม 2555 17:13
  • I am aware of this registry setting, but as stated in the linked article (http://support.microsoft.com/kb/937624/en-us):
    Important This workaround may make your system unsafe. Microsoft does not support this workaround. Use this workaround at your own risk.
    Since the customer works with security relavant data, this is not an option.

    Hi,

    The best reference I have found yet about this specific issue (other than the mostly useless caveat you pointed out in the knowledge base article) is this blog response. (I say mostly useless because they give a warning without any context or support.) In other words, the "attack surface" that is potentially exposed by enabling this setting is extremely small.

    Of course you are welcome not to use EnableLinkedConnections, but in my experience is 1) there is no known exploit that takes advantage of this setting, and 2) it solves the problem.

    Also: I would point out that the registry setting is not needed when the users that are logging on are not members of the local Administrators group, as there is no split token in this case. If security is the real concern then you should not have users logging on as Administrators in the first place.

    Bill

    21 มีนาคม 2555 17:45
  • Bill - I agree.

    I also believe that a call or post to MS support will get the patch for this and fix it.  No copy of WIndows 7 that I have installed on WS2003/WS2008/WS2008R2 domins has ever exhiited this symprom but all were isnstalled with SP1 nad all patches up to October of last year.  I find no reerences to this issue on any newly installed systems but older installs still report tyhis. 

    In many cases I have found that issues reported would track back to a missing SP1 or to files on the PC that needed to be updated.

    I had one last week.  A Dell. The installed image had old systemm files even though it had come with SP1.  I ran SFC/SCANNOW and about 30 files were replaced.  The issues reported including authentication failures all disappeared.

    Dell has had this issue as far back as XP.  The delivered systems pre-installed OC is not the same as the recovery image.

    I recommend chacking all patches and updates then running SFC/SCANNOW.  After running SFC you need to reboot then run Windows update a couple of times.

    I have a very strong feeling that this will fix the  issue.  If not then contact MS for assistance.


    ¯\_(ツ)_/¯

    • เสนอเป็นคำตอบโดย Richard MuellerMVP, Moderator 2 เมษายน 2555 0:17
    • ทำเครื่องหมายเป็นคำตอบโดย Richard MuellerMVP, Moderator 2 เมษายน 2555 20:39
    • ยกเลิกการทำเครื่องหมายเป็นคำตอบโดย Bill_StewartModerator 14 พฤษภาคม 2555 21:20
    • ยกเลิกการนำเสนอเป็นคำตอบโดย Bill_StewartModerator 14 พฤษภาคม 2555 21:20
    21 มีนาคม 2555 20:02
  • I tested a GPO logon script that maps a drive and confirmed this is not a problem on Windows XP, Windows Server 2003, Windows 7, or Windows Server 2008 R2. In all cases I can logon as administrator (or a normal user) and the logon script maps the drive and I can see it. Unfortunately, my Vista computer died so I cannot test that OS. I also searched and found no patches or updates to fix this on Vista. You seem to have identified the only work arounds. I think kb 937624 is the only solution (other than the ugly launchapp.wsf).


    Richard Mueller - MVP Directory Services

    24 มีนาคม 2555 18:21
  • Ricard - I could not find any KBs either but I know that on later Vista it was fixed. SP2 maybe.  It was one of those silent Microsft fixes that they don't like to admint needed to be made.  Sort of like thefixes to teh MSI installer that fixed the WMI issues.  If you tals to teh correct team they will say you need MSI 4.5 or later installed.  I suspect the same is true for Vista which is anopther system MS seems to be wanting to abandon.

    Remember Windows ME?

    Windows 7 sort of makes Vista look like a wasre of time.  Did you notice that you cannot buy WS2008 anymore.  We couldn't get a single copy out of CDW.  We did get it with SA as a fallback with the WS2008R2 licenses.  It just showed up as downloadable along with the R2 version.


    ¯\_(ツ)_/¯

    24 มีนาคม 2555 18:49