Wednesday, July 26, 2017

Skype For Business Cloud Connector Edition version 2.0

Microsoft released Skype for business Cloud Connector Edition in April, 2016 for GA. As we know Cloud Connector Edition makes it possible to connect any existing telephone circuit to Cloud PBX in Office 365 using the simple server and minimal configuration. The availability of Skype for Business Cloud Connector Edition comes with additional capability of on-premises PSTN connectivity for existing Lync Server/Skype for Business server deployment. That allows the user’s phone capability to be managed out of Office 365 while their phone call continue to use their existing phone number, circuits and PSTN provider contract.

Click here for releases and features of Skype for Business Cloud Connector Edition

Skype for Business Cloud Connector Edition Version 2.0

Now Microsoft released Skype for Business Cloud Connector Edition version 2.0, there are multiple improvement are:

Media Bypass
Media bypass allows a client to send media directly to the PSTN next hop a gateway /SBC and removed the CCE from the media path, which will improve the voice quality, minimum latency, possibility of packet loss and other failure. It will improve the scalability and enables a higher number of concurrent calls. Also it will reduce the load on Cloud Connector.

Support of 16 Cloud Connector Edition per one PSTN Site:

Initial released of Cloud Connector Edition support only 4 instances of CCE are supported per PSTN site, means each Cloud Connector can support up to 500 simultaneous calls, it means one site can support 1500 simultaneous call/lines (1 instance reserved for HA). The ratio of 1:10 means we had support for 9000 to 15000 of available line to users.
Now many organization want to centralize Cloud Connectors in one location for cost save and the number of the users can exceed 15000 and need more Cloud Connector instances per site. In new released Cloud Connector Edition version 2.0 can support 45,000 to 75,000 simultaneous call/lines.

Ability to manipulate SIP headers for billing or interoperability purposes:
Cloud Connector Edition version 2.0 enable manipulate of SIP header via the INI file. We can manipulate following headers from INI file:
Enable Fast Fail-over Timer- Default value is “TRUE” if outbound calls, if you not answered by the gateway within 10 seconds, call will routed to the next available gateway, if the no addition trunks than call will dropped, in this case slow networks and gateway response when the call take more than 10 seconds. Now we need to change the value to “FALSE” same time we have to change the value from connected SBC or Gateway also.
Forward Call History: These parameter turn on SIP headers that are used to report the initial caller in simultaneous ringing, Call forwarding and Call Transfer scenario, setting the parameters to true will turn on two SIP headers History-Info & Referred-By.

Forward PAI: PAI is a private extension to SIP which enables SIP servers to assert the identity of authenticated users.

Use of Office 365 Skype for Business account instead of a Global Administrator account
Now any account of with Skype for Business administrator role to perform management task, this will help larger organization with many administrator to easily management to keep secure access rights.

Auto-generated passwords for local administrator of Cloud Connector instances:
No longer required the manually create a password for the forest administrators. Password for those accounts are generated during the installation. In initial released of CCE during the deployment, there were two account created at the forest level and one account for each Domain Account (VM).

Hybrid Voice flag in Mediation Service User Agent to better distinguish Cloud Connector calls in the Call Quality Dashboard means when a call is placed every server or client reports its name in SIP user-Agent header for diagnostics purposes.

Improvements to self-monitoring and self-troubleshooting process:
One of the critical improvement is self-monitoring and troubleshooting mechanism. New release added following events, if one of the events outlined above is detected, the entire instance of the Cloud Connector is drained and marked as offline:
·       One or more Virtual Machines of a Cloud Connector instance are not connected to internal or internet virtual switch.
·       One or more Virtual Machines of a Cloud Connector instance are in saved or stopped status.
·       The following services are not running:

On Central Management Store Virtual Machine:
  • Skype for Business Master Replicator Agent
  • Skype for Business Replica Replicator Agent

On Mediation Server Virtual Machine:
  • Skype for Business Replica Replicator Agent
  • Skype for Business Server Mediation

On Edge Server Virtual Machine:
  • Skype for Business Replica Replicator Agent
  • Skype for Business Server Access Edge
  • Skype for Business Server Audio/Video Edge
  • Skype for Business Server Audio/Video Authentication
  • Skype for Business Server Web Conferencing Edge 


Monday, June 26, 2017

Password Synchronization- Password Hash Sync -Office365

SaaS applications are different, they are not installed on a local machine and don’t have the access to local Active Directory domain controller that’s why SaaS application often use disjoint identity providers and user have to maintain separate username and passwords multiple cloud-based applications. Single Sign-On (SSO) is the common answer to resolving this. SSO is defined as the ability for two disjoint identity provider to trust one another so that as a user can log in IDP and then when trying to access resources secured by the second IDP and not need to log in again. That trust called federation trust.

Office 365 is the one of the popular SaaS application, which has the three identity models for Office 365, and we have to determine the successful Office 365 onboarding is start with the simple identity model that meet organizational needs. Once you finalize the identity model then you have to think another part of the Office 365. Let’s take a look at each one in a brief detail:

Cloud identity: In this model user is created and managed in Office 365 and store in Azure Active Directory and the password is verified by Azure Active Directory. There are no equivalent user account on-premises.
Synchronized Identity: In this model, the user identity is managed in On-Premises server and the accounts and password hashes are synchronized to the cloud. The user can enter the same password on-premises and in the cloud also, the password is verified by Azure Active Directory. In this model, we need to use sync tool such as AAD, DirSync.
Federated identity: This model requires a synchronized identity but one changes, the user password is verified by the on-premises identity provider. No need to password hash synchronized to Azure Active Directory. We can use Active Directory Federation Services or any third party federation provider.

In this article I will try to explain the Synchronized Identity (Password Hash Sync), let’s start:

What is Password Hash Sync
We have involved from plain text password storage to hashing a password, to appending salts etc. When a password has been hashed it means it has been turned into a scrambled representation of itself. Password hashing is one of the most basic security considerations that must be made when designing any application that accepts passwords from users, without hashing any password that is stored in your application's database can be stolen if the database is compromised.

Hashing is a type of algorithm which takes size of data and turns it into a fixed-length of data. This is often used to ease the retrieval of data as you can shorten large amounts of the data to a shorter string.
Now a question is what is the difference between hashing and encryption, simple is hash is not reversible.

You cannot directly turn a hashed value into the password, but you can work out what the password is if you continually generate hashes from passwords until you find one that matches a so-called brute-force attack or similar methods.

Following if the workflow for account registration and authentication in a hash-based account system:
  •        The user creates an account.
  •        Users password is hashed and stored in the database.
  •        When a user tries to log in, the hash of the password they entered is checked against the hash of their real password (retrieve from the Database).
  •        If the hashes match, the user is granted access, if the not user will get the message “Invalid login credentials”.

When the username or password they got wrong, always give a generic message “Invalid username or password” this will prevent attackers from enumerating valid username without knowing their passwords.

Modern Hashing Algorithms
MD-5, SHA-1, SHA-2, SHA-3

When & Why use the Password Hash Sync
We are using password hash sync because to implement simple then federation service, Microsoft always want to integrate on-premises AD to Azure AD and password hash sync does this without the need for some multiple servers. Password hash sync provides a smooth path for these organizations to move to the cloud. Also, the advantage of password sync is that, unlike a federation, it does not depend upon an external federation service to process authentications. There is only one configuration option to add password hash sync to Directory Sync tool this is done during the configuration wizard and is a small checkbox where we can choose password hashes in addition to the users’ profile attributes. If enabled password hash sync applies to all synchronized users. While a Federation deployments take some efforts due to additional servers and network implementation, on-premises servers also required internet access through any corporate firewalls in a secure way, and they also have to be highly available since logins are not possible if internet connectivity is offline. Password Hash Sync is the feature of directory synchronization it only required a single server with outgoing access to the Internet in order to connect to Azure AD there is no requirement for inbound connections, custom firewall openings or highly available configurations.

                                                           Photo courtesy of Microsoft

How Password Synchronization works

  •        Every two minute the password sync agent on the DC connect server request stored password hashes from DC with help of the replication protocol (MS-DRSR) to sync the data between the DCs.
  •         DC encrypts the MD5 hash from DC4 password hash before sending of the RPC session key and a salt. The DC also passes the salt to the synchronization agent by using the DC replication protocol so that agent will decrypt the envelope.
  •        MD5crryptoServiceProvider and salt to generate a key to decrypt the received data back to its original MD4 format, password synchronization agent does not have the access to the clear text password.
  •        The Password synchronization agent’s use the MD5 for replication protocol compatibility with the DC and only use on-premises between the DC and the password synchronization agent.
  •        Password sync agent expands the 16-byte binary password hash to 64 bytes by first converting the hash to a 32-byte hexadecimal string, then converting this string back into binary with UTF-16 encoding.
  •        Password sync agent adds a salt, consisting of a 10-byte length salt, to the 64-byte binary to further protect the original hash. Then combines the MD4 hash plus salt and input into the PBKDF2 function.
  •        Password sync agent takes the resulting 32-byte hash, concatenates both the salt and the number of SHA256 iterations to transmits the string from Azure AD Connect to Azure AD over SSL.
  •        Now when the user tries to sign in to Azure AD and give the password, the password is run through the same MD4+Salt+PBKDF2+HMAC-SHA256 process, if the hash matches the hash stored in Azure AD, the user has entered the connect password and is authenticated.

                                                               Photo courtesy of Microsoft 


Thursday, May 25, 2017

Multi-Factor Authentication Setup-Office 365

What is Multi-Factor Authentication

Two –step verification is a method of authentication that requires more than one verification method and adds a critical second layer of security to user sign-in and transaction. Azure multi-factor authentication is the method of verifying who you are that requires the use of more than just a username and password. Users are required to acknowledge a phone call, text message, or app notification from their smartphone after entering their passwords and they can only login after second authentication factor has been satisfied.
There are multiple options for verification methods:
  •          Typical Password
  •          Trusted device that is not easily duplicate such as a Phone
  •          Biometrics

Why use Azure Multi-Factor Authentication

Today, every organization having the facilities to work from anywhere, connected from anywhere and people are increasingly connected with their smartphones, tablets, laptops and PCs, which means they need more security to access the company’s application, email etc. Azure multi-factor authentication is an easy to use and reliable solution for accessing your emails & applications. Azure multi-factor authentication is very simple to set up and use, it can set up with just a few simple clicks with extra protection to allows users to manage their devices. Azure MFA integrated cloud and on-premises Active Directory and Apps it also good for mission critical scenario. Azure MFA provide strong authentication using highest industry standards.

How Azure Multi-Factor Authentication Works

Azure Active Directory is the authentication authority for Office365, this application developed to support MFA use the Active Directory Authentication Library (ADAL) to authenticate to services using OAuth 2.0. OAuth is an open standard for authentication that is supported by many other third party vendors. The client application such as Outlook, OWA use Active Directory Authentication Library(ADAL) to get access to users’ data using the access tokens acquired through the authentication process. Using access tokens means that the applications can continue to access data without having to store or provide user credentials. There is two type of the tokens are used, a refresh token is issued following a successful user authentication. This is the master token that is used to acquire the access tokens necessary to access user data. For example, when the Outlook first connects and authenticates with Office365 a refresh token to get an access token that’s valid for Exchange, the same token is valid across the Office 365. A refresh token lasts two weeks; refresh tokens generate by Azure Active Directory. If you are not using /office 365 the more than two weeks, the refresh tokens with expiring and will need to be reestablished through authentication.

                          Photo courtesy of Microsoft

Methods available for two-step verification

When a user signs in, an additional verification is sent to the user. The following are a list of methods that can be used for this second verification.

Phone Call  
A call is placed to a user’s registered phone asking them to verify that they are signing in by pressing the # sign or entering a PIN. 
Text Message
A text message will be sent to a user’s mobile phone with a six-digit code.Enter this code in to complete the verification process.
Mobile App Notification 
A verification request is sent to a user’s smartphone asking them to complete the verification by selecting Verify from the mobile app. This will occur if you selected app notification as your primary verification method. Example -Phone Sign In -Microsoft Authenticator
Mobile app verification code
The mobile app, which is running on a user’s smartphone, displays a 6-digit verification code that changes every 30 seconds. The user finds the most recent code and enters it on the sign-in page to complete the verification process. This will occur if you selected a verification code as your primary verification method.
3rd party OATH tokens
Azure Multi-Factor Authentication can be configured to accept 3rd party verification methods.

Set up Multi-Factor Authentication in the Office 365

Go to the Office 365 admin center.
Navigate to Users and select Active Users then click on more option and select Setup Azure multi-factor auth, Your screen should look like one of the following:

Once clicked on Azure multi-factor auth, you will see the all users list

Now we need to enable MFA for one particular user, we can search and select user and enabled MFA

Once click on enable multi-factor auth you will get the confirmation.

Here you can see the users status

Also, you can set the setting  from manage user settings

Here are the user's settings for MFA

Also, you can set the service settings

Now time to log in with account, we have given the account

Now here you can see asking for security verification and click on setup
Now set the additional security verification

Set up the Phone Authentication preferences

Set up the Office Phone Authentication preferences

Here you can set up Mobile App notification if you want

Now set the additional security verification and set the phone number whare you will get text or call, as I choose the "Authentication Phone" number

Now you can see the text message has been sent to selected mobile number

Now you can see the app password has been received
Once we set up the security, now this will be my login page, where I have to put the verification code

We can also verify via Power Shell

C:\>Import-module msonline

We will get the following log in windows
Here we will get the got the verification code and after entering the verification code we logged in

There are three versions of multi-factor authentication:

  • Multi-Factor Authentication for Office 365
  • Multi-Factor Authentication for Azure Administrators
  • Azure Multi-Factor Authentication

here is the feature comparison of versions

Azure Multi-Factor Authentication provides selectable verification methods for both cloud and on-premises.

Happy Learning!

Thank you!

Wednesday, May 3, 2017

Disable E-mail Signature changes in Outlook Web App-Office 365

After the migration of mailboxes into cloud i was checking the disclaimer Cloud and found that by default the end-user has the ability to configure signatures and kind of messes up an e-mail signature solution. And my customer want to disable this feature. Now we do have option to disable such feature of OWA, we can also disable signature on the Outlook client using Group Policies.


Logged on the EAC (Exchange Admin Center), click on permissions, and then click on Outlook Web App policies.

Double click on Outlook Web App policies than features and you can see the default Email Signature is checked

Now time to disable the "Email signature" just unchecked the option.

Now user does not have the option to configure the email signature.

Thank you!

Happy Learning!

Thursday, April 20, 2017

Enable Phone Sign In -Microsoft Authenticator

Recently, Alex Simons has blogged on "No password, phone sign in for Microsoft accounts". This a great enhancement in Microsoft second factor or "no password" technology.

With phone sign-in, Microsoft shifting the security burden from our memory to our device. Just add our account to the Android or iOS Microsoft Authenticator app, then enter our username as usual when signing in somewhere new. Instead of entering our password, we’ll get a notification on our phone. Unlock our phone, tap “Approve”, and we’re in.

This process is easier than standard two-step verification and significantly more secure than only a password, which can be forgotten, phished, or compromised. Using your phone to sign in with PIN or fingerprint is a seamless way to incorporate two account “proofs” in a way that feels natural and familiar.

There are a few things you need to consider to complete "phone sign" option.
First download Microsoft Authenticator app from store than configured for personal account, you will see an option from the drop-down menu to select Enable phone sign-in.

If you don't configure or add your Microsoft account in your Authenticator App, you don't see a "use the Microsoft Authenticator app instead" option.  Instead, you will have only see the password sign-in option as shown below:

You will see the following verification message on your login screen and on your mobile device.

Open your Microsoft account and click on next

Now you will see the option "Use the Microsoft Authenticator app instead", once you click you will get
You can also copy the code

Once click "Use the Microsoft Authenticator app instead" you will get following option "Deny" or "Approve"

Once approve you have to open your phone
once approve we are in in my emails

But you don't see this option If you are adding a new Microsoft account on an iPhone.  Microsoft will automatically set it up for you by default.  So add your Microsoft Account and login to a Microsoft service using this account. You will see an additional "password less".

TimeZone /Regional Settings for Shared Mailboxes in Office 365

During the migration to Office 365, I was working with one of the user to correct the issue of time zone of shared mailboxes. I noticed the time was off by a few hours when accessing some shared mailboxes in Office 365 using Outlook Web App (OWA). It was set to Microsoft’s default—Pacific Standard Time.
If you access the shared mailboxes using the desktop version of Outlook (2010, 2013 or 2016), this typically won’t be a problem as the desktop version of Outlook will simply use your PC’s regional settings. However, for various reasons, the desktop version of Outlook may not be an option.
OWA Timezone Settings for User Mailboxes in Office 365
By default when we logs into the OWA for first time, it will give us option to set the regional settings by choosing the default language and time zone, also we can change from Settings -->Mail -->General and select the time zone.
OWA Timezone Settings for Shared Mailboxes in Office 365
In Shared mailboxes work a little differently. We are not log directly into a shared mailbox as there is no user associated with one. If we have the requisite permissions to access a shared mailbox, we could open it in OWA to set the regional settings for it. The process is a little more involved than if you were opening your own mailbox for the first time.
Configure Timezone Settings for Shared mailboxes in Office 365 using OWA
To manually configure region and timezone settings for a shared mailbox via OWA, simply log into OWA as yourself, click your avatar and select Open another mailbox. Enter the shared mailbox name and click Open. From here, go to Options and select Mail from the navigation pane on the right. Select General from the navigation pane on the left, and click Region and timezone. Make any applicable changes to your language, date format, time format and/or timezone settings, then click Save.
Using PowerShell
For all shared mailboxes
Get-Mailbox –RecipientTypeDetails SharedMailbox | Set-MailboxRegionalConfiguration –Language “en-US” –TimeZone “Central Standard Time” –DateFormat “M/d/yyyy” –TimeFormat “h:mm tt”
For a single shared or user mailbox
Get-Mailbox –Identity | Set-MailboxRegionalConfiguration –Language “en-US” –TimeZone “Central Standard Time” –DateFormat “M/d/yyyy” –TimeFormat “h:mm tt”
For all mailboxes
Get-Mailbox | Set-MailboxRegionalConfiguration –Language “en-US” –TimeZone “Central Standard Time” –DateFormat “M/d/yyyy” –TimeFormat “h:mm tt”

Tuesday, April 18, 2017

AAD Connect Version 1.1.484.0 Released

Azure Active Directory Connect version 1.1.484.0 has been released, which includes several fixes and service account improvements. It also simplifies the port architecture required during the setup of Pass-Through Authentication.

Proper directory synchronization is key to a healthy hybrid environment, so it's important to keep on top of upgrades to your directory synchronization infrastructure.

Known issues:
·         This version of Azure AD Connect will not install successfully if the following conditions are all true:
1.    You are performing either DirSync in-place upgrade or fresh installation of Azure AD Connect.
2.    You are using a localized version of Windows Server where the name of built-in Administrator group on the server isn't "Administrators".
3.    You are using the default SQL Server 2012 Express LocalDB installed with Azure AD Connect instead of providing your own full SQL.
Fixed issues:
Azure AD Connect sync
·         Fixed an issue where the sync scheduler skips the entire sync step if one or more connectors are missing run profile for that sync step. For example, you manually added a connector using the Synchronization Service Manager without creating a Delta Import run profile for it. This fix ensures that the sync scheduler continues to run Delta Import for other connectors.
·         Fixed an issue where the Synchronization Service immediately stops processing a run profile when it is encounters an issue with one of the run steps. This fix ensures that the Synchronization Service skips that run step and continues to process the rest. For example, you have a Delta Import run profile for your AD connector with multiple run steps (one for each on-premises AD domain). The Synchronization Service will run Delta Import with the other AD domains even if one of them has network connectivity issues.
·         Fixed an issue that causes the Azure AD Connector update to be skipped during Automatic Upgrade.
·         Fixed an issue that causes Azure AD Connect to incorrectly determine whether the server is a domain controller during setup, which in turn causes DirSync upgrade to fail.
·         Fixed an issue that causes DirSync in-place upgrade to not create any run profile for the Azure AD Connector.
·         Fixed an issue where the Synchronization Service Manager user interface becomes unresponsive when trying to configure Generic LDAP Connector.
AD FS management
·         Fixed an issue where the Azure AD Connect wizard fails if the AD FS primary node has been moved to another server.
Desktop SSO
·         Fixed an issue in the Azure AD Connect wizard where the Sign-In screen does not let you enable Desktop SSO feature if you chose Password Synchronization as your Sign-In option during new installation.
New features/improvements:
Azure AD Connect sync
·         Azure AD Connect Sync now supports the use of Virtual Service Account, Managed Service Account and Group Managed Service Account as its service account. This applies to new installation of Azure AD Connect only. When installing Azure AD Connect:
o    By default, Azure AD Connect wizard will create a Virtual Service Account and uses it as its service account.
o    If you are installing on a domain controller, Azure AD Connect falls back to previous behavior where it will create a domain user account and uses it as its service account instead.
o    You can override the default behavior by providing one of the following:
§  A Group Managed Service Account
§  A Managed Service Account
§  A domain user account
§  A local user account
·         Previously, if you upgrade to a new build of Azure AD Connect containing connectors update or sync rule changes, Azure AD Connect will trigger a full sync cycle. Now, Azure AD Connect selectively triggers Full Import step only for connectors with update, and Full Synchronization step only for connectors with sync rule changes.
·         Previously, the Export Deletion Threshold only applies to exports which are triggered through the sync scheduler. Now, the feature is extended to include exports manually triggered by the customer using the Synchronization Service Manager.
·         On your Azure AD tenant, there is a service configuration which indicates whether Password Synchronization feature is enabled for your tenant or not. Previously, it is easy for the service configuration to be incorrectly configured by Azure AD Connect when you have an active and a staging server. Now, Azure AD Connect will attempt to keep the service configuration consistent with your active Azure AD Connect server only.
·         Azure AD Connect wizard now detects and returns a warning if on-premises AD does not have AD Recycle Bin enabled.
·         Previously, Export to Azure AD times out and fails if the combined size of the objects in the batch exceeds certain threshold. Now, the Synchronization Service will reattempt to resend the objects in separate, smaller batches if the issue is encountered.
·         The Synchronization Service Key Management application has been removed from Windows Start Menu. Management of encryption key will continue to be supported through command-line interface using miiskmu.exe. For information about managing encryption key, refer to article Abandoning the Azure AD Connect Sync encryption key.
·         Previously, if you change the Azure AD Connect sync service account password, the Synchronization Service will not be able start correctly until you have abandoned the encryption key and reinitialized the Azure AD Connect sync service account password. Now, this is no longer required.
Desktop SSO
·         Azure AD Connect wizard no longer requires port 9090 to be opened on the network when configuring Pass-through Authentication and Desktop SSO. Only port 443 is required. 

Download the latest version of AAD Connect here.

Tuesday, February 21, 2017

Office 365- Hybrid Configuration with Skype for Business Online-Lync 2013

Recently, one of my customers want to do the pilot for the hybrid deployment of the Skype for Business online, currently, a customer running on Lync 2013 on premises. So just want to share my experience & process to deploy the hybrid environment for Skype for Business.

Hybrid connectivity between Lync 2013 server and Skype for Business online means users of a domain are split between using Lync 2013 server and Skype for Business online. Some of the domain users are homed on-premises, and some users are homed online.

Before moving forward we have to make sure our on-premises is matching requirement, following are:

Skype for Business client support

Before you decide to deploy hybrid deployment you have to check which client support for Skype for Business online. There are some differences in the features supported in Skype for Business clients, as well as the features available in on-premises and online environments. The following clients are supported with Skype for Business Online in a Skype for Business hybrid deployment:

Lync 2010
Lync 2013
Lync Windows Store app
Lync Web App
Lync Mobile
Lync for Mac 2011
Lync Room System
Lync Basic 2013

for more details click here Clients for Skype for Business Online

Topology Requirements

To configure your deployment for the hybrid with Skype for Business Online, you need to have the  Lync Server 2013 deployment with all servers running Lync Server 2013. For more details Lync Server 2013 Reference Topologies for Enterprise Hybrid Deployments

Requirements for Federation Allowed/Blocked Lists

The allowed domains list includes domains that have a partner Edge fully qualified domain name (FQDN) configured, following are the requirement to successfully configure a hybrid deployment:
Domain matching must be the same configuration on on-premises and Office 365 tenant.
The blocked domain list in the on-premises deployment must exactly match the blocked domain list on an online tenant.
The Allowed domains list in the on-premises deployment must exactly match the allowed domains list for your online tenant.
Federation must be enabled for the external communications for the online tenant, which is configured by using the Lync Online Control Panel.
If the partner discovery is enabled on the on-premises deployment, then open federation must be configured for your online tenant if the partner discovery is not enabled, then closed federation must be configured for your online tenant.

DNS Requirement

We have to make sure when we are creating the DNS records for hybrid deployments, all Lync external DNS records should point to the on-premises infrastructure, additionally, we have to ensure the DNS resolution described with following records in on-premises:
_sipfederationtls._tcp.     Edge Server (for all supported SIP domains resolving to Access Edge external IPs)
DNS A records               Internal corporate Network (for Edge Web Conferencing Service FQDN)

Firewall Considerations

Client on corporate network must be able to perform standard Internet DNS lookups, for more Office 365 URLs and IP address ranges

Port and protocol 

TCP 443
TCP 80 and 443
TCP 5061
RTP/TCP 50000-59999

Preparing the Network for a Lync Hybrid Deployment

The network requirements for a Lync hybrid deployment are similar to the requirements for a cloud-only deployment. However, there are several additional firewall port requirements compared to a cloud-only deployment, and there is at least one additional DNS requirement for the hybrid deployment, depending on the configuration. We need to do the Network Assessment before start any configuration, we can use Skype for Business Network Assessment tool. The Skype for Business Network Assessment Tool provides the ability to perform a simple test of network performance to determine how well the network would perform for a Skype for Business Online call.


We have to make sure we have following utilities installed and working smoothly to complete the tasks for configuring the Hybrid.
1. Active Directory Synchronization (AAD Connect).
2. Office 365 tenant with Skype for Business online enabled.
3. ADFS for single sign on.
4. Windows Power Shell for single sign on.
5. Microsoft online Services Sign-in Assistant.
6. Up to date CU for Lync Server on premises.

Following are steps involve

Add your domain and verify ownership
Install and Configure Active Directory synchronization
Install and Configure Active Directory Federation Services (AD FS)
Install and Configure Active Directory Federation Services Proxy (AD FS Proxy)
Configure Single Sign-on (SSO) with ADFS
Configure federation of Lync Server 2013 with Lync Online
Move user to Lync Online and test calls between Lync Online and Lync Onprem

Add your domain and verify ownership

Once you signed up Office 365, you will get the Office 365 Tenant account. From this account, you will add your domain. This will allow Microsoft to host the desired Office 365 services for you and will allow you to use you own domain, rather than the tenant domain account ( default account.

The process should be quite easy and painless as long as you have access to the Microsoft Online Portal, with a Global Admin account, and access to your public facing DNS.

for step by steps you follow Adding and Verifying a Domain for the NEW Office 365

Install and Configure Active Directory synchronization
Install and Configure Active Directory Federation Services (AD FS)
Install and Configure Active Directory Federation Services Proxy (AD FS Proxy)

Office 365 uses the cloud-based user identity management service Azure Active Directory to manage users. You can also integrate your on-premises Active Directory with Azure AD by synchronizing your on-premises environment with Office 365. Once you set up synchronization you can decide to have their user authentication take place within Azure AD or within your on-premises directory.
For Step-by-Step Guide for AAD Connect Custom installation + Federation with AD FS click here.

Configure Single Sign-on (SSO) with ADFS

Once we complete the ADFS and ADFS Proxy setup, we can now configure SSO between the Onprem AD and O365's Azure AD. First, we have to download and install the Microsoft Azure Active Directory Module for Windows PowerShell on the ADFS computer. Once installed, open the module and run the following PowerShell commands to setup a trusted federation domain:

First, give the credential

$cred = get-Credential

connect online service

Connect-MsolService -Credential $cred

Now time to convert your domain to federated domain

Convert-MsolDomainToFederated -DomainName

time to verify the configuration

Get-MsolFederationProperty -DomainName

Now it's time to test single sign-on connectivity, we can use the Microsoft Connectivity Analyzer Click the Office 365 tab, click Microsoft Single Sign-On, and then click Next. Follow the screen prompts to perform the test.

Configure federation of Lync Server 2013

We must enable the federation to allow communications with Office 365, we can use Power Shell for performing all the steps:

Set-CSAccessEdgeConfiguration -AllowOutsideUser1 -UseDnsSrvRouting -AllowFederatedUses

Confirm the settings with the following command


Nest configure the provider Skype for Business online, first, we have to identify the existing suppliers


Remove the existing provider

Remove-CsHostingprovider -Identity "Skype for Business Online"

Verify again with the command


Now time to add the Skype for Business Online supplier with the following parameters:

New-CSHostingProvider -Identity SkypeforBusinessOnline -ProxyFqdn "" -Enable $true -EnableSharedAddressSpace $true -hostOCSUsers $true -Verification level UseSourceVerification -Is local $false -AutodiscoverUrl

Configuration of Office365

In the Skype Online Administration Center into your Office 365, validate that the federation is enabled in "Organization" – "External Communications".

Configure SharedSipAddressSpace

Before moving users from Lync Onprem to Lync Online, we need to configure the O365 tenant to share the SIP address space with the on-premises deployment. If this is not configured, we may see the following error message

Set-CsTenantFederationConfiguration -SharedSipAddressSpace $true

Move user to Skype for Business and Lync Onprem

Now we can proceed to use the Move-CsUser cmdlet in the Onprem Lync Management Shell: to move the user from Onprem to Online.

Move-CsUser -Identity -Target -Credential $cred -HostedMigrationOverrideUrl

After the Move-CsUser command completes successfully with no errors, we can log into O365 Lync admin center to see the user is now homed online.

On the Onprem Lync Control Panel we can see the same user is specified as homed online

Happy Learning!

Thank you!