RebelAdmin.com - The Tech Blog You Need
RebelAdmin.com - The Tech Blog You Need
  • Active Directory
  • Azure Active Directory
  • Azure
  • Windows Server
  • Contact us
Browsing Tag
active directory domain service
Active Directory Azure Active Directory

Mastering Active Directory, Second Edition Released!

August 10, 2019 No Comments

As most of you were aware, I published my book "Mastering Active Directory" back in, 2017. When I released it, I had my doubts! It was my first book even though I was writing to blogs for many years. But over the last 2 years, I had many positive feedbacks. Thousands of people all around the global read this book. Lots of them requested another book. So Yes! I heard it loud and clear. 

I glad to announce the public release of my second book, "Mastering Active Directory, Second Edition" today. It is available for purchase worldwide now.

I also take this opportunity to thanks all my readers who believed in me. It is you who encouraged me to release another edition this soon. 

What Is new in the second edition? 

The new content for this edition is covering,

• Tips to Design your Hybrid AD environment by evaluating business and technology requirements 

• Deep dive into different authentication methods which can use in Hybrid AD environment

• How to protect sensitive data in a hybrid environment using Azure Information Protection

• Learn about protecting identities in Hybrid AD environment 

• Integrate with Azure Active Directory and Manage identities in Hybrid Environment using Azure Active Directory PowerShell for Graph module

Book Name: Mastering Active Directory, Second Edition

ISBN: 978-1789800203

Number of Pages: 786

Publisher: Packt Publishing

Book is available in paperback and kindle format.

https://www.amazon.com/dp/178980020X/ref=olp_product_details?_encoding=UTF8&me=

It also can access via subscriptions, 

https://www.packtpub.com/cloud-networking/mastering-active-directory-second-edition

Continue reading
Reading time: 1 min
Written by: Dishan M. Francis
Active Directory

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

July 14, 2019 No Comments

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

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

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

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

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

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

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

• No NTLM authentication

• No DES or RC4 encryption in Kerberos pre-authentication

• No delegation using the unconstrained or constrained method

• No Kerberos TGT valid more than 4 hours

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

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

Get-ADGroup -Identity "Protected Users"

The following screenshot shows the output for the preceding command:

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

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

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

The first part of the command will retrieve the group and the second part will add the user Adam to it.

Continue reading
Reading time: 3 min
Written by: Dishan M. Francis
Active Directory MICROSOFT

Step-by-Step Guide to Migrate from Active Directory 2012 R2 to Active Directory 2019 (PowerShell Guide)

January 28, 2019 No Comments

Windows server 2019 was available for public (GA) from early oct 2018. In past i have written many articles about domain migrations by covering different Active Directory versions. So, it is time me to write about AD 2019 migrations. In this demo I am going to demonstrate how to migrate from Active Directory 2012 R2 to Active Directory 2019. The same procedure is going to apply for any AD version from Windows Server 2008.   

Migration itself is very straight forward task. 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.

• Evaluate business requirement for active directory migration 

• Perform Audit on Existing Active Directory Infrastructure

• Provide Plan for implementation Process

• Prepare Physical / Virtual resources for Domain Controller

• Install Windows server 2019 Standard / Datacenter

• Patch Servers with latest Windows Updates

• Assign Dedicate IP address to Domain Controller

• Install AD DS Role

• Migrate Application and Server Roles from the Existing Domain Controllers.

• Migrate FSMO roles to new Domain Controllers

• Add New Domain controllers to the Existing Monitoring system

• Add New Domain controllers to the Existing DR Solution

• Decommission old domain controllers 

• Raise the Domain and Forest Functional level

• On Going Maintenance 

As per the above figure therebeladmin.com domain has two domain controllers.  In here, the FSMO role holder is running windows server 2012 R2. Domain and forest functional level currently operating at Windows server 2012 R2. A new domain controller with Windows server 2019 will be introduce and it will be the new FSMO role holder for the domain. once FSMO role migration completed, Domain controller running windows server 2012 R2 will be decommissioned. After that forest and domain function level will raised to the windows server 2019. 
In the demonstration, REBEL-DC2012 is the domain controller with windows server 2012 R2 and REBEL-DC2016 is the domain controller with windows server 2019. 
 
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.
 
 
1. Log in to the Server 2019 as a member of local administrators group. 
2. Add server to the existing domain as member
 
 
3. After restart, log in to the server as Enterprise Administrator
4. Assign static IP address to the server
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. Configure the new server as additional domain controller.
 
Install-ADDSDomainController
-CreateDnsDelegation:$false
-NoGlobalCatalog:$true
-InstallDns:$true
-DomainName "therebeladmin.com"
-SiteName "Default-First-Site-Name"
-ReplicationSourceDC "REBEL-DC2012.therebeladmin.com"
-DatabasePath "C:\Windows\NTDS"
-LogPath "C:\Windows\NTDS"
-NoRebootOnCompletion:$true
-SysvolPath "C:\Windows\SYSVOL"
-Force:$true
 
 
There are no line breaks for the command and I have listed it as above to allow readers to identify on the parameters clearly.
 

Argument

Description

Install-ADDSDomainController

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

-NoGlobalCatalog

If you do not need to create the domain controller as global catalog server, this parameter can use. By default, system will enable global catalog feature.

-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.

Once execute the command it will ask for SafeModeAdministrator Password. Please use complex password to proceed. This will be used for DSRM.

8. After configuration completed, restart the system and log back in as administrator to check the AD DS status. 

Get-Service adws,kdc,netlogon,dns

Will confirm the status of the AD DS service. 

Get-ADDomainController -Filter * |  Format-Table Name, IPv4Address, Site

Will list down the domain controllers along with the IP address and Sites it belongs to.

9. Migrate all five FSMO roles to the New domain controller using following command,

Move-ADDirectoryServerOperationMasterRole -Identity REBEL-DC2019 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

In above the REBEL-DC2019 is domain controller running with windows server 2019. 

Once its completed, we can verify the new FSMO role holder using 

Netdom query fsmo

10. The new step of the process is to decommission the old windows domain controller which running with windows server 2012 R2. To do that execute the following command as enterprise administrator from the relevant DC. 

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 therebeladmin.com domain.

11. Next step is to raise the domain and forest functional level to windows server 2019. To do that can use the following commands.

To upgrade domain functional levels

Set-ADDomainMode –identity therebeladmin.com -DomainMode Windows2016Domain

To upgrade forest function levels

Set-ADForestMode -Identity therebeladmin.com -ForestMode Windows2016Forest

With windows server 2019, there is no domain or forest functional level called windows2019. It is still 2016.

Now we have completed the migration from AD DS 2012R2 to AD DS 2019. Same steps apply when migrate from windows server 2008, Windows server 2008 R2, Windows server 2012 & Windows server 2016.

12. 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. 

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.

Continue reading
Reading time: 5 min
Written by: Dishan M. Francis
Active Directory

Step-by-Step Guide to install Active Directory in Windows Server 2019 (PowerShell Guide)

October 7, 2018 1 Comment

Finally waiting game is over, Windows server 2019 is now available for public. So, it is time to start planning for your production migrations. In this demo I am going to demonstrate how we can setup Active Directory 2019 with new AD forest. I will discuss new features of AD 2019 in a later post. 

In below, I created a checklist which we can use to track the progress of installation. 

Active Directory Domain Service Installation Check List for First Domain Controller

 Produce Active Directory Design Document 

 Prepare Physical / Virtual resources for Domain Controller

 Install Windows server 2019 Standard / Datacenter

 Patch Servers with latest Windows Updates

 Assign Dedicate IP address to Domain Controller

 Install AD DS Role

 Configure AD DS according to Design

 Review logs to verify the healthy AD DS installation and configuration

 Configure Service and Performance Monitoring 

 AD DS Backup / DR Configuration 

 Produce System Documentation 

Design Topology
 
As explain in the above figure, in my demo environment, rebeladmin.com will be the forest root domain. The first domain controller install on the forest will hold all five FSMO roles. Once additional domain controllers are in place you can place them in appropriate locations. 
 
1. To start the configuration, I logged in to Windows server 2019 server as local administrator. 
 
Continue reading
Reading time: 4 min
Written by: Dishan M. Francis
Active Directory MICROSOFT

Manage Active Directory Permissions with Delegate Control method

March 15, 2018 No Comments

In one of my previous post I explained how we can manage AD administration privileges using ACLs. If you didn’t read it yet you can find it using http://www.rebeladmin.com/2018/02/step-step-guide-manage-active-directory-permissions-using-object-acls/

This Delegate Control method also works similar to ACLs, but its simplified the process as its uses,

• Delegation of Control Wizard which can use to apply delegated permissions. 

• Allows to use predefined tasks and assign permission to those

The Wizard contain following predefined tasks which can use to assign permissions. 

• Create, delete, and manage user accounts

• Reset user passwords and force password change at next logon

• Read all user information

• Create, delete and manage groups

• Modify the membership of a group

• Manage Group Policy links

• Generate Resultant Set of Policy (Planning)

• Generate Resultant Set of Policy (Logging)

• Create, delete, and manage inetOrgPerson accounts

• Reset inetOrgPerson passwords and force password change at next logon

• Read all inetOrgPerson information

This also allows to create custom task to delegate permissions, if it’s not covered from the common task list. 

Similar to ACLs, Permissions can apply in,

1) Site – Delegated permission will valid for all the objects under the given Active Directory Site. 

2) Domain – Delegated permission will valid for all the objects under the given Active Directory Domain. 

3) OU – Delegated permission will valid for all the objects under the given Active Directory OU.

As an example, I have a security group called Second Line Engineers and Scott is a member of it. I like to allow members of this group to reset password for objects in OU=Users,OU=Europe,DC=rebeladmin,DC and nothing else. 

1) Log in to Domain Controller as Domain Admin/Enterprise Admin

2) Review Group Membership Using 

Get-ADGroupMember “Second Line Engineers”

dele1

3) Go to ADUC, right click on the Europe OU, then from list click on “Delegate Control”

4) This will open new wizard, in initial page click Next to proceed. 

5) In next page, Click on Add button and add the Second Line Engineers group to it. Then click Next to proceed.

dele2

6) From the task to delegate window select Delegate the following common tasks option and from list select Reset user passwords and force password change at next logon. In this page, we can select multiple tasks. If none of those works, we still can create custom task to delegate. Once completes the selection, click next to proceed. 

dele3

7) This completes the wizard and click on Finish to complete. 

8) Now it’s time for testing. I log in to Windows 10 computer which has RSAT tools installed as user Scott. 

According to permissions, I should be able to reset password of an object under OU=Users,OU=Europe,DC=rebeladmin,DC

Set-ADAccountPassword -Identity dfrancis

This allows to change the password successfully. 

dele4

However, it should not allow to delete any objects. we can test it using,

Remove-ADUser -Identity "CN=Dishan Francis,OU=Users,OU=Europe,DC=rebeladmin,DC=com"

And as expected, it returns access denied error. 

dele5

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.

Continue reading
Reading time: 2 min
Written by: Dishan M. Francis
Active Directory MICROSOFT

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

February 17, 2018 No Comments

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.

Continue reading
Reading time: 4 min
Written by: Dishan M. Francis
Active Directory MICROSOFT

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

February 13, 2018 No Comments

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.

Continue reading
Reading time: 1 min
Written by: Dishan M. Francis
Active Directory MICROSOFT

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

February 7, 2018 No Comments

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. 

Continue reading
Reading time: 3 min
Written by: Dishan M. Francis
Active Directory MICROSOFT

How to Seize FSMO Roles? (PowerShell Guide)

January 17, 2018 No Comments

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.

Continue reading
Reading time: 1 min
Written by: Dishan M. Francis
Active Directory Windows Server 2016

Create Active Directory User Objects using PowerShell

January 2, 2018 No Comments

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.

Continue reading
Reading time: 2 min
Written by: Dishan M. Francis
Page 1 of 212»

Search

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Microsoft MVP

MVP for Last 5 Years!

July 19, 2018

I am glad to announce that I have been awarded with MVP award by Microsoft for 5th consecutive time. It is a true honor to be a part of such a great community. I got my first award back in 2014 under Active Directory category. […]

Book Release

Mastering Active Directory, Second Edition Released!

August 10, 2019

Mastering Active Directory, Second Edition Released!

As most of you were aware, I published my book "Mastering Active Directory" back in, 2017. When I released it, I had my doubts! It was my first book even though I was writing to blogs for many years.

Follow Us

Twitter
LinkedIn

© 2018 copyright Dishan Francis // All rights reserved