Active directory

Microsoft Entra lifecycle workflows Part 02 – How to synchronize value for employeeHireDate attribute from on-premises Active Directory ?

In my previous blog post, I explained how we can automate JML (Joiners/Movers/Leavers) process by using Microsoft Entra lifecycle workflows. You can access it using https://www.rebeladmin.com/2022/11/step-by-step-guide-automate-jmljoiners-movers-leavers-process-with-microsoft-entra-lifecycle-workflows/#more-6030 . In this article, I used employeeHireDate Azure AD attribute value to trigger the workflow. At the moment this value cannot be set using UI and can only update using MS Graph. After reading the article, a few readers came back to me and ask how they can sync this attribute from on-premises Active Directory. The employeeHireDate attribute is not available in Microsoft Active Directory so it is not possible to sync value directly. However, it is possible to use a different attribute to record the value and then synchronize it to Azure AD. In this blog post, I am going to demonstrate how we can synchronize value to employeeHireDate attribute from on-premises Active Directory by using Azure AD Connect.

Pre-requisites

Before we start, we need to make sure the following prerequisites are in place.

1. Existing Azure AD Connect Sync – In here I assume you already have a working Azure AD Connect sync. You also can sync values by using Azure AD Connect Cloud sync but in this blog post, I am only focusing on Azure AD Connect sync.

2. Existing Attribute – You can choose any existing Active Directory attribute to record the value for employeeHireDate but it must be a string. In this demo configuration, I am going to use msDS-cloudExtensionAttribute1 Active Directory attribute.

3. Correct Data Format – The value must follow a specific format which is “yyyyMMddHHmmss.fZ“. As a example, if the hire date is 01st Dec 2022 it will be 20221201080000.0Z (In here I used 08 am as the starting time).

Once we have the above prerequisites in place, we can go ahead with the configuration tasks.

In my demo environment, I already configured Microsoft Entra lifecycle workflow to automate certain onboarding tasks. The configuration of the workflow is explained at https://www.rebeladmin.com/2022/11/step-by-step-guide-automate-jmljoiners-movers-leavers-process-with-microsoft-entra-lifecycle-workflows/

Set Department and Manager attributes

My workflow will only trigger for joiners in Sales department. Also as a step in the workflow, the new employee’s manager should receive a TAP (Temporary Access Pass) via email. For that users also need to have a manager assigned before the workflow triggers. As I am syncing users from on-premises Active Directory, I already set department and manager attributes for the new users.

Set employeeHireDate attribute value in on-premises Active Directory

There is no attribute called employeeHireDate in on-premises Active Directory. So we have to use an already existing attribute to record the value for employeeHireDate and then sync this data to Azure AD. This attribute must be a string. For this demo, I have chosen msDS-cloudExtensionAttribute1 attribute to record the value.

The value for employeeHireDate should be recorded in a specific format. Otherwise, the value will not be populated correctly in Azure AD. The format for value is “yyyyMMddHHmmss.fZ“. In my example, I used 06th Dec 2022 as the hire date. So the format of the value should be 20221206080000.0Z (In here I used 08:00 as the starting time).

I went ahead and populate these values for the selected users in on-premises Active Directory.

Step-by-Step Guide: Active Directory Migration from Windows Server 2008 R2 to Windows Server 2022

Windows Server 2008 and Windows Server 2008 R2 Operating system reached the end of their support cycle on the 14th of January 2020. Because of this many organizations wanted to migrate away from these legacy operating systems. End-of-life operating systems have a direct impact on various industry compliances, IT audits, Penetration tests, and so on. Even business does not have a business requirement to upgrade, end of life operating system leaves no choice but to upgrade.

In the past, I did a similar blog post covering migration AD from Windows Server 2008 to Windows Server 2016. Microsoft released Windows Server 2022 recently (Aug 2021) and I thought it good to demonstrate how we can migrate AD from 2008 R2 to the newest. AD migrations from other operating systems (newer than Windows Server 2008R2) also follow a similar process.

What is New in Active Directory?

AD DS’ improvements are bond to its forest and domain functional levels. Upgrading the operating system or adding domain controllers that run Windows Server 2022 to an existing AD infrastructure isn’t going to upgrade the forest and domain functional levels automatically. We need to upgrade it manually once older domain controllers are decommissioned. There was a big difference with Windows Server 2019 when it comes to forest and domain functional levels. With each and every Windows Server release up to Windows Server 2016, had a new forest and domain functional level. But with Windows Server 2019 there were NO new forest or domain functional levels. It is the same with Windows Server 2022. The maximum forest and domain functional level we can choose still is Windows Server 2016.

Active Directory Domain Services was first introduced to the world with Windows Server 2000. For more than 21 years, AD DS helps organizations to manage digital identities. However, the modern access management requirements are complicated. Businesses are using more and more cloud services now. The majority of the workforce is still working from home and accessing sensitive corporate data via unsecured networks. Most software vendors are moving into SaaS model. Cybercrimes are skyrocketing and identity protection is at stake. To address these requirements, we need to go beyond legacy access management. Azure Active Directory is a cloud-based, managed, Identity as a Service (IDaaS) provider, which can provide world-class security, strong authentication, and seamless collaboration. So, it does make sense why there are no significant changes to on-premises AD anymore.

One of the key themes of Windows Server 2022 is “security”. Advanced multi-layer security in Windows Server 2022 provides comprehensive protection against modern threats. This also adds an additional layer of security to roles run on Windows Server 2022 including Active Directory. For more details about these security features please refer to https://docs.microsoft.com/en-us/windows-server/get-started/whats-new-in-windows-server-2022

Active Directory Migration Check List

Migrating FSMO roles to a new server and upgrading forest and domain functional levels doesn’t take more than few minutes but when it comes to migration there are few other things we need to consider. Therefore, I have summarized the AD DS Migration process with the following checklist.

Evaluate the business requirements for Active Directory migration.
Perform an audit on the existing Active Directory infrastructure to verify its health.
Create a detailed implementation plan.
Prepare the physical/virtual resources for the domain controller.
Install Windows Server 2022 Standard/Datacenter.
Patch the servers with the latest Windows updates.
Assign a dedicated IP address to the domain controller.
Install the AD DS role.
Migrate the application and server roles from the existing domain controllers.
Migrate the FSMO roles to the new domain controllers.
Add new domain controllers to the existing monitoring system.
Add new domain controllers to the existing DR solution.
Decommission the old domain controllers (all).
Raise the domain and forest functional levels.
Perform ongoing maintenance (Group Policy review, new-feature implementations, identifying and fixing Active Directory infrastructure issues, and more)

Most Common Questions About Active Directory Migrations

Below I listed some of the most common questions about AD migration,

Can I keep the same IP address for the PDC? Yes, you can. Active Directory fully supports IP address changes. Once FSMO role migration is completed, you can swap the IP addresses of Domain Controllers.
Can I downgrade forest/domain functional levels? If you required you can do so but this is not a recommended approach. From Windows Server 2008 R2, we can downgrade forest/domain functional levels.
Do I need to migrate the DNS role? No, it is part of the AD. When you add a new domain controller, you can make it as a DNS server too.
Do I need to change SYSVOL replication from FRS to DFS? If your domain is built based on Windows server 2008 or Windows Server 2008 R2, you are already using DFS for SYSVOL replication. If you originally migrated from Windows server 2003, it’s more likely you are still using FRS. In that case, before migration, you need to change the SYSVOL replication method from FRS to DFS. I already have a blog post covering this topic https://www.rebeladmin.com/2015/04/step-by-step-guide-for-upgrading-sysvol-replication-to-dfsr-distributed-file-system-replication/
Can I keep Windows 2008 R2 Domain Controllers and upgrade forest and domain functional level to Windows Server 2016? No, you can’t. Before forest and domain functional level upgrade, you need to decommission Windows server 2008 R2 domain controllers.

Design topology

As per the following diagram, the rebeladmin.net domain has two domain controllers:

As explained in the above illustration, The FSMO role holder DC08 is a Windows Server 2008 R2 Domain Controller. The domain and forest functional levels currently operate in Windows Server 2008 R2. A new domain controller with Windows Server 2022(DC22) will be introduced and will be the new FSMO role holder for the domain. Once the FSMO role migration is complete, the domain controller running Windows Server 2008 R2 will be decommissioned. After that, the forest and domain functional levels will be raised to Windows Server 2016.

When you introduce new domain controllers to existing infrastructure, it is recommended that you introduce the forest root level first and then go to the domain tree levels. [Read more…] about Step-by-Step Guide: Active Directory Migration from Windows Server 2008 R2 to Windows Server 2022

Step-by-Step Guide : Migrating AD CS from Windows Server 2008 R2 to Windows Server 2019

Windows Server 2008 R2 extended support ended on 1/14/2020. This raised interest in migrating various Windows Server Roles from Windows Server 2008 R2 to latest. I thought it will be useful to do step-by-step guide to migration AD CS role from Windows Server 2008 R2 to Windows Server 2019. We also can use same steps to migrate AD CS role from Windows Server 2012/2012R2/2016.

Demo Setup

The following figure shows the demo environment that I will be using for this particular task.

As illustrated in above, In the demo environment I have 4 servers/pc. The role of each servers/pc as following,

Host Name	Operating System	Role
REBEL-PDC01	Windows Server 2019	Primary Domain Controller in rebeladmin.com Active Directory Domain
W08CS	Windows Server 2008 R2	Existing Certificate Authority
W19CS	Windows Server 2019	After AD CS configuration is migrated, this server will become the Certificate Authority in rebeladmin.com domain
PC01	Windows 10	Test PC

In here the plan will be to migrate AD CS configuration from existing Windows Server 2008 R2 based certificate authority to newly built server with Windows Server 2019. For the demo purpose the current certificate authority is deployed using single-tier model which means a single server will work as root CA as well as issuing CA. The AD CS migration process mainly contain following steps,

1) Backup configuration of existing Certificate Authority
2) Remove AD CS role from Windows 2008 R2 server
3) Install AD CS role in new Windows 2019 server
4) Restore configuration from previous Certificate Authority
5) Testing

Let’s go ahead and start the process by exporting current CA configuration from W08CS server. [Read more…] about Step-by-Step Guide : Migrating AD CS from Windows Server 2008 R2 to Windows Server 2019

Step-by-Step Guide: Active Directory Migration from Windows Server 2008 to Windows Server 2019

As you may already know, Windows Server 2008 and 2008 R2 products reached End of Extended support on 1/14/2020. So if your Active Directory is running on Windows Server 2008, It is time to look for upgrade options.

In this blog post, I am going to demonstrate how to migrate Active Directory from Windows Server 2008 to Windows Server 2019.

AD Migration task itself is very straight forward. But there are other things you need to consider before you do an AD migration. Below I listed a checklist you can use on many occasions.

Active Directory Migration Check List

• Evaluate business requirement for Active Directory migration
• Perform Audit on Existing Active Directory Infrastructure to make sure there are no existing health issues
• Provide Plan for implementation Process
• Prepare Physical / Virtual resources for Domain Controller
• Install Windows server 2019 Standard / Datacenter
• Patch Servers with latest Windows Updates
• Assign Dedicate IP address to Domain Controller
• Install AD DS Role
• Migrate Application and Server Roles from the Existing Domain Controllers.
• Migrate FSMO roles to new Domain Controllers
• Add New Domain controllers to the Existing Monitoring system
• Add New Domain controllers to the Existing DR Solution
• Decommission old domain controllers
• Raise the Domain and Forest Functional level
• On-Going Maintenance (Group Policy Review, New Features Implementations, Identify and fix active directory infrastructure issues)

If organizations running AD DS, it’s obvious it to have active directory integrated applications. Some of those may use it just for LDAP authentication and some may use advanced integration with modified active directory schema. with active directory migration, some of these applications may require modifications or upgrades to match with the new AD DS version. Therefor before the implementation process, it is important to recognize these active directory integrated applications and evaluate its impact on the migration.

LDAP Connection String Modifications – To use single-sign-on (SSO) with applications it may use LDAP connections to domain controllers. sometimes applications use hardcoded hostnames or IP addresses of domain controllers to define the connections. If domain migration involves IP address changes and Hostname changes, alternation to these records will be needed.

Schema Version Changes – Some legacy applications only support certain versions of active directory schema. This is specifically applying for custom made active directory integrated applications. This is very rare but I have to face these in my active directory migrations projects. Therefore if it’s not well-known applications, check with the application vendor if it supported new AD DS schema version.

Application Migrations – Some organizations have legacy application versions that no longer support or develop by its vendor. There are occasions where these types of issues turn to be bottlenecks for AD Migration projects. Once I was working on AD DS 2003 to AD DS 2012 R2 migration project. The organization had a legacy application that runs on windows server 2000 system. AD DS 2012 R2 does not support windows server 2000-member servers. The vendor who created the application no longer in business. Then we had to users to similar type application which supports new operating systems before we start the Active Directory migrations.

Server Roles/Applications installed on Domain Controllers – In the majority of the cases, once FSMO roles migrated to new domain controllers, old domain controllers will be decommissioned. Even though Microsoft recommends not to install applications or other server roles in domain controllers, people still do it. Some of the common roles installed in domain controllers are DHCP, File Servers, Licensing Server. If existing domain controllers are subject decommission these applications and server roles need to migrate new servers.

Most Common Questions About Active Directory Migrations

In below I listed some of the most common questions I get about AD migration,

1. Can I keep the same IP address for the PDC? Yes, you can. Active Directory fully supports for IP address changes. Once FDMO role migration is completed, you can swap the IP addresses of Domain Controllers.
2. Can I downgrade forest/domain functional levels? Yes, you can do it from Windows server 2008 R2.
3. Do I need to migrate the DNS role? No, it is part of the AD. When you add a new domain controller, you can make it as DNS server too.
4. Do I need to change SYSVOL replication from FRS to DFS? If your domain is built based on Windows server 2008 or Windows Server 2008 R2, you are already using DFS for SYSVOL replication. If you originally migrated from Windows server 2003, it’s more likely you are still using FRS. In that case, after the migration, you can also change the SYSVOL replication method from FRS to DFS. I already have a blog post covering this topic https://www.rebeladmin.com/2015/04/step-by-step-guide-for-upgrading-sysvol-replication-to-dfsr-distributed-file-system-replication/
5. Can I keep Windows 2008 Domain Controllers and upgrade forest and domain functional level to Windows Server 2016? (Windows server 2019 does not have the forest and domain functional level name as Windows server 2019. it is still called Windows server 2016) – No, you can’t. Before forest and domain functional level upgrade, you need to decommission Windows server 2008 domain controllers.

Demo Environment

As per the above figure, rebeladmin.com domain has two domain controllers. The FSMO role holder (REBEL-DC2008) is running a domain controller based on windows server 2008. Domain and forest functional level currently operating at Windows server 2008. A new domain controller with Windows Server 2019 (REBEL-DC2019) will be introduced and it will be the new FSMO role holder for the domain. once FSMO role migration completed, Domain controller running windows server 2008 will be decommissioned. After that forest and domain, the functional level will be raised to the windows server 2019.

Note – When you introduce new domain controllers to the existing infrastructure it is recommended to introduce to the forest root level first and then go to the domain tree levels.

Step-by-Step Guide to Active Directory “Protected Users security group”

The Protected Users security group was introduced with Windows Server 2012 R2 and continued in Windows Server 2019. This group was developed to provide better protection for high privileged accounts from credential theft attacks. Members of this group have non-configurable protection applied. In order to use the Protected Users group, PDC should be running with a minimum of Windows Server 2012 R2 and the client computers should be running with a minimum of Windows 8.1 or Windows 2012 R2.

If a member of this group logs into Windows 8.1, Windows Server 2012 R2, Windows 10, Windows Server 2016 or Windows server 2019, we can expect the following:

• Members of this group cannot use NTLM, digest authentication, or CredSSP for authentication. Plain text passwords are not cached. So, any of the devices using these protocols will fail to authenticate to the domain.

• Kerberos long-term keys not cached. For accounts in this group, the Kerberos protocol verifies authentication at each request (the TGT acquired at log on).

• Sign-in is offline. A cached verifier is not created at sign-in.

For the Protected Users group feature, it is not a must to have a domain or forest functional level run on Windows Server 2012 R2 or higher (Windows Server 2008 is the minimum as Kerberos needs to use AES). The only requirement is to run the PDC emulator FSMO role in the Windows Server 2012 R2 domain controller.

If the AD environment uses Windows Server 2012 R2 or Windows Server 2016 domain functional levels, it provides additional protections with Protected User groups, as:

• No NTLM authentication

• No DES or RC4 encryption in Kerberos pre-authentication

• No delegation using the unconstrained or constrained method

• No Kerberos TGT valid more than 4 hours

[su_note]Service accounts and computers cannot be members of the Protected Users' security group. These accounts can be protected using different features, such as policy silos, which I will explain later in this chapter.[/su_note]

To start with, we can review the Protected Users security group using the following command:

Get-ADGroup -Identity "Protected Users"

The following screenshot shows the output for the preceding command:

We can add users to the Protected Users group using ADAC, ADUC MMC, and PowerShell. This group is located in the default Users container in AD.

In here, we are going to add the user account Adam in to the Protected Users group using the following command:

Get-ADGroup -Identity "Protected Users" | Add-ADGroupMember –Members "CN=Adam,CN=Users,DC=rebeladmin,DC=com"

The first part of the command will retrieve the group and the second part will add the user Adam to it. [Read more…] about Step-by-Step Guide to Active Directory “Protected Users security group”

Active directory

Microsoft Entra lifecycle workflows Part 02 – How to synchronize value for employeeHireDate attribute from on-premises Active Directory ?

Pre-requisites

Set Department and Manager attributes

Set employeeHireDate attribute value in on-premises Active Directory

Step-by-Step Guide: Active Directory Migration from Windows Server 2008 R2 to Windows Server 2022

What is New in Active Directory?

Active Directory Migration Check List

Most Common Questions About Active Directory Migrations

Design topology