Pass-Through Authentication (PTA) allows users to sign in to both on-premises and cloud-based applications using the same passwords. Here, you do not have to care about SSO.
Note: No passwords in the cloud, all authentications have to be performed on-premises. Therefore, when users sign in using Azure AD, this feature validates users’ passwords directly against your on-premises Active Directory. See the link below for how this is done https://channel9.msdn.com/Shows/OEMTV/OEM1710
Below are the steps on how PTA works On-premises you have an agent (Microsoft AAD App Proxy Connector) constantly polling your Azure AD to check if there are credentials up to date. It is worth to note that, it is your agent that is constantly contacting Azure AD and not Azure AD contacting your agent, so there are no incoming ports to open.
When the user types its credentials, they are put in a queue in Azure AD and retrieved by the on-premises agent.
The agent verifies them and updates the queue with something like “good creds” or “bad creds”.
Azure AD validates the authentication or prompts the user for its credentials again if they were incorrect.
So, it is great to know that we don’t rely on ADFS to authenticate but still do not have SSO for your domain joined machines.
As at the time of this writing, there is currently a preview feature as described byPierre Audonnet [MSFT]. He explained that there is currently a new preview feature called the Azure AD Connect Seamless SSO. This means you will have SSO functionalities for domain joined machines when they are connected on-premise, just like you had an ADFS farm. See the link for more information https://blogs.technet.microsoft.com/pie/2017/02/06/do-i-really-need-adfs/
Note: The major difference between AD FS and PTA is that, outside the complexity of AD FS, it enables us to support other methods of Password Authentication, 3rd party MFA and Smart Cards Authentication.
You can federate your on-premises environment with Azure Azure Active Directory (AD) and use this federation for authentication and authorisation. This sign-in method ensures that all users authentication occur on-premises. This method allows administrators to implement more rigorous levels of access control.
Federation using Microsoft’s Active Directory Federation Services (AD FS) allows Azure AD to pass authentication requests from service providers such as Office 365 and back to your on-premises AD to provide a single sign-on experience to SaaS applications for your users. This provisioning of user identities from on-premise AD forest to Azure AD is currently handled by Azure AD Connect, previously it was handled by Directory synchronisation (DirSync).
Note: AD FS with DirSync has a has a drawback to this architecture as it can only synchronise with a single Windows Server AD forest and this has been replaced with Active Directory AD Connect.
Note: The major difference between AD FS and PTA here is that, outside the complexity of AD FS is. It enables us to support other methods of Password Authentication, 3rd party MFA and Smart Cards Authentication.
Active directory Federation Services (AD FS):
AD FS provides secure access control and single sign on (SSO) across a wide variety of applications in the cloud such as O365, cloud based SaaS applications, and applications on-premise (corporate network). Here are some benefits of ADFS below;
This service enables your corporate firm to provide SSO functionality to legacy and modern applications both on-premise and in the cloud.
Provides Seamless sign-on option across all platforms with the same credentials.
Enables developers to focus on application development and not on authentication and identity, thereby providing developers with an easy way to authenticate users who reside in the organizations directory system.
AD FS 2016 enables three new options for sign on without passwords, enabling organizations to avoid risk of network compromise from phished, leaked or stolen passwords.
AD FS with MFA – This is one of the methods I will be testing to integrate Azure MFA authentication provider with AD FS. From AD FS 2016, there is a possibility to sign into application ONLY with the Azure MFA code without requiring you to enter your username and password at the initial time. This works by
Setting the Azure MFA as the primary authentication method where the end-user is prompted to username and the OTP code from the Azure Authenticator app
With Azure MFA set as the secondary (additional) authentication method, the user provides primary authentication credentials (using Windows Integrated Authentication, username and password, smart card, or user or device certificate), then sees a prompt for text, voice, or OTP based Azure MFA login.
With the newly integrated built-in Azure MFA adapter, setup and configuration for Azure MFA with AD FS is relatively straight forward.
Now, there is absolutely no need to have the MFA server setup on premise, we can leverage on the capabilities (functionalities) of Azure MFA.
Passwordless Access from Complaint Devices. AD FS provides the ability to sign-on and access control based on the compliance state of the device. Here if the device is non-compliant, users can re-initiate login when the device attribute changes and compliance is re-evaluated
Enable Access only from devices that are managed and compliant.
Enable Extranet Access only from devices that are managed or compliant
Require multi-factor authentication for computers that are not managed or not compliant
Sign-in using Windows Hello for Business: Windows 10 introduces Windows Hello and Windows Hello for Business, replacing user passwords with strong device-bound user credentials protected by a user’s gesture (a PIN, a biometric gesture like fingerprint, or facial recognition). To view these settings, type in the search icon “Windows Hello”, this will display the windows hello settings where these settings can be done.
Access Control Policy Templates in AD FS Note: There are templates to make AD FS configuration and policies effortless without having to know claim language rules. With access control policies, administrators can use built in templates to apply common policies.
Permit intranet access only
Permit everyone and require MFA from Extranet
Permit everyone and require MFA from a specific group
The templates are easy to customize using a wizard driven process to add exceptions or additional policy rules and can be applied to one or many applications for consistent policy enforcement.
ADFS Requirements: Every AD FS and Web Application Proxy has an SSL certificate to services Https to the federation service. Also the Web Application Proxy can have an additional SSL certificates to service requests to published applications.
1. SSL Certifictes: Below are the stated requirements for obtaining a SSL certificate.
It must be publicly trusted (well known CA) for live(production) systems
Server Authentication Enhanced Key Usage (EKU) value must be included in the certificate
Should contain the federation service name eg. Fs.contoso.com in the Subject Alternative Name (SAN).
For user authentication on 443, certificate should contain certauth.<federation service name>”, such as “certauth.fs.contoso.com” in the SAN
For device registration or for modern authentication to on premises resources using pre-Windows 10 clients, the SAN must contain “enterpriseregistration.<upn suffix>” for each UPN suffix in use in your organization.
Since I will not be using a proxy Server, I will ignore the steps needed to request for a license. Note: If you were to deploy the Web Application proxy server, you will have to use the same certificate both on the Federation Server and Web Application proxy server
2. Service Communication Certificate: Here use the same SSL certificate for your Federation Server. Not really required as stated in Microsoft documentation with Azure AD and O365. By default, AD FS configures the SSL certificate provided upon initial configuration as the service communication certificate.
3. Token Signing Certificate This certificate is used to sign issued tokens to relying parties, so relying party applications must recognise the certificate and its associated key as known and trusted. When the token signing certificate changes, such as when it expires and you configure a new certificate, all relying parties must be updated.
Recommendation: Use the AD FS default, internally generated, self-signed token signing certificates. . If you are required to you a publicly signed SSL certificate for this this, see Microsoft documentation.
4. Token Encryption and Decryption Certificates: These certificates are used by claim providers that encrypt tokens issued on AD FS. Recommended: Also use internally generated certificate for this purpose. I you are required to you a publicly signed SSL certificate for this this, see Microsoft documentation.
Note: Certificates that are used for token-signing and token-decrypting/encrypting are critical to the stability of the Federation Service. Customers managing their own token-signing & token-decrypting/encrypting certificates should ensure that these certificates are backed up and are available independently during a recovery event.
5. User License: When using x509 user certificate authentication with AD FS, all user certificates must chain up to a root certification authority that is trusted by the AD FS and Web Application Proxy servers.
For the Hardware Requirements I will not be using internal database for AD FS configuration database and therefore will not be using the SQL Server
Note: The AD FS database size is very small, and AD FS does not put a significant processing load on the database instance. AD FS does, however, connect to the database multiple times during an authentication, so the network connection should be robust.
Due to my environment size, I will be using more than the specified requirement by Microsoft with a recommended requirement of 4GB of RAM and 100GB Disk space. Will be using 4GB of Memory and 200 GB of disk space.
Active Directory Domain Services (AD DS) Requirements. 1. Domain Controller Requirement There for I will be using Windows Server 2016 as it is required for Microsoft Passport for Work.
2. Domain functional level I am using is WS 2016: This is required for client certificate authentication if the certificate is explicitly mapped to a user’s account in AD DS.
Schema Requirements Note: firstly, If it is a new AD FS2016 would require AD 2016 schema with a minimum version of 85. Secondly, if you would like to raise an existing AD FS (FBL) to 2016 level, this would require AD 2016 schema with a minimum of version 85.
Service Account Requirements 1. Group managed service accounts are supported as well as standard account type can be used as a service account for AD FS. The needed permission needed at runtime will be added to the service account automatically when you configure AD FS. 2. The User Rights Assignment required for the AD service account is “Log on as a Service”. 3. The User Rights Assignments required for the ‘NT Service\adfssrv’ and ‘NT Service\drs’ are ‘Generate Security Audits’ and ‘Log on as a Service’.
Domain Requirements AD FS servers must be domain joined. All AD FS servers within a Farm must be deployed in a single domain.
Multi-Forest Requirements: Since we do not have this kind of environment, I will not be discussing this further.
Configuration database requirements: Here are the advantages of using either the WID or SQL Server. Windows Internal database (WID): 1. The artifact resolution profile of SAML 2.0 is not supported in a WID farm. 2. Also, the Token reply detection is not supported in a WID farm (This This functionality is only used only in scenarios where AD FS is acting as the federation provider and consuming security tokens from external claims providers.)
Browser Requirements: When AD FS authentication is performed over a web browser, the following guidelines must be followed.
JavaScript must be enabled.
For SSO, the client browser must be configured to accept cookies
Server Name Indication (SNI) must be supported What is SNI? Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. (src: wiki).
For user and device certificate authentication, the browser must in deed support SSL client certificate authentication.
For seamless sign on using Windows Integrated Authentication, the federation service name (such as https://fs.contoso.com) must be configured in local intranet zone or trusted sites zone.
Network Requirements
Firewall: TCP port 443 should be enabled in bound and if client user certificate authentication (clientTLS authentication using X509 user certificates) is required and the certauth endpoint on port 443 is not enabled, AD FS 2016 requires that TCP port 49443 be enabled inbound on the firewall between the clients. Since I am not using an Web Application Proxy, this is ignored.
DNS: All intranet clients within the organization must be able to resolve the AD FS service name to the AD FS server. Same principle applies (extranet/internet) out the cooperate network.
For Windows Integrated authentication, you must use a DNS A record (not CNAME) for the federation service name.
For user certificate authentication on port 443, “certauth.<federation service name>” must be configured in DNS to resolve to the federation server.
For device registration or for modern authentication to on premises resources using pre-Windows 10 clients, “enterpriseregistration.<upn suffix>”, for each UPN suffix in use in your organization, must be configured to resolve to the federation server or web application proxy.
Since, we are not going to use a load balancer; this scenario requirement will not be considered and discussed.
Permission Requirement:
Local administrative rights on the AD FS server in order to configure. Most times, in a domain wide area, this permission is not sufficient enough and therefore, a Domain administrator’s right must be assigned in order to create and add objects in AD.
In Windows Server, AD FS has a federation service role that acts as an
Identity provider: This means, it authenticates users and provides security tokens to applications that trust AD FS or
Federation consumer: Here, it consumes token from other identity provides and then provides security tokens to applications that trust AD FS.
Note: The function of providing extranet access to applications and services that are secured by AD FS in Windows Server 2012 R2 is now performed by a new Remote Access role service called Web Application Proxy.
Below are the three steps in integrating Windows Active Directory (AD) with Azure Active Directory (AD).
Password hash synchronization (PHS)
Pass-through authentication (PTA) and
Federation (AD FS)
I will be implementing and testing the integration with ADFS SS0 and Pass-Through Authentication.
Federation with single sign-on (SSO) ADFS: This option provides SSO capabilities + MFA option and does not store the password hash in the cloud.
Pass-Through Authentication: This option provides SSO abilities as well but does not have the option to use the MFA and does not store password hash in the cloud.
The Microsoft Hybrid Identity with Azure AD: Microsoft’s identity solutions extend both on-premises and cloud-based capabilities. These solutions create a common user identity for authentication and authorization to all resources, regardless of location. This is referred to as a hybrid identity.
Note: The Azure AD Connect replaces legacy Directory synchronization (DirSync) or Azure AD Sync. Azure AD Connect synchronize your on-premises Active Directory to Azure Active Directory. This allows you to provide a common identity for your users for Office 365, Azure, and SaaS applications integrated with Azure AD. See the video below on how to set up Azure AD Connect and synchronize your on-premises AD to AAD. https://channel9.msdn.com/Shows/OEMTV/OEM1710.
Due to the increase in cybercrime, it is very vital to adopt appropriate security measures to prevent (stall) these threats. Multi-Factor Authentication (MFA), also known as Two-Factor Authentication (2FA) can help us overcome this by preventing unauthorized access to your application.
Microsoft Azure Multi-Factor Authentication helps safeguard access to data and applications by providing an additional layer of security. It can also be used to secure access to on-premises and cloud applications and this helps protect unauthorized access to on-premise and cloud-based applications. See the link below on how this works. Issues resulting in passwords theft and identities being compromised can be mitigated simply by using a second-factor authentication (2FA) https://channel9.msdn.com/Blogs/Azure/Windows-Azure-Multi-Factor-Authentication-Server
New customers may no longer purchase Azure Multi-Factor Authentication as a standalone offering effective September 1st, 2018. Multi-factor authentication will continue to be available as a feature in Azure AD Premium or Microsoft 365 Business licenses
Also, the on-premise setup of MFA Server is no longer possible.
Microsoft
As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments on-premise. https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfaserver-deploy New customers that would like to have MFA implemented for them should use cloud-based Azure Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
Prerequisites for deploying (using) Azure MFA – For cloud-only environment(s) require no pre-requisites for setup. – The hybrid Identity scenario requires Azure AD Connect. Here user identities are synchronized or federated with the on-premises Active Directory Domain Services with Azure Active Directory. – For on-premise legacy application published for cloud access. Azure MFA with Radius Authentication requires a Network Policy Server (NPS).
Note: For Microsoft Office 2010 or earlier, or Apple Mail for iOS 11 or earlier customers would have to upgrade Microsoft Office 2013 or later and Apple mail for iOS 12 or later. Conditional Access is not supported by legacy authentication protocols.
Starting in March of 2019 the phone call options will not be available to MFA and SSPR users in free/trial Azure AD tenants. SMS messages are not impacted by this change. Phone call will continue to be available to users in paid Azure AD tenants. This change only impacts free/trial Azure AD tenants.
Manage B2B collaboration Partners (Guest) credentials and identities.
Azure offers Availability Zones for resiliency and high availability. This ensures Business Continuity solutions in place.
On-Premises and Cloud App Handling: Provides users with seamless access to your apps regardless of the location. This is made possible because the SSO easily provides access to apps like Concur, SAP, Office 365, SharePoint, etc.
It allows policies to be set for secure access to apps by creating application-specific security policies with conditional access with Azure AD. It allows risk assessment from users, locations, and devices to determine whether access should be allowed, verified, restricted, or blocked.
Azure AD Integration: Self-Service BitLocker Recovery
Advanced security and usage reports: This provides information about irregular sign-in attempts, devices used and also gives an overview of the most active use application by users.
On-premise Azure MFA needed to enable 2fa thereby increasing and protecting unauthorized access to on-premise and cloud-based applications. It also integrates conditional access with MFA (based on groups, location, and device status).
Identity Protection and Governance: Enables us to identify and generate reports on a vulnerable account which is not possible using Active Directory only. This help detect sign-in details of Users IP addresses and other suspicious activities
Investigate risk events and perform Privileged Identity management.
With AD FS and Pass-through Authentication available (PTA with SSO), this ensures no password hashes are stored in the cloud.
Azure AD multi-factor authentication and conditional access: This help create improved application security with full management control.
Saves your cost of acquiring hardware and licenses and help IT in focus on Administrative tasks.
Supports regulatory compliance such as ISO, SOC, PCI-DSS, HIPAA, GDPR, etc.
Deprecated (Outdated) Information: Read more https://docs.microsoft.com/en-us/azure/germany/germany-overview-data-trustee
Previously, for German customers, AAD had an isolated datacenter where access to customer data was operated by the data trustee, T-Systems International a subsidiary company of Deutsche Telekom (not Microsoft). It ensures that there is no connection with other Microsoft global cloud services but this has changed as they no longer accept customers Since August 2018.
AAD is a Cloud Identity and Access Management solution that provides directory services, application access management, and advanced identity protection. It’s single sign-on (sso) and Multi-Factor Authentication (MFA) capability helps protect employees from cyberattacks.
The Difference between Azure AD and Windows Active Directory: There is a slight difference as Windows Active Directory is focused on securing Windows desktops and servers on premise while AAD is all about web-based authentication standards such as OpenID and OAuth.
Prices (License) – Editions of AAD: As of this time, this comes in four editions which are as follow;
Office Apps Edition: This licensing edition does not include lots of basic identity and access management functionalities such as MFA with Conditional Access and also does not provide Identity Protection / Governance functionalities such as Risk-based conditional access policies and permission management, Also does not include the Hybrid Identities, Advanced Management of Group Access, etc.
Premium Editions: These license options are available through the Open Program / Volume License Program. This is a simple and cost-effective way to acquire the latest Microsoft technology and this is sub-divided into Premium 1 and Premium 2. – Premium 1: This option also does not include some advanced functionalities of Identity Protection and Governance in determining risks and vulnerable accounts and Privileged Identity Management (PIM) etc. – Premium 2: This license model is recommended as it has all the advanced functionalities such asIdentity and Access Management on-premise, cloud, and hybrid environments. It also offers adds reports as shown below.
Sign in from IP addresses and suspicious activities
Irregular sign-in devices used and show users that most actively use an application.
Alerts in the form of emails to Azure AD administrators when anomalous behaviors are detected.
It might interest you to know that, Microsoft offers open programs to Government Organization and Educational Institution which allows the initial purchase of 5 or more licenses and this depends on your eligibility. Here are the different license programs available for the open program.
Open Value: This program is basically for small and medium scale companies with relatively few desktops. It also has software assurance, technology training courses, and product support, etc. The license is valid over the total years of agreement (meaning the total cost of the license can be spread through the entire period of subscription).
Open Value Subscription: It provides the lowest budget upfront of the open program options with the flexibility to reduce the total licensing cost in the future if the need decreases. Here the software is not purchased but subscribed to and the monthly costs are lower.
Open License: One-time payment but grants unlimited use of software (i.e., upfront payment in a large sum). In this program, the five license minimum initial purchase is waived. This is not ideal as it is difficult to tell how many licenses and updates would be needed in the coming years. This has technical support included.
Preboot execution environment (commonly known as PXE) is used to boot a device or virtual machine over a network. You can use PXE to achieve the following scenarios and this is used to remotely install a guest operating system over a network without needing the operating system installation media.
Hyper-V currently has two generations of VM hardware which are; – Generation 1: These VMs has a legacy version of Hyper-V, and has a little bit of overhead when it comes to using to PXE boot because it uses the legacy BIOS, while – Generation 2: Hyper-V machine is a UEFI-based VMs.
Note: A machine configured with UEFI will use bootx64wdsmgfw.efi on the WDS server when starting the boot. A legacy boot will use bootx64wdsnbp.com.
The generation of the Hyper-V virtual machine matters, because PXE uses different boot files depending on if the machine boots either using Legacy BIOS or UEFI. It is recommended to use Generation 2 VMs and if you do not feel the need to, this could be because you have not yet enabled UEFI in your environment.
Generation 2 VM Installation – In the Installation Option – Select Install an Operating System later
Click on Next or finish.
Note: When you click on next, it will show you the summary screen of the VM Installation, next click on finish Hardware configuration to support PXE – Ensure you have your network at the top.
Ensure under Network Adapter – Under Advanced features that the checkbox is selected for Protected Network (This absolutely depends on your environment need).
