Identity Services (part 1)

By Ashwin Venugopal -

 



Active Directory Domain Services (AD DS)

AD DS is widely known for providing a variety of business-related and technological benefits by serving as an identity as well as access management solution for on-premises, independently managed isolated environments and the most of its characteristics reflects this underlying premise. There are three main scenarios that involves AD DS and Azure VMs:
  • AD DS deployed to Azure VMs without cross-premises connectivity- This deployment results in the creation of a new forest, with all domain controllers residing in Azure. You can use this approach if you plan implement the Azure-resident workloads hosted on Azure VMs that rely on Kerberos authentication or GROUP Policy but have no on-premises dependencies.

  • Existing on-premises AD DS deployment with cross-premises connectivity to an Azure virtual network where the Azure VMs reside- This scenario uses an existing on-premises AD environment to provide authentication for Azure VM-resident workloads. When considering this design, you should also the latency associated with cross-premises network traffic.

  • Existing on-premises AD DS deployment with cross-premises connectivity to an Azure virtual network hosting additional domain controller on Azure VMs- The main objective of this scenario is to optimize the workload performance by localizing authentication traffic. 

If you are planning to deploy AD DS domain controllers to Azure VMs, you should also consider the following points: 

  • Cross-premises connectivity- If you intend to extend your existing AD DS environment to Azure, then the key design element will be cross-premises connectivity between your on-premises environment and the Azure virtual network. You can set up either the site-to-site Virtual Private Network (VPN) Microsoft Azure ExpressRoute. 

  • Active Directory Topology- In cross-premises scenarios, you should also configure AD DS sites to reflect your cross-premises network infrastructure which readily allows you to localize the authentication traffic and controls the replication traffic between on-premises as well as Azure VM-based domain controllers. Besides, a proper site design also ensures that the domain controllers on the given site handle authentication requests originating from that site.

  • Read-Only Domain Controllers (RODCs)- Some of the customers worry about deploying the writeable domain controllers to Azure VMs due to the security concerns which can be easily mitigated by deploying RODCs instead. RODCs and the writeable domain controllers offers similar user experiences. Although, RODCs lowers the volume of egress traffic and the corresponding charges, but, it is a good option an Azure resident workload does not require frequent write access to AD DS. 

  • Global Catalog Placement- Regardless of your domain topology, you should configure all your Azure VM-based controllers as global catalog servers preventing global catalog lookups from traversing the cross-premises network links, which would negatively affect performance. 

Integrating Linux with AD DS 

There are several ways to integrate Linux VMs with Active Directory and the following three options are based on built-in or freely available components:
  • LDAP Authentication / Authorization- It leverages the compliance of AD with LDAP standards. LDAP Authentication does not allow the users to change their passwords from the Linux client. So, to overcome this short coming, you can initiate a password change process that confirms to your password expiration policy either by providing users an alternative method to change their password or by having an automated password refresh mechanism in place. 

  • Kerberos 5 Authentication / LDAP Authorization- In Kerberos Authentication, NSS (Name Service Switch) still uses LDAP, an dworks the same as with LDAP  Authentication, but PAM (Plugable Authentication Module) makes use of the pam_krb5 module to authenticate against the Kerberos Key Distribution Center (KDC) implemented in AD. This is a popular configuration, because it works with out-of-the box components in a secure way while providing password changing capabilities. 

  • Windbind Authentication / Authorization- It is a more complex solution, requiring a Windbind deamon to run on the Linux systems while providing more advanced technical capabilities, such as support for RPC and NTLM, and does not require any specific components to be installed aon authenticating AD DS domain controllers. Windbind is a part of Samba interoperability suite, which also offers file sharing capabilities using the SMB protocol. If you plan to use SMB, Windbind is a logical choice. 






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