A Few Simple rules…

1. If you don’t have ADFS or an existing 3^rd party federation service..
   • Use Password # Sync. It is the simplest option for customers and has the lowest infrastructure needs.
   • If for some reason the policy in your organization does not allow Password # Sync and only needs desktop SSO for domain joined devices, strongly evaluate using PTA as an option. PTA does not require any deployment in the DMZ which simplifies the deployment infrastructure when compared with ADFS. Of note, we recently (@Ignite 2017) announced that F5 can now fully replace the ADFS proxy capabilities for the DMZ. So, if you have an F5 device already, the difference between ADFS and PTA diminish significantly.
   • Use ADFS if you need specific capabilities that the prior options do not offer. See table below for more info.
2. If you already have ADFS for other applications, continue to use it. It is recommended not to split out your IDP’s where possible so that end users can have a consistent sign-in experience. We recommend moving your applications over to Azure AD for additional security controls such as Identity protection based on risk, device based conditional access across web apps and native clients and provisioning support for specific SaaS apps. You can still enable P#S for your users that provide additional benefits such as leaked credential detection and as a fall back mechanism if your datacenter/ADFS goes down. You can then consider other options such as P#S or PTA based on your needs.
3. If you have a 3^rd party federation service and it only supports SAML-P, evaluate ADFS as there are # of use cases that do not work when the IDP only supports SAML-P. We’ve seen many customers go down this route as many use cases when connecting to Azure AD require WS-Trust. The most common ones are AAD SSO & Conditional Access from Win10 devices when logging in with U/P and EAS support. A common patterns employed by customers is to redirect all passive browser-based flows to the 3rd party IDP, but handle all active flows (WS-Trust) directly via ADFS. This provides a consistent sign-in experience.
4. If you have a 3^rd party federation service that supports WS-*, ensure that the product and version is part of the “Works with Azure AD” list. If this is not present, I would evaluate one of the existing MSFT options. If it's present do check with your vendor against the cases that I listed below.
5. If you have Azure AD premium licenses for all your active users in the cloud, you should seriously consider using PHS or PTA as you will have all the security capabilities available via Azure AD (e.g. Conditional Access). If not, I'd recommend you consider the options below, especially the ones called out as premium below to make an informed evaluation.

Comparing the Sign-in Options

Notes

1. HA with auto-failover: In the case of PTA, this is automatically done by the cloud service. In the case of ADFS, the load balancer can be configured to send requests only to ‘healthy’ nodes. With password # sync, you will have to manually elevate the staging Azure AD Connect server to become active if the current server goes down.
2. Certificate sign-in: ADFS can integrate with your enterprise PKI to allow sign-in using certificates. These certificates can be soft-certificates deployed via trusted provisioning channels such as MDM or GPO or smartcard certificates (including PIV/CAC cards) or Hello for Business (cert-trust). See this blog for more information.
3. Users in multiple untrusted AD forests: With ADFS in 2016, an untrusted forest can be configured as an LDAP directory that allows you to sign-in those users from a single ADFS setup. To learn more about LDAP directory setup with ADFS, see this link.
4. 3^rd party LDAP directory: Customers requiring to sign-in users from a 3^rd party LDAP directory to access Azure AD apps (and Office 365) can now use a new feature in ADFS 2016 to sign these users in. To learn more about this feature and configure it, see this link.
5. Win10 Hello For Business (Cert Trust): For customers looking to deploy Hello For Business as part of their Win10 deployment, this option is only relevant if you need the TPM protected credentials to be used with down-level domain controllers (<2016 DC’s) or with VPNs that only support certificates. Otherwise, the key trust model can be used. Also, in this option, ADFS 2016 also becomes the provisioning endpoint for the TPM protected certificates and makes the provisioning simpler with auto-renewal & instant PIN use (coming soon). It is also possible to use MDM to provision the certificates. For Hybrid Azure AD Joined devices (domain joined devices that are also registered with Azure AD), the ADFS option is recommended due to the more seamless and deterministic experience that is integrated with Windows logon.
6. Custom MFA: Azure AD recently announced support for 3rd party MFA providers integrated with Conditional Access. This is currently in preview and supports RSA, Trusona & Duo. To learn more see this link.
7. Sign-in with domain\samaccountname: While ADFS supports this and can be used in multiple use cases, we recommend customers to move to signing in with a UPN suffix. Also, it is possible in ADFS in a single UPN suffix scenario to customize the Java Script in the sign-in pages to only require the samaccountname.
8. Office first time login on DJ devices: Office apps are optimized on first sign-in to look up the local UPN and seamlessly sign-in the user using WS-Trust Kerberos endpoints from the Identity provider. If this is not available, Office throws up a dialog where the user must enter their UPN in the Azure AD home realm discovery page which then redirects to the IDP and can support desktop SSO. This capability is likely needed if you are planning on exposing Office apps through a Virtual Desktop Solution that is not using persistent sessions. In this case, each login is treated like a first time login.

What about 3rd party Identity Providers?

• Acquisition of Primary Refresh Token (PRT, think of this like an internet compatible kerb TGT) when a user logs into an Azure AD Joined or a Hybrid Azure AD Joined device. This is because the Windows client uses WS-Trust to talk to the IDP and get a token for the user which is then used to translate to a PRT. Failure to PRT will manifest in the following issues.
  • Users fail to login into an Azure AD Joined device with a password
  • Users manage to login into a Hybrid Azure AD Joined device but do not get Single Sign On to applications
  • Users manage to login into a Hybrid Azure AD Joined device but fail to access applications protected with device based Conditional Access controls. This is because the PRT also contains the device information that is used to validate against a device based CA policy.
• Windows Hello For Business (Cert Trust) is only supported with ADFS for federated customers. This is because there is tight integration between the windows client to trigger and provision the WHFB Certificate for the users. ADFS (2016+) acts as registration authority for the TPM protected certificates and integrates with a customer's enterprise PKI system. Note that you may not need Cert Trust deployment of Windows Hello For business and can use the Key based deployment. For this, you will need to ensure that you have moved your domain controllers for user account forests up to Windows Server 2016 or higher. Additionally, you will need to ensure that you have an adequate solution that works using an alternate form of credentials.

• Instant registration for Hybrid Azure AD Joined devices for federated customers: The client attempts to register the device post reboot on a domain joined device. If the customer is federated, it optimistically attempts to register the device as the computer account using WS-Trust kerberos endpoint. Subsequently, the sync mechanism (via AAD Connect) keeps this consistent with Azure AD. If the instant registration fails, it falls back to the sync mechanism registering in the cloud, but with a delay (typically 30 minutes). This fall back mechanism is only available if you are on Windows OS build 1803 or higher.  If you are considering Hybrid Azure AD Join with VDI sessions, I'd strongly recommend using an IDP that supports WS-Trust (like ADFS), other wise the delay will impact end user sessions.
• First time SSO to Office apps on domain joined machines: When Office apps run the first time on a domain joined machine (including Office Pro Plus activation), it checks for the local logged in UPN and attempts to use WS-Trust kerberos authentication to seamlessly sign-in the user with no user interaction. If this optimization fails, Office will prompt a dialog where the user will be asked to minimally enter their UPN on the Azure AD sign-in page so that Azure AD can then redirect to the appropriate IDP.
• Legacy Mail Authentication: All legacy mail clients (Outlook 2010 or lower) use HTTP basic authentication to Exchange Online (EXO). Here EXO proxies this back to the federated IDP via WS-Trust. This also includes any mobile clients that uses EAS protocol. The only exception is on latest versions of iOS where the EAS client uses modern authentication (with OAuth) to sign-in the user. Legacy authentication is generally considered a security risk as it exposes password authentication API's to the extranet. It is recommended to move all Office clients over to modern authentication patterns that provide better security.

• 3rd party MFA support integrated with Azure AD Conditional Access: While specific vendors are available within Azure AD for MFA support via custom control in Conditional Access, your MFA provider may not be in the supported list or you may not have the necessary AAD Premium 2 licenses for this or your MFA provider is an on-premises only solution. In this case, you would want to have MFA integrated with your IDP. Integration with Azure AD Conditional Access is supported but your IDP needs to support the ability to respond to a protocol element that requests for MFA and issues additional assertion in the SAML token for AAD to accept it. Some additional notes about this.
  • The 'supportsMFA' flag MUST be set on the federated domain settings. This can be done via AAD PowerShell
  • The IDP must support triggering MFA when AAD sends a request to the IDP. For IDP's that use WS-Fed, it must support "wauth=http://schemas.microsoft.com/claims/multipleauthn". For IDP's that use SAML protocol, it MUST support when the uri "http://schemas.microsoft.com/claims/multipleauthn" is sent in the "<samlp:RequestedAuthnContext>" element as per SAML specification.
  • The IDP must issue the SAML token with the assertion of "http://schemas.microsoft.com/claims/multipleauthn". For WS-Fed, it needs to be added as an attribute assertion of type "http://schemas.microsoft.com/claims/authnmethodsreferences". For SAML protocol, it needs to be added as part of the "<saml:AuthnContext>" element in the SAML token.
  • NOTE: The SAML protocol exchange is not supported in AAD for production yet but is expected to be coming soon.

Summary

• 1/16/2019: Added WHFB cert trust bullet for 3rd party IDP support
• 12/11/2018: Added section on 3rd party IDP support
• 3/15/2018: PTA support for EAS added. Also added a couple of coming soon for first time sign-in to Office apps on Windows.
• 12/18/2017: Added note on Azure SQL
• [Don't remember all the updates I've made as things changed]

• While we’ve always been upfront to our customers to run in a High Availability environment (at least 2 ADFS servers and 2 WAP servers), we see customers using just a single ADFS server and a single WAP server. Note that we see some of our competitors “tout” a simpler solution but conveniently avoid talking about high availability requirements and bury it fairly deep in their documentation. Recently we saw cosmic karma hit one of our customers which took them some time to restore login functionality to Office 365. So, we really wanted to enable our customers to restore login functionality in a shorter time. Note that we still recommend customers to run in a HA configuration as you can then be in a zero-impact situation even if a server goes down.
• For most mid to large organizations, IT admins always want a quick way to go back in case there is some ‘catastrophe’ due to a configuration change gone wrong. The rapid restore tool enables this use case as well.
• Larger IT organizations typically tend to minimize risk by mimicking their production environment in a parallel setup and validate any change prior to rolling it into production. We do this in our own IT organization in Microsoft as well (we have 2 ADFS farms handling millions of login transactions per day). The Rapid Restore tool enables this use case as well where it easy to take a “snapshot” of the existing ADFS farm configuration and clone it to a new machine that is isolated, perform configuration changes and validate them (let's say by using a HOSTS file or private DNS server).

What cool features do we have for this release?

• Supports ADFS 2012R2 and ADFS 2016 (does not support ADFS 2.0 or ADFS 2012)
• Supports both SQL and WID configurations of ADFS
• Supports both self-generated token signing certificates (the default configuration in ADFS) or custom token signing certificates. In the case of custom token signing certificates, we will attempt to export these as well if it exportable. If they are not exportable, then you have to install these on the target machine prior to the restore process.
• Supports export and restore of SSL certificates if the certificate is exportable. Otherwise, you will have to install these on the target machine prior to the restore process.
• Supports storage of the exported backup in a networked folder or better still offers support to store in Azure storage.
• All exported backups are strongly encrypted using the password provided.
• Backups can be done on-demand or can be integrated within a scheduled task on the machine
• Any custom attribute stores, additional authentication providers (for MFA) or local claims provider trusts (ADFS 2016 feature) are also backed up and restored.
• All page customizations are backed up and restored.

How does it work?

#1. Get Ready

import-module ADFSRapidRecreationTool.dll

#2. Create a backup

Backup-ADFS -StorageType "FileSystem" -StoragePath "C:\Users\administrator\testExport\" -EncryptionPassword "password" -BackupComment "Clean Install of ADFS (FS)" -BackupDKM

#3. Restore from backup

Restore-ADFS -StorageType "FileSystem" -StoragePath "C:\uSERS\administrator\testExport\" -DecryptionPassword "password"

Related Links

• Download the “AD FS Rapid Restore Tool”
• TechNet documentation for “AD FS Rapid Restore Tool”

• Native apps on iOS & Android did not support this even with modern authentication. The challenge here was that the browser dialog that the authentication library used on these devices could not access the certificate provisioned to the device (app sandboxing) or the browser dialog did not support client TLS capabilities. This changed with the latest iOS/Android platforms and the authentication support makes full use of these capabilities.
• EAS access to Exchange Online did not support certificate authentication and only supported HTTP basic authentication.
• There was no way in Azure AD to revoke a prior session state when the cert (or the device that stores it) gets compromised. Note that this is very important because while ADFS may do the orignial authentication for modern auth apps, subsequent access tokens are obtained by the app from Azure AD by using a refresh token. In this interaction the request does not go back to ADFS.

• Support for certificate authentication on native apps requires modern authentication. The only exception is EAS for which there is special support in EXO & Azure AD.
• Certificate authentication for browser apps & native apps is only supported for federated tenants that use ADFS or a 3^rd party IDP that supports certificate authentication. [Note: Using certificate authentication via EAS to EXO is supported for managed domains. However, if the end user were using browser or native apps, they would have to use username/password to login]
• The Office app needs to have been updated with the latest modern authentication libraries. Not all of them support yet. Please refer to Office documentation or the Azure AD documentation for the list. For now, the list of apps is called out in the blog post.
• Some of the Office apps (with modern authentication enabled) send 'prompt=login' to Azure AD in their request. By default Azure AD translates this in the request to ADFS to 'wauth=usernamepassworduri' (asks ADFS to do U/P auth) and 'wfresh=0' (asks ADFS to ignore SSO state and do a fresh authentication). For people interested in certificate authentication on these applications, you will need to modify the default Azure AD behavior. Just set the 'PromptLoginBehavior' in your federated domain settings to be 'Disabled'. See https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-faq#BKMK_7 for more information and parameter reference.

How do I configure my ADFS for this?

Ensure pre-requisites are met & configured

• You need ADFS 2012R2 or higher. You will need the Web Application Proxy to support this for extranet access. If you were per-chance using a third party proxy, this is not supported unless they support MS-ADFSPIP protocol document (all the MUST’s).
• Ensure that all the roots and intermediary certificate authorities are populated correctly on all your ADFS and Web Application Proxy servers. ADFS uses the core windows OS support for this functionality and ensuring that you have the trust chain configured is needed for client TLS to work correctly. Most folks will use group policy to do this. TIP: Ensure that roots & intermediaries are placed correctly in their own stores. Having duplicates or improperly placing them will prevent it from working correctly.
• Ensure that port 49443 is reachable between the client device and ADFS as well as the client device and WAP servers. This may require additional firewall configuration to allow this traffic to flow between the client and ADFS/WAP servers. This is the default port at ADFS performs user certificate authentication.
• ADFS 2016 supports a mode that allows user certificate authentication to happen over port 443. This is useful when you have more stringent firewall restrictions. To enable this, you will need your SSL certificate to have certauth.your_adfs_service_name added as an alternate subject name. Also, in this mode, wild card certs with no alt subj name are not supported. To configure this, you can find more info here.
• Ensure that all revocation endpoints are reachable from the client device (inside or outside your network) as well from each of the ADFS/WAP servers.

Enable Certificate Authentication on ADFS

• Open up the ADFS Management Console (MMC plug-in) and enable it on the primary authentication policy for extranet and optionally the intranet. Given most of your devices that use certificate authentication are likely to come only from the extranet, you could just enable it for the extranet. The policy should look like this

• Validate that it works. You can use Windows or iOS/Android devices with a browser to check if it works correctly. After browser validation, you can try one of the supported Office apps listed in the blog post to try it out. You are now set. If you are having issues, refer to #1 to check it out.

Send the necessary claims to Azure AD.

• First we need to get ADFS to pass these claims through to the issuance pipeline by adding the following 2 rules in the “Active Directory” Claims Provider trust. This tells ADFS that any time we are authenticating an Active Directory User, to allow this to pass through.

c:[Type == " http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber"]  => issue(claim = c); c:[Type == " http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer"]  => issue(claim = c);

• Now add the same rules in the Azure AD/Office 365 relying party trust.

c:[Type == " http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber"]  => issue(claim = c); c:[Type == " http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer"]  => issue(claim = c);

Customize the Sign-In experience

Set-AdfsAuthenticationProviderWebContent -Name CertificateAuthentication -DisplayName "Sign in with a certificate"

• Hide the choice entries (don't disable) when loading up.
• Detect the platform using the user agent string that is available to JS
• Auto-click "Cert Auth" link if iOS/Android is detected
• Auto-click or un-hide other elements if a platform outside of iOS/Android is detected

[Optional] Restrict token issuance based on certificate properties

• Ensure that there was a distinct issuer or EKU for the certificate template.
• Pass through these claims as we did in the prior section. The claim type for EKU (issuer is already handled in the prior section) would be “http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku”
• Add issuance authorization rules on the Azure AD/Office 365 relying party trust to restrict access by checking for the specific EKU or issuer if the user had done certificate authentication.

Related Links

• Latency of sync operations
• Object Change trend

Sync Latency

Sync Object Changes

• There are 3 types of roles supported in Connect Health. Owners (can do everything), Contributor (can view and make management changes) and Reader (can just view). These roles can be assigned to users or groups
• Scope of Access: You can do this across all your service instances or assign at a per service instance. Typically you would do only manage access across all service instances. However, as we expand to supporting sync and AD DS, we wanted to support isolation based on customer input.
• By default (even though you cannot see it), all Azure AD Global Administrators in your tenant are owners across all service instances. This is the base policy for Connect Health and cannot be changed.

• Successful logins that can be pivoted by Application, Network Location, Type of Authentication or the server. This can be useful for capacity planning, understanding your load balancing or seeing the trends of how end users login. For example, one of our customers used this to find the optimal down time across their global data centers for maintenance operations. Another customer, used this to see adoption trends for applications.
• Failed logins that can be pivoted by the failure type (e.g. disabled account, username/password failure). This is useful from a security standpoint to understand baselines and observe trends. Changes in trends are likely to need you to dig in further.
• Unique user account logging in via ADFS that can be pivoted by applications.This really gives the perspective of adoption & ROI for running the authentication service as it provides info on how many unique users are logging in through ADFS for your applications.

Top 50 Users with failed Username/Password logins

• I have a complex password that I fat finger quite often especially on mobile devices
• I forgot my password and take a few guesses on what it is
• I make a typo on my user ID

• A badly written app saves the password for a user account and keeps retrying continuously even after the password has expired. (we see this quite often for some of our testing apps internally within Microsoft IT environment). In this case, if you know the app and the user you’d want to contact them and investigate.
•  A malicious user attempting to sign-in to a user’s account with a series of well-known passwords.

The Azure Portal Experience

• Total # of failed username/password logins in the last 30 days
• Average # of users that failed with a bad username/password login on a daily basis. This piece of data gives you a baseline and if you see this jump up, definitely something that you should pay attention to and investigate.

• The total # of failed logins due to a bad username/password on a per-day basis. This great to get a good baseline for your current usage. You will typically see this # decrease during weekends and increase during the week.
• The total # of unique users that failed logins on a per-day basis. This is also great to establish a baseline.

• USER ID: This shows the user id that was used. Note that the value is what the user typed in and in some cases, you will also see the wrong user id being used.
• FAILED ATTEMPTS: This shows the total # of failed attempts for that specific user id. The table is sorted with the most # of failed attempts bubbling to the top so that you can see the top hitters.
• LAST FAILURE: This shows the timestamp when the last failure occurred. This gives you sense if the problem is still occurring or has been fixed.
• LAST FAILURE IP: [Updated on 11/3/16] This shows the last IP address where we saw the failed request originate from. This requires ADFS 2012R2 (with the latest patches) or higher. See picture below for this.

• Failed logins due to disabled accounts or locked out accounts are not included in this. If you'd like a separate report for this and it is important to you, do let us know (info at the end of this post)

1. Establish a baseline of failed logins and the # of users that have failed logins due to bad username/password. Any time you are above your baseline, dig into the top offenders.
2. For the top offenders, check to see how many failed attempts they have. In a 30-day period, you shouldn’t see anything over a value of 100 (or a value that is deemed to not be a security event in your org). If so, it is likely that there is a rogue app and you can track down the rogue app by reaching out to the user. Also, check if the user recently changed their password resulting in the rogue app constantly trying to login with the expired credentials. If you find that it is a rogue app due to an expired password, do let the vendor know as this pattern is essentially vector for an inadvertent DOS attack.
3. If it is not a rogue app, there is potential for malicious activity. You can take additional precautions by
   1. Resetting the password for the user
   2. Enabling MFA at ADFS or in Azure AD with Azure MFA
4. For those of you who use AD Account Lockout Policies or ADFS extranet soft account policy, this also provides you a baseline # to set within your organization.

• Connect Health is targeted at customers who don’t have any or have limited monitoring capabilities on their identity infrastructure. A well monitored identity system is key to having reliable access to applications services such as Office 365.
• You can also run Connect Health alongside SCOM agents as it offers some unique capabilities such as providing insight into logins and additional reports around these.
• As I’d mentioned, you need Azure AD premium for this. For more information, see Getting started with Azure AD Premium. You can also start a free 30-day trial. Check out this link.

• Ability to update alert definitions without requiring admin intervention. Imagine, we released a critical patch to ADFS and want to alert admins on this, we just need to add the alert at the service level and it would just show up for you.
• Ability to look at multiple data points to determine if there is an issue. Often, you need more than a single data point from a server or multiple data points across many servers to determine if it is truly an issue. For example, let’s say your CPU is spiking. To truly alert, we want to look at data points for the last 3 hours before really letting you know if it is an issue. A cloud service truly this makes it possible without putting the burden on you.
• Ability to compare data with other AAD/Microsoft service components. Imagine, wanting to compare the token signing certificate used by ADFS currently with the one stored in the cloud, we can do this all from the service and make it easy.

The Alerts Part

• “Active” shows the number of active alerts. This is what you’d care about the most from an operational standpoint. The # of active alerts could either be alerts or warnings.
• “Resolved from last 24 hours” shows the # of alerts that were generated and resolved. This is useful when you want to review past instances that got fixed or to simply let your manager know ‘Hey, I fixed this issue’.
• As with any part within the new Azure Portal, you can always pin a part to your dashboard by just right clicking on the part and clicking “Pin to dashboard’. This is such a core concept in the new portal that focuses on “Pin the parts that you care about the most”.

• Clicking on any location within this part will open up the Alerts “blade”.

The Alerts Blade

• Within active alerts, the alerts are sorted by when the alert was raised with the most recent one on the top. This way the most recent issues are shown at the top.
• The Typecolumn is to show the severity of the impact. This way, it is clear to you on which needs to be acted upon earlier. Within the service, we deem an alert type to be one of the following:
  • Error: These are issues that you should not be having and we need you to fix as soon as possible as this is end user impacting. One exception is that we also deem the “Health service data is not up to date” to be an error if we are not receiving the critical information (e.g. event logs) that enables the services to process and let you know if you have an issue.
  • Warning: These are things that we don’t believe to be end user impacting yet, but could be a potential issue in the future. Also, an issue where you are not running in optimal configuration is deemed a warning.
• The ‘Scope’column gives you the indication of whether the issue is occurring in a single server, multiple servers or impacts the entire service.
  • If it is a single server, you will see the server name in the scope column (e.g. ADFS-01)
  • If it is the same issue on multiple servers, we opted to collapse this into a single row item because it is very likely it is a similar issue but needs to be fixed on each of these servers. It’s just easier to view and operated in a single context.
  • If it at the service level, you will see the service name as the value in the scope column. (e.g. adfs.contoso.com)
• The ‘Last Detected’column provides a timestamp on when we processed data that still makes us think there is an issue. It is very useful to compare it with the ‘Raised’ column (time when we first detected the issue) and provides you a view into how long the issue has been active.
  • Note: Every time we check and find the same issue, we don’t raise a new issue and merely update the existing alert with the most recent information.
• The ‘Resolved Alerts’section provides you a similar view as active, but you’ll see the ‘Resolved’ column now filled with a value. This list is sorted by the ‘Resolved’ timestamp with the most recent being listed first.
  • By default, this is list is for the alerts resolved in the last 24 hours. However, you can go change the time range by clicking on the ‘Time Range’ Command at the top of the blade

• You can also get email notifications by clicking on the 'Notification Settings' in the command bar on this blade. We opted to provide this at a service instance level (e.g. a specific ADFS farm) versus having one tenant wide setting across all the services. The reason for this is that we've had customers tell us that getting email notifications and its audience can vary based on the service instance. For example, I want email notifications for my production ADFS service but not for my test ADFS service. Also, we took this route because as we add more support for monitoring AAD Connect(sync)/ADDS, the target audience for alerts for these will vary. If you think also would like a setting at the global level, do let us know. Also, don't forget to hit the 'Save' button on the command bar at the top of the blade when making changes.

• Clicking on an ‘Active’ or ‘Resolved’ alert will now take you to the Alert “Blade” which provides you details of the specific alert.

The Alert Blade

• ‘Raised’ & ‘Last Detected’ give you an indication of the length of an ongoing issue. If multiple servers are impacted, we use the earliest timestamp to indicate the time since you first started seeing the issue.
• ‘Issue’ tells you about the issue and where possible it’s impact. This way, as an admin, you clearly understand the impact and can prioritize resolving the issue based on the impact. In some cases, the issue can be due to more than one reason. We will list this out where possible.
• ‘Fix’ as it states is all about giving you instructions, on how to fix the issue. We try to be as prescriptive as possible so that it is easy for the admin to immediately know the instructions to fix this.
• In many cases, there is great content for you to learn or understand issues. We make this available for you right there with ‘Related Links’

How do alerts get raised?

1. A single data point that is received by the service (e.g. EventID==94)
2. Multiple data points of the same type or of different types (e.g. EventID==94 && ADFS.AADRP == Disabled)
3. Multiple data points of the same type across a time range (e.g. CPU)

How do alerts get resolved?

• The conditions that were checked to raise the alert change in a more recent collection of the data, because you made a fix (e.g. the SSL certificate in ADFS servers were updated)
• In some cases, especially event log based alerts, we may not have a positive suppression event. In this case, we auto resolve the alert within a certain period of time. The current service level setting is 72 hours

Can I disable or add an alert?

• Desktop SSO after you have logged in from a domain joined machine.
• Improved experience if you are using devices such as iOS/Android that don’t support seamless Kerberos authentication
• Improved experience if you are using browsers such as Firefox or Chrome on Windows domain joined machines where the browser is not capable of supporting seamless Kerberos authentication. Please note that in some cases/versions of these browsers, they do support Kerberos authentication, but configuration can be quite cumbersome.

Setting the Configuration for Windows 10 Domain Joined devices

How does it work?

1. When ADFS 2012 R2 receives a request over passive protocols such as WS-Fed, SAML or OAuth Authorize endpoints inside your network, it reads the UA string on the HTTP request.
2. It compares the UA string to the list that is configured by the admin (or uses the defaults in the system).
3. If it cannot find a match (‘contains’ match), it then falls back to forms authentication so that the experience is better.

• Desktop SSO from a domain joined machine accessing office resources from inside their corporate network. This was especially relevant with Outlook because in prior versions, the user would need to enter their username & password even if the were logging in from a domain joined machine inside their company network.
• Customers want to enable MFA for extranet access or only have smartcard login available to their users

Today I’m going to blog about password change feature in ADFS. This is not a well-known feature but a very useful one for many organizations.

Password change is the ability for a user (in Active Directory Domain Services) to change their password with knowledge of their old password. Note that this is not password reset where the user does not know their password and needs to use an alternate credential (such as phone or security questions) to reset their password. One such example is Azure Active Directory that provides Self-Service Password Reset capabilities in the cloud that make this simple for end users.  Traditionally users would use their windows domain joined devices inside their corporate devices or they would change password through their on-premises OWA system that provided this functionality. However, with moving to Office 365 and the advent of multiple devices accessing company resources, users cannot really use those same mechanisms anymore. Employees are also not always connected to the corporate network when their password need to be changed which can also prove to be challenging and a help desk call generator.

The feature in ADFS was meant to address the above issues. The use cases that we targeted were the following:

• Expired Password: User is accessing applications such as Office 365 and is logging onto ADFS using their expired password. At this time, ADFS will interrupt the login flow (when password change is enabled) and ask the user to change their password. Once they change their password, they are seamlessly taken back to the login page, enter their changed password and subsequently taken to the application that they were logging into.
• User Must Set Password at next login: Many times when you have a new employee or when a password is reset through a password reset mechanism such as the SSPR feature in Azure AD, users need to change their passwords at the next login into AD.
• Change Password when passwords are soon to expire: We targeted this case specifically for Office 365 applications where ADFS can notify Office apps that a password is set to expire with 14 days (not configurable) and notify the user and now the user can just click on the change password link when this notification appears and can change their password via ADFS.
• Change Password any time by directly going to the password change URL: This is simply a case where the user can bookmark the change password URL and just access this to change their password in AD.

Enabling Change Password in ADFS

By default, this functionality is disabled in ADFS. Change password looks just like another endpoint in ADFS and all you need to do is enable the endpoint. You can use the MMC snapin to enable this.

You can also do this via PSH using the Set-AdfsEndpoint cmdlet.

Once enabled, users can always access the change password page via https://adfs.contoso.com/adfs/portal/updatepassword/. It would look like this

Note: ADFS 2012 R2 required authenticated/registered devices (a.k.a ‘workplace join’) to allow the change of passwords. Based on customer feedback, we have relaxed this constraint and allow this from all devices. You will need to apply 3035025 hotfix on all the ADFS servers.

Enabling password expiry notification

This is a use case that is specifically targeted towards logging into Office 365. Enabling this requires a modification to the ‘issuance’ claims rules for the relying party trust that represents Azure Active Directory. If you used AAD PSH to create this RP trust, you will see this as the “Office 365 Identity Platform” RP trust.

All you need to do is to add the following claims rule to the issuance claims when sending tokens to Azure AD/Office 365.

c1:[Type == "http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime"]

=> issue(store = "_PasswordExpiryStore", types = ("http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime", "http://schemas.microsoft.com/ws/2012/01/passwordexpirationdays", "http://schemas.microsoft.com/ws/2012/01/passwordchangeurl"), query = "{0};", param = c1.Value);

With the above rule we are sending 3 additional claims

• Password Expiration Time: This is the time when the user’s password will expire
• Password Expiration Days: This is the number of days remaining prior to the password expiry
• Password Change URL: This is the URL of the password change URL from ADFS

Hope you found this blog post useful. Feel free to post comments on this blog post to ask questions or leave feedback. You can also tweet to @MrADFS.

--Sam