Key Points, Theoretical Questions & Scenario-Based Questions

1. Key Points (50)

• Active Directory Domain Services (AD DS) provides centralized management of users, computers, groups, policies, and network resources instead of managing each computer separately.
• An Active Directory Object is any resource stored in the AD database (users, computers, groups, OUs, printers, shared folders), each with its own attributes and permissions.
• A user object's attributes include username, password, email, department, and contact details; a computer object's attributes include computer name, OS info, and domain membership.
• A user account authenticates users and grants access to domain resources (computers, shared folders, applications, and printers).
• A domain user account is created in AD and offers centralized authentication and password management across the domain—ideal for enterprise environments.
• A Local User Account exists only on a single computer, cannot be centrally managed, and is used mainly in standalone/workgroup setups.
• When a computer joins the domain, AD automatically creates a Computer Object for it, allowing centralized Group Policy application and management.
• Groups let administrators assign permissions once to a group rather than individually to every user — members automatically inherit the group's permissions.
• An Organizational Unit (OU) is a logical container used to organize AD objects, apply Group Policies, and delegate administrative control.
• OU design best practices: create department-wise OUs, separate users and computers, use clear naming conventions, and avoid excessive nested OUs.
• OUs are created in Active Directory Users and Computers (or dsa.msc) via right-click the domain → New → Organizational Unit.
• User accounts are created inside an OU via New → User, entering name/username, then setting password options like 'must change at next logon' or 'password never expires.'
• Joining a computer to a domain (via sysdm.cpl → Change → Domain) automatically creates its Computer Object in AD.
• Active Directory groups are divided into two Group Types: Security Groups and Distribution Groups.
• Security Groups are security-enabled and used to assign permissions to resources such as folders, printers, and applications.
• Security Groups can contain users, computers, and other groups, and are used in access control lists (ACLs).
• Distribution Groups are used only for email communication (e.g., with Exchange Server) and cannot be used to assign resource permissions.
• Distribution Groups are not security-enabled and cannot appear in ACLs — their purpose is message distribution, not access control.
• Group Scope defines where a group can be used and what members it can contain, while Group Type defines the group's purpose (security vs. communication).
• There are three Group Scopes in AD: Global, Domain Local, and Universal.
• Global Groups organize users from the same domain (e.g., by department) and can contain users and other global groups from that domain.
• Domain Local Groups are used to assign permissions to resources within the same domain and can contain users, Global Groups, and Universal Groups from any domain.
• Universal Groups are used in multi-domain forests and can contain users and Global Groups from multiple domains — useful for enterprise-wide access management.
• Universal Group membership changes increase Active Directory replication traffic across the forest, so they should be used carefully.
• AGDLP is the recommended AD permissions strategy: Accounts → Global Groups → Domain Local Groups → Permissions.
• In AGDLP, permissions are assigned to Domain Local Groups, Global Groups (containing user accounts) are nested inside them, keeping administration clean and scalable.
• Best practice: use Security Groups for permissions, Distribution Groups only for email, and avoid assigning permissions directly to individual users.
• Delegation of Control allows assigning limited administrative permissions to specific users/groups without granting full Domain Admin rights.
• Delegation follows the Principle of Least Privilege — users receive only the minimum permissions required to perform their specific tasks.
• Without delegation, Domain Admins must handle every task, increasing workload and security risk; with delegation, responsibilities are distributed safely.
• Delegation is commonly implemented at the OU level, so admins (e.g., HR_Admins) control only their own OU rather than the whole domain.
• Common delegated tasks include resetting passwords, unlocking accounts, creating/deleting user accounts, managing groups, and joining computers to the domain.
• The Delegation of Control Wizard is a built-in AD tool (right-click an OU → Delegate Control) that simplifies assigning predefined administrative tasks.
• Delegating password-reset permission to a Helpdesk group lets them reset passwords for a specific OU without giving access to domain-level settings.
• Custom Delegation lets administrators manually assign very specific permissions beyond the wizard's predefined task list, but requires careful configuration to avoid security gaps.
• Delegation should be granted through Security Groups (e.g., Helpdesk_Admins) rather than to individual users, so permissions update automatically as group membership changes.
• Best practices for delegation: least privilege, delegate via groups, avoid unnecessary Domain Admin access, use OU-level delegation, document and regularly review permissions.
• Poor delegation design can lead to unauthorized access, administrative confusion, and infrastructure instability.
• Organizations should continuously monitor delegated permissions using audit logs, AD auditing tools, and SIEM solutions to track who changed what.
• A typical enterprise delegation split: Helpdesk resets passwords/unlocks accounts; Desktop Support manages computer objects/domain joins; Server Admins manage servers and Group Policy.
• Benefits of proper AD object management include centralized administration, better security, simplified authentication, easier permission management, and improved scalability.
• A Security Group example: assigning folder permissions once to 'HR_Security_Group' automatically grants access to every member added to that group.
• A Distribution Group example: emailing 'All_Employees' reaches every member without manually selecting each person's address.
• The key functional difference: Security Groups control access to resources; Distribution Groups control who receives group emails — they are not interchangeable.
• Domain Local Groups are best placed close to the resource they protect (e.g., 'HR_Folder_Access' assigned directly on the HR_Data shared folder).
• Global Groups are best used to logically organize users by department/role before nesting them into Domain Local Groups for permission assignment.
• Group creation in AD (New → Group) requires specifying both a Group Name, a Group Scope (Global/Domain Local/Universal), and a Group Type (Security/Distribution).
• Adding users to a group is done via the group's Members tab → Add → enter username → Check Names → OK.
• OU-level delegation improves security isolation, simplifies department-wise administration and policy management, and reduces the risk of unauthorized domain-wide changes.
• A well-delegated environment separates 'who can do what' by team/OU, so no single non-admin role has broader access than its job requires.
• Regularly reviewing and removing unused delegated permissions is essential, since outdated or excessive delegated rights are a common source of privilege-creep security risk.

2. Theoretical Questions (30)

Q1. What is an Active Directory Object?

Answer: Any resource stored in the Active Directory database — such as a user, computer, group, OU, or printer — each containing its own attributes and permissions.

Q2. What is the difference between a Domain User Account and a Local User Account?

Answer: A Domain User Account is created in AD and offers centralized authentication/management across the domain. A Local User Account exists only on one computer and cannot be centrally managed, limiting scalability.

Q3. What happens when a computer joins a domain?

Answer: AD automatically creates a Computer Object for that device, giving it an identity in AD so administrators can apply Group Policies and manage it centrally.

Q4. What is an organizational unit (OU), and why is it used?

Answer: An OU is a logical container used to organize AD objects (users, computers, groups). It helps apply Group Policies, delegate administrative control, and simplify administration.

Q5. What are the best practices for OU design?

Answer: Create department-wise OUs, separate users and computers, use clear naming conventions, avoid excessive nested OUs, and design based on administrative needs.

Q6. Why are Groups used in Active Directory instead of assigning permissions to individual users?

Answer: Groups let administrators assign permissions once, and every member automatically inherits them — this greatly reduces administrative effort and configuration errors compared to managing hundreds of users individually.

Q7. What is the difference between a Security Group and a Distribution Group?

Answer: A Security Group is security-enabled and used to assign resource permissions (folders, printers, apps). A Distribution Group is used only for email communication and cannot control access to resources.

Q8. Can a Distribution Group be used to assign folder permissions? Why or why not?

Answer: No — Distribution Groups are not security-enabled and cannot appear in Access Control Lists (ACLs), so they cannot be used to grant resource access; only Security Groups can.

Q9. What is Group Scope, and how is it different from Group Type?

Answer: Group Type defines the group's purpose (security vs. communication). Group Scope defines where the group can be used and what members it can contain — Global, Domain Local, or Universal.

Q10. What is a Global Group used for?

Answer: To organize users from the same domain (typically by department or role) before nesting them into Domain Local Groups for permission assignment.

Q11. What is a Domain Local Group used for?

Answer: To assign permissions to resources within the same domain. It can contain users, Global Groups, and Universal Groups from any domain, and is typically created close to the resource it protects.

Q12. What is a Universal Group, and when should it be used?

Answer: A group that can contain users and Global Groups from multiple domains within a forest, used for enterprise-wide/multi-domain access management — but used carefully since changes increase replication traffic.

Q13. What is the AGDLP strategy?

Answer: A best-practice AD permissions model: Accounts are placed into Global Groups, Global Groups are nested into Domain Local Groups, and Permissions are assigned to the Domain Local Groups.

Q14. Why is AGDLP considered a best practice?

Answer: It simplifies administration, improves scalability, eases troubleshooting, centralizes permission management, and reduces administrative errors compared to assigning permissions directly to users or groups inconsistently.

Q15. What is Delegation of Control in Active Directory?

Answer: The process of assigning limited administrative permissions to specific users or groups for specific tasks, without granting full Domain Admin rights.

Q16. What is the Principle of Least Privilege, and how does it relate to delegation?

Answer: It means users should receive only the minimum permissions needed for their job. Delegation applies this principle by granting narrow, task-specific rights instead of broad administrative access.

Q17. Why is delegation important in enterprise environments?

Answer: Without it, Domain Admins must handle every task, increasing workload and security risk. Delegation distributes responsibilities safely across teams while keeping overall control centralized.

Q18. What is OU-level delegation, and why is it commonly used?

Answer: Assigning administrative permissions scoped to a specific OU (e.g., HR_Admins managing only the HR OU) rather than the whole domain — it improves security isolation and simplifies department-wise administration.

Q19. What are common tasks that organizations delegate to support teams?

Answer: Resetting passwords, unlocking accounts, creating/deleting user accounts, managing group membership, and joining computers to the domain.

Q20. What is the Delegation of Control Wizard?

Answer: A built-in AD tool (accessed by right-clicking an OU → Delegate Control) that simplifies assigning predefined administrative permissions to users or groups, reducing configuration errors.

Q21. What is Custom Delegation, and when is it used?

Answer: Manually assigning very specific permissions beyond the wizard's predefined task list — used in large enterprises needing precise access control, but it requires careful configuration to avoid security gaps.

Q22. Why should delegation be granted through Security Groups rather than individual users?

Answer: Because permissions are assigned once to the group; when someone joins or leaves the team, admins simply add/remove group membership instead of reconfiguring individual permissions — simplifying management and scaling better.

Q23. What are the best practices for delegation of control?

Answer: Follow least privilege, delegate through Security Groups, avoid unnecessary Domain Admin access, use OU-level delegation, maintain documentation, and regularly review delegated permissions.

Q24. What risks arise from poor delegation design?

Answer: Unauthorized access, administrative confusion, security vulnerabilities, and infrastructure instability due to overly broad or poorly tracked permissions.

Q25. Why should delegated permissions be regularly monitored and reviewed?

Answer: Because outdated or excessive permissions accumulate over time (privilege creep), creating security risks; regular audits using AD auditing tools/SIEM help catch unused or inappropriate access.

Q26. What is the typical delegation split between Helpdesk, Desktop Support, and Server Admin teams?

Answer: Helpdesk: resets passwords and unlocks accounts. Desktop Support: joins computers to the domain and manages computer accounts. Server Admins: manage servers and configure Group Policies.

Q27. What is the difference between administrative control at the OU level vs. full Domain Admin level?

Answer: OU-level control limits an admin's rights to objects within a specific OU (e.g., HR OU), while full Domain Admin rights grant control over the entire domain — OU-level is safer and more scoped.

Q28. Why might a Helpdesk team be denied permission to modify Group Policies even though they can reset passwords?

Answer: Because delegation follows least privilege — password reset is a narrow, low-risk task, while modifying Group Policy affects the whole domain/OU and is reserved for higher-trust administrative roles.

Q29. What steps are followed to create a Security Group in AD?

Answer: Open Active Directory Users and Computers, select the OU, right-click → New → Group, enter the group name, select the Group Scope, choose 'Security' as the Group Type, and click OK.

Q30. How do you add users to a group in Active Directory?

Answer: Open the group's Properties, go to the Members tab, click Add, enter the username, click Check Names, then click OK — the user then inherits the group's assigned permissions.

3. Scenario-Based Questions (12)

For scenario questions: identify whether the issue is about permission management (Security Groups/AGDLP), communication (Distribution Groups), or administrative scope (Delegation/OU design), then apply the matching best practice.

Q1. A company has 200 employees across HR, IT, and Finance, and the admin is currently assigning shared-folder permissions to each employee individually. Onboarding a new hire takes hours because of this. What should be changed, and how?

Answer: Create department-based Security Groups (e.g., HR_Security_Group, Finance_Security_Group), assign the shared-folder permissions once to each group, then simply add new hires to the relevant group — they'll inherit access automatically instead of requiring individual configuration.

Q2. Management wants to send a company-wide holiday announcement by email, but the admin mistakenly tries to assign folder permissions to the group used for this purpose and it doesn't work. What group type is being misused, and why doesn't it work for permissions?

Answer: A Distribution Group is being misused — Distribution Groups are not security-enabled and cannot appear in ACLs, so they can't grant resource access. Folder permissions must be assigned to a Security Group instead; a Distribution Group should only be used for email distribution.

Q3. An organization has offices in India, US, and UK, each in its own AD domain within the same forest. They want all HR managers across every domain to access one shared enterprise HR portal. Which group scope should be used, and why?

Answer: A Universal Group — since it can contain users and Global Groups from multiple domains within the same forest, making it the correct choice for enterprise-wide access spanning multiple domains, unlike Global or Domain Local groups which are more domain-restricted.

Q4. A shared folder called Finance_Data needs to be accessed by all Finance employees. The admin wants to follow AD best practices instead of assigning permissions directly to each user. What structure should be set up, step by step?

Answer: Follow AGDLP: (1) add Finance user accounts to a Global Group like Finance_Global, (2) create a Domain Local Group like Finance_Folder_Access and assign it NTFS/share permissions on Finance_Data, (3) nest Finance_Global inside Finance_Folder_Access — so all Finance users inherit access through the group chain.

Q5. A newly formed Helpdesk team needs to reset passwords and unlock accounts for HR employees only, but should not be able to touch server configurations or domain-wide settings. How should this be configured?

Answer: Use the Delegation of Control Wizard on the HR OU: right-click the HR OU → Delegate Control → add the Helpdesk group → select 'Reset user passwords and force password change at next logon' and 'unlock accounts' — this grants exactly those rights scoped to the HR OU only, without any domain-level access.

Q6. An IT director is worried that giving Domain Admin rights to every department's local IT support staff is too risky, but each department does need to manage its own users. What approach solves this while keeping things secure?

Answer: Implement OU-level Delegation of Control: create a separate OU per department (HR, IT, Finance) and delegate limited permissions (e.g., create/reset/manage users) to each department's admin group scoped only to their own OU — avoiding domain-wide Domain Admin rights altogether.

Q7. A Desktop Support engineer was accidentally given permission to modify Group Policy Objects along with their computer-management delegation, and they unintentionally changed a domain-wide policy, causing an outage. What principle was violated, and how should delegation be corrected?

Answer: The Principle of Least Privilege was violated — the engineer received more access than their job required. Delegation should be corrected to grant only 'create, delete, and manage computer accounts' (their actual task) and explicitly exclude Group Policy management rights.

Q8. A company's security audit reveals that a former Helpdesk employee's account still has password-reset delegation rights on the HR OU, six months after they left. What process failure does this represent, and what should be implemented going forward?

Answer: This reflects a failure to regularly review/monitor delegated permissions (privilege creep). Going forward, the organization should implement periodic audits of delegated rights, remove permissions promptly during offboarding, and use AD auditing tools/SIEM to track and flag stale or unused delegated access.

Q9. An organization wants new hires to automatically inherit both file-share access AND email distribution list membership as soon as they're placed in the right department. How should they structure their groups to achieve both with minimal admin effort?

Answer: Create two parallel groups per department: a Security Group (e.g., HR_Security_Group) for file/resource permissions, and a Distribution Group (e.g., HR_Announcements) for email — then add each new hire to both groups (or use nested Global/Domain Local security groups plus a separate distribution group) so one onboarding step covers both access and communication needs.

Q10. A multi-domain enterprise notices unusually high Active Directory replication traffic after HR made frequent changes to a group used for cross-domain portal access. What group scope is likely responsible, and what best practice should be followed?

Answer: A Universal Group is likely responsible, since membership changes to Universal Groups replicate across the entire forest. Best practice is to minimize frequent membership changes to Universal groups—instead, nest more stable Global Groups inside the Universal Group so day-to-day user changes happen at the Global Group level, which has lighter replication scope.

Q11. A company wants its Server Administration team to manage Group Policies and servers, but not touch HR or Finance user accounts, while its HR admins should manage only HR user accounts and nothing else. How should OUs and delegation be designed to enforce this?

Answer: Create separate OUs (HR, Finance, Servers) matching each team's scope. Delegate Group Policy and server management rights only on the Servers OU to the Server Admin group, and delegate user-account management rights only on the HR OU to the HR_Admins group — this way each team's delegated permissions are isolated to their own OU and cannot cross into others.

Q12. An admin used Custom Delegation to grant a junior IT staffer very specific rights ('modify group membership only'), but the staffer is now requesting broader access to 'just make things easier.' What should the admin do, and why?

Answer: The admin should deny the broader request and keep the custom delegation scoped to 'modify group membership only,' consistent with least privilege — convenience is not a valid justification for expanding administrative access, and any genuine new task should be delegated as its own narrowly scoped permission if truly required.

 Related: Azure System Administration - Job Ready Internship Program