Storing credentials for Powershell scripts – Encrypted Strings or Credential Manager

If you’ve been reading through some of our other blog posts, you’ll have noticed that we generally like to automate things using Powershell – which quite often requires storing credentials somehow. Preferably not in plain text.

In our existing scripts on this blog, the process has generally involved generating an encryption key, using that key to convert a password to an encrypted string, then storing both in individual files. While that method works fine and has some nice benefits, there’s another alternative that’s worth knowing about: storing credentials in Windows Credential Manager.

I’ll put the code for both methods further down, but first I’d like to list the main differences between the two methods:

Encrypted string in file

  • Portable between users and computers
  • Can be used in WinPE or wherever Powershell is available
  • Only as secure as the NTFS permissions on the files storing the key and encrypted password (someone with read access can use powershell to reveal the password if they know what the files are for)
  • Utilises a bit of ‘security by obfuscation’ – depending on how you name the files, no one is going to know what they’re for, and malware/viruses definitely aren’t going to realise the files are encrypted credentials that could be easily reverse-engineered.
  • When used with Task Scheduler, the scheduled task can be run as any user/local system

Windows Credential Manager

  • Only portable between computers if using roaming profiles; isn’t portable between users
  • Can only be used in a full-windows environment that has Windows Credential Manager (ie: not in WinPE)
  • Is as secure as the Windows account attached to the credential store (assuming a complex password, pretty secure)
  • If the Windows account becomes compromised somehow (you leave the PC unlocked, malware/virus, etc), it’s a relatively simple process to pull any account details you’ve stored in Windows Credential Manager via Powershell.
  • When used with Task Scheduler, the scheduled task has to be running as the Windows account attached to the credentials store

So, how do you do each of these?

 

Scripting Office 365 licensing with disabled services

In the past I’ve had a few clients request scripts to automatically set/assign licenses to users in Office 365 – Generally pretty simple stuff. Recently I had a client ask to disable a particular service within a license – again, not all that difficult – unless you want to actually check if a license/service is already configured correctly (and not make any changes if it is). Took a little while to work out, so figured I’d share the love!

Just to set a license for a user is a pretty simple process – all you need is the license ‘SkuId’ value of the relevant license. To get a list of the ones available in your tenant, run: Get-MsolAccountSku You’ll get a list of the available license SkuId’s and how many are active/consumed. In this article we’ll use an example SkuId of Contoso:STANDARDWOFFPACK_IW_STUDENT. Once you have the SkuId, all you need to run to assign the license is:

You’ll notice that the code above sets the location first – this is required, as you can’t apply a license without a location being set! What if you didn’t want to have all the applications available for the user? For example, the above license includes Yammer Education. In this case, we need to create a ‘License Options’ object first.

 So where did we get the “YAMMER_EDU” from? You can list the available services for a license by running:

What if we wanted to disable multiple services in the License Option? The “-DisabledPlans” option accepts a comma-separated list. For example:

Ok, so now we know how to get the available licenses and related services – as well as how to assign the license to the user. What if we wanted to check if a license is assigned to a user first? Personally, I’m not a huge fan of just re-stamping settings each time you run a script – so I thought I’d look into it. The easiest method I’ve found is to try bind to the license, then check if it’s $null or not:

From there we can do whatever we want – if the license is found and that’s all you care about, you can skip – otherwise you can use the other commands to set the license.
So what if we also want to make sure YAMMER_EDU is disabled as well? That’s a little trickier. First we need to bind to the license like we did above, then we need to check the status of the relevant ‘ServicePlan’.

At this point it’s probably a good idea to talk about the structure of these objects – you may not need to know it, but for anyone trying to modify these commands it might be helpful:

  • A ‘User’ object contains an attribute ‘Licenses’. This attribute is an array – as a user can have multiple licenses assigned.
  • A ‘License’ object contains two attributes relevant to this script; ‘AccountSkuID’ and ‘ServiceStatus’
    • AccountSkuId is the attribute that matches up with the AccountSkuId we’re using above
    • ServiceStatus is another array – it contains an array of objects representing the individual services available in that license – and their status.

The two attributes attached to a ‘ServiceStatus’ object that we care about are:

  • ServicePlan.ServiceName – this is the name to match the service above (eg: YAMMER_EDU)
  • ProvisioningStatus – this can be a bunch of values, but mostly ‘Success’, ‘Disabled’ or ‘PendingInput’. I’d assume there’s also ‘Provisioning’, but I’ve never seen it.

With this in mind, we can put together a script like the following – it reads the UPN and AccountSkuID from a CSV file, though you could use whatever source you like and update the script accordingly.

Note: In order to run this script, you’ll need:

 

Automating Mailbox Regional Settings in Exchange Online

When you migrate (or create) a mailbox in Exchange Online, the first time a user goes to open their mailbox they are prompted to select their Timezone and Language. I recently had a client ask for a more automated method of pre-populating these values, so thought I’d have a look into it.

Of course, there’s no global way to define these settings for users before they get a mailbox, so the settings have to be set once the mailbox has been migrated – this really only leaves the option of a custom powershell script – either something you run after each migration (or creation), or on a periodic schedule.

First, to the settings themselves. As it turns out, you can use the same commands that you’d use in on premise Exchange: Get-MailboxRegionalConfiguration and Set-MailboxRegionalConfiguration – which also means this script could be adapted to be used on premise as well. The two settings we’re concerned with here are “Language” and “TimeZone”. Since the client we’re dealing with here is solely based in Australia, we’re going to be setting all users to a language of “en-AU”. For the TimeZone, Microsoft provide a list of valid values here: https://support.microsoft.com/en-us/kb/2779520

Except that they’re missing two Australian time zones. The actual valid values for Australia are:

  • AUS Central Standard Time – Darwin
  • Cen. Australia Standard Time – Adelaide
  • AUS Eastern Standard Time – Canberra, Melbourne, Sydney
  • E. Australia Standard Time – Brisbane
  • Tasmania Standard Time – Hobart

So with that in mind, we can use the following commands:

Since we’re talking about a national business with users in different time zones, the time zone value is going to need to change for each user. In order to automate this, we’ll need some source information available that indicates in which state the user is located – ideally, you’re going to be using the ‘Office’ field in the user’s AD account – though obviously you could use any available attribute. The reason I recommend ‘Office’ (or ‘physicalDeliveryOfficeName’) is because it’s synchronised to Office 365 with the user account (and becomes ‘Office’).

Note: You don’t actually need the value in Office 365 – if you’re running the script on premise, you can query your AD directly and ignore the attributes in 365. When I wrote the script I opted to solely use data that was in Office 365 – primarily because I was developing the script remotely and didn’t have direct access to their AD – so if you want to use your local AD instead of values in 365, you’ll need to modify the script!

For this client, the ‘Office’ value for each user is prefixed with the state (ie: SA, NSW, QLD, WA) – so it was relatively simple to use a ‘Switch’ function in Powershell (similar to a ‘Case’ statement in vbscript).

In order to use the script, you need the following:

You’ll also need to update the 5 variables at the top of the script (paths, etc), as well as the Time Zones (and criteria) in the Switch statement.

 

Using Azure RM Site to Site VPN with a Dynamic IP

In the interests of saving a bit of money, I decided to switch my ADSL service from an expensive business connection to a cheap residential connection. In Australia this also means switching from a static IP address to a dynamic IP address. With most web-based services now able to be proxied via Microsoft’s Web Application Proxy (and other services using unique ports), it seemed like everything would be fine with a combination of a Dynamic DNS service and port forwarding. I only run a development environment at home, so if I could save some money without any real impact, all the better!

After I made the switch, I realised that I’d forgotten about my site-to-site VPN between my development environment and Azure Resource Manager (AzureRM). For those familiar with AzureRM and Site to Site VPN, you’ll know that your on premise IP address is configured in a “Local Network Gateway” object. I thought perhaps that you could enter a DNS entry in the IP address field – no such luck.

So I had a look around online to see if anyone else had some easy solution I could poach. While I could find a solution for Azure Classic, the objects are completely different in AzureRM (and the powershell commands are different) – so while it gave me a direction, I couldn’t use the solution as-is. So I had a look at the available AzureRM powershell cmdlets – primarily Get-AzureRmLocalNetworkGateway  and Set-AzureRmLocalNetworkGateway . The problem I came across was that ‘Set’ command really only accepts two parameters – a LocalNetworkGateway object, and AddressPrefix (for your local address spaces). No option to change the Gateway IP. The documentation didn’t give any additional information either.

Based on previous experience with powershell, I had assumed that the LocalNetworkGateway input object would need to refer to an existing object. As a last resort, I decided to try modify it before setting anyway – and it worked! So essentially we can do something like:

Obviously this is a fair way from an automated solution that can be run on a schedule! In order to put it into a workable solution, the following overall steps need to be taken:

  1. Configure a dynamic DNS service (such as www.noip.com) – this’ll need to be automatically updated via your router or client software
  2. On the server that will be running the scheduled task, install the Azure Powershell Cmdlets (as per https://azure.microsoft.com/en-us/documentation/articles/powershell-install-configure/)
  3. Create an administrative account in Azure AD that has administrative access on the subscription (they must be listed in the Azure Classic portal under Settings > Administrators). It’s important to note that when using the Login-AzureRM Credentials  command that the credentials used must be an ‘organisational account’ – you can’t use a Microsoft Live account (even if it’s a subscription administrator).
  4. Use some method of saving credentials for use in Powershell. I prefer to use a key-based encryption so it’s transportable between computers – a guide on doing this can be found here: http://www.adminarsenal.com/admin-arsenal-blog/secure-password-with-powershell-encrypting-credentials-part-2/
  5. Update the following values in the following script:
    1. DynDNS: the external DNS entry that resolves to your dynamic IP
    2. SubscriptionName: the name of your Azure subscription. This can be retrieved using Get-AzureRMSubscription
    3. User: the organisational administrative account
    4. PasswordFile: the file containing the encrypted password
    5. KeyFile: the file containing the encryption key (obviously you want to keep this safe – as it can be used to reverse engineer the password!)
    6. Address Prefixes on line 42.
  6. When running the script via Task Schedule, ensure you also specify the ‘Start In’ directory – otherwise you need to hard code paths in the script.