Plan Your Identity & Authentication Solution (part 1)

By Ashwin Venugopal -

 



To read part 2, please click here
To read part 3, please click here



Microsoft 365 Identity Models

If you want to plan for user account, you have to understand the two identity models through which you can either maintain your organization's identities only in cloud or you can maintain your on-premises Active Director Domain Services (AD DS) identities to use them for authentication whenever a user access Microsoft 365 cloud services.

Cloud-only Identity

It uses users accounts that exist in Azure AD only and is generally used by small organizations not having an on-premises servers or don't use AD DS to manage local identities. You can easily manage a cloud identity with the help of tools like the Microsoft 365 admin center and Windows PowerShell. 

Hybrid Identity

It is known for using accounts that originates in an on-premises AD DS and have a copy in the Azure AD tenant of a Microsoft 365 subscription. Azure AD connect offers synchronization to an ongoing account while running on an on-premises server, checking for changes in AD DS, and forwarding those changes to Azure AD.

While implementing hybrid identity, you should know that your on-premises AD DS is your authoritative source for account information i.e. the administrative tasks are mostly done on-premises, which are then synchronized to Azure AD and as the original as well as authoritative user accounts are always stored in the on-premises AD DS, you can easily manage your identities with the help of the same tools as AD DS like AD Users and Computers tool instead of using the Microsoft 365 admin center or Office 365 PowerShell to manage the synchronized user accounts in Azure AD.

Authentication for Hybrid Identity

There are two types of authentications for hybrid identity model: 

  1. Managed Authentication- It is handled by Azure AD with the help of a locally-stored hashed version of the password and then sending the credentials to an on-premises software agent to be authenticated by the on-premises AD DS.
  2. Federated Authentication- The client computer requesting authentication can be redirected to another identity provider.  

Managed Authentication

The two types of managed authentication are- Password Hash Synchronization (PHS), where Azure AD performs the authentication itself; and Pass-through Authentication(PTA), where AD DS performs the authentication.

  • Password Hash Synchronization- Here, you can easily synchronize your AD DS user accounts with Microsoft 365 and manage your users on-premises. The user passwords' hashes are synchronized to Azure AD from your AD DS so that the user can have the same password on-premises as well as in the cloud. This is the simplest way know to authenticate AD DS identities in Azure AD and some of the premium features of Azure AD like Identity Protection requires PHS regardless of any selected authentication method.

  • Pass-through Authentication (PTA)- It offers a simple password validation for Azure AD authentication services with the help of a software agent running on one or more on-premises servers to validate the users directly with your AD DS. It permits the users to sign in to on-premises, Microsoft 365 resources, and the applications using their on-premises account as well as password. This configuration can validate users passwords directly against your on-premises AD DS without storing password hashes in Azure AD and can be used for the organizations having security requirements to immediately enforce on-premises user account states, password policies, and logon hours. 

Federated Authentication

It is generally used for large enterprise organizations having more complex authentication requirements where users accounts are managed on-premises and AD DS identities are synchronized with Microsoft 365. Here also, users can have same password on-premises and in the cloud without having to sign-in again to use Microsoft 365.

Federated authentication is also capable of supporting additional authentication requirements like smartcard-based authentication or a third-party multi-factor authentication and is generally used if organizations have an authentication requirement not natively supported by Azure AD.  











To read part 2, please click here
To read part 3, please click here













  

Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more