Embedding o365 credentials into PowerShell

Sometimes it is necessary to schedule scripts with credentials for services such as Office 365 that require authentication.  These passwords can be stored securely rather than in plain text

read-host -assecurestring | convertfrom-securestring | out-file C:\temp\creds.txt

As an example for usage

$pass = get-content C:\temp\creds.txt | convertto-securestring
$creds = new-object -typename System.Management.Automation.PSCredential -argumentlist “admin@stevenwatsonuk.onmicrosoft.com”,$pass
Connect-MsolService -credential $creds

however this is not using strong encryption and there are readily available ways of reversing the stored password just stops the plain text access http://stackoverflow.com/questions/7468389/powershell-decode-system-security-securestring-to-readable-password 

Script to find out onmicrosoft.com availability

Useful PowerShell script found here https://www.linkedin.com/pulse/how-check-office-365-tenant-name-availability-aaron-dinnage

# Syntax:	Get-TenantStatus.ps1 -name "microsoft"
# Determines if the tenant name requested is available or already taken within Office 365.
# Provide a desired tenant name without the .onmicrosoft.com suffix to check if that tenant name is available.

param( $name )

Function Usage
$strScriptFileName = ($MyInvocation.ScriptName).substring(($MyInvocation.ScriptName).lastindexofany("\") + 1).ToString()



C:\PS> .\$strScriptFileName -name `"microsoft`"


If (-not $name) {Usage;Exit}

$uri = "https://portal.office.com/Signup/CheckDomainAvailability.ajax"
$body = "p0=" + $name + "&assembly=BOX.Admin.UI%2C+Version%3D16.0.0.0%2C+Culture%3Dneutral%2C+PublicKeyToken%3Dnull&class=Microsoft.Online.BOX.Signup.UI.SignupServerCalls"

$response = Invoke-RestMethod -Method Post -Uri $uri -Body $body

$valid = $response.Contains("SessionValid")
if ($valid -eq $false)
	Write-Host -ForegroundColor Red $response

$available = $response.Contains("<![CDATA[1]]>")
if ($available) {
	Write-Host -ForegroundColor Green "Available"
} else {
	Write-Host -ForegroundColor Yellow "Taken"


Connecting to Office 365 using PowerShell

Exchange Online

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

Skype for Business
May also need http://go.microsoft.com/fwlink/?LinkId=294688 beforehand

$UserCredential = Get-Credential
$session = New-CsOnlineSession -Credential $credential -Verbose
Import-PSSession $session


Modern Authentication

Even though SSO or ADFS is used within Office 365 initially both Outlook and Skype clients will prompt for credentials providing a not-so seamless environment.

If enabled, Modern Authentication will make this seamless for Office 2013 and Office 2016. Office 2013 will require a registry which can be deployed via GPO.

HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL REG_DWORD 1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version REG_DWORD 1

Using PowerShell to check

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session
Get-OrganizationConfig | select *OAuth*

To change

Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true

Similarly for Skype for Business

$UserCredential = Get-Credential
$session = New-CsOnlineSession -Credential $credential -Verbose
Import-PSSession $session
Get-CsOAuthConfiguration | select *Adal*

To change

Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed




SSL wildcard certificate missing private key after vendor auto renewal

A vendor (in this case godaddy) auto renewed an existing wildcard SSL cert.  This was renewed against the original CSR of which the server no longer existed.

Upon import to a server (that already had the private key for the expiring certificate) it did not associate a private key and could not be used.  The vendor told us to “re-key” the certificate however this would invalidate the current, live certificate within 3 days.  We could not carefully plan and reconfigure all dependencies within 3 days.

Fortunately the simple was simple.  From a server that already has the private key from the previous certificate extract the thumbprint of the new certificate and run the following,

certutil -repairstore my {thumbprint}

This should locate the primary key and associate with the new cert.