Skip Ribbon Commands
Skip to main content

Quick Launch

Todd Klindt's home page > Todd Klindt's SharePoint Admin Blog > Posts > Connecting to Office 365 with Multiple Accounts in PowerShell without Losing Your Damned Mind
November 06
Connecting to Office 365 with Multiple Accounts in PowerShell without Losing Your Damned Mind

The last (and first) installment in my ever popular “Without Losing Your Damned Mind” blog series, How to Connect to with Multiple Office 365 Accounts in your Browser without Losing Your Damned Mind, was a mild success, and the series was picked up. We decided it was time for a sequel, and here it is.

As an IT Pro/Administrator in the Microsoft space you have to love PowerShell. You don’t have to be an expert in it (though that really helps, I envy those guys) but you have to be confident enough with PowerShell that you can see some PowerShell on the web and be able to understand what it’s doing before you run it yourself. The way you do that is slowly, after months and years, forcing yourself to do tasks in PowerShell no matter how much it sucks. In the context of Office 365 that can get cumbersome because you have to authenticate against cloud services all the time, with many different accounts, and that requires that cursed act of typing your password. Over and over and over again. I hate typing passwords so very much. It gets worse when sometimes I’m connecting as me, sometimes as my own tenant global admin, sometimes as a customer’s tenant admin, sometimes as a different customer’s admin, it never ends.

A while back I started using Windows’ Credential Manager to manage my PowerShell logins, and that’s what this blog post is going to be about. I will assume you already know how to connect to Office 365 and Azure with PowerShell and that you have all of the necessary modules, executables, and the like installed.

The secret sauce that makes this all bearable is a PowerShell module called PowerShell Credential Manager. This little beauty uses native PowerShell to access the Credential Manager in Windows. There are other modules that do similar things, and you can actually do all of this yourself in PowerShell without a module. I’ve found this module to be the best that works for me, but this process is the same regardless of what you use.

You can install it with this line:

Install-Module -Name CredentialManager

It installs the following cmdlets:

Get-StoredCredential
Get-StrongPassword
New-StoredCredential
Remove-StoredCredential

You can use New-StoredCredential to put a new entry in the Windows Credential Manager. You can also use the Credential Manager UI to do it. It’s all the same. To create a credential with New-StoredCredential use something like this:

New-StoredCredential –Target O365Admin –username admin@tenant1.onmicrosoft.com -password pass@word1 –Persist LocalMachine

New-StoredCredential –Target Jimmy –username Jimmy@tenant1.onmicrosoft.com -password pass@word1 –Persist LocalMachine

New-StoredCredential –Target OtherAdmin –username admin@tenant2.onmicrosoft.com -password pass@word1 –Persist LocalMachine

And so on. A couple of things of note. First, all of the passwords are in plain text. If you’re running a transcript make sure you clear those out. Also, the –Persist switch is important. If you don’t add that, the Stored Credential will vanish into the ether when you close this PowerShell window. You won’t know why it doesn’t work the next and you’ll be very confused. Maybe that’s just me. You can also add a comment for the credential with the –Comment parameter.

Running the command looks like this:

image

The entries look like this in Windows:

SNAGHTML67af9a89

You can get to this screen in Control Panel, or by typing “cred” in the Start Menu. The credentials you create in PowerShell will show up under “Generic Credentials” and you can use anything that’s already there. You can also create credentials with the cleverly named, “Add a generic credential” link at the top. It doesn’t matter how they get there, it just matters that they’re there. You can create as many credentials as you want. There’s no charge. Smile

Now that we’ve loaded the Credential Store up with some yummy Office 365 Credentials, how do we use? The magic word is Get-StoredCredential.

We can use Get-StoredCredential to securely pull credentials from the Credential Manager and pass them to a PowerShell cmdlet. You can save them in a variable, or just call it directly when you connect. Here is how you connect to Azure AD:

Connect-MsolService -Credential (Get-StoredCredential -Target O365Admin)

It looks like this:

image

No passwords were typed (Hooray!) and that means you can securely automate it. The process is the same for other Connect style cmdlets. Here are a couple of examples:

Connect-AzureAD -Credential (Get-StoredCredential -Target O365Admin)

Connect-SPOService -Url https://blogpost-admin.sharepoint.com -Credential (Get-StoredCredential -Target O365Admin)

If I wanted to sign in as the Jimmy account, I would pass that to the –Target parameter:

Connect-SPOService -Url https://blogpost-admin.sharepoint.com -Credential (Get-StoredCredential -Target Jimmy )

I’m a frequent user of the PnP PowerShell. I’d give up sliced bread before I gave them up. While you can use this same approach with them, you have another option that’s even less typing:

Connect-PnPOnline -Url https://blogpost-admin.sharepoint.com -Credential O365Admin

The Connect-PnPOnline cmdlet (and maybe others) natively know to check the Credential Manager if it’s passed a string.

That’s all there is to it. Once you create a credential it’s yours to use however you’d like, as often as you’d like. This isn’t restricted to Office 365, either. Any PowerShell cmdlets that take credentials can take advantage of this.

Enjoy.

tk

ShortURL: https://www.toddklindt.com/PoshMultipleAccounts

Comments

Only one problem with this one

I like the solution but we require our passwords to be changed ever xx days. If you do that the credential store does not get updated from our experience, so you would have to make sure to update that ever xx days.
 on 11/7/2018 11:13 AM

This is great, but what about MFA

Best practise is to use MFA for all global admin(at least). Do you know if ther is a solution to that ”problem”?

Regards
Anders
 on 11/9/2018 2:02 AM

Re: This is great, but what about MFA

I'm planning a blog post on that as well. :)

tk
Todd O. KlindtNo presence information on 11/13/2018 3:24 PM

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title


Body *


Today's date *

Select a date from the calendar.
Please enter today's date so I know you are a real person

Twitter


Want a message when I reply to your comment? Put your Twitter handle here.

Attachments

 

 Please Support my Sponsors