Category Archives: Windows Server 2016

Active Directory Managed Service Accounts (PowerShell Guide)

Services Accounts are recommended to use when install application or services in infrastructure. It is dedicated account with specific privileges which use to run services, batch jobs, management tasks. In most of the infrastructures, service accounts are typical user accounts with “Password never expire” option. Since these service accounts are not been use regularly, Administrators have to keep track of these accounts and their credentials. I have seen in many occasions where engineers face in to issues due to outdated or misplace service account credential details. Pain of it is, if you reset the password of service accounts, you will need to update services, databases, application settings to get application or services up and running again. Apart from it Engineers also have to manage service principle names (SPN) which helps to identify service instance uniquely. 

After considering all these challenges Microsoft has introduced Managed Service Accounts with windows server 2008 R2. These accounts got following features and limitations,

No more password management. It uses a complex, random, 240-character password and change that automatically when it reaches the domain or computer password expire date.

It cannot be lock out or use for interactive login. 

One managed service account only can use in one computer. it cannot be share between multiple computers

Simplified SPN Management – System will automatically change the SPN value if sAMaccount details of the computer change or DNS name property change. 

In order to create Managed service account, we can use following command, I am running this from the domain controller.

New-ADServiceAccount -Name "MyAcc1" -RestrictToSingleComputer

In above command I am creating service account called MyAcc1 and I am restricting it to one computer. 

Next step is associate the service account with the Host REBEL-SRV01 where I am going to use this service account. 

Add-ADComputerServiceAccount -Identity REBEL-SRV01 -ServiceAccount "MyAcc1"

Next step is to install service account in the REBEL-SRV01 server. We need active directory PowerShell module for this. We can install it using RSAT tools. Once its ready run the command,

Install-ADServiceAccount -Identity "MyAcc1"

Once it’s done, we can test it using,

Test-ADServiceAccount "MyAcc1"

It is return the value True which means the test is successful. 

From active directory server, we can verify the service account by running
Get-ADServiceAccount "MyAcc1"
Tip – When configure the Manager service account in service make sure to leave the password as empty. You do not need to define any password there as system auto generate the password. 
This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on also follow me on twitter @rebeladm to get updates about new blog posts.

Manage Active Directory Organizational Units (OU) with PowerShell

Similar to any other active directory object, OU structure can manage using Active Directory Administrative Center (ADAC), Active Directory Users and Computers (ADUC) MMC and PowerShell. In this post, I am going to demonstrate how to manage OU structure using PowerShell. 

New Organization Unit can create using New-ADOrganizationalUnit cmdlet. The complete syntax can review using,

Get-Command New-ADOrganizationalUnit -Syntax

As the first step, I am going to create new OU called “Asia” to represent Asia Branch. 

New-ADOrganizationalUnit -Name "Asia" -Description "Asia Branch"

In above command -Description defines description for new OU. When there is no path defined, it will create the OU under the root. We can review the details of the new OU using,

Get-ADOrganizationalUnit -Identity “OU=Asia,DC=rebeladmin,DC=com”


We can add/change values of OU attributes using, 

Get-ADOrganizationalUnit -Identity “OU=Asia,DC=rebeladmin,DC=com” | Set-ADOrganizationalUnit -ManagedBy “Asia IT Team”

Above command will set ManagedBy Attribute to “Asia IT Team”

Tip – When you use ManagedBy attribute, make sure to use existing active directory object for the value. It can be individual user object or group object. If not, command will fail. 

 “Protect from Accidental Deletion” for OU object is nice small safe guard we can apply. It will prevent Accidental OU object deletion. This will be apply by default if you create OU using ADAC or ADUC. 

Get-ADOrganizationalUnit -Identity “OU=Asia,DC=rebeladmin,DC=com” | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

As the next step, I am going to create Sub OU under Asia OU Called “Users”.

New-ADOrganizationalUnit -Name "Users" -Path “OU=Asia,DC=rebeladmin,DC=com” -Description “Users in Asia Branch” -ProtectedFromAccidentalDeletion $true

Above command will create OU called Users under path OU=Asia,DC=rebeladmin,DC=com. It is also protected from accidental deletion. 

Now we have OU structure created and next step is move objects to it. for that we can use Move-ADObject cmdlet. 

Get-ADUser “tuser3” | Move-ADObject -TargetPath “OU=Users,OU=Asia,DC=rebeladmin,DC=com”

Above command will find user “tuser3” and move object to OU=Users,OU=Asia,DC=rebeladmin,DC=com

We also can move multiple object to the new OU. 

Get-ADUser -Filter 'Name -like "Test*"' -SearchBase “OU=Users,OU=Europe,DC=rebeladmin,DC=com” | Move-ADObject -TargetPath “OU=Users,OU=Asia,DC=rebeladmin,DC=com”

In above command, It will first search all the user accounts what is starts with “Test” in OU=Users,OU=Europe,DC=rebeladmin,DC=com and then move all objects it found to new OU path. 

Tip – If you have ProtectedFromAccidentalDeletion enable on objects, it will not allow to move object to different OU. It need to remove before object move.

If we need to remove OU object it can be done using Remove-ADOrganizationalUnit cmdlet. 

Remove-ADOrganizationalUnit “OU=Laptops,OU=Europe,DC=rebeladmin,DC=com”

Above command will remove OU=Laptops,OU=Europe,DC=rebeladmin,DC=com Organization Unit. 

This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on 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 "" -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. 

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. 

Import-Csv "C:\ADUsers.csv" | ForEach-Object {
$upn = $_.SamAccountName + “” 
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 + “” 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) 
This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on 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. 
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.
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. 
-DomainName ""
-SiteName "Default-First-Site-Name"
-ReplicationSourceDC ""
-DatabasePath "C:\Windows\NTDS"
-LogPath "C:\Windows\NTDS"
-SysvolPath "C:\Windows\SYSVOL"




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


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


This parameter defines the FQDN for the active directory domain.


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.


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.


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


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


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

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.
Once its completed it will be a member server of the 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 -DomainMode Windows2016Domain
To upgrade forest function level, you can use following command

Set-ADForestMode -Identity -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.
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 also follow me on twitter @rebeladm to get updates about new blog posts.

Project “Honolulu” for better windows server management experience

If you worked with windows server 2003 or earlier before, I am sure you know how painful it was to install roles and manage those. We had to go through “Add or Remove Windows Components” and many “MMC”. Also, it was recommended to run “Security Configuration Wizard” before install roles as security settings not come default with role installation. To address these difficulties Microsoft introduced “Server Manager” with windows server 2008. It replaced many of wizards’ server 2003 had. It made roles and feature management easy. It was further developed and was available with every server operating system released after windows server 2008. 

Project “Honolulu” from Microsoft is to bring server management in to next level. It is simple but powerful web based interface which can install on windows 10 or windows server 2016. It can use to configure and troubleshoot servers locally or remotely. 

Why it is good? 

1. Simplified one web console for server management – Instead of using multiple MMC to manage resources, Honolulu gives simple web based interface to do it. It also allows to go from simple role install to advanced troubleshooting using same console.  

2. Better interconnection – With Honolulu we can connect windows server 2016, windows server 2012 R2, windows server 2012, Hyper-V 2016/2012R2/2012 in to one console. It also allows to manage failover cluster, hyper-converged environments from same console. Microsoft also working with partners to refine their SDK and extension model.

3. No Agents or No additional configurations – To connect servers to console it is not required agents or any other additional configuration. Only requirement is to have connectivity between gateway server and member servers. 

4. Familiar tools packaged together – web based console allow you to access familiar tools from one place. For an example, you can access Server management, registry editor, firewall tools via console. Before we had to use different methods to open those MMC. This also make it easy to adopt without additional trainings. 

5. Flexible for integration – the design itself welcoming third parties to create modules and integrate it with Honolulu so those applications or services also can manage via same console. 

6. Can use to manage resources via internet – Honolulu web console (web server components) can publish to remote networks and allow engineers to manage servers without using traditional management methods such as VPN, RDP etc. 

Will it replace other management tools? 

At the moment System center and Operation Management Suite (OMS) provides advanced infrastructure management capabilities. Project Honolulu will be complementary to those existing tools but it is not mean to replace in any mean.

Is it got anything to do with Azure? 

No, it is not. It can use with in azure VMs too. Console doesn’t need internet access even to operate. 

When it will release? 

At the moment, it is in technical preview stage. It will be released in year 2018. However, this will not prevent you from testing and providing feedback to improve it further. 

Is it supporting all operating systems?

It can only install on windows server 2016 or windows 10. 


Install Honolulu

Managed node

Managed HCI cluster

Windows Server 2016




Windows Server version 1709



Yes, under insider program

Windows 10




Windows Server 2012 R2




Windows Server 2012




However, if you need to manage windows server 2012 R2 and 2012 you need to install Windows Management Framework (WMF) version 5.0 or higher first as required PowerShell features not available in earlier versions.  

Honolulu has two components.
Gateway – Gateway is to manage connected servers via Remote PowerShell and WMI over WinRM. 
Web Server – It is the UI for Honolulu and users can access it via HTTPS requests. It also can publish to remote networks to allow users to connect via web browser. 
Feedback is important 
The project is still in early stage. We all can contribute to make it perfect. Feel free to submit your feedback via 
Let’s take a look!
Now it’s time to install and play with it. In my demo environment, I have two windows servers 2016 under domain I am going install it on one server and get both servers connected to the console. 
1. Log in to the server as administrator 
3. Double click on .exe to install. In initial window accept the license terms and click Next to continue. 
4. In next window click on tick box to select “Allow project “Honolulu” to modify this machine’s trusted host’s settings”. In same window can select “create a desktop shortcut to launch project “Honolulu”” option to create desktop shortcut. 
5. In next window, we can define a port for management site. For demo purpose, we can use self-sign certificate to allow HTTPS requests. once selections are made, click Install to proceed. 
6. Once installation is completed, double click on shortcut to launch the console.
Note : Console is recommended to use on Edge or Chrome browser. If you using IE, it will give error saying to use it on recommended browser. 
7. In initial window, it will launch a tour to explain project Honolulu. You can either follow it or skip. 
8. In home page, it lists the servers added to console. By default, it has the server it is installed on. 
9. To add new server to the list, click on Add button.
10. Then it shows the list of connections types available. In demo, I am going to add single server so I am going to choose “Add Server Connection” 
11. In next window, it asks the name of the server. please provide server name and click on Submit
You need administrator account to add server to console. In my demo, I am using domain admin account to install and configure Honolulu. If you are in workgroup environment, it will give option to define admin account user name and credentials. 
We also can import multiple servers using .txt file. 
Once its added, it will show up on home page. 
12. In order to manage server, click on the server name in homepage. Then it will bring up the server overview page. 
In this page, it gives real-time information about server performance. It also provides data about server resources. not only that it also gives options to restart or shutdown server, access settings and edit computer name. 
13. Using Device tab, we can view the details about the server hardware resources. 
14. Certificate tab allows to view all the certificates in server. more importantly it shows certificates for local machine and current user in same window. If its traditional method we have to open this using MMC. 
15. Events tab shows all the events generated in server. 
16. Files tab works similar to file explorer. You can create folders, rename folders and upload files to folders using it. unfortunately, you can’t change permissions of the folders at the moment. 
17. Firewall Tab is one of my favorites. Now it is easy to see what each rule does. It also allows to modify rules if needed.  
18. Registry tab is also very useful. Using same console now we can add or modify registry entries. 
19. Roles and Features tab allow you to install/remove roles and features.
20. Services tab work similar to traditional services mmc. It can use to status of services, start services, stop services or change startup mode. 
21. Storage tab helps to manage allocated storage to server. 
In this blog post, I tried to go through each option but I like to encourage you to go and check its capabilities in details. It is easy to implement yet powerful. This marks the end of the blog post and hope it was useful. If you have any questions feel free to contact me on also follow me on twitter @rebeladm to get updates about new blog posts.

When AD password will expire?

In Active Directory environment users have to update their passwords when its expire. In some occasions, it is important to know when user password will expire.

For user account, the value for the next password change is saved under the attribute msDS-UserPasswordExpiryTimeComputed

We can view this value for a user account using a PowerShell command like following, 

Get-ADuser R564441 -Properties msDS-UserPasswordExpiryTimeComputed | select Name, msDS-UserPasswordExpiryTimeComputed 

In above command, I am trying to find out the msDS-UserPasswordExpiryTimeComputed attribute for the user R564441. In output I am listing value of Name attribute and msDS-UserPasswordExpiryTimeComputed


In my example, it gave 131412469385705537 but it’s not mean anything. We need to convert it to readable format. 

I can do it using,

Get-ADuser R564441 -Properties msDS-UserPasswordExpiryTimeComputed | select Name, {[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}

In above the value was converted to datetime format and now its gives readable value. 


We can further develop this to provide report or send automatic reminders to users. I wrote following PowerShell script to generate a report regarding all the users in AD. 

$passwordexpired = $null

$dc = (Get-ADDomain | Select DNSRoot).DNSRoot

$Report= "C:\report.html"


<title>Password Validity Period For $dc</title>


BODY{background-color :LightBlue}



$passwordexpired = Get-ADUser -filter * –Properties "SamAccountName","pwdLastSet","msDS-UserPasswordExpiryTimeComputed" | Select-Object -Property "SamAccountName",@{Name="Last Password Change";Expression={[datetime]::FromFileTime($_."pwdLastSet")}},@{Name="Next Password Change";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}}

$passwordexpired | ConvertTo-Html -Property "SamAccountName","Last Password Change","Next Password Change"-head $HTML -body "<H2> Password Validity Period For $dc</H2>"|

Out-File $Report

     Invoke-Expression C:\report.html

This creates HTML report as following. It contains user name, last password change time and date and time it going to expire. 


The attributes value I used in here is SamAccountName, pwdLastSet and msDS-UserPasswordExpiryTimeComputed. pwdLastSet attribute holds the value for last password reset time and date. 

Hope this was useful and if you have any questions feel free to contact me on also follow me on twitter @rebeladm to get updates about new blog posts. 

Microsoft Advanced Threat Analytics (ATA) – Part 02

In previous part of this blog post I have explain what is ATA and what it is capable of. If you not read it yet you can find it in here

In this part of the post I am going to demonstrate how we can setup ATA. Before we start I like to explain about the demo environment we going to use.

  • This deployment is going to use AD environment which running AD DS 2016 with Forest and Domain functional levels set to Windows Server 2016.
  •  All the servers used in the demo is running with windows server 2016 with latest updates.
  • The Server which is going to use as ATA center has two IP addresses assigned which is and
  • In demo, we are going to use ATA Lightweight Gateway, which will be installed on domain controller directly. There for no port mirroring or separate gateway server required.
  • All the SSL used in deployment are self-signed certificates.
  • We will be using separate service account to connect ATA center with Domain Controller.

First Step of the setup is to get ATA center setup,

Deploying ATA Center

1) Log in to the server which is planned to use as ATA center as domain and or enterprise administrator.

2) Download ATA Center Installation files. It is allowing to use 90 days’ trial as well. 

3) Then run Microsoft ATA Center Setup.exe as Administrator

4) Then In the first window select the relevant language and click Next.

5) In next window, it shows license terms. Read and click on Next to continue

6) Then it asks how you like to know about updates. It is recommended to use Microdot Updates for that. Choose option Use Microsoft Update when I check for updates and then click Next.

7) Then in next window we can define application installation paths, database path, center service IP address and port, SSL certificates, Console IP address. After changes, click on Install to begin the installation. 


8) Once installation finished, it will give option to launch the ATA center. 

9) After launch ATA center, log in to it using the account used to install ATA center. If you need later you can add additional administrator accounts. 

10) As soon as login, it gives window to provide account and domain info to connect to Active directory. Type the service account info you going to use for this. This account is just a typical user account and no additional permission needed (except read permission for all AD objects). once account details entered, click on test connection option to verify the connection and then click on Save


Deploying ATA Lightweight Gateway

1) Log in to the Domain Controller as Domain Admin or Enterprise Admin. 

2) Launch IE and connect to ATA Center URL. It is via the console IP we specify during the ATA center installation. 

3) Log in to ATA center as an Administrator. 

4) In initial page, it will look like following. Click on link Download gateway setup and install the first Gateway


5) In next page, it gives option to download the Gateway Setup files. Click on the download button to download the installation files. 


6) After download completes, extract the file and run the Microsoft ATA Gateway Setup.exe 

7) In language page, select the relevant language and click Next to continue.  

8) Then, it will give the confirmation about deployment type. By default, it detects the type as Lightweight Gateway. Click Next to proceed with the deployment.


9) In next window, we can specify the installation path, SSL certificate information and account details to register the gateway with the ATA center. This account should be a member of ATA administrator group. once all typed in, click on Install to begin the installation. 


10) Once it completed, log in to ATA center and verify if you can see it is successfully registered. 


 ATA Testing

 The easiest way to test the ATA functions is to simulate a DNS reconnaissance attack. In order to do that,

1) Log in to a Domain Computer

2) Open the command prompt and type, nslookup – and press enter. The server name can be replaced by any available domain controller FQDN. 

3) The type ls

4) Then log in to ATA center and check the timeline. There we can see the detected event. 


In here it is only display it as a time line entry, but ATA also allows to send events as email alerts. This configuration can be done using ATA Center > Configuration > Mail Server Settings and Notification Settings


Then, once an event is raised it will sent out an email alert too.


This completes the ATA deployment. If you have any questions feel free to contact me on

Just Enough Administration (JEA)

I was off from blogging for few months as I had to spend my free time on another task which will help all of you more. Stay tuned! More info will share soon. Anyway, I am back on blogging!

JEA was first introduced in 2014 and it was the first approach towards the privilege access management comes with windows server 2016. JEA allows to provides role based privileges instead of full administrative privileges.

Peter is working in 2nd line support. Every month he needs to run script against helpdesk system to create custom report which indicates monthly support tickets progress. In order to do that he log in to helpdesk server and run the script. This script needs to run as administrator of the server. there for he is member of administrator group. However, this is the only task he run on that server with such privileges. Administrator of a server has privileges to do almost anything on the server. if someone else got access to peter’s account, nothing will prevent from changing entire helpdesk system. Using JEA, we can assign just enough privileges for peter to run the scripts from helpdesk host instead of giving administrator privileges. Privileges assigned for peter is only valid for helpdesk server and he cannot run same script from another server.

There are few limitations with JEA,

  • This is fully worked with PowerShell. Not everyone uses PowerShell.
  •  Not supported with each and every management tasks. If you working with script which works with multiple hosts it will difficult to use JEA.
  • Not every third-party application support to work with JEA.

If above limitations stopping you, most suitable solution with be the privileged access management with windows server 2016. Privileged access management will be covered in later blog post.

There are two components in JEA,

PowerShell Session Configuration file

This allows to map users to the hosts. Using it we can map users, groups to specific management roles. It also allows to configure global settings such as virtual accounts and transcription policies. PowerShell Session Configuration file is system specific. There for, configuration settings can apply per-host basis.

Role Capability files

These configuration files specify what actions can perform by the users. It can be a running a script, running a service, running cmdlets or running a program. These tasks can group in to roles and share it with other users. 


In this demo, I am using a system with windows server 2016 with latest updates.

In order to install JEA, we need to log in to the system as local administrator and open the PowerShell.

1. Then run command, Install-Module xJEA. It will ask few questions before it import some modules. Provide appropriate answers to install them.


2. Once its completed we can confirm it using Find-Module –Name xJEA


3. Once JEA module installed and next step is to prepare the environment. It can be done using a script which comes with JEA module. it is located at, C:\Program Files\WindowsPowerShell\Modules\xJea\\Examples\SetupJEA.ps1

This script will,

·         Removes all existing endpoint configuration from the host

·         Configure the DSC Local Configuration Manager to apply changes, then checks every 30 minutes to make sure the configuration has not altered

·         Enables Debug mode

To run the file, navigate to folder C:\Program Files\WindowsPowerShell\Modules\xJea\\Examples\ and run .\SetupJEA.ps1


That’s it! we done the installation and initial configuration. 


JEA installation comes with 3 demo endpoint configurations which we can use as reference to create endpoint. These demo files are located in C:\Program Files\WindowsPowerShell\Modules\xJea\\Examples




configuration Demo1


    Import-DscResource -module xjea

    xJeaToolKit Process


        Name         = 'Process'

        CommandSpecs = @"








    xJeaEndPoint Demo1EP


        Name                   = 'Demo1EP'

        Toolkit                = 'Process'

        SecurityDescriptorSddl = 'O:NSG:BAD:P(A;;GX;;;WD)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)'                                 

        DependsOn              = '[xJeaToolKit]Process'



Demo1 -OutputPath C:\JeaDemo


Start-DscConfiguration -Path C:\JeaDemo -ComputerName localhost -Verbose -wait -debug -ErrorAction SilentlyContinue -ErrorVariable errors

if($errors | ? FullyQualifiedErrorId -ne 'HRESULT 0x803381fa')


    $errors | Write-Error     



start-sleep -Seconds 30 #Wait for WINRM to restart


$s = New-PSSession -cn . -ConfigurationName Demo1EP

Invoke-command $s {get-command} |out-string

Invoke-Command $s {get-command stop-process -Syntax}

# Enter-pssession $s


Remove-PSSession $s


As per the above it only allowed to use following cmdlets.

  • Default JEA configuration
  • Get-Process
  • Get-Service
  • Stop-Process,Name,calc;notepad
  • Restart-Service,Name

According to above Stop-Process cmdlet only can use to stop calculator and notepad process. But it allows to use Restart-Service, Get-Process, Get-Service cmdlets.

In order to run the demo config, navigate to C:\Program Files\WindowsPowerShell\Modules\xJea\\Examples and run .\Demo1.ps1


Once its successfully execute, we can verify the new PowerShell session configuration using,



In order to test, now we need to connect to new endpoint. It can be done using

Enter-PSSession –ComputerName localhost –ConfigurationName demo1ep

In above –ConfigurationName defines the endpoint name.

As soon as I run the command, its connect to the endpoint and change the path to C:\Users\JSA-Demo1EP\Documents


in the backend JEA commands execute using JEA local administrator account. This login details no need to know by end users and its password been reset on daily basis automatically. This user is setup as part of the installation process by JEA.



Once session is connected, we can test it with an allowed command first. According to configuration we allowed to run Get-Service command without any limits.


The use I logged in to this computer is a local administrator. So, I have enough privileges to restart the computer using Restart-Computer cmdlet. But now I am connected to endpoint. According to endpoint config it should not allow me to do so.


Voila! It is working as expected. there are lot of channel9 videos, articles out there which discuss about JEA capabilities. I encourage you to go through them and get more understanding on this great tool. Also through the GitHub you can find lot of sample endpoint configurations.

Hope this post was helpful and if you have any question contact me on

Time Based Group Membership – AD DS 2016

In new AD DS 2016 allows administrators to assign temporally group membership which is expressed by TTL (Time-To-Live) value. This value will add to the Kerberos ticket. This also called as “Expiring-Link” feature. When user assign to a temporally group membership, his login Kerberos ticket granting ticket (TGT) life time will be equal to lowest TTL value he has. 

This feature is not enabled by default. The reason for that is, to use this feature the forest function level must be windows server 2016. Also, once this feature is enabled, it cannot be disabled. 

Let’s see how it works

Enable-ADOptionalFeature ‘Privileged Access Management Feature’ -Scope ForestOrConfigurationSet -Target

tg2 can be replaced with your FQDN.

I have a user called Peter which I need to assign Domain Admin group membership for 15 minutes.

Get-ADGroupMember “Domain Admins” will list the current member of domain admin group. 


Next step is to add the peter to the domain admin group for 15 minutes.

Add-ADGroupMember -Identity ‘Domain Admins’ -Members ‘peter’ -MemberTimeToLive (New-TimeSpan -Minutes 15)


Once its run, we can verify the TTL value remaining for the group membership using,

Get-ADGroup ‘Domain Admins’ -Property member -ShowMemberTimeToLive


Once I log in as the user and list the Kerberos ticket it shows the renew time with less than 15 minutes as I log in as user after few minutes of granting.


Once the TGT renewal come the user will no longer be member of domain admin group. 

hope this was useful and if you have any questions feel free to contact me on

Step-by-Step guide to migrate active directory FSMO roles from windows server 2012 R2 to windows server 2016

Windows server 2016 was released for public (GA) on mid oct 2016. Its exciting time as businesses are already working on migrating their services in to new windows server 2016 infrastructures. In this post, I am going to explain how you can migrate from active directory running on windows server 2012 R2 to windows server 2016 active directory. The same steps are valid for migrating from windows server 2012, windows server 2008 R2 and windows server 2008.

In my demo setup, I have a windows server 2012 R2 domain controller as PDC. I setup windows server 2016 and already added to the existing domain.


Current domain and forest functional level of the domain is windows server 2012 R2.


So, let’s start with the migrate process. 

Install Active Directory on windows server 2016
1. Log in to windows server 2016 as domain administrator or enterprise administrator
2. Check the IP address details and put the local host IP address as the primary DNS and another AD server as secondary DNS. This is because after AD install, server itself will act as DNS server
3. Run servermanager.exe form PowerShell to open server manager (there is many ways to open it) 
4. Then click on Add Roles and Features
5. It will open up the wizard, click next to continue
6. In next window keep the default and click next
7. Roles will be installed on same server, so leave the default selection and click next to continue
8. Under the server roles tick on Active Directory Domain Services, then it will prompt with the features needs for the role. Click on add features. Then click next to proceed
9. On the features windows keep the default and click next
10. In next window, it will give brief description about AD DS, click next to proceed 
11. Then in next window it will give brief description about configuration and click on install to start the role installation process. 
12. Once installation completed, click on promote this server to a domain controller option
13. It will open up the Active Directory Domain Service configuration wizard, leave the option Add a domain controller to existing domain selected and click next.
14. In next window define a DSRM password and click next
15. In next window click on next to proceed
16. In next windows, it asks from where to replicate domain information. You can select the specific server or leave it default. Once done click next to proceed. 
17. Then it shows the paths for AD DS database, log files and SYSVOL folder. You can change the paths or leave default. In demo, I will keep default and click next to continue
18. In next windows, it will explain about preparation options. Since this is first windows server 2016 AD on the domain it will run forest and domain preparation task as part of the configuration process. Click next to proceed.
19. In next window, it will list down the options we selected. Click next to proceed. 
20. Then it will run prerequisite check, if all good click on install to start the configuration process.
21. Once the installation completes it will restart the server. 
Migrate FSMO Roles to windows server 2016 AD
I assume by now you have idea what is FSMO roles. If not search my blog and you will find article explaining those roles. 
There are 2 ways to move the FSMO roles from one AD server to another. One is using GUI and other one is using command line. I had already written articles about GUI method before so I am going to use PowerShell this time to move FSMO roles. If you like to use GUI mode search my blog and you will find articles on it. 
1) Log in to windows server 2016 AD as enterprise administrator
2) Open up the Powershell as administrator. Then type netdom query fsmo. This will list down the FSMO roles and its current owner. 
3) In my demo, the windows server 2012 R2 DC server holds all 5 fsmo roles. Now to move fsmo roles over, type Move-ADDirectoryServerOperationMasterRole -Identity REBELTEST-PDC01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster and press enter
In here REBELTEST-PDC01 is the windows server 2016 DC. If FSMO roles are placed on different servers, you can migrate each and every FSMO roles to different servers. 
4) Once its completed, type netdom query fsmo again and you can see now its windows server 2016 DC is the new FSMO roles owner. 

Uninstall AD role from windows server 2012 R2
Now we moved FSMO roles but we still running system on windows 2012 R2 domain and forest functional levels. In order to upgrade it, first we need to decommission AD roles from existing windows server 2012 R2 servers. 
1) Log in to windows 2012 R2 domain server as enterprise administrator
2) Open the PowerShell as administrator
3) Then type Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartition and press enter. It will ask for local administrator password. provide new password for local administrator and press enter.
4) Once its completed it will restart the server.
Upgrade the forest and domain functional levels to windows server 2016
Now we have the windows server 2012 R2 domain controllers demoted, next step is to upgrade domain and forest functional levels. 
1) Log in to windows server 2016 DC as enterprise administrator 
2) Open PowerShell as administrator
3) Then type Set-ADDomainMode –identity -DomainMode Windows2016Domain to upgrade domain functional level to windows server 2016.  In here is the domain name. 
4) Then type Set-ADForestMode -Identity -ForestMode Windows2016Forest to upgrade forest functional level.
5) Once done you can run Get-ADDomain | fl Name,DomainMode and Get-ADForest | fl Name,ForestMode to confirm new domain and functional level 
Hope this post was useful and if you got any questions feel free to contact me on