Use Credentials in scheduled task script.

Hello i am actually doing a script wich i start once and then everyday it will start at the same hour.

This thing is that i need to connect my email adresse in order to send mails and i was wondering if it possible that my script dont ask for my password the next time?

you can, but how are you going to achieve this, are you planning to use ScheduledTasks ?

Yeah going to use ScheduledTask.

I need my script to be the sneakiest possible in order to not bother me or the person who will use it.

You can store credentials to a file for reuse, but they’ll only be valid from the machine and the account that stored them.

Pretty straightforward stuff, you take in a PSCredential and export to file:

Get-Credential | Export-CliXml -Path .\cred.xml

Then when you actually run the task, you import it in a similar way:

$Credential = Import-CliXml -Path .\cred.xml

[quote quote=148970]You can store credentials to a file for reuse, but they’ll only be valid from the machine and the account that stored them.

Pretty straightforward stuff, you take in a PSCredential and export to file:

<textarea class="ace_text-input" style="opacity: 0; height: 18px; width: 6.59781px; left: 44px; top: 0px;" spellcheck="false" wrap="off"></textarea>
1
Get-Credential | Export-CliXml -Path .\cred.xml
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Then when you actually run the task, you import it in a similar way:
<textarea class="ace_text-input" style="opacity: 0; height: 18px; width: 6.59781px; left: 44px; top: 0px;" spellcheck="false" wrap="off"></textarea>
1
$Credential = Import-CliXml -Path .\cred.xml
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[/quote]

 

Oh okay, thank i just tried it and it works!

Thank you!

be aware there are still pretty big security concerns with this type of approach.
Remember security isn’t part of powershell, all security is handled with the permissions that the account running the script has.

So if anyone is aware of the location where this script is stored, and has modify access, they can edit the script to maliciously perform any task that the running account has permission to perform.

IE someone could configure your script to email your CEO with your mailbox to deliver malware.

I would encourage you to run this past your security department prior to full implementation.
Personally, I wouldn’t want to have someone else execute a script with my own credential under any circumstance.
I’d explore a service account, shared mailbox, or some other approach.

So if anyone is aware of the location where this script is stored, and has modify access, they can edit the script to maliciously perform any task that the running account has permission to perform.
 

That isn’t how credentials work in the example Joel gave. Import/Export-CliXml uses the Data Protection API (DPAPI) to encrypt and decrypt the contents of the credential object. Someone else browsing to the script and executing it, modified or not, will not completely work because their user account was not used to encrypt the credential object - it will fail to decrypt the credentials so the RunAs portion of the script will fail.

In short, only the user who encrypted the credential object, on the same machine they encrypted it, will be able to decrypt and thus use the object. Only if that same user lost control of their credentials could that script be executed by someone else who logged in as them, and that’s larger problems at that point.

Yep. Worth mentioning, I think, that even with DPAPI it’s not perfectly secure, but it’s pretty difficult to swipe the creds when stored this way unless you’re the kind of admin who occasionally leaves their workstation logged in unattended and unlocked.

 

 

That’s exactly what i use, and even it’s nor that secure for the moment, it’s test phase.

I will have te think and re-think about security before use it out of my LAN.

Thank everyone to help me out with this problem!

I would do something like this.

$cred = [pscredential]::new("mail@domain.com",(ConvertTo-SecureString -String "Password" -AsPlainText -Force))

I would advise strongly against that, especially if the credentials have any privileges. Storing credentials at all is a little bit of a risky prospect, but storing them in plaintext in a script file is, essentially, inexcusable and probably a very dangerous thing to do.

I did store it in a text file (because it’s only a test mail for test) but i do want to store and secure thoes informations.

Do i need to know about xml ou just creat it with basic ?

 

I think we are all going to struggle with advice on how to perform your task.

your original post mentioned you and others running the script, and you say you need to associate the script with your mailbox.
There is no truly secure way for multiple people to execute this script using your stored credentials.
The encryption methods above rely upon the script being executed from the same machine, from the same account.

Think of it this way, what you are asking for us to help you with, is a secure way for you to share your password with 1+ other people to perform an action utilizing the credential.

Why not just give them your pw on a sticky?

[quote quote=149459]I think we are all going to struggle with advice on how to perform your task.

your original post mentioned you and others running the script, and you say you need to associate the script with your mailbox.

There is no truly secure way for multiple people to execute this script using your stored credentials.

The encryption methods above rely upon the script being executed from the same machine, from the same account.

Think of it this way, what you are asking for us to help you with, is a secure way for you to share your password with 1+ other people to perform an action utilizing the credential.

Why not just give them your pw on a sticky?

[/quote]

I must have missexplain.

I actually doing this script and for now only me is interacting with it.

When it will be done, only one person will interact with it and this person will have to add is own creds instead of mine.

You may intend for only one person to interact with it, but there’s no guarantee they will be the only one. If they leave their credentials stored in plain text in some file, somewhere, you have very little control over whether or not a malicious actor will come in and use them wherever they please.

 

so, the cred encryption process listed above will protect the creds themselves.

The big thing to know, is the stored creds will “ONLY” work for the exact same user account that encrypted the pw, running on the same computer that was used to encrypt the pw.

Truthfully, its not that big of a deal to do authentication when dealing with these types of scripts.
I’d just include a get-credential and move on with my life, and just enter the pw whenever I needed that specific process to execute.

Or if I’m performing this as part of a recurring thing, I’d be exploring service accounts with the lowest level of permissions required and utilize a scheduled task.

Yes i am aware of that, i will probably change it for something more secure!