Tag Archives: Active Directory Domain Service

Step-by-Step Guide to setup Active Directory Lightweight Directory Services (AD LDS)

When we talk about active directory we refer it as one service but AD DS attached to many other components as well. DNS, Group Policies, SYSVOL replication are few example for this. Each of these components need to operate well in order to run healthy active directory environment. It doesn’t come easy, its involve with investment on resources, time and skills. In Active Directory Service, the core values are centralized identity management, authentication and authorization capabilities. All these extra components make it easy to archive its core values but same time it also opens up risks such as dependencies and security. Failure or compromise of these components/service will make impact on entire active directory infrastructure. 

Microsoft Windows Core and Nano Servers also count as “Operating Systems”. These doesn’t have fancy GUIs, sparkly applications running. But it is still doing the job of operating system. It allows users to build it from scratch according to their requirements. It also increases the server up time (less updates), reliability, performance and security. Soon after Microsoft releases the First Active Directory version, there were conversation start specially from application developers by requesting a version with pure LDAP capabilities. They wanted to element all these dependencies and management requirements, so they can focus on application development upon core AD functions. After windows server 2003, Microsoft releases Active Directory Application Mode (ADAM) which allowed administrators to run “cut down” version of active directory without group policies, Kerberos, file replication etc. It can run on desktop computer or member server similar to any other windows service. Same time it was providing all core values of Active Directory Service. With Windows server 2008, Microsoft renamed it to “Active Directory Lightweight Directory Services” and allow to install the role using Server Manager. This version provided more control and visibility to administrators to deploy and managed LDS instances. This was continued with all the AD DS versions after that and included in windows server 2016 too. 

LDS installation 

In Windows server 2016 Operating system, it can install using Server Manager. in order to install LDS, User need to log in with local administrator privileges. 

Once log in to the Server Manager, click on Add Roles and Features. Then follow the wizard and select Active Directory Lightweight Directory Services under server roles and proceed with the enabling the role. 

lds1

Once the role is installed, click on Post-Deployment Configuration wizard in Server Manager. LDS can setup two way. One is as a unique instance and other one as a replica of an existing instance. Replica option is similar to clone copy of an existing instance. This is useful especially in development environment where engineers can maintain number of application versions. 

lds2

In next window, we can define name and description for the LDS instance. 

lds3

In next window, we can define the LDS port. By default, LDAP port is set to 389 and SSL port is set to 636. if you running multiple instance these can be change accordingly. 

After that, we can create application directory partition. This allows applications to use this partition as data repository to store application related data. If application is capable of creating partition this step is not necessary and can create relevant partition during the application deployment process. When defining the application partition name, it need to provide as distinguished name format. 

lds4

Next step is to define location to store LDS data files. After that it gives option to specify service account for LDS. If its workgroup environment you can use network service account or local user account for it. if its domain environment it can be AD user account.

lds5

After that we need to define AD LDS administrator account. By default, it selects the user account that used for the installation. If needs it can change to different account or group.

Once we define the administrator account, next step is to define which LDIF file to import. It is a text file which represent data and commands which will use by LDAP instance. It can contain one or more LDIF files. These files are depending on application requirements.  As example if its users’ functionalities the relevant file will be MS-User.LDF.

lds6

This will complete the AD LDS installation and once it completed we can create relevant object and manage them. There is two way to connect to it. one way is to connect using ADSI edit tool. 

lds7

LDS objects also can manage using PowerShell cmdlets. It is same commands which users for AD DS and only difference is to define the DN and Server. 

New-ADUser -name “tidris” -Displayname “Talib Idris” -server ‘localhost:389’ -path “CN=webapp01,DC=rebeladmin,DC=com”

The above command will create user account called tidris on local LDS instance runs on 389. Its DNS path is “CN=webapp01,DC=rebeladmin,DC=com”

Get-ADUser -Filter * -SearchBase "CN=webapp01,DC=rebeladmin,DC=com" -server ‘localhost:389’ 

Above command going to list all the user accounts in LDS instance CN=webapp01,DC=rebeladmin,DC=com

lds8

AD LDS also can install in desktop operating system using windows features option under Program and Features. The installation steps are similar to server version. once enabled the feature, the setup wizard can find under Administrative Tools. 

lds9

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Step-by-Step guide to force replication for an AD Object (PowerShell Guide)

Once object is added to a domain controller, it needs to replicate to all other domain controllers. otherwise users will face issues on login, using AD integrated application and services etc. The replication is depending on many different facts such as replication schedule, intra site connectivity. However sometime it is required to force the replication between domain controllers for fast results. Following script can use to replicate a object from one DC to another forcefully. 

## Replicate Object to From Domain Controller to Another ##

$myobject = Read-Host 'What is your AD Object Includes?'

$sourcedc = Read-Host 'What is the Source DC ?'

$destinationdc = Read-Host 'What is the Destination DC ?'

$passobject = (Get-ADObject -Filter {Name -Like $myobject})

Sync-ADObject -object $passobject -source $sourcedc -destination $destinationdc

Write-Host "Given Object Replicated to" $destinationdc

Above script will ask for few questions, 

1) Name of Object – This no need to be DN. All need is text included in object Name field

2) Source DC – Hostname of Source DC

3) Destination DC – Hostname of Destination DC

Once relevance info provided, the object will be replicated forcefully. 

frep1

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Step-by-Step Guide to work with Group Managed Service Accounts (gMSA) (PowerShell Guide)

In one of my previous blog posts I talked about managed service accounts. Before start on this I really recommend you to read it to have better understanding. It can find on http://www.rebeladmin.com/2018/01/active-directory-managed-service-accounts-powershell-guide/ . As I explained in there one managed service account only can use with one computer. But there are operation requirements which required to share same service account in multiple hosts. Microsoft network load balancer, IIS server farms are good example for these. All the hosts in these server groups required to use same service principal for authentications. Group Managed service accounts provides the same functionalities as managed service accounts but its extend its capabilities to host group levels. This is first introduced with windows server 2012. 

Group managed service accounts got following capabilities,

No Password Management 

Supports to share across multiple hosts

Can use to run schedule tasks (Managed service accounts do not support to run schedule tasks)

It is uses Microsoft Key Distribution Service (KDC) to create and manage the passwords for the gMSA. 

Key Distribution Service was introduced with the windows server 2012. KDS shares a secret (root Key ID) among all the KDS instance in the domain. This value will change periodically. When gMSA required a password, windows server 2012 domain controller will be generated password based on common algorithm which includes root key ID. Then all the hosts which shares the gMSA will query from domain controllers to retrieve the latest password. 

Requirements for gMSA

Windows server 2012 or higher forest level

Widows server 2012 or higher domain member servers (Windows 8 or upper domain joined computers also supported)

64-bit architecture to run PowerShell command to manage gMSA

Tip – gMSA not supported for the Failover Clustering setup. But it is supported for services which is run upon Failover clusters. 

In order to start the configuration process, we need to create KDS root key. This need to run from domain controller with domain admin or enterprise admin privileges. 

Add-KdsRootKey –EffectiveImmediately

Once this is executed, it has default 10 hours’ time limit to replicate it to all the domain controllers and start response to gMSA requests. In testing environment with one domain controller, it can force to remove this waiting time and start to response gMSA immediately. This is NOT recommended for production environment. 

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

After that we can create the first gMSA account. First I have created an AD group “IISFARM” and add all my IIS servers to it. This farm will be using the new gMSA account. 

New-ADServiceAccount "Mygmsa1" -DNSHostName "web.rebeladmin.com" –PrincipalsAllowedToRetrieveManagedPassword "IISFARM"

In above Mygmsa1 is the service account and web.rebeladmin.com is the FQDN of the service. Once its processed we can verify the new account using,

Get-ADServiceAccount “Mygmsa1”

gmsa1

Next step is to install it on server in IIS Farm. It needs active directory PowerShell module to run it. It can be install using RSAT. 

Install-ADServiceAccount -Identity "Mygmsa1"

Tip – If you created the server group recently and add the host, you need to restart the host computer to reflect the group membership. Otherwise above command will fail. 

Once its executed we can test the service account by running,

Test-ADServiceAccount " Mygmsa1"

gmsa2

Similar to managed service account, when you configure the gMSA with any service, leave the password as blank. 

Uninstall Service Account

There can be requirements to remove the managed service accounts. This can be done by executing, 

Remove-ADServiceAccount –identity “Mygmsa1”

Above command will remove the service account Mygmsa1. This is applying to both type of managed service accounts. 

This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts. 

How to Seize FSMO Roles? (PowerShell Guide)

In AD environment, FSMO role seize process only should use in a disaster where you cannot recover the FSMO role holder. It should be using for day to day operations. Some of the FSMO roles (RID, Domain Naming Master, Schema Master) can still afford few hours’ downtime with minimum business impacts. There for do not use the Seize option as the first option if still FSMO role holder can recover or fix. 

Once seize process is completed, the old FSMO role holder should not bring online again. It is recommended to format and remove it from network. In any given time, it is not possible to have same FSMO role appear in two servers in same domain.

In following example, there are two domain controllers in the infrastructure. REBEL-SDC02 is the FSMO role holder and REBEL-PDC-01 is additional domain controller. Due to hardware failure, I cannot bring REBEL-SDC02 online and I need to seize the FSMO roles. 

s1

In order to seize the roles following command can use,

Move-ADDirectoryServerOperationMasterRole -Identity REBEL-PDC-01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force

s2

This command will take few minutes to complete as in background it will try to connect to original FSMO role holder. 

The only change in the command from FSMO role transfer is the -Force at the end. Otherwise its exact same command. You also can seize individual role by using Move-ADDirectoryServerOperationMasterRole -Identity REBEL-PDC-01 -OperationMasterRole <FSMO Role> -Force

In their <FSMO Role> can be replaced by the actual FSMO role value.

Once command completed we can test the new FSMO role holder. 

s3

As we can see REBEL-PDC-01 become the new FSMO role holder. 

This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Create Active Directory User Objects using PowerShell

There are few ways to create user objects in Active Directory. If it’s using GUI, it can be done using Active Directory Administrative Center or Active Directory Users and Computers MMC. If it is using command line, it can be done using windows command-line or PowerShell. In this demo, I am going to show how we can create user object using PowerShell. 

In order to create user object in active directory we can use New-ADUser cmdlet in PowerShell. You can view the full syntax for the command along with the accepted data types using,

Get-Command New-ADUser -Syntax

In order to create a New User account using PowerShell the minimum value you need to pass is -Name. it will create a disabled user account and you still can define values for other attributes later. 

This is a sample which can use to create a user account,

New-ADUser -Name "Talib Idris" -GivenName "Talib" -Surname "Idris" -SamAccountName "tidris" -UserPrincipalName "tidris@rebeladmin.com" -Path "OU=Users,OU=Europe,DC=rebeladmin,DC=com" -AccountPassword(Read-Host -AsSecureString "Type Password for User") -Enabled $true

In the command,

Name – Defines the Full Name

Given Name – Defines the First Name

Surname – Defines the Surname

SamAccountName – Defines the User Name

UserPrincipalName – Defines the UPN for the user account

Path – Defines the OU path. The default location is “CN=Users,DC=rebeladmin,DC=com”

AccountPassword – This will allow user to input password for the user and system will convert it to the relevant data type

Enable – defines if the user account status is enabled or disabled. 

uadd1
 
You can create a user account with minimum attributes such as Name and UPN. Then later can define a password and enable the account. User account cannot enable without a password. To define password can use Set-ADAccountPassword -Identity cmdlet and to enable account can use Enable-ADAccount -Identity cmdlet. 
 
Instead of executing multiple commands to create multiple user objects, we can create a CSV (comma-separated values) file which include data for attributes and use it to create accounts in one go. 
 
In demo I am using following CSV file. 
 
uadd2

Import-Csv "C:\ADUsers.csv" | ForEach-Object {
$upn = $_.SamAccountName + “@rebeladmin.com” 
New-ADUser -Name $_.Name `
 -GivenName $_."GivenName" `
 -Surname $_."Surname" `
 -SamAccountName  $_."samAccountName" `
 -UserPrincipalName  $upn `
 -Path $_."Path" `
 -AccountPassword (ConvertTo-SecureString “Pa$$w0rd” -AsPlainText -force) -Enabled $true
}
 
In above script Import-Csv cmdlet used to import the CSV file created. I have defined parameter $upn = $_.SamAccountName + “@rebeladmin.com” to use for the  -UserPrincipalName value. In script, I have defined a common password for all the accounts using -AccountPassword (ConvertTo-SecureString “Pa$$w0rd” -AsPlainText -force) 
 
uadd3
 
This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Step-by-Step Migration Guide to Active Directory 2016 (PowerShell Guide)

This is my first blog post in 2018. So, first of all Happy New year to my blog readers!

In many occasions, I have written articles about Active Directory Migrations. But still I get lots of emails from readers to clarify things about AD migrations. So, I thought to revisit it by covering most common questions I gets. Also in this blog post, I will show how to do the AD migration only using PowerShell.

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

Active Directory Migration Check List 

Evaluate business requirement for active directory migration 

Perform Audit on Existing Active Directory Infrastructure to verify its health status

Create Plan for implementation Process

Prepare Physical / Virtual resources for Domain Controller

Install Windows server 2016 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 controller to the Existing DR Solution

Decommission old domain controllers 

Raise the Domain and Forest Functional level

On Going Maintenance 

Tips – During audit process you need to verify if your applications will support new AD schema. it is very rare but I have seen legacy applications which is not support newer schema versions. 
 
Also in some scenarios, it is hard to replace primary dc with a DC running with different IP address. AD is supported for IP changes even after FSMO role changes. There for if need you can swap IP addresses after you migrate FSMO roles. 
 
Topology
 
In my demo environment, I have an existing domain controller running with windows server 2012 R2. I am going to migrate it to a windows server 2016 server.
 
mig1
 
In the demonstration, REBEL-WIN-DC01 is the domain controller with windows server 2012 R2 and REBEL-SDC01 is the domain controller with windows server 2016. 
 
Tip – 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.
 
Add Additional Domain Control 
 
As per plan I need to add a new domain controller with windows server 2016 to existing domain first.
 
1) Log in to the Server (Windows server 2016) as a member of local administrators group. 
2) Add server to the existing domain as member. 
3) Log in to domain controller as enterprise administrator.  
4) Verify the static IP address allocation using ipconfig /all.
5) Launch the PowerShell Console as an Administrator
6) Before the configuration process, we need to install the AD DS Role in the given server. In order to do that we can use Following command. 

Install-WindowsFeature –Name AD-Domain-Services -IncludeManagementTools
 
7) After successful role service Installation, next step is to configure the domain controller. It can be done using following PowerShell command. 
 
Install-ADDSDomainController
-CreateDnsDelegation:$false
-InstallDns:$true
-DomainName "rebeladmin.com"
-SiteName "Default-First-Site-Name"
-ReplicationSourceDC "REBEL-WIN-DC01.rebeladmin.com"
-DatabasePath "C:\Windows\NTDS"
-LogPath "C:\Windows\NTDS"
-SysvolPath "C:\Windows\SYSVOL"
-Force:$true 


Argument

Description

Install-ADDSDomainController

This cmdlet will install the domain controller in active directory infrastructure.

-SiteName

This Parameter can use to define the active directory site name.  the default value is Default-First-Site-Name

-DomainName

This parameter defines the FQDN for the active directory domain.

-ReplicationSourceDC

Using this parameter can define the active directory replication source. By default, it will use any available domain controller. But if need we can be specific.

-InstallDns

Using this can specify whether DNS role need to install with active directory domain controller. For new forest, it is default requirement to set it to $true.

-LogPath

Log path can use to specify the location to save domain log files.

-SysvolPath

This is to define the SYSVOL folder path. Default location for it will be C:\Windows

-Force

This parameter will force command to execute by ignoring the warning. It is typical for the system to pass the warning about best practices and recommendations. 

 
Once execute the command it will ask for SafeModeAdministrator Password. Please use complex password to proceed. This will be used for DSRM.
 
After configuration completed, restart the system and log back in as administrator to check the AD DS status. 

Get-Service adws,kdc,netlogon,dns
 
Move FSMO Roles 
 
Now we have additional domain controller and next step is to migrate FSMO roles to the new server. 
 
We can migrate all five FSMO roles to the New domain controller using following powershell command,
 
Move-ADDirectoryServerOperationMasterRole -Identity REBEL-SDC01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
 
In above the REBEL-SDC01 is domain controller running with windows server 2016. Once its completed, we can verify the new FSMO role holder using 
 
Netdom query fsmo
 
mig2

 
Decommission Old Domain Controller 
 
Now we moved FSMO roles over and next step is to decommission old DC which is running with windows server 2012 R2. 
In order to do that, log in to old DC as enterprise administrator and run following powershell command,

Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartition
 
After execute the command it will ask to define password for the local administrator account.
 
mig3
 
Once its completed it will be a member server of the rebeladmin.com domain.
 
Raise Domain and Forest Functional level

After you remove your last domain controller running with windows server 2012 r2 (if its 2012 or 2008 r2 same thing apply) we can raise Domain and Forest Functional level to windows server 2016. You need it to have features comes with AD 2016. 
To upgrade domain functional level, you can use following powershell command
 
Set-ADDomainMode –identity rebeladmin.com -DomainMode Windows2016Domain
 
To upgrade forest function level, you can use following command

Set-ADForestMode -Identity rebeladmin.com -ForestMode Windows2016Forest
 
After the migration completes we still need to verify if its completes successfully.
 
Get-ADDomain | fl Name,DomainMode
 
This command will show the current Domain functional level of the domain after the migration. 
 
Get-ADForest | fl Name,ForestMode
 
Above command will show the current forest functional level of the domain. 
Also, you can use
 
Get-EventLog -LogName 'Directory Service' | where {$_.eventID -eq 2039 -or $_.eventID -eq 2040} | Format-List
 
To search event ID 2039 and 2040 in the “Directory Service” log which will show the forest and domain functional level updates.
 
mig4
 
Event ID 1458 will verify the transfer of the FSMO roles. 

Get-EventLog -LogName 'Directory Service' | where {$_.eventID -eq 1458} | Format-List
 
You can use following to verify the list of domain controllers and make sure the old domain controller is gone. 
 
Get-ADDomainController -Filter * | Format-Table Name, IPv4Address
 
Apart from these you also can go through Directory Service and DNS Logs to see if there’s any issues recorded.
 
This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Step-by-Step guide to create custom Active Directory Attributes

In active directory schema, it is allowed to add custom attributes. In organizations, there are situations where this option is useful. It is most of the time related to application integration requirements with active directory infrastructure. In modern infrastructures, applications are decentralizing identity management. Organization’s identities can sit on active directory as well as applications. Some may in in-house infrastructures and some may even in public cloud. If these applications are integrated with active directory it’s still provides central identity management but it’s not always. Some applications have their own way of handling its user accounts and privileges. Similar to active directory attributes, these applications can also have their own attributes defined by its database system to store the data. These application attributes most of the time will not match the attributes on active directory. As an example, HR system uses employee ID to identify an employee record uniquely from others. But active directory use username to identify a unique record. Each system’s attributes hold some data about the objects even its referring to same user or device. If there is another application which required to retrieve data from both system’s attributes how we can facilitate such without data duplication?

One’s a customer was talking to me regarding similar requirement. They have active directory infrastructure in place. They also maintaining a HR system which is not integrated with active directory. They got a new requirement for an employee collaboration application which required data input in specific way. It has defined its fields in the database and we need to match the data on that order. Some of these required data about users can retrieve from active directory and some of user data can retrieve from the HR system. Instead of keeping two data feeds to the system we decided to treat the active directory as the trustworthy data source for this new system. If active directory need to hold all the required data, it somehow need to store the data comes from HR system as well. The final solution was to add custom attributes to active directory schema and associate it with the user class. Instead of both system operate as data feeds, now HR system pass the filtered values to Active directory and it exports all the required data in CSV format to the application.  

In order to create custom attributes, go to active directory schema snap-in, right click on attributes container and select create attribute

Tip – In order to open active directory schema snap-in you need to run command regsvr32 schmmgmt.dll from the Domain Controller. After that you can use MMC and add active directory schema as snap-in. 

Then system will give a warning about the schema object creation and click OK to continue. 

It will open up a form and this is where we need to define the details about custom attribute. 

1) Common Name – This is the name of the object. It is only allowed to use letters, numbers and hyphen for the CN. 

2) LDAP Display Name – When object is referring in script, program or command line utility it need to call using the LDAP Display name instead of the Common Name. when you define the CN, it will automatically create the LDAP Display name. 

3) X500 Object ID – Each and every attribute in active directory schema has unique OID value. There is script develop by Microsoft to generate these unique OID valves. It can be found in https://gallery.technet.microsoft.com/scriptcenter/Generate-an-Object-4c9be66a#content it also can directly run using following PowerShell command. 

 

#--- 

$Prefix="1.2.840.113556.1.8000.2554" 

$GUID=[System.Guid]::NewGuid().ToString() 

$Parts=@() 

$Parts+=[UInt64]::Parse($guid.SubString(0,4),"AllowHexSpecifier") 

$Parts+=[UInt64]::Parse($guid.SubString(4,4),"AllowHexSpecifier") 

$Parts+=[UInt64]::Parse($guid.SubString(9,4),"AllowHexSpecifier") 

$Parts+=[UInt64]::Parse($guid.SubString(14,4),"AllowHexSpecifier") 

$Parts+=[UInt64]::Parse($guid.SubString(19,4),"AllowHexSpecifier") 

$Parts+=[UInt64]::Parse($guid.SubString(24,6),"AllowHexSpecifier") 

$Parts+=[UInt64]::Parse($guid.SubString(30,6),"AllowHexSpecifier") 

$OID=[String]::Format("{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}",$prefix,$Parts[0],$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6]) 

$oid 

#---

 

4) Syntax – It define the storage representation for the object. It is only allowed to use syntaxes defined by Microsoft. One attribute can only associate with one syntax. In below I listed few common used syntaxes in attributes. 

 

Syntax

Description

Boolean

True or False 

Unicode String

A large string

Numeric String

String of digits

Integer

32-bit Numeric value

Large Integer

64-bit Numeric value

SID

Security Identifier Value

Distinguished Name

String value to uniquely identify object in AD

Along with the syntax we also can define the minimum or maximum values. If it’s not defined it will take the default values. 

In following demo, I like to add a new attribute called NI-Number and add it to the User Class

attri1

As the next step, we need to add it to the user class. In order to do that go to classes container, double click on user class and click on attributes tab. In there by clicking the add button can browse and select the newly added attribute from the list. 

attri2

Now when we open a user account we can see the new attribute and we can add the new data to it. 

attri3

Once data been added we can filter out the information as required. 

Get-ADuser “tuser4” -Properties nINumber | ft nINumber

attri4

Note – To add the attributes to the schema you need to have schema administrator privileges or enterprise administrator privileges. 

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.  

Review Active Directory Domain Service Events with PowerShell

There are different ways to review Active Directory service related logs in a domain controller. Most common way is to review events under Event Viewer mmc. 

event1

We can review events using server manager too. 

event2

We also can use PowerShell commands to review event logs or filter events from local and remote computers without any additional service configurations. Get-EventLog is the primary cmdlet we can use for this task. 

Get-EventLog -List

Above command will list down the details about the log files in your local system including the log file name, max log file size, number of entries. 

Get-EventLog -LogName ‘Directory Service’ | fl

Above command will list down all the events under the log file Directory Service

we also can limit the number of events we need to list down. As an example, if we only need to list down the latest 5 events from the Directory Service log file, we can use,

Get-EventLog -Newest 5 -LogName ‘Directory Service’

We can further filter down it by listing down evens according to entry type. 

Get-EventLog -Newest 5 -LogName ‘Directory Service’ -EntryType Error

Above command will list down first five “errors” in the Directory Service log file.

We also can add time limit to filter events more. 

Get-EventLog -Newest 5 -LogName ‘Directory Service’ -EntryType Error –After (Get-Date).AddDays(-1)

Above command will list down the events with error type ‘error’ with in last 24 hours under Directory Service log.

We also can get the events from the remote computers. 

Get-EventLog -Newest 5 -LogName ‘Directory Service’ -ComputerName ‘REBEL-SRV01’ | fl -Property *

Above command will list down the first five log entries in Directory Service log file from REBEL-SRV01 remote computer. 

event3

We also can extract events from few computers in same time. 

Get-EventLog -Newest 5 -LogName ‘Directory Service’ -ComputerName “localhost”,“REBEL-SRV01”

Above command will list down the log entries from local computer and the REBEL-SRV01 remote computer. 

When it comes to filtering, we can further filter events using the event source. 

Get-EventLog -LogName ‘Directory Service’ -Source “NTDS KCC”

Above command will list down the events with the source NTDS KCC

It also allows to search for the specific event ids. 

Get-EventLog -LogName ‘Directory Service’ | where {$_.eventID -eq 1000}

Above command will list down the events with event id 1000. 

Note – There are recommended list of events which we need to audit periodically to identify potential issues in active directory environment. The complete list is available for review under https://docs.microsoft.com/en-gb/windows-server/identity/ad-ds/plan/appendix-l–events-to-monitor

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.  

Active Directory Lingering objects

If you are maintaining healthy AD infrastructure it is very much unlikely to see lingering objects in AD. Let’s assume a Domain Controller has been disconnected from Active Directory environment and stayed offline more that the value specified tombstone lifetime attribute. Then it was again reconnected to replication topology. The objects which were deleted from Active Directory during the time that particular domain controller stayed offline will be remain as lingering objects on it. 

When object was deleted using one domain controller, it replicates to other domain controllers as tombstone object. it contains few attribute values but it cannot be used for active operations. It remains in Domain Controllers until it reaches the time specify by tombstone lifetime value. Then tombstone object will be permanently deleted from the directory. Tombstone time value is forest wide setting and depend on the operating system running. For operating systems after windows server 2003, default tombstone value is 180 days.  

The problem happens when the Domain Controller with lingering object involve with outbound replication. In such situation, one of following can happen. 

If the destination domain controller has strict replication consistency enabled it will halt the inbound replication from that particular Domain Controller. 

If the destination domain controller has strict replication consistency disabled it will request full replica and will reintroduced to the directory. 

Events 1388, 1988, 2042 are clues for lingering objects in Active Directory Infrastructure. 

Event id

Event Description

1388

Another domain controller (DC) has attempted to replicate into this DC an object which is not present in the local Active Directory Domain Services database. The object may have been deleted and already garbage collected (a tombstone lifetime or more has past since the object was deleted) on this DC. The attribute set included in the update request is not sufficient to create the object. The object will be re-requested with a full attribute set and re-created on this DC. Source DC (Transport-specific network address): xxxxxxxxxxxxxxxxx._msdcs.contoso.com Object: CN=xxxx,CN=xxx,DC=xxxx,DC=xxx Object GUID: xxxxxxxxxxxxx Directory partition: DC=xxxx,DC=xx Destination highest property USN: xxxxxx

1988

Active Directory Domain Services Replication encountered the existence of objects in the following partition that have been deleted from the local domain controllers (DCs) Active Directory Domain Services database. Not all direct or transitive replication partners replicated in the deletion before the tombstone lifetime number of days passed. Objects that have been deleted and garbage collected from an Active Directory Domain Services partition but still exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog servers in other domains in the forest are known as "lingering objects". This event is being logged because the source DC contains a lingering object which does not exist on the local DCs Active Directory Domain Services database.

This replication attempt has been blocked. The best solution to this problem is to identify and remove all lingering objects in the forest. Source DC (Transport-specific network address): xxxxxxxxxxxxxx._msdcs.contoso.com Object: CN=xxxxxx,CN=xxxxx,DC=xxxxxx,DC=xxx Object GUID: xxxxxxxxxxxx

2042

It has been too long since this machine last replicated with the named source machine. The time between replications with this source has exceeded the tombstone lifetime. Replication has been stopped with this source. The reason that replication is not allowed to continue is that the two machine's views of deleted objects may now be different. The source machine may still have copies of objects that have been deleted (and garbage collected) on this machine. If they were allowed to replicate, the source machine might return objects which have already been deleted. Time of last successful replication: <date> <time> Invocation ID of source: <Invocation ID> Name of source: <GUID>._msdcs.<domain> Tombstone lifetime (days): <TSL number in days> The replication operation has failed.

Strict replication consistency

This setting is controlled by a registry key. After windows server 2003, by default this setting is enabled. The key can be found under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters 

lin1

Removing lingering objects

Lingering objects can be remove using:

repadmin /removelingeringobjects <faulty DC name> <reference DC GUID><directory partition>

In the preceding command:

faulty DC name: It represents the DC which contains lingering objects

reference DC GUID: It is the GUID of a DC which contains an up-to-date database that can be used as a reference

directory partition is the directory partition where lingering objects are contained

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.  

Azure AD Connect Staging Mode

Azure AD Connect is the tool use to connect on-premises directory service with Azure AD. It allows users to use same on-premises ID and passwords to authenticate in to Azure AD, Office 365 or other Applications hosted in Azure. Azure AD connect can install on any server if its meets following,

The AD forest functional level must be Windows Server 2003 or later. 

If you plan to use the feature password writeback, then the Domain Controllers must be on Windows Server 2008 (with latest SP) or later. If your DCs are on 2008 (pre-R2), then you must also apply hotfix KB2386717.

The domain controller used by Azure AD must be writable. It is not supported to use a RODC (read-only domain controller) and Azure AD Connect does not follow any write redirects.

It is not supported to use on-premises forests/domains using SLDs (Single Label Domains).

It is not supported to use on-premises forests/domains using "dotted" (name contains a period ".") NetBios names.

Azure AD Connect cannot be installed on Small Business Server or Windows Server Essentials. The server must be using Windows Server standard or better.

The Azure AD Connect server must have a full GUI installed. It is not supported to install on server core.

Azure AD Connect must be installed on Windows Server 2008 or later. This server may be a domain controller or a member server when using express settings. If you use custom settings, then the server can also be stand-alone and does not have to be joined to a domain.

If you install Azure AD Connect on Windows Server 2008 or Windows Server 2008 R2, then make sure to apply the latest hotfixes from Windows Update. The installation is not able to start with an unpatched server.

If you plan to use the feature password synchronization, then the Azure AD Connect server must be on Windows Server 2008 R2 SP1 or later.

If you plan to use a group managed service account, then the Azure AD Connect server must be on Windows Server 2012 or later.

The Azure AD Connect server must have .NET Framework 4.5.1 or later and Microsoft PowerShell 3.0 or later installed.

If Active Directory Federation Services is being deployed, the servers where AD FS or Web Application Proxy are installed must be Windows Server 2012 R2 or later. Windows remote management must be enabled on these servers for remote installation.

If Active Directory Federation Services is being deployed, you need SSL Certificates.

If Active Directory Federation Services is being deployed, then you need to configure name resolution.

If your global administrators have MFA enabled, then the URL https://secure.aadcdn.microsoftonline-p.com must be in the trusted sites list. You are prompted to add this site to the trusted sites list when you are prompted for an MFA challenge and it has not added before. You can use Internet Explorer to add it to your trusted sites.

Azure AD Connect requires a SQL Server database to store identity data. By default a SQL Server 2012 Express LocalDB (a light version of SQL Server Express) is installed. SQL Server Express has a 10GB size limit that enables you to manage approximately 100,000 objects. If you need to manage a higher volume of directory objects, you need to point the installation wizard to a different installation of SQL Server.

What is staging mode? 
 
In a given time, only one Azure AD connect instance can involve with sync process for a directory. But this gives few challenges. 
 
Disaster Recovery – If the server with Azure AD connect involves in a disaster it going to make impact on sync process. This can be worse if you using features such as password pass-through, single-sing-on, password writeback through AD connect.
Upgrades – If the system which running Azure AD connect needs upgrade or if Azure AD connect itself needs upgrade, will make impact for sync process. Again, the affordable downtime will be depending on the features and organization dependencies over Azure AD connect and its operations. 
Testing New Features – Microsoft keep adding new features to Azure AD connect. Before introduce those to production its always good to simulate and see how it will impact. But if its only one instance, it is not possible to do so. Even you have demo environment it may not simulate same impact as production in some occasions. 
 
Microsoft introduced the staging mode of Azure AD connect to overcome above challenges. With staging mode, it allows you to maintain another copy of Azure AD connect instance in another server. it can have same config as primary server. It will connect to Azure AD and receive changes and keep a latest copy to make sure the switch over is seamless as possible. However, it will not sync Azure AD connect configuration from primary server. it is engineer’s responsibility to update staging server AD connect configuration, if primary server AD connects config modified. 
 
Installation
 
Let’s see how we can configure Azure AD connect in staging mode.
 
1) Prepare a server according to guidelines given in prerequisites section to install Azure AD Connect. 
2) Review current configuration of Azure AD connect running on primary server. you can check this by Azure AD Connect | View current configuration 

sta1
 
sta2
 
3) Log in to server as Domain Administrator and download latest Azure Ad Connect from https://www.microsoft.com/en-us/download/details.aspx?id=47594
4) During the installation, please select customize option. 
 
sta3
 
5) Then proceed with the configuration according to settings used in primary server. 
6) At the last step of the configuration, select Enable staging mode: When selected, synchronization will not export any data to Ad or Azure AD and then click install
 
sta4
 
7) Once installation completed, in Synchronization Service (Azure AD Connect | Synchronization Service) we can confirm there is no sync jobs. 
 
sta5
 
Verify data
 
As I mentioned before, staging server allows to simulate export before it make as primary. This is important if you implement new configuration changes. 
 
In order to prepare a staged copy of export, 
 
1) Go to Start | Azure AD Connect | Synchronization Service | Connectors 
 
sta6
 
2) Select the Active Directory Domain Services connector and click on Run from the right-hand panel. 
 
sta7
 
3) Then in next window select Full Import and click OK.
 
sta8
 
4) Repeat same for Windows Azure Active Directory (Microsoft) 
5) Once both jobs completed, Select the Active Directory Domain Services connector and click on Run from the right-hand panel again. But this time select Delta Synchronization, and click OK.
 
sta9
 
6) Repeat same for Windows Azure Active Directory (Microsoft)
7) Once both jobs finished, go to Operation tab and verify if jobs were completed successfully. 
 
sta10
 
Now we have the staging copy, next step is to verify if the data is presented as expected. to do that we need to get help of a PowerShell script.  

 
Param(
    [Parameter(Mandatory=$true, HelpMessage="Must be a file generated using csexport 'Name of Connector' export.xml /f:x)")]
    [string]$xmltoimport="%temp%\exportedStage1a.xml",
    [Parameter(Mandatory=$false, HelpMessage="Maximum number of users per output file")][int]$batchsize=1000,
    [Parameter(Mandatory=$false, HelpMessage="Show console output")][bool]$showOutput=$false
)

#LINQ isn't loaded automatically, so force it
[Reflection.Assembly]::Load("System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089") | Out-Null

[int]$count=1
[int]$outputfilecount=1
[array]$objOutputUsers=@()

#XML must be generated using "csexport "Name of Connector" export.xml /f:x"
write-host "Importing XML" -ForegroundColor Yellow

#XmlReader.Create won't properly resolve the file location,
#so expand and then resolve it
$resolvedXMLtoimport=Resolve-Path -Path ([Environment]::ExpandEnvironmentVariables($xmltoimport))

#use an XmlReader to deal with even large files
$result=$reader = [System.Xml.XmlReader]::Create($resolvedXMLtoimport) 
$result=$reader.ReadToDescendant('cs-object')
do 
{
    #create the object placeholder
    #adding them up here means we can enforce consistency
    $objOutputUser=New-Object psobject
    Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name ID -Value ""
    Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name Type -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name DN -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name operation -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name UPN -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name displayName -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name sourceAnchor -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name alias -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name primarySMTP -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name onPremisesSamAccountName -Value ""
    Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name mail -Value ""

    $user = [System.Xml.Linq.XElement]::ReadFrom($reader)
    if ($showOutput) {Write-Host Found an exported object... -ForegroundColor Green}

    #object id
    $outID=$user.Attribute('id').Value
    if ($showOutput) {Write-Host ID: $outID}
    $objOutputUser.ID=$outID

    #object type
    $outType=$user.Attribute('object-type').Value
    if ($showOutput) {Write-Host Type: $outType}
    $objOutputUser.Type=$outType

    #dn
    $outDN= $user.Element('unapplied-export').Element('delta').Attribute('dn').Value
    if ($showOutput) {Write-Host DN: $outDN}
    $objOutputUser.DN=$outDN

    #operation
    $outOperation= $user.Element('unapplied-export').Element('delta').Attribute('operation').Value
    if ($showOutput) {Write-Host Operation: $outOperation}
    $objOutputUser.operation=$outOperation

    #now that we have the basics, go get the details

    foreach ($attr in $user.Element('unapplied-export-hologram').Element('entry').Elements("attr"))
    {
        $attrvalue=$attr.Attribute('name').Value
        $internalvalue= $attr.Element('value').Value

        switch ($attrvalue)
        {
            "userPrincipalName"
            {
                if ($showOutput) {Write-Host UPN: $internalvalue}
                $objOutputUser.UPN=$internalvalue
            }
            "displayName"
            {
                if ($showOutput) {Write-Host displayName: $internalvalue}
                $objOutputUser.displayName=$internalvalue
            }
            "sourceAnchor"
            {
                if ($showOutput) {Write-Host sourceAnchor: $internalvalue}
                $objOutputUser.sourceAnchor=$internalvalue
            }
            "alias"
            {
                if ($showOutput) {Write-Host alias: $internalvalue}
                $objOutputUser.alias=$internalvalue
            }
            "proxyAddresses"
            {
                if ($showOutput) {Write-Host primarySMTP: ($internalvalue -replace "SMTP:","")}
                $objOutputUser.primarySMTP=$internalvalue -replace "SMTP:",""
            }
        }
    }

    $objOutputUsers += $objOutputUser

    Write-Progress -activity "Processing ${xmltoimport} in batches of ${batchsize}" -status "Batch ${outputfilecount}: " -percentComplete (($objOutputUsers.Count / $batchsize) * 100)

    #every so often, dump the processed users in case we blow up somewhere
    if ($count % $batchsize -eq 0)
    {
        Write-Host Hit the maximum users processed without completion... -ForegroundColor Yellow

        #export the collection of users as as CSV
        Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
        $objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation

        #increment the output file counter
        $outputfilecount+=1

        #reset the collection and the user counter
        $objOutputUsers = $null
        $count=0
    }

    $count+=1

    #need to bail out of the loop if no more users to process
    if ($reader.NodeType -eq [System.Xml.XmlNodeType]::EndElement)
    {
        break
    }

} while ($reader.Read)

#need to write out any users that didn't get picked up in a batch of 1000
#export the collection of users as as CSV
Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
$objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation

 
Save this as .ps1 on C Drive. 
 
1) Open PowerShell and type cd "C:\Program Files\Microsoft Azure AD Sync\Bin" (if your install path is different use the relevant path)
2) Then run .\csexport "myrebeladmin.onmicrosoft.com – AAD" C:\export.xml /f:x in here myrebeladmin.onmicrosoft.com -AAD should replace with your Azure AD connector name. This will export config to C:\export.xml
3) Then type .\analyze.ps1 -xmltoimport C:\export.xml in here analyze.ps1 is the script we saved in beginning of this section. 
4) Then it will create CSV file called processedusers1.csv and it’s contain all changes which will sync to Azure AD. 
 
However, this step is always not required. It can make as primary server without import and verify process. 
 
How to make it as primary Server?
 
In order to make staging server as primary server,
 
1) Go to Start | Azure AD Connect | Azure AD Connect
2) Then click on Configure in next page. 
3) In next page select option Configure staging mode and click Next
 
 
sta11
 
4) In next page provide the Azure AD login credentials for directory sync account. 
5) In next window, untick Enable staging mode and click Next
 
sta12
 
6) In next window select start the synchronization process… and click Configure
 
sta13
 
This completes the process of promoting staging server in to primary. Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.