Connecting Exchange online PowerShell with MFA enabled Admin Account

Introduction

Multi Factor Authentication (MFA) help safeguard application and data access via a range verification methods that includes phone call, text, app verification etc. Microsoft introduced MFA for Office 365 in 2014 that help administrators to secure corporate information in Office 365 by enforcing a second factor authentication. Connecting with Exchange online PowerShell with MFA enabled admin account is not supported with standard PowerShell module.

It’s highly recommended to configure Multi Factor Authentication (MFA) for all users and admin accounts in Office 365.

Connecting Exchange online PowerShell with MFA enabled admin account requires you to download and install Exchange Online Remote PowerShell module that support MFA.

Install MFA Enabled Exchange Online Remote PowerShell Module steps should be performed in Internet Explorer otherwise you will receive an error message that says “Application can’t be started“.

Install MFA Enabled Exchange Online Remote PowerShell Module

To connect exchange online using MFA enabled admin account, you need to install MFA enabled exchange online remote powershell module that can be downloaded from Exchange online admin center in Office 365.

  • Login to Office 365 using global admin credentials.
  • Navigate to Admin > Admin Centers > Exchange.

Connecting Exchange online PowerShell with MFA enabled Admin Account

  • In Exchange Admin Center, Navigate to Hybrid and Click Configure under “The Exchange online PowerShell Module supports multi-factor authentication. “

Connecting Exchange online PowerShell with MFA enabled Admin Account

  • The Wizard will launch application install process, Click on Install.

Connecting Exchange online PowerShell with MFA enabled Admin Account

  • Wait for the application installation process to complete.

Connecting Exchange online PowerShell with MFA enabled Admin Account

  • Once the Installation process is completed, it will launch Exchange Online PowerShell Module that supports MFA.

Connecting Exchange online PowerShell with MFA enabled Admin AccountOnce the process of installing MFA Enabled Exchange online remote PowerShell module, the next step is to connect with Exchange online PowerShell using MFA enabled admin account.

Connecting Exchange online PowerShell with MFA enabled Admin Account

Connecting Exchange online powershell with MFA enabled admin account requires you to perform the following steps.

  • Run the following cmdlets to connect with Exchange Online PowerShell.

C:\> Connect-EXOPSSession -Username <user@domain.onmicrosoft.com>

Connecting Exchange online PowerShell with MFA enabled Admin Account

  • When prompted, Enter your global admin credentials.

Connecting Exchange online PowerShell with MFA enabled Admin Account

  • Once user credentials are verified, you will be redirected towards MFA verification.

I have setup MFA to use verification code from mobile app.

Connecting Exchange online PowerShell with MFA enabled Admin Account

  • Once you verify the multi-factor authentication, Exchange online remote powershell module will start loading the remote session.Connecting Exchange online PowerShell with MFA enabled Admin Account
  • Once the Remote Session is loaded, you can perform tasks related to Exchange online.

Connecting Exchange online PowerShell with MFA enabled Admin AccountConclusion

Multi-Factor Authentication help secure access to corporate environment and it’s highly recommended to set up MFA for all users and admin accounts. In this blog post, we review the process to access Exchange Online PowerShell after the admin account is setup for MFA. Connecting Exchange online PowerShell with MFA enabled admin account will ensure the security of your environment and help administrators perform their day to day tasks using PowerShell.

Office 365 share free busy between tenants

Introduction

Recently I have seen scenario’s where customer was looking for a way in Office 365 to share free busy between tenants. Nowadays, it seems to be a common ask by customers if its possible for two different organizations hosted on two different Office 365 tenants owned by two different companies to share free busy information with each other like they are used to doing with on premises Exchange.

By default, all office 365 tenants have a federation trust setup with Microsoft federation gateway.

Office 365 has a federation gateway configured with Microsoft Federation Gateway. This allows organizations to setup free busy between tenants by setting up “Organizational Relationship” to allow access and sharing permissions.

Configuring Office 365 share free busy between tenant

Let’s start out with the two domains of msexperttalk.com and msmvpservices.com, and then we will assume they have both been updated to Office 365 tenants. Now, we want to share free busy information between them. Configuring Office 365 share free busy between tenant’s is a two step approach. Each step will set up the relationship from its side.

Part 1 – MSExpertTalk to MSMVPServices

We need to pull the federation information from the Microsoft federation gateway and use that to establish an organizational trust from MSExpertTalk.com to msmvpservices.com. User the following PowerShell cmdlets to connect with Exchange online using Global Admin credentials.

C:\> $Cred = Get-Credential

C:\>$session=new-pssession -ConnectionUri https://ps.outlook.com/powershell -ConfigurationName microsoft.exchange -Credential $Cred -Authentication basic -AllowRedirection

C:\>Import-PSSession  $session -AllowClobber | Out-Null

Office 365 share free busy between tenantsYou can connect with Office 365 PowerShell by using a PowerShell script available at TechNet Gallery. Once you are connected with the MSExpertTalk Office 365 tenant, run the following cmdlet to retrieve the federation information of contoso.com

C:\> Get-FederationInformation -DomainName msmvpservices.com

This step verifies everything is good with MSExpertTalk and the Microsoft federation gateway.

Now we need to establish the organizational relationship.

C:\> Get-FederationInformation-DomainName Msmvpservices.com | New-OrganizationRelationship -Name FreeBusyMSMVP -Enabled $true -FreeBusyAccessEnabled $true -FreeBusyAccessLevel ‘AvailabilityOnly’ -FreeBusyAccessScope $null

After this completes, run Get-OrganizationRelationship to verify.

This will complete your step 1 to configure the free busy sharing from your tenant with msmvpservices.com. Next step is to configure msmvpservices.com to share free busy information with your office 365 tenant.

Part 2 – MSMVPServices to MSExpertTalk

Now we need to pull the federation information from the Microsoft federation gateway and use that to establish an organizational trust from MSMVPServices to MSExpertTalk.

From MSMVPServices.com, we open Powershell and connect to Office 365.

C:\> $userCredential = Get-Credential

C:\> $session=new-pssession -ConnectionUri https://ps.outlook.com/powershell -ConfigurationName microsoft.exchange -Credential $usercredential -Authentication basic -AllowRedirection

C:\> Import-PSSession $session -AllowClobber | Out-Null

C:\> Connect-MsolService -Credential $userCredential

Now that we are connected to the MSMVPSerivces Office 365 tenant, we need to collect the federation information for MSExpertTalk.com

Now, we establish the organizational relationship.

C:\> Get-FederationInformation -DomainName msexperttalk.com | New-OrganizationRelationship -Name MSExpertFreeBusy -Enabled $true -FreeBusyAccessEnabled $true -FreeBusyAccessLevel ‘AvailabilityOnly’ -FreeBusyAccessScope $null

After this completes, run Get-OrganizationRelationship to verify.

Conclusion

With both sides set up, we can log into OWA from either side and set up a meeting with a user in the other domain to check for availability. Since you followed this handy guide, you should see the availability and life is good. Please note that this configuration only enables you to setup free busy sharing between two tenants. It will not allow users to view users in address book from other organization. For users to show up in address book, you need to configure GAL Sync between tenants.

I hope you found this helpful in getting your tenants connected, availability working, and keeping it working as you grow with Office 365.

Microsoft Teams Global Availability

Today on March 7th, 2017, Microsoft has announced the Microsoft Teams Global Availability. Per Microsoft announced, Microsoft Teams global availability celebration will start on Tuesday, March 14th at 8:30am PDT. The celebration agenda is going to be the Microsoft Teams Global Availability.

Microsoft will host an online event to celebrate Microsoft teams global availability and Microsoft Corporate Vice President Kirk Koenigsbauer and a special guest will share perspectives around new stuff in Microsoft Teams and how customers are leveraging Microsoft Teams in Office 365 to collaborate and be more productive.

You can register for online event by from here 

Microsoft Teams Global Availability

 

 

Office 365 Email Protection with DKIM and DMARC

Introduction

Email spoofing is the most common challenge that every organization is facing in current digital world regardless of the size of the organization. Office 365 email protection with DKIM and DMARC helps organization to protect against spoofing that tend to have increased number of spam emails. DomainKeys Identified Mail (DKIM) and Domain-based Messaging and Reporting Compliance (DMARC) checks trusted authenticated sender to prevent untrusted senders from sending spoofed emails.

Inbound validation of DKIM and DMARC is supported in Office 365

What is DKIM?

Domainkeys Identified Mail (DKIM) is a method to validate a digitally signed messaged that appears in the DKIM Signature header in the message headers. It ties an email message to the organization responsible for the message.

Office 365 Email Protection with DKIM and DMARC

More details on DKIM can be found on TechNet.

What is DMARC?

Domain-based Messaging and Reporting Compliance (DMARC) is designed to protect email spoofing when the phisher has spoofed the 5322.From email address that is the email address displayed in email clients like outlook. Sender Policy Framework (SPF) protect the phisher to spoof the emails from 5321.MailFrom. DMARC catches the case that is more deceptive. DMARC results are stamped in authentication header of email.

DMARC evaluate both DKIM and SPF and ensure that the domain matches the domain in 5322.From address. SPF does not protect against 5322.From spoofed emails.

Q: Helo woodgrovebank.com
Q: Mail from: phish@phishing.contoso.com  <– 5321.MailFrom
Q: Rcpt to: astobes@tailspintoys.com
Q: data
Q: To: “Andrew Stobes” <astobes@tailspintoys.com>
Q: From: “Woodgrove Bank Security” security@woodgrovebank.com  <– 5322.From
Q: Reply-To: “Woodgrove Bank Security” <phish@phishing.contoso.com>
Q: Subject: Woodgrove Bank – Action required
Q: Greetings User,
Q: We need to verify your banking details. Please click the following link to accomplish this.
Q: http://short.url/woodgrovebank/updateaccount/12-121.aspx
Q: Thank you,
Q: Woodgrove Bank

The end user will see this information as below.

This email can pass SPF check if the phisher has published the SPF check for woodgrovebank.com but as we know the phisher has spoofed the email using 5321.MailFrom and DMARC will fail on this email. DMARC configurations are already in place in Office 365 for inbound emails and you don’t have to configure anything. In next blog article, we will look into how we can configure DMARC for outbound emails in Office 365.

For more information on office 365 email protection with DKIM and DMARC, please go through the following posts.

Customized Office 365 OWA URL

When you are working with your customers to transition them to Office 365One of the most important ask is to have customized Office 365 OWA URL to ease end users and have them not to remember something that is not related or company branded like outlook.office.com. I received these type of requests almost on all of my engagements when customers are moving to Office 365 from on-premises messaging environment to Office 365 or a 3rd party messaging system.

This blog post is not applicable when you have Exchange hybrid deployment. Exchange hybrid deployment has a lot of different things and scenario’s.

Office 365 OWA can be accessed by users by visiting the known URL of Office 365 i.e. http://portal.office.com and click on the Outlook icon to access the mails in Office 365. Users can also access their emails on OWA by visiting http://outlook.office.com URL but for users to have it customized Office 365 OWA URL to visit for accessing the emails is something that can be company branded like mail.msexperttalk.com?

In order to setup the OWA URL redirection for your organization’s customized Office 365 OWA URL, you need to create a CNAME entry in your public DNS to point to outlook.office.com. 

Create CNAME record with the name of Mail and point it to outlook.office.com 

Once the CNAME records are in place for both public and private DNS of the company, your users now can access OWA by using customized Office 365 OWA URL by visiting http://mail.domain.com and in my case it’s http://mail.msexperttalk.com. You can visit the Office blog site to see the details of other DNS records requirements for Office 365.

 

1 2 3 10