Technical Blog | REBELADMIN

Learn about Active Directory and Various Azure Services

Domain Service

Step-by-Step Guide to Restrict Azure AD Administration portal

In order to manage Azure AD, we use Azure Active Directory option in https://portal.azure.com. By default, any user under Azure AD can access this option event they do not have a Directory role. In my demo setup, I have a user called "Emily Braun". She doesn't have any Directory role assigned. 

Then I log in to Azure portal https://portal.azure.com as the user and then go to Azure Active Directory option. It didn't block me accessing it. 

I can go to All users and see user account details. 

I even can see the Groups memberships details. 

 

Also, can view application assignments. 

As an end user I also can see the Azure AD Connect details. 

[Read more…] about Step-by-Step Guide to Restrict Azure AD Administration portal

Manage Active Directory Permissions with Delegate Control method

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 https://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.

Step-by-Step guide to Manage Active Directory Permissions using Object ACLs

Users or groups access and permissions to a shared folder is controlled by its Access Control List (ACL). Similar way we can define permissions to Active Directory Objects. This can apply to individual object or apply to AD Site/Domain/OU and then inherit to lower level objects. 

As an Example, I have a security group called “First Line Engineers” and Liam is a member of this group. Liam is engineer of Europe office. In active directory environment, he should allow to add user objects under any sub OU in “Europe” OU. But he should not be allowed to delete any object under it. Let’s see how we can do it using ACLs. 

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

2) Review Group Membership Using 

Get-ADGroupMember “First Line Engineers”

acl1

3) Go to ADUC, right click on the Europe OU and click properties. Then go to Security tab.

4) In security tab, click on Add 

5) In the new window, type First Line Engineers and click Ok. After, In Security Tab, select First Line Engineers and click on Advanced

acl2

6) In next window, select the First Line Engineers from the list and click on Edit

7) From Applies to list select “This object and all descendant objects”. Then it will apply permission to all child objects. 

acl3

8) Under the Permissions section, tick Create All child objects and click Ok. 

9) Then keep clicking Ok until all permission window closed. 

10) Then I log in to Windows 10 computer which has RSAT tools installed as user Liam. 

11) According to permissions, he should be able to add user account under Europe OU. 

New-ADUser -Name "Dale" -Path "OU=Users,OU=Europe,DC=rebeladmin,DC=com"

This successfully add the user. Let’s see if we can add another user on different OU. 

New-ADUser -Name "Simon" -Path "OU=Users,OU=Asia,DC=rebeladmin,DC=com"

And as soon as I run it, I gets access denied error. 

acl4

According to applied permissions, I should not be able to delete any object under OU=Users,OU=Europe,DC=rebeladmin,DC=com either. Let’s check it using, 

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

And as soon as I run it, I gets access denied error. 

acl5

As above confirms we can manage permissions for AD management tasks in granular level. 

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