Plan Directory Synchronization (part 2)

By Ashwin Venugopal -

 




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




Plan for Azure AD Connect

Before starting your planning, you should know the answers of the following questions:
  1. On what server do you want to install Azure AD Connect?
  2. Do you require an Azure AD Connect failover scenario?
  3. Do you want to synchronize one or more Active Directories (or multiple Forests)?
  4. Do you want to synchronize all or only part of your Active Directory?
  5. Do you want to synchronize all object attributes or use specific filters?
  6. Do you want to use advanced configuration features like password synchronization, password writeback, or device writeback?  

You have to consider the following issues with respect to password hash synchronization:

  • To implement password hash synchronization, the user can authenticate with the help of same username and password as on-premises. Azure AD Connect can perform password hash synchronization and store it in the respective user object in Azure AD.

  • However, if you don't want to implement password hash synchronization, then you will have to implement Active Directory Federation Services (AD FS) or Azure AD pass-through authentication to provide single sign-on, otherwise you can provide each user with a separate passwords for their Azure AD account. 

The Microsoft 365 Security Administrator should also include the following steps in his/her planning preparation:

  1. Planning the Azure AD Connect Server
  2. Planning the Azure AD Connect Staging Server
  3. Planning Active Directory Federation Services for Azure AD Connect
  4. Planning the sourceAnchor attribute

Planning the Azure AD Connect Server

The following topics should be considered to decide about the server for installing the tool:

  1. Can be installed on a domain controller, member server, or non-domain joined server.
  2. Supports Windows Server 2008 or later.
  3. You can use the light version of the SQL Server Express to install to the Azure AD Connect Server if your AD have less than 100,000 objects but if there are more than 100,000 objects, then you have to plan for an additional SQL Server to manage the database as well as load.    

No one can have more than one Azure AD Connect server connected to a single Azure AD or Microsoft 365 tenant.

Planning the Azure AD Connect Staging Server

It can install additional server(s) in staging mode which are capable of reading data from all the connected directories, except writing anything on them. As a normal synchronization cycle is used, it always have an updated copy of the identity data.

If the primary server fails due to any disaster, then you can fail over to the staging server in the Azure AD Connect wizard which can be located in a different datacenter having no shared infrastructure with the primary server. You can manually copy any configuration changes made on the primary server to the second server.

You can also have more than one staging server if you want to have multiple backups in different datacenters. 

Planning Active Directory Federation Services For Azure AD Connect

If you are implementing AD FS, then you have to consider the following prerequisites:

  • A Windows Server 2012 R2 or later server for the federation server with remote management enabled. 
  • A Windows Server 2012 R2 or later server for Web Application Proxy Server with remote management enabled.
  • An SSL certificate for the federation service name that you intend to use.
  • Add a domain you plan to use in Microsoft 365 with single sign-on.  

Planning the sourceAnchor Attribute

It can be defined as an attribute immutable during the lifetime of an object which is capable of uniquely identifying an object as being the same object on-premises and in Azure-AD. This attribute can be used for the following scenarios:

  • When a new sync engine server is built, or rebuilt after a disaster recovery scenario, then this attribute can link existing objects in Azure AD with objects on-premises.
  • If you move from a cloud-only identity to a synchronized identity model, then this attribute will help the objects to "hard match" existing objects in Azure AD with on-premises objects.
  • If you are using federation, then this attribute along with the userPrincipalName is used in the claim to uniquely identify a user.   

If you want to decide about the object to use as the sourceAnchor, you can consider the following:

  • For a single forest on-premises, it is recommended to use the msDs-ConsistencyGuid attribute which can also be helpful for DirSync as well as using express settings in Azure AD Connect.

  • If you have multiple forests and you don't plan to move users between forests as well as domains in the same forest, then you can use objectGUID attribute in this case.

  • However, if you are moving users between forests and domains, then you have to find an attribute that can't change or moved with the users during the move. You can also introduce a synthetic attribute (an attribute that can hold something which looks like a GUID) and a custom rule in the sync engine server to create this value according to the objectGUID while updating the selected attribute in AD. 

  • Alternately, you can also pick an existing attribute you know will not change which can be a commonly used attribute employeeID. you should not use the attributes containing a user's name which can change if a person marries or divorces, or the user's position which can also change if a person changes assignments, or attributes with an @-sign; hence, email and userPrincipalName (UPN) cannot be used.  











To read part 1, 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

Deployment (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 3, please click  here Microsoft Sentinel Content Hub Content in Microsoft Sentinel includes any of the following types: Data connectors offer log ingestion from different sources into Microsoft Sentinel. Parsers give log formatting/transformation into ASIM formats, supporting usage across various Microsoft Sentinel content types and scenarios. Workbooks provide monitoring, visualization, and interactively with data in Microsoft Sentinel, highlighting meaningful insights for users.  Analytics rules give alerts that point to relevant SOC actions via incidents.  Hunting Queries are used by SOC teams to proactively hunt for threats in Microsoft Sentinel. Notebooks help SOC teams in using advanced hunting features in Jupyter and Azure Notebooks. Watchlists support the ingestion of specific data for enhanced threat detection and reduced alert fatigue.  Playbooks and Azure Logic Apps Custom Connectors provide featu...
Read more