To connect SharePoint Online, SharePoint Online Management PowerShell to be installed on the client machine and it can be downloaded from the below location.

https://www.microsoft.com/en-in/download/details.aspx?id=35588

Once the SharePoint Online Management Shell installed, you can launch the SharePoint Online Management Shell and connect the SPO service using below options

Option 1: Using User Name and Password

  1. Store the credential to a variable

$Cred = Get-Credential –UserName admin@superhybridcloud.onmicrosoft.com –Message “Type your Password”

  1. Connect SPO Service

Connect-SPOService –Url https://superhybridcloud-admin.sharepoint.com –Credential $Cred

Option 2: Using MFA

Note: Passing user name and password as mentioned on Option1 won’t show an option to pass the MFA challenge. So if MFA enabled, use this Option.

  1. Connect SPO Service

Connect-SPOService -Url https://superhybridcloud-admin.sharepoint.com

Browser will be launched and it will ask for credential. Once the authentication successful it will trigger MFA prompt, once the MFA challenge successful, you will be connected to SPO service.

Connecting SharePoint Online PowerShell is easy Right. J

Configuring OWA session timeout is an important security measure that every organization should follow to keep Organizations data safe. Below the default session time out settings for Outlook Web Access (OWA) or Outlook on the Web (OotW).


OWA forms based authentication provides 2 option to choose whether you logged in from a Private or Public computer. OWA session time out depends on user’s selection.

  • If it is a Private computer – OWA session time out at 15 minutes of inactivity
  • If it is a Private computer – OWA session time out at 8 to 12 hours of inactivity

Make a note of the word 15 minutes of inactivity. Session will time out only when there is no activity at outlook web access.

Note: Typing something in meeting requests, appointments contacts, or tasks is not considered as an activity.

Your Corporate Security may advice you to configure a session time out based on the security concerns like every 15 minutes or two hours once etc. and to change the settings, you should have Organization Administrator rights in Exchange Online and you need to run the below command.

Set-OrganizationConfig -ActivityBasedAuthenticationTimeoutEnabled:$True -ActivityBasedAuthenticationTimeoutWit hSingleSignOnEnabled: $True -ActivityBasedAuthenticationTimeoutInterval 00:15:00

You have to wait for quite some time for the settings to replicate and You can run the below command to check the settings are properly configured.

Get-OrganizationConfig | fl Activity*

Ultimate aim of this post is that, when you are setting OWA session timeout for lesser interval and configured Azure Conditional Access Policy to trigger MFA when accessing Exchange Online Mailbox in OWA, users experience will be affected as every time they have to Key in MFA challenge when logging in OWA.

Educate your users about the 15 minutes OWA session time out settings and your MFA challenge settings and if they are the user where they will access only OWA to see their emails, then ask them to check the option not to prompt for MFA challenge for next 24 hours.

Again, if you think it is a security concern, discuss with your corporate security about the challenge and decide a solution considering user experience and security measures.

Hope this is informative and you like it.

Device Management in Azure AD is required to ensure the devices connecting to the cloud services are meeting the Company Security and Compliance Standards. If you have On-Premise Active Directory, computers related to that company are joined to that AD and administrators will have control to those AD joined devices like pushing group policies etc.

Joining a Computer to Azure Active Directory is similar to joining a computer to local active directory. Difference is Azure AD is in Cloud and when joining a machine to Azure AD, it provides additional capabilities like Single Sign On experience when accessing the applications and we can restrict access to those devices based on the Azure AD Join status using Azure Conditional Access.


Device Join to Azure Active Directory are three types:

  • Hybrid Azure AD Join: Device joined to On-Premise Active Directory and Azure Active Directory.
  • Azure AD Join: Device joined directly with Azure AD (not On-Premise AD Domain joined)
  • Azure AD Registered (Workplace Join): Device registered with Azure Active Directly like Windows 10 Personal and Mobile Devices.

During the Azure conditional access validation, all the above devices joined to azure are considered as domain joined devices and the respective settings will be applied.

Hybrid Azure AD Join in Windows 10

Windows 10 Device Registration process explained as

  1. Group Policy pushed to the machine starts the device registration with Azure AD
  2. Windows Device will query AD to get the information about the Azure AD Tenant
  3. Windows Device authenticates itself to Azure AD via ADFS to get a token for device registration
  4. Windows Device generates key pairs used for device registration
  5. Windows Device registers with Azure AD via Azure Device Registration Service.

Below the detailed explanation on how the Hybrid Azure AD Join works

We need to configure few things for Hybrid Azure AD Join to work properly like AD Connect deployment, Group Policy pushing and ADFS Issuance Transformation Rule etc… those prerequisites configuration steps not explained here. We will assume those are already set and will see the flow on how the Azure AD Join working in Windows 10 Machine.

  1. Group policy pushed to Windows 10 clients, which creates a task for the device registration to work and the task will be triggered.
  2. Windows 10 client queries AD (Service Connection Point object) which has the details about the Azure AD tenant to which the client has to connect. Azure AD Connect deployment will create those objects. I have highlighted the path for reference on the diagram.
  3. Azure AD Tenant information like the Azure AD name and the ID will be sent to Windows 10 Client.
  4. A hidden Internet browser is launched and the OAuth code authentication request is sent to Azure AD
  5. Azure AD redirects the client to authenticate with ADFS
  6. Client will reach ADFS by sending the computer account as identity, using Windows Integrated Authentication. Note: If the device is in Internet, then the authentication will fail because the WAP server will have form based authentication and you won’t know the prompt in hidden browser to authenticate.
  7. ADFS validates the computer identity with AD
  8. After the successful authentication, AD send the claim details to ADFS
  9. ADFS send a token along with 3 claims to Windows client, which the device will sent it to Azure AD for successful authentication
  10. Client sends the token along with 3 claims about the device received from ADFS to Azure AD
  11. Azure AD trust the token from ADFS server as it is already integrated and send a final token to Client for Azure Device Registration
  12. Device creates a Private/Public key pair to be used in a certificate-signing request from Azure DRS, to obtain the certificate that the device will use to authenticate to Azure AD later on. In addition, the task generates a second private/public key pair that is later used to bind the Primary Refresh Token (PRT) to the physical device upon authentication.
  13. Task send the Certification Signing Request along with final token received from Azure AD to Azure Device Registration Service.
  14. Azure DRS authorize the token, create a certificate, creates a Device object with its certificate thumbprint and return the certificate to the client.
  15. Client stores the certificate in the User My Store.

If you see above, the device registration is successful. For the Single Sign-On experience in Windows 10, the Primary Refresh Token will be received from Azure AD.

User sign-in to client using his credential, the Cloud Authentication Provider plug-in in windows client authenticates with Azure AD and ADFS, to obtain the Primary Refresh Token. Cloud Authentication Provider knows the Azure AD and ADFS details from the cache available during the Device Registration. Cloud AP plugin will directly send the credential to ADFS and get the SAML token and present it to Azure AD for authentication, Azure AD authenticates it and build a PRT with both User and Device claims and it will return to Window device.

I hope this is informative and you like it. Please comment for any clarification.