Martello BLOG : 2020

How ADFS and Azure AD connect can impact Microsoft 365 users

How ADFS & Azure AD Connect Can Impact Microsoft 365 Users

Originally posted on gsx.com

Office 365, now called Microsoft 365, is no doubt, the biggest cloud service on the planet. Despite its size and market share, it’s important to remember that cloud services are reliant on-premises components. If you want to ensure the availability and performance of Exchange online, Teams or SharePoint, you need to make sure that your Microsoft identities are working fine too. That is why we’ve just released new functionalities for our Microsoft Office 365 service quality monitoring product. Martello Gizmo is now able to test, alert and report on the availability and performance of your Microsoft ADFS and Azure AD Connect in parallel with our unique capabilities to monitor the end-user experience of the Microsoft Office 365 suite.

Want to see how it works? Sign up for our 14-day free trial and test our solution directly in your environment.Get started today!

Let’s start with ADFS

As you know, Active Directory Federation Services (ADFS) provides users with single sign-on access to systems and applications across organizational boundaries. It is usually used as an identity management option for Office 365.

Ensuring the availability of this service is critical. If your ADFS infrastructure is unavailable, end-users won’t be able to log into Office 365 services.

One of the most common issues with ADFS is disconnection. If you’ve ever tried signing into Office 365 or other Microsoft cloud services and failed to connect, you know how frustrating this can be. If users sign into a cloud service with a federated user account, the connection to ADFS will fail if they try to connect remotely or use an email connection to sign in.

So, what causes the missed connection? The ADFS service might not be exposed correctly to the Internet, impacting your ADFS server proxy. This causes expired SSL certificates, incorrect IIS authentication endpoint configurations, and/or distrust between the ADFS proxy server and the ADFS Federation Service.

There are three ways to fix these Microsoft Office 365 issues:

Try troubleshooting the ADFS SSL certificate issues on the ADFS service by updating the SSL certificate on the proxy service.
Retune the ADFS proxy server IIS authentication settings to default.
Rerun the ADFS Proxy Configuration wizard from the Administrative Tools interface.

To fix ADFS issue you need to be aware of them. It is not because a user can’t log into Microsoft service that it is automatically ADFS.

We’ve seen from customers that many were trying to troubleshoot a login error for hours before realizing the root cause of the issue was ADFS.

For this reason, it is important to test in real time the ADFS service and make sure it performs well to avoid any issue.

That is what Martello Gizmo is doing for you.

Martello Gizmo tests the ADFS exactly as a user would, by trying to perform a full authentication to Microsoft Office 365. Martello Gizmo sends the request against Windows credentials and makes sure the ADFS server is responding to the request with the token quickly.

Our Office 365 monitoring solution checks the time taken by the overall process, displays the metrics in real time and alerts in case of abnormal latency.

The result allows administrators to quickly identify and troubleshoot ADFS issues from a single dashboard, reducing headaches and improving overall performance in your Office 365 environment.

Another ADFS point of failure that we often see from our customers is the certificates.

ADFS requires several certificates to secure the communication, enable user authentication and authorization requests to federation servers- federation servers proxies an ADFS enabled Web servers.

It is critical to make sure these certificates are always up to date.

Martello Gizmo constantly checks the status of these certificates and warns you as soon as one of them is set to expire in the next 30 days. With that feature you will never miss a renewal and you’ll be sure that user authentication problems are not caused by this avoidable issue.

See how you can empower enterprise IT to ensure a product Microsoft 365 experience.Give it a test run today!

Let’s Talk Now About Azure AD Connect

The other pillar of Microsoft identities also plays a critical part in the ability for users to connect to their Microsoft Office 365 service. Again, this service is installed on-premises on a Windows server.

As you know, Azure AD Connect is responsible for the synchronization between your Active Directory identities and Microsoft Office 365.

If the synchronization is not working, the established connection will still work, but any change in the on-premises directory will not show on Microsoft 365. So, you will have connection issues with your users.

Once again, if you do not monitor the status of this synchronization, it will be difficult for you to find the root cause of connections to cloud services issues.

We’ve seen at large enterprises that it is not the first thing they check, which makes sense because plenty of reasons that can lead to user’s authentication issue.

That is why it is important to keep an eye on it. This is exactly what Martello Gizmo is doing.

GSX Gizmo Azure AD Connect

Martello Gizmo constantly check the status and the time of the last synchronization between your AD and Microsoft 365. If the last synchronization failed or just never happen, you will be alerted.

Therefore, you won’t spent time troubleshooting a user’s connection issue caused by Azure AD Connect since you’ll have the alert and the information, right under your eyes at the minute it happens.

As you see, Microsoft Office 365 is a cloud service that requires hybrid component to be available for your users. At Martello, we understand that.

That is also why our latest version provides so many features for Hybrid Exchange deployments. The future is the cloud, but the future is connected to the present where on-premises servers and services are still indispensable to allow users to be more productive.

Learn more about Martello’s service management solution for your Azure services here.

Be productive about authentication issues in ADFS

Be Proactive About Authentication Issues in ADFS

Originally posted on gsx.com

Active Directory Federation Services (AD Federation Services) is a feature of the Windows Server operating system that extends end users’ single sign-on access to applications and systems outside the corporate firewall.

System Resources

Martello for ADFS provides live monitoring and reporting for CPU, Memory, and Average Disk time. Martello also monitors the performance of ADFS through critical performance counters, which helps troubleshoot issues quickly in any organization during congestion or performance load issues.

Token Requests/Sec
Token Requests
Federation Metadata requests/sec
Artifact resolution requests/sec
Extranet Account Lockouts
Password Change Successful Requests
Password Change Failed Requests
External Authentication Failures

Martello provides real-time monitoring and keeps the performance counter information up to 400 data points (analyze, trends, forecasts).

Martello shows the collected statistics information in Graphs, which allows the administrator to point out the issue easily and provide the resolution quickly.

Certificates

In any Active Directory Federation Services (ADFS) design, various certificates must be used to secure communication and facilitate user authentication and authorization requests that are made to federation servers, federation server proxies, and AD FS-enabled Web servers.

Certificates will be playing a major role in Active Directory Federation Services and it’s very important to monitor and make sure we renew the certificates before they expire and create a huge impact in the organization.

Martello monitors ADFS certificate information triggers an alert to administrators on Expiry notification with the date of expiration, subject and thumbprint value.

Synthetic Transactions

Martello not only performs server monitoring, but also mimics end-user actions and perform synthetic transactions on ADFS environment.

Martello Solutions as a user will send the request against windows credentials and make sure the ADFS server is responding to the request with the token quickly. Martello also notifies the time taken to receive the response from the ADFS server and triggers an alert in case the response time exceeds the threshold. This test will let the administrators know if there is any issue with the federation server and authentication.

Martello as a user will frequently access the Federation Metadata information and make sure the server responding the request with the proper information.

At Martello, we consider Identities management as a critical component of Office 365 monitoring. Any issue with Identities management can have huge impact on the end-user experience, and can require extensive amounts of troubleshooting time for the administrator while end-users are unable to connect to the service.

We help you test the Office 365 service from end to end, including with:

Monitoring of the Microsoft Identities management tools (AD, Azure AD Connect, and ADFS)
Monitoring of the actual end-user experience, measured at the site level, from multiple locations
Monitoring of the network latency from the user to the Office 365 Datacenter
Monitoring of key users statistics (mailboxes and actives devices statistics) to help identify any usage issues

Silhouette of person in a crossroad with three different paths

Managing Service Level Agreements

Originally posted on gsx.com

We are delighted to post an article on the challenges of managing Service Level Agreements by ITIL Standards, by Bill Heffernan of SureSkills. Service Level Agreements (SLAs) are fundamental to effective service provision. They provide the basis for managing the relationship between the service provider and the customer, describing the agreement between the service provider and customer for the service to be delivered, including how the service is to be measured. Basically, SLAs are intended to ensure the provider understands what they are supposed to deliver, the customer knows what to expect, and both can see (empirically) what is actually being delivered. However, effectively managing Service Level Agreements can prove to be challenging without the right tools.

Regrettably, the ‘agreement’ role of the SLA is lost in many organisations, where SLAs are used as ‘weapons’ to defend or challenge the provider or customer. The emphasis for SLAs must be on agreement, and the SLA should not be used to hold either side to ransom. A true partnership should be developed between the IT service provider and the customer, enabling a collaborative approach to quality improvement.

Metrics and Key Performance Indicators (KPI) are a core element of an SLA. Ineffective or absent KPI can cause a service to fall into disrepute and a blame culture can develop. KPI for the service must accurately reflect the expectations and perceptions of both the customer and service provider.

To manage service provision, we need:

Service metrics which reflect the end-to-end quality of service or ‘user experience’
Process metrics to inform the service provider and customer of the effectiveness (achieving goals) and efficiency (use of resources) of key activities within the service delivery function.
Technology metrics to inform the IT provider at the component level, enabling the identification of issues and improvement opportunities

When considering SLA KPI we must recognize that Customer perceptions are influenced by:

Attributes of service that are indicators of value e.g. relative performance, reliability or security of a remote work space service
Present or prior experience of similar attributes
Relative endowment of competitors and other peers i.e. what they have
Customers self image or actual position in market (innovator, market leader, risk taker) i.e. do I expect leading edge solutions or accept / expect robust security requirements to access the service

When considering KPI from an IT perspective, we need to recognize that the customer is not excessively concerned with how the provider delivers the service and, as such, is NOT interested in visibility of the majority of KPI which the IT provider uses to manage the service e.g. component performance. On this basis, component and process KPI should not be included in the SLA. They are primarily articulated in Operational Level Agreements and Underpinning Contracts which underpin the SLA. Obviously, certain process KPI will overlap with customer expectations for the service e.g. “95% of incident which impacts more than 50 people in the organisation will be resolved within 4 hours” – customer expectation and Incident Management effectiveness KPI.

We also needs to consider the inclusion of Objective KPI (number of major incidents in a month) and Subjective KPI (Improvements in customer satisfaction).

Finally, we need to consider any scope or constraint measurements that may be required to provide context for current service levels. For example, incident resolution targets or service performance targets may be defined in the context of the number of user of the services (up to 500 concurrent users). In this case, we need to have visibility of the number of concurrent users at any time. It’s a possible discussion for another day but it is imperative that we always consider how we are going to measure each aspect of the service, before including it in the SLA. The mechanism, source and frequency of data collection, processing, analysis and reporting should be mutually agreed between the customer and IT service provider.

So, in summary:

Managing Service Level Agreements requires specific measurements (KPI)

When selecting KPI, ask, what indicates value to the customer?

Enhanced performance in the business
Constraints removed from the business
Availability & Reliability of the Service
Performance of the service o Security of the service o Service Continuity (ability to recover from disaster)

Do not include IT ‘management’ KPI i.e. component & process metrics only used by IT.

Consider “How and how often, can I measure that?”
Consider Objectives and Subjective metrics

Remember scope measures that may be required for context.

Above all else, do not forget the #1 rule – Nothing should be included in an SLA unless it can be effectively monitored and measured at commonly agreed points. Learn more about Martello’s Service Level Agreement monitoring solution today!

Elevate Microsoft 365 Managed Services

Featured News

Martello BLOG : 2020

How ADFS & Azure AD Connect Can Impact Microsoft 365 Users

Be Proactive About Authentication Issues in ADFS

Managing Service Level Agreements

MARTELLO – Ontario, Canada

MARTELLO – Genève, Switzerland

MARTELLO – Nice, France

MARTELLO – Paris, France

MARTELLO – Amsterdam, The Netherlands

MARTELLO – Texas, USA

MARTELLO – New York, USA

Products

Use Cases

Solutions

Resources

Partners

About Us