Bypass ExecutionPolicy for dot-sourced script

Hello together,
I have a simple script which creates a xml file with user credentials. When I run it as admin it works fine, but when it comes to the general users, I run in two problems.

  1. The user is not allowed to change the execution policy.
  2. The network drive is not persistent and gets removed after the script ends.

For both problems I found solutions.

  1. To change the ExecutionPolicy I just call the file with ExecutionPolicy Bypass from a script running with admin rights:

Powershell.exe -ExecutionPolicy Bypass -File C:\MyScript\ConnectNetworkShare.ps1

  1. To get a persistent network drive I just dot-source the script:

. C:\MyScript\ConnectNetworkShare.ps1

Both work fine, but how can I get these two solutions together?
Is there any way to set the ExecutionPolicy for the script to bypass and dot-source it at the same call?

Best regards
EOberfrank

Eike,
Welcome to the forum. :wave:t3:

That sounds weird … are you using user credentials to create the XML file or do you create an XML file containing user credentials … ?? :thinking:

What exactly do you mean with “gets removed”? Are you talking about a mapped drive letter? If that’s the case whay not just using the UNC path instead?

First of all …

When you post code please format it as code - NOT as quote.

When you post code, sample data, console output or error messages please format it as code using the preformatted text button ( </> ). Simply place your cursor on an empty line, click the button and paste your code.

Thanks in advance

How to format code in PowerShell.org 1 <---- Click :point_up_2:t4: :wink:

( !! Sometimes the preformatted text button hides behind the settings gear symbol. :wink: )

That sounds shady … may I ask whatfor do you do this?

Does the user have admin rights? If not - running the script with admin rights means running it in another context. Are you sure that’s what you need?

Regardless of that - encrypting a password using a secure string can only be reversed with the same user account ON THE SAME computer!!!

That’s why I recommended using the UNC path instead.

1 Like

Hi Olaf,
thanks for the advice with the gear. I was looking for a button for code, but didn’t clicked on the gear. :smiley:

About the xml file:
Before we used and cmd file with the “net use” command, but in that case the users had written their password unencrypted in the cmd.
With the xml file it is not perfectly secured but much better than using a cmd file, because you need at least some encyption knowledge to decrypt the password string.
And yes, only the specific users should be able to access the network share on their specific computers.

About the ExecutionPolicy:
We use baramundi here to distribute software. With that software you can run powershell scripts on computers with admin rights. So I have this baramundi script with the above powershell script and can deploy it to the computers which are used by people who should get access to that network drive.

About the UNC path:
You mean that I just create a shortcut to the specific folder… well that might work. I’ll try that.

But it would be interesting how to solve my problem if there are network drivers where they need to use specific users to access them. :slight_smile:

I didn’t get yet why you need this at all. :man_shrugging:t3:

If a user needs access to a particular drive or service the user should have the proper rights on the drive or the service. It shouldn’t be necessary to use other credentials than their own. :man_shrugging:t3:

Are we talking about an Windows Active Directory Domain?

1 Like

Export-Clixml (Microsoft.PowerShell.Utility) - PowerShell | Microsoft Learn

OP may be using this. On windows, it exports PSCredential Objects using WIndows DPAPI, so it’s encrypted by the user running it.

I know that. Thanks. I just wanted to point out, that you cannot use these encrypted passwords on other computers … a lot of people expect that … that’s all.

Hi Olaf,

first of all thank you.
Your idea with and shortcut with an UNC-Links works fine.

Yes, we use Azure with Entra ID. There we also have some technical users which are used for specific purposes. So in some cases I have to connect with network drives with the credentials of the technical user.

Do I have to mark somehow that my problem is solve?
Edit: Found it!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.