Friday, December 1, 2017

SQL AlwaysOn-Skype For Business

There are many changes on Skype for Business included high availability such as server pooling, disaster recovery with pool pairing, and several modes of Back End server high availability such as always on availability groups, database mirroring, and SQL fail over clustering.

High availability referring to make sure that services are available even one or more servers goes down and disaster recovery means keeping services going in the event of a natural or human caused disaster and preserving as much data from before the disaster as possible.

Skype for business server providing the high availability options in Front End as pool pairing as well as high availability options are in Back End servers such as database mirroring, Always On availability groups, SQL fail over clustering, Always On fail over cluster instances (FCI).

Worked on a project for Skype for Business deployment with one of mu customer, and want to share my experience through this post. In this post my main focus on configuring the SQL Server AlwaysOn Availability Group for Skype for Business.

Before Starting 

As always we have to go through the prerequisite, following are the recommendation from Microsoft

Server requirements for Skype for Business Server 2015

Back End Server high availability in Skype for Business Server

Windows Failover Clustering

Following are the recommendation for configuration of the Windows Failover Clustering

Failover Clustering Hardware Requirements and Storage Options

Understanding Requirements for Failover Clusters

IPs Address and DNS

First of all we need to do ensure that our SQL nodes are configured on the customer LAN and domain joined.

SQL AlwaysOn

Next we need to decide the IP addressing for the SQL availability group, we need IP address for SQL AlwaysOn Group listener and DNS name for SQL AlwaysOn Group listener.

Service Accounts

Again we have to follow the best practice to use Active Directory Service Account where possible.

Network Configuration

First we have to configure the Network for public and private network card on both SQL servers.

Windows Failover Clustering 

Now time to install the Windows Failover Clustering role on servers, we have two option, first you can run the PowerShell command

Install-WindowsFeature Failover-Clustering

and 2nd option from GUI

Once complete we can see the "Failover Cluster Manager" in server tools

Now time to create failover cluster, open from console of failover cluster manager

Select Create Cluster

Click Next on Create Cluster Wizard

Brows the both nodes from Active Directory and click on add

Next wizard for validating the cluster configuration test before continue, i have selected Yes

Now it will start validating the configuration

Select "Run all Test"

next wizard ready for test configuration

wizard is running for validating the configuration

here is the validation report for cluster configuration.

Next wizard you have to give the Cluster IP address and Cluster Name

next we have to make sure uncheck on "Add all eligible storage to the cluster" and press Next to continue

Once Windows Server Failover Cluster now created and we can get the warning regarding Quorum witness, we can ignore now as  we will  define latter also we can view the report

Now we can see all the details from Failover Cluster manager Console

Now we have to define the Quorum\Witness folder and permission.

Now create the Cluster Quorum from Failover Cluster Manager

Quorum cluster configure wizard will give all details, click Next

here we have option to select the Quorum witness
next wizard configure the a file share witness

Next brows and select the file share witness
Once we select the path of the file share witness click on Next
Now you can see the Cluster Quorum configuration has been completed and we can view the report also.

Now we can see the both nodes are online from Failover Cluster manager console

Now we see the completed the installation and configuration of the Windows Failover Cluster, In next part 2 we will start SQL installation and configuration.

Wednesday, November 15, 2017

Email Journaling Options- Office 365

Using Journal Rules, organizations can keep track of correspondences. This can be used to ensure quality by implementing journal rules that catalog all of the email messages sent by the sales staff to anybody outside the organization.

Journaling help organization respond to legal, regulatory, and organizational compliance requirements by recording inbound and outbound email communication.

Before moving forward we have to understand the difference between Office 365 and Archiving:
Journaling It is record all communications, including email communications in an organization for use in the organization’s email retention or archival strategy.

Data Archive It is kind of backing up the data, removing it from its native environment, and storing it elsewhere for reducing the data storage.

Journal rule scope:
  •          Internal messages only
  •          External messages only
  •          All messages

Journal Recipient
We can implement journaling rules by specifying the SMTP address of the recipient or we can apply on all mailboxes for journal.

Journaling mailbox
The journaling mailbox is used to collect journal reports. How you configure the journaling mailbox depends on your organization's policies, regulatory requirements, and legal requirements. You can specify one journaling mailbox to collect messages for all the journal rules configured in the organization, or you can use different journaling mailboxes for different journal rules or sets of journal rules.

Office 365 does not allow to designate a mailbox which is hosted on Office 365 as a journaling mailbox. The only option we have to designate a mailbox which is located in an On-Prem Exchange server or a third party journaling solutions provider.

In Office 365, a workaround can be used to get this done by using Mail Flow Rules in Exchange Online. Below steps provide guidance to implement it on On-premises Journaling solution.

First, log into the Office 365 Portal using the Admin credentials

Exchange Online Admin Centerà Mail Flow sectionà Rules

Once inside the Mail Flow rules section, click on the + sign àCreate a new rule

Give the name of the ruleàApply this rule ifà drop down options select “the sender is located” (option since we want to have all the emails from senders within the organization to be recorded)àclick on “Select One” à “Select Sender Location” option box

Inside the organization” option from the drop down menuàClick OK

Next we have to go to the “Do the following” section and select “Bcc the message to” option from the drop down menuà select the mailbox that you need to Bcc all the messages which are sent by the sender of the organization. 

Select the mailbox created for the journaling purpose name  à “OK”à Select enforce—Save.

Now organization start getting messages Bcc’ed to the mailboxes

Setting up a Office365 Journaling Mailbox

If we want to create the dedicated email journaling with in Office365 and all email exchange will forward to this mailbox.

Login to Office365 ECP

Go to Setup--> Quick Start-->Start

Choose default domain and click Next

Click Add users and assign licenses and click Next.

Select Add users 

Click on Next 

Now you can assign the role and click on Next and assign the Licenses Exchange Online Plan1--Click Next

Next page you can specify the email address where you would like to receive information about the new users and any email temporary passwords, we can add up to five recipients, Next page note the user name and password and click on finish.

We can make sure the Journal mailboxes should only authorized people have access to them. They may contain sensitive information in them and should never be left open for everyone in the organization.


Thank you!
Happy Learning...

Friday, November 3, 2017

ActiveSync now working- Exchange 2007 to Exchange 2013- Office 365/Hybrid


Issues with ActiveSync, when I configured mailbox on the Exchange 2013 with Activesync it work without any issues, if the mailbox is in Exchange 2007 server than it get failed


We are working on migration from Exchange 2007 to Office365 hybrid deployment (Exchange 2013), when we tried to move Client Access Server traffic from Exchange 2007 to Exchange 2013 servers, OWA redirect from Exchange 2013 to Exchange 2007 works without any issues. Autodiscover works fine and autoupdated all outlook profiles. But only issues with Activesync. we already have the updated SAN certificate on both environment and updated DNS records.

The Client Access Server attempting to proxy has been denied permissions for the “Exchange Web Services Token Serialization” and/or “Exchange Web Services Impersonation” rights which are required for cross-site proxy, including cross-site availability lookups.

The resolution is to remove the proxying CAS server or their nested group membership from any group that explicitly denies “Exchange Web Services Token Serialization” and “Exchange Web Services Impersonation” to the CAS being proxied to CrossSite CAS. The default list of security groups with explicit Deny permissions are:
Exchange Organization Administrators
Schema Admins
Domain Admins
Enterprise Admins

To be sure there are no other groups that have the explicit deny permissions for the needed rights, run the following command to verify all users/groups on the CAS which are denied these permissions:

Get-ADPermission -id CrossSiteCAS | where {$_.ExtendedRights -like "ms-Exch-EPI-Impersonation" -or $_.ExtendedRights -like "ms-Exch-EPI-Token-Serialization" -and $_.Deny -like "True"} | ft -autosize User,ExtendedRights

if any run the this command giving the exchange 2013 mailbox servers rights to the 2007 CAS servers.

Get-ClientAccessServer -Identity “Exchange2007-CAS01” | Add-ADPermission -Accessrights Extendedright -Extendedrights "ms-Exch-EPI-Token-Serialization" -User "domain\Exchange2013-MBX01$"

Effective permissions for the CAS can also be verified through ADSIEdit.

Go to the configuration container, Services, Microsoft Exchange, Organization, Administrative Groups, Exchange Administrative Group (FYDIBOHF23SPDLT), Servers, CAS
Properties > Security Tab > Advanced button > Effective Permissions tab
Select... button > object types button > check computers > ok > enter the CAS
Scrolling down the list about one quarter the way, you should find the "Exchange Web Services Impersonation" and "Exchange Web Services Token Serialization" rights.


Once we run the below command and see there are some deny

Get-ADPermission -id CrossSiteCAS | where {$_.ExtendedRights -like "ms-Exch-EPI-Impersonation" -or $_.ExtendedRights -like "ms-Exch-EPI-Token-Serialization" -and $_.Deny -like "True"} | ft -autosize User,ExtendedRights

We run below command for resolution:

Get-ClientAccessServer -Identity “Exchange2007-CAS01” | Add-ADPermission -Accessrights Extendedright -Extendedrights "ms-Exch-EPI-Token-Serialization" -User "domain\Exchange2013-MBX01$"

Thank you!

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!