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 

 References:-
https://docs.microsoft.com/en-us/azure/active-directory/connect/
http://security.blogoverflow.com/2013/09/about-secure-password-hashing/



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
C:\>Connect-MSolService

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.


Workaround:

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 sharedmailbox@Domain.com | 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
PSOM/TLS 443
STUN/UDP 3478
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.


Prerequisites

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 (@domain.onmicrosoft.com) 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

Get-CsAccessEdgeConfiguration

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

Get-CsHostingProvider

Remove the existing provider

Remove-CsHostingprovider -Identity "Skype for Business Online"

Verify again with the command

Get-CsHostingprovider

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

New-CSHostingProvider -Identity SkypeforBusinessOnline -ProxyFqdn "fed.online.tech.com" -Enable $true -EnableSharedAddressSpace $true -hostOCSUsers $true -Verification level UseSourceVerification -Is local $false -AutodiscoverUrl https://webdir.online.tech.com/Autodiscover/AutodiscoverService.svc/root


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 sipfed.online.tech.com -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!



Sunday, February 5, 2017

Exchange 2016 and Skype for Business Integration-OWA

In Skype for Business IM integration with OWA enable the user to publish the presence and view the presence of the other without having a local Skype for the Business client running. By default, the integration between exchange 2016 and skype for a business server for this feature is not enabled.

In previous Exchange versions, we simply need to edit the web.config file with Exchange certificate thumbprint. Also if Microsoft Exchange Unified Messaging Call Router service and the Microsoft Exchange Unified Messaging service runs on the same box then there was no need to create an application pool for OWA integration. However, these two steps have been replaced with Exchange 2016 because of all roles in the same box. For deep dive Exchange 2016 click here

You can also check Integrating Lync 2013 with Exchange 2013 in my old post.


Exchange 2016 and Skype for Business Integration

Before starting the configuration part we have to make sure Server to Server authentication are working and Exchange Autodiscover services are configured correctly.

Self-signed SSL certificate (Microsoft Exchange Auth Certificate) is installed on the each Exchange servers, this will for the server to server authentication on Exchange side.

We can verify on Exchange Server with Power Shell

Get-ExchangeCertificate



In Skype for Business server, we have to request a certificate for SkypeFB web services which can also use for the OAuthTokenIssuer for the server to server communication as long as you use this SSL certificate on all your front end servers.

We can verify with Power Shell command

Get-CsCertificate –Type OAuthTokenIssuer


we can verify the IM presence to open the OWA.

as we can see there is no presence available now, we will verify once our configuration complete.


Configure Auto discover

We need to make sure that Autodiscover services configured/running correctly, if it is not configured correctly integration with Skype for Business will not work.
We can use Power Shell command to verify the configuration 

Get-ClientAccessService | Select-Object Name, AutoDiscoverServiceInternalUri | Format-List


Get-ClientAccessServer -Identity MX1 | Select-Object AutoD*

you can get for other exchange servers also.


Create the DNS Records

We have to create two DNS record before modifying the Exchange configuration, which is mostly autodiscover aware clients will query when attempting to locate an Exchange Server.

Create a new Alias (CNAME) record in the under forward lookup zone, pointing to the Exchange Server FQDN



Second, create the new Service Location (SRV) record using the following parameters pointing this record to the CNAME record.


We can verify DNS records with help of nslookup command



Update the Autodiscover URL

If the AutodiscoverServiceInternalUri has not correct then we must have configured with the following command:

Set-ClientAccessService –Identity MX1 –AutoDiscoverServiceInternalUri https://autodiscover.tech.com/autodiscover/autodiscover.xml



Configure OAuth

OAuth is the server to server authentication mechanism used between the Skype for business and Exchange servers to establish secure communications. During the skype for business server deployment SSL certificate specified the OAuth. We need to make sure that OAuth is configured to the Skype for Business FE servers, we can user Power Shell command to verify the OAuth

Get-CsOAuthConfiguration



Before the integration with Skype for Business partner application we need to know about the Exchange Autodiscover configuration with following Power Shell command:

Get-ClientAccessServer -Identity MX1 | Select-Object AutoDiscoverServiceI*

AutoDiscoverServiceInternalUri 
—————————— 
https://autodiscover.tech.com/autodiscover/autodiscover.xml



Now we have to configure the OAuth from SfB front end server

Set-CsOAuthConfiguration -Identity global -ExchangeAutodiscoverUrl https://autodiscover.tech.com/autodiscover/autodiscover.svc


Here is the point we are using .svc not .xml in autodiscover URL.

Now run again Get-CsOAuthConfiguration command for complete details


We are now ready for integration and everything we already configured on both sides.


Configure Exchange 2016 server 

Now in Exchange server side, we need to configure the metadata authentication URL, we can complete the pairing a new partner application will also need to be defined on the Skype for Business side. We need the metadata URL for SfB authentication.

This URL should be identical to the following format, utilizing the SfB Front End server FQDN.

https://autodiscover.tech.com/autodiscover/metadata/json/1

Connect to this URL in a web browser from the Skype for Business Server to validate connectivity, which will give you more details.

Now configure the Configure-EnterprisePartnerAppliation with the following command

.\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl “https://autodiscover.tech.com/autodiscover/metadata/json/1″ -ApplicationType Lync

Once command executes successfully restart the IIS.



Configure Skype for Business 

For complete the pairing we need to configure Skype for Business side also, we need to configure metadata authentication URL of the Exchange server which will be the following format:

https://autodiscover.tech.com/autodiscover/metadata/json/1

We can test this URL on Skype for Business server will give you the more details.
Once you get the all details now time to add the partner application with help of Skype for Business management Shell


New-CsPartnerApplication –Identity Exchange –ApplicationTrustLevel Full –MetadataUrl hrrps://autodiscover.tech.com/autodiscover/metadata/json/1

Test the Connectivity

Now time to validate the configuration partner application relationship has been successfully established with help of the following command:

Test-CsExStorageConnectivity –SipUri sip:dinesh.singh@tech.com –verbose

The test cmdlet returns a successful result of “Test Passed”.


Enabling Skype for Business for OWA


On Exchange Server 2016

First, run the command on Exchange Management Shell

Get-ExchangeCertificate

Copy the thumbprint on the notepad which we require in next steps.
From Exchange Management Shell specify the IM server and certificate thumbprint with help of the following command:

New-SettingOverride –Name “OwaOverride” –Component OwaServer –Section IMSettings –Parameters @(“IMServerName=” –Reason “Configure IM” –Server MX1

If you want to make change all Exchange servers, you can remove the MX1 from above cmd.

Now refresh the IM settings on the Exchange servers, you have to do on every Exchange 2016 server which used for Outlook Web App, run following command on Exchange management Shell

Get-ExchangeDiagnosticInfo –Server MBX1 Process Microsoft.Exchange.Directory.TopologyService –ComponentVariantConfiguation –Argument Refresh

Next, we have to Restart outlook web app application pool with help of the following command 

Restart-WebAppPoolMSExchnageOWAAppPool

Once complete verify the OWA virtual directory with help of below cmdlet

Get-Owavirtualdirectory

Now enable IM on Owa with help of the following command:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory –InstantmessagingEnabled $true –InstantMessagingType OCS

Now you can run the  cmdlet

Get-OwaVirtualDirectory | fl command for checking the two properties “InstantMessagingEnabled-true & InstantMessagingType-ocs”

Now it's time to allow IM on the OWA web policy with using Power Shell command line

Set-OwaMailboxPolicy –identity “default” –InstantMessagingEnabled $True –InstantMessagingType “OCS”

From Skype for business Server

We completed configuration from Exchange side now it’s time to configure on Skype for business server 

First get the site id with help of following command
Get-CsSite | Select-object DisplayName, SiteID

Note down the result 

Now time to configure trusted application pool with help of cmdlet

New-CsTrustedApplicationPool –Identity “mx1.tech.com” –Registrar “fe1.tech.com” –Site “techUSA” –RequiresReplication $False


Once you hit the command and it will ask to confirm then type A and hit enter

Now time to create a trusted application and map it to the pool which we created with help of following cmd

New-CsTrustedApplication –Application OutlookWebApp –trustedApplicationPoolFqdn mx1.tech.com –Port 5199

Finally, we have to need the publish the topology

Enable-CsTopology


Now, time to check the IM presence is in OWA is available.



Thank you!

Happy Learning!