# Access control

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/access-control

## Quick definition

Access control decides who gets in and what they can do once inside. It is like having a security guard at a door who checks your ID and only lets you into rooms you are allowed to enter. The system works by verifying your identity and then checking if you have permission to access a specific resource.

## Simple meaning

Think of access control like the system that manages keys and locks in a large office building. When you arrive at work, you might have a key card that opens the main door. That is the first step of access control: proving you are allowed to enter the building at all. Once inside, your key card might only open certain floors or specific offices. The accounting department people cannot open the server room, and the IT team cannot open the payroll safe. That is access control in action.


Access control is not just about doors and keys. In the digital world, it works the same way. When you log into your email, you type a username and password. That is the system checking your identity. Then, the system decides what you can do in your email. You can read your own emails, but you cannot read your boss's emails unless your boss gives you permission. That is also access control.


There are three main ideas behind access control. The first is identification. You say who you are, usually with a username or an ID card. The second is authentication. You prove you are that person, typically with a password, a fingerprint, or a security token. The third is authorization. The system checks a set of rules to see what you are allowed to do. Are you allowed to open this file? Can you edit this document? Can you delete this folder? The rules are set by someone in charge, like an IT administrator.


An everyday analogy is a hotel. When you check in, you show your ID and credit card. The front desk person identifies you and authenticates you by matching your name to the reservation. Once that is done, they give you a key card that only opens your room and maybe the gym. You cannot open other guests' rooms. The hotel's system is an access control system. It keeps guests safe and ensures that only the right people get into the right places.


Access control is everywhere online too. When you use a streaming service, you log in with your email and password. The service checks your subscription level. If you have a basic plan, you can only watch on one screen. If you have a premium plan, you can watch on four screens. The service is using access control to enforce what you paid for. Without access control, anyone could watch anything, which would be chaos for the company and unfair to paying customers.


In short, access control is about making sure the right people have the right access at the right time. It is a core part of security because it prevents unauthorized people from seeing or changing things they should not. For beginners, the key takeaway is that access control has three parts: who you are, proving who you are, and what you are allowed to do. Once you understand those three parts, you understand the foundation of digital security.

## Technical definition

Access control is a fundamental security mechanism that governs the ability of subjects (users, processes, devices) to perform actions on objects (files, network resources, system functions). It operates based on a set of policies and rules defined by an organization's security framework. The three core phases of access control are identification, authentication, and authorization, often referred to as the AAA triad. Identification is the claim of identity, typically via a username or user ID. Authentication verifies that claim through factors such as passwords (knowledge), tokens or smart cards (possession), or biometrics (inherence). Authorization then determines the specific access rights granted to the authenticated subject based on predefined policies.


Access control models define how authorization rules are structured and enforced. The most common models are Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC). In DAC, the owner of an object decides who can access it. This is common in file systems where a user can set permissions on their own files. MAC uses a central authority to assign security labels to subjects and objects. A subject can only access an object if their clearance level meets or exceeds the object's classification level. MAC is typically used in government and military environments enforcing multilevel security.


RBAC is the most widely used model in enterprise IT. Permissions are assigned to roles, and users are assigned to roles. A user in the 'Network Admin' role inherits all permissions associated with that role. This simplifies management because when a user changes job functions, you only change their role assignment, not individual permissions. ABAC is more granular and dynamic. It evaluates attributes of the subject (e.g., job title, clearance), the object (e.g., classification), the environment (e.g., time of day, location), and the action (e.g., read, write). For example, a policy might allow read access to a document only if the user is in the office and during business hours.


Access control is implemented through various technologies. Access Control Lists (ACLs) are lists of permissions attached to an object, specifying which subjects can perform which actions. ACLs are used in network devices (routers, firewalls) and operating systems. Authentication protocols like Kerberos, LDAP, and SAML facilitate secure verification of identities across networked systems. Kerberos uses tickets to grant access without transmitting passwords over the network. LDAP is used for directory services, often storing user credentials and group memberships. SAML and OAuth are used for federated identity and single sign-on (SSO), allowing users to authenticate once and access multiple applications.


In modern cloud and network environments, access control extends to network segmentation via firewalls and VLANs. Firewalls use rules (ACLs) to permit or deny traffic based on IP addresses, ports, and protocols. 802.1X is a port-based network access control standard used in wired and wireless networks. It authenticates devices before they are allowed to connect to the local area network. In cloud environments like AWS and Azure, access control is managed through Identity and Access Management (IAM) services. IAM policies are JSON documents that define permissions for users, groups, and roles. These policies can be very granular, allowing or denying actions on specific resources under specific conditions.


A critical component of access control is the principle of least privilege. This principle dictates that a subject should only be granted the minimum permissions necessary to perform their job function. Combining this with separation of duties ensures that no single user has excessive control. For example, a user who approves purchase orders should not also be able to create vendor accounts. Audit logs are essential for monitoring access control effectiveness. They record who accessed what, when, and what actions were performed. Regular review of audit logs helps detect unauthorized access attempts and policy violations.


Access control is also enforced in software development through application-level authorization. Developers use frameworks to protect API endpoints, web pages, and database queries. Common implementations include OAuth 2.0 for delegated access and OpenID Connect for authentication. Access control vulnerabilities, such as broken access control (OWASP Top Ten), occur when an application fails to properly enforce restrictions, allowing an attacker to view or modify unauthorized data. Proper access control requires careful design, regular testing, and adherence to standards such as NIST SP 800-53 or ISO 27002.

## Real-life example

Imagine you live in a large apartment building with a secure entrance. Every resident has a key fob that opens the front door. That key fob is your identity. The building's security system recognizes your fob's unique code and knows it belongs to apartment 5C. That is identification. When you press the fob against the reader, the system checks that the fob is valid and hasn't been reported stolen. That is authentication. Then, the system allows you to turn the handle and enter the building. That is authorization.


Inside the building, there are other doors. The laundry room requires a different key. The rooftop garden is only open to residents who live on the top floor. The mailroom is accessible to everyone but only during certain hours. These are all access control rules. The building manager sets these rules. He decides who gets a key to the laundry room and when the rooftop door unlocks. In IT, the system administrator does the same thing with computer resources.


Now think about a visitor arriving. The visitor buzzes your apartment. You answer and unlock the main door remotely. You have just granted temporary authorization to that visitor. The visitor can only be in the lobby and your apartment. They cannot go into the laundry room or other apartments without additional permission. This is exactly how delegated access works in IT. A user can sometimes grant another person access to a file or folder. In Windows, this is called share permissions. In cloud storage like Google Drive or OneDrive, you can share a document with someone by sending them a link. You are acting like the building owner, setting specific access for a specific person.


Another everyday analogy is a gym membership. When you sign up, you prove your identity with a photo ID and provide a payment method. The gym gives you a membership card that you scan at the entrance. That card works during the gym's operating hours. If you have a basic membership, you can only use the ground floor equipment. If you have a premium membership, you can also access the pool and classes. The gym's access control system checks your membership level when you scan your card and only opens the doors you are allowed to pass through. This is a perfect match for Role-Based Access Control in IT. Your membership tier is your role, and each role has specific permissions defined by the gym's policies.


A failure in access control is like an apartment building where the locks are all the same. Any resident's key can open any door. That would be a serious security problem. Someone could walk into your apartment, take your belongings, or damage your property. In IT, this is what happens when a server has no firewall rules or when a database has a misconfigured access control list. An attacker or even a careless employee can access data they should never see. That is why access control is one of the most important security controls in any organization.

## Why it matters

Access control matters because it is the primary mechanism for protecting sensitive data and system integrity. Without effective access control, any user could potentially view, modify, or delete any file, database, or configuration setting. This would make confidentiality, integrity, and availability impossible to maintain. In a practical IT context, access control failures are a leading cause of data breaches. The Verizon Data Breach Investigations Report consistently shows that misconfigured access controls and stolen credentials are among the top attack vectors.


For IT professionals, implementing proper access control is a daily responsibility. Whether you are setting up a new employee's accounts, configuring a firewall, or designing a cloud IAM policy, you are making decisions that directly affect the organization's security posture. Mistakes in access control can lead to compliance violations. Regulations like GDPR, HIPAA, and PCI-DSS require strict access control measures. Failing to implement them can result in fines, lawsuits, and reputational damage.


Access control also enables operational efficiency. By using role-based access control, an administrator can quickly provision and deprovision user permissions when employees change roles or leave the company. This reduces the risk of orphaned accounts that become security holes. Access control supports the principle of least privilege, which minimizes the blast radius of a compromised account. If a helpdesk worker's account is taken over, but they only have read access to the ticket system, the impact is limited. If that same account had administrative privileges, the attacker could take over the entire IT infrastructure.


In cloud computing, access control is even more critical because the perimeter is no longer a physical network boundary. Cloud services are accessed over the internet, so every API call, every login, and every data request must be authorized. Services like AWS IAM, Azure RBAC, and Google Cloud IAM are central to cloud security. Misconfigured S3 buckets, overly permissive IAM roles, and shared access keys are some of the most common and dangerous mistakes. Understanding access control is not optional for cloud practitioners. It is the foundation of everything they do.

## Why it matters in exams

Access control is a core topic across nearly every major IT certification exam. For the CompTIA Security+ (SY0-601) exam, access control is a major domain. You will see questions about the three As (Identification, Authentication, Authorization), access control models (DAC, MAC, RBAC, ABAC), and the principle of least privilege. Expect multiple-choice questions that present a scenario and ask which model or concept is being used. For example, a question might describe a situation where a server administrator sets permissions on a folder, and you need to identify that as Discretionary Access Control (DAC).


For AWS Certified Solutions Architect (SAA-C03), access control is tested extensively through IAM policies, S3 bucket policies, and security groups. Questions often require you to interpret a JSON policy document and determine whether access is allowed or denied. You may also see scenario-based questions about cross-account access, federation, and condition keys. Understanding the difference between identity-based policies, resource-based policies, and the effect of explicit deny over allow is critical. AWS exam questions frequently combine access control with networking concepts like NACLs and security groups.


The Microsoft Azure AZ-104 and MS-102 exams focus heavily on Azure RBAC, Azure Active Directory (now Entra ID), and conditional access policies. You will need to understand how to assign roles at different scopes (management group, subscription, resource group, resource). Questions will ask about the built-in roles like Contributor, Reader, and Owner, and when to use custom roles. The MD-102 exam for Microsoft Endpoint Manager includes access control for device management, such as enrolling devices and deploying compliance policies. The Microsoft SC-900 exam is foundational but still covers the core concepts of identity and access in the Microsoft ecosystem.


For the ISC2 CISSP exam, access control is a full domain (Domain 5: Identity and Access Management). This is a deep and technical area. You will need to know all the access control models in detail, along with attacks on access control (e.g., password guessing, social engineering, privilege escalation). The exam is heavy on the difference between administrative, technical, and physical controls. You must understand federated identity, SSO, Kerberos, and the difference between centralized and decentralized access control. The CISSP exam also tests the entire lifecycle of identity management: provisioning, review, revocation.


The CompTIA CySA+ exam approaches access control from a behavior analytics and monitoring perspective. Questions might involve interpreting access logs, detecting anomalous access patterns, and recommending remediation based on least privilege violations. The exam expects you to understand how to use tools like SIEM to correlate access events. For all these exams, common question types include scenario-based identification, best practice selection, and troubleshooting where access is unexpectedly denied or granted. You must be able to read policy syntax and understand the effect of each rule.

## How it appears in exam questions

In IT certification exams, access control appears in several recurring question patterns. The first is the scenario-based question. The question describes a situation where a user or a system cannot access a resource, and you must determine the most likely cause. For example, a user reports that they cannot access a shared folder that they could access yesterday. The exam expects you to consider changes in group membership, password expiry, or modified permissions. Another common scenario is a security incident where an employee accessed data they should not have. You might be asked which access control model violation occurred or what principle was violated.


The second type of question is the policy interpretation question. For AWS and Azure exams, you will be shown a JSON policy or a permissions assignment and asked whether access is granted or denied. These questions test your ability to read policy syntax, understand the order of evaluation, and recognize the effect of condition keys. For example, an AWS IAM policy might deny access to all S3 buckets except one, and you need to see if a specific action is allowed. In Azure, you might be asked what level of access a user has after being assigned the 'Reader' role at the subscription scope.


The third type is the design or recommendation question. You are given a business requirement, such as "The company wants to ensure that contractors can only access files during business hours and only from company-managed devices." You must select the best access control solution. This could involve proposing a conditional access policy in Azure, configuring an S3 bucket policy with a time condition, or implementing a VPN combined with an IAM role. These questions test your ability to apply access control concepts to real-world constraints.


Troubleshooting questions are also common. A question might describe that after adding a user to a security group, the user still cannot access a resource. You need to know that group membership changes may not apply until the next logon, or that there is a hierarchy issue with permissions. In network access control, a troubleshooting question might involve a user who cannot connect to Wi-Fi. You might need to check if 802.1X authentication is configured correctly, or if the user's certificate has expired. These questions require a systematic approach to identifying the failure point.


Finally, there are multiple-choice questions that directly test definitions and models. You might be asked "Which access control model allows the owner of an object to set permissions?" The answer is DAC. Or "Which principle ensures a user has only the minimum necessary permissions to perform their job?" The answer is least privilege. While these are straightforward, they are mixed in with trickier questions that combine two concepts, such as applying least privilege in a MAC environment. The key is to understand not just the definition but how each model works in practice.

## Example scenario

A medium-sized company called GreenLeaf Inc. has 200 employees. The IT department uses a file server running Windows Server that stores shared folders for each department. The accounting folder contains payroll data, and the HR folder contains employee records. The company wants to ensure that only the HR team can read and edit files in the HR folder, and only the accounting team can access the accounting folder. All other employees should have no access to these folders.


The IT administrator, Alex, decides to use Role-Based Access Control (RBAC). Alex creates two security groups in Active Directory: HR_Staff and Accounting_Staff. Alex then places all HR employees into the HR_Staff group and all accounting employees into the Accounting_Staff group. On the file server, Alex goes to the permissions of the HR folder and grants the HR_Staff group the 'Modify' permission. He then explicitly denies the Accounting_Staff group any access to that folder. For the accounting folder, he does the reverse.


A few days later, a new employee named Sam is hired into the accounting department. Alex adds Sam's user account to the Accounting_Staff group. Sam can now access the accounting folder without any additional configuration. Later, Sam is transferred to HR. Alex removes Sam from the Accounting_Staff group and adds him to the HR_Staff group. Sam can no longer access the accounting folder, and he gains access to the HR folder. The principle of least privilege is maintained because every employee only sees the files relevant to their job.


Now consider what happens if a manager from marketing wants to see the payroll numbers for budgeting. The manager asks Alex for temporary access to the accounting folder. Alex creates a time-limited rule that grants the manager's user account read-only access for one week. After the week passes, Alex revokes that access. This is an example of attribute-based access control (ABAC) where time is an attribute. In a real exam scenario, you might be asked what changes are needed to the group memberships or folder permissions to accomplish this without creating a security risk.

## Common mistakes

- **Mistake:** Thinking that authentication and authorization are the same thing.
  - Why it is wrong: Authentication only verifies identity (who you are), while authorization determines what you can do. A user can be authenticated but still denied access if they lack permission.
  - Fix: Remember AAA: Authentication proves identity, Authorization grants permissions, Accounting logs actions.
- **Mistake:** Confusing Deny and Allow rules without understanding that Deny always overrides Allow in most systems.
  - Why it is wrong: If a user is granted Allow access through one group but Deny access through another group, the explicit Deny takes precedence. Many learners think the most recent rule applies, but it is the explicit Deny that wins.
  - Fix: Default-deny mindset: if any Deny applies to the user for that action, access is denied, even if an Allow exists elsewhere.
- **Mistake:** Believing that adding a user to a security group immediately grants permissions without requiring a new logon or token refresh.
  - Why it is wrong: In Windows Active Directory, group membership is evaluated at logon. If a user is already logged in and added to a group, they must log off and back on for the change to take effect. In cloud environments, a session refresh may be required.
  - Fix: Always advise the user to log off and log back on, or use tools like 'klist purge' to refresh Kerberos tickets.
- **Mistake:** Assuming that a user with 'Read' access cannot accidentally overwrite a file if they have write permissions at a higher folder level.
  - Why it is wrong: In many file systems, permissions propagate downward. If a user has 'Modify' on a parent folder and 'Read' on a child file, the effective permission may depend on inheritance settings. Usually, the most restrictive permission applies, but it varies.
  - Fix: Always check effective permissions using tools like PowerShell or the Effective Permissions tab in Windows. Test with a dummy file.
- **Mistake:** Thinking that physical access control (e.g., a locked door) is separate from logical access control and not part of the same security strategy.
  - Why it is wrong: Physical and logical access controls are complementary. An attacker who can physically access a server can bypass many logical controls. A complete security strategy integrates both.
  - Fix: Consider the defense-in-depth model: physical controls are the first layer, followed by network, system, and application controls.
- **Mistake:** Over-permissioning by assigning the 'Owner' or 'Administrator' role to users who only need basic access.
  - Why it is wrong: Giving users more permissions than necessary violates the principle of least privilege and increases the risk of accidental or malicious data breaches.
  - Fix: Clearly define job roles and map required permissions to each. Audit existing permissions regularly and remove excessive rights.

## Exam trap

{"trap":"A scenario where a user is denied access to a resource even though they are a member of a group that has 'Allow' permissions. The trap is that the user might also be a member of another group that has an explicit 'Deny' permission for that resource.","why_learners_choose_it":"Learners tend to look only at the positive permissions that apply to the user's primary group and forget to check if there are any Deny permissions from other group memberships. They assume that because the user is in one allowed group, access is automatically granted.","how_to_avoid_it":"When evaluating access, always consider all groups the user is a member of. Remember the rule: explicit Deny always overrides any Allow, including inherited Allows. In exams, the answer often hinges on an explicit Deny from a secondary group."}

## Commonly confused with

- **Access control vs Authentication:** Authentication is the process of proving who you are, usually with a password or another factor. Authorization is the process of granting or denying access to a resource after you have been authenticated. You can authenticate successfully but still be denied authorization. (Example: You log into a website with your email and password (authentication works), but you are not allowed to view the admin panel because your account is a standard user (authorization fails).)
- **Access control vs Accounting:** Accounting (or auditing) is the process of logging and tracking user activities. While access control decides who can do what, accounting records what they actually did. Both are part of the AAA framework, but they serve different purposes. (Example: Access control lets a user read a file. Accounting logs that the user read the file at 3:15 pm.)
- **Access control vs Encryption:** Encryption protects data by making it unreadable without a decryption key. Access control protects data by restricting who can see it in the first place. Encryption is about scrambling data; access control is about permission. (Example: A locked file cabinet is access control. Putting the papers inside the cabinet in a secret code is encryption. Both are needed for strong security.)
- **Access control vs Privilege escalation:** Privilege escalation is an attack that tries to gain higher permissions than originally granted. Access control is the defense that should prevent privilege escalation. The two are opposites: one is a violation, the other is the control. (Example: A normal user exploits a software bug to gain root access. That is privilege escalation. Proper access control would patch the bug or remove unnecessary privileges to block the attack.)
- **Access control vs Network segmentation:** Network segmentation uses firewalls and VLANs to separate network traffic into zones. Access control often works within those zones to restrict user actions. Segmentation reduces the attack surface, while access control enforces policy on the remaining access points. (Example: A VLAN separates the HR network from the IT network. Within the HR network, access control ensures only HR staff can open payroll files.)

## Step-by-step breakdown

1. **Subject request** — A user, process, or device requests access to a resource. For example, a user double-clicks a file on a shared drive. The operating system intercepts this request and forwards it to the security subsystem.
2. **Identification** — The system asks 'Who are you?' The subject provides a unique identifier, such as a username or user ID (SID in Windows). This step does not verify the identity yet, it just claims it.
3. **Authentication** — The system verifies the claim of identity using one or more factors. The subject provides a password, a fingerprint scan, or a token code. The system compares this against stored credentials. If they match, authentication succeeds.
4. **Authorization check** — The system looks up the subject's permissions. It checks the ACL of the object or evaluates the IAM policy. It considers the user's group memberships, the action requested (read, write, delete), and any conditions (time, location, device).
5. **Policy evaluation** — The access control system processes all applicable policies. In IAM, it evaluates explicit Deny first, then Allows, and then default Deny. If an explicit Deny is found, access is denied immediately. If no Deny but an Allow exists, access is granted. If neither, access is denied by default.
6. **Access decision** — Based on the policy evaluation, the system outputs a decision: Grant or Deny. If grant, the subject's request proceeds to the execution phase. If deny, the subject receives an error message like 'Access Denied' or 'Permission Denied'.
7. **Action execution** — If granted, the subject can perform the requested action on the object. The operating system or application performs the actual read, write, delete, or execute operation. The action is logged for auditing purposes.
8. **Audit logging** — The system records the access attempt, the decision, the subject's identifier, the object, the action, and the timestamp. These logs are sent to a central syslog or SIEM for monitoring and incident response.
9. **Periodic review** — Administrators regularly review access logs and access rights to ensure they remain appropriate. This is part of the identity lifecycle. Users who changed roles or left the company have their access revoked or modified.

## Practical mini-lesson

In practice, access control is implemented at multiple layers in an IT environment. The first layer is the physical layer: server rooms with biometric locks and badge readers. The second is the network layer: firewalls with ACLs that permit or deny traffic based on source/destination IP and port. The third is the system layer: operating system permissions on files and folders. The fourth is the application layer: authentication and authorization within a web application or database.


A common practical implementation is Role-Based Access Control (RBAC) in a Microsoft Active Directory environment. An administrator creates global security groups in AD, such as 'Finance_Read', 'Finance_Write', 'HR_Read', and 'HR_Write'. Then, the administrator assigns these groups to the appropriate permissions on shared folders. Users are placed into groups based on their job role. For example, a finance analyst is added to 'Finance_Read' and 'Finance_Write', but a finance manager might only be in 'Finance_Read'. This granular separation allows the administrator to enforce least privilege easily.


In cloud environments, the approach is similar but uses resource-based policies. In AWS, an S3 bucket can have a bucket policy that grants access to a specific IAM role. A user who assumes that role gets access. In Azure, you assign RBAC roles at the resource group scope. For example, the 'Virtual Machine Contributor' role allows a user to manage virtual machines in that resource group but not in other resource groups. The key is to scope permissions as narrowly as possible.


What can go wrong? The most common issue is excessive permissions. An administrator might give a user the 'Owner' role on an entire subscription to fix a temporary issue, then forget to revert it. Another issue is group nesting. If a user is a member of Group A, which is a member of Group B, which has a Deny permission, the user inherits that Deny. Troubleshooting requires checking effective permissions. Tools like 'dsget user memberof' or 'Get-AzureADUserMembership' help trace group hierarchies.


Another practical challenge is managing service accounts. Service accounts often need high privileges, but they should still follow least privilege. A service account that runs a backup script needs only read access to the source files and write access to the backup destination, not admin rights on the server. Hardening service accounts means setting a complex password, disabling interactive logon, and regularly rotating the password.


For exam preparation, the most important practical skill is reading and interpreting access control policies. For AWS exams, you must understand that a policy has an Effect (Allow or Deny), an Action (s3:GetObject), a Resource (arn:aws:s3:::my-bucket/*), and optionally a Condition. The evaluation logic is: if there is an explicit Deny, it's Deny. If there is no Deny but there is an Allow, it's Allow. If neither, it's Deny by default. Practice with sample policies to see how overlapping rules interact. For Azure, understand role assignments and scope inheritance. A role assigned at the root management group applies to all child subscriptions.


Finally, always test access. After setting permissions, log in as the user and attempt the action. Watch for token caching issues. If a user is denied but should be allowed, check if the token cached an older permission set. The solution is often to log out and log back in, or use 'klist purge' to clear the Kerberos ticket cache.

## Commands

```
aws iam create-user --user-name Bob
```
Creates a new IAM user in AWS. Used to establish identity-based access control for an individual.

*Exam note: Tests understanding of IAM user creation as the first step in granting permissions; often paired with policy attachments in SAA exams.*

```
aws s3api put-bucket-policy --bucket my-bucket --policy file://policy.json
```
Attaches a resource-based policy to an S3 bucket to control access at the bucket level.

*Exam note: Appears in AWS SAA scenarios about cross-account access or public bucket misconfigurations; evaluates resource vs. identity policies.*

```
New-AzRoleAssignment -SignInName user@domain.com -RoleDefinitionName Contributor -Scope /subscriptions/{sub-id}/resourceGroups/Prod
```
Assigns the Contributor role to a user at a resource group scope in Azure. Implements RBAC.

*Exam note: Common in AZ-104 questions on role-based access control scopes (management group, subscription, resource group).*

```
Set-ADUser -Identity JohnDoe -AccountNotDelegated $true
```
Prevents a user's credentials from being delegated to services via Kerberos delegation in Active Directory.

*Exam note: Tests Kerberos delegation and constrained delegation restrictions; relevant for MD-102 and security-focused exams.*

```
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
```
Adds an iptables rule to allow SSH access only from a specific subnet, enforcing network access control.

*Exam note: Used in Security+ and CySA+ to test host-based firewall rules and least-privilege network access.*

```
Get-ADGroupMember -Identity 'Domain Admins'
```
Lists members of the Domain Admins group in Active Directory. Validates privileged access control.

*Exam note: Appears in MS-102 and CISSP scenarios about privileged account management and separation of duties.*

```
chmod 750 /var/www/secure
```
Sets Unix file permissions to owner rwx, group rx, others none. Implements discretionary access control (DAC).

*Exam note: Common in Linux-based access control questions for Security+, testing permission inheritance and octal notation.*

## Troubleshooting clues

- **Incorrect IAM policy syntax causing access denied** — symptom: User receives 'AccessDenied' error when trying to read an S3 object, despite having a policy attached.. The policy may have a typo in the resource ARN (e.g., missing bucket name wildcard) or an implicit deny from an explicit deny statement. (Exam clue: Exam questions often present a misconfigured policy with an invalid ARN, testing ability to identify the syntax error.)
- **Azure RBAC role assignment not taking effect** — symptom: User assigned 'Reader' role at subscription scope cannot list resources in a specific resource group.. Role assignment may not have propagated yet (up to 5 minutes) or a deny assignment at a higher scope blocks the reader role. (Exam clue: AZ-104 questions test understanding of propagation delays and deny assignments overriding role assignments.)
- **Delegation failure with constrained delegation** — symptom: Service ticket request fails with 'KDC_ERR_BADOPTION' when a server tries to delegate to a back-end service.. Constrained delegation is improperly configured-the front-end service's SPN is not permitted to delegate to the specific back-end SPN. (Exam clue: CISSP and MD-102 questions present this as a Kerberos delegation issue, testing constrained vs. unconstrained delegation.)
- **S3 bucket publicly accessible despite blocking public access settings** — symptom: Anonymous user can read objects in a bucket even though Block Public Access is enabled at the account level.. Block Public Access settings apply only to newly applied policies; an existing bucket policy with public access written before the block may still allow access. (Exam clue: AWS SAA exams test the precedence of Block Public Access vs. bucket policies and the need to update existing policies.)
- **NFS permission denied on shared directory** — symptom: User from a client system gets 'Permission denied' when trying to write to an NFS-mounted directory.. The directory's Unix permissions or NFS export options (e.g., 'root_squash') restrict write access; client's UID may not match the owner. (Exam clue: Security+ and CySA+ questions test NFS export options and Unix DAC as part of file-level access control.)
- **Missing ACL entry for application-specific firewall port** — symptom: Application service fails to start because it cannot bind to port 8443; firewall logs show dropped packets.. A network ACL or security group rule (cloud or on-prem) explicitly denies inbound traffic on that port, or the allow rule has a lower priority than a deny rule. (Exam clue: Common in SC-900 and AZ-104 scenarios about network security group rule evaluation order (deny rules take precedence).)
- **Privileged Access Workstation (PAW) unable to authenticate** — symptom: Admin using a PAW cannot log into a domain controller, receiving 'Logon failure: unknown user name or bad password'.. The PAW may be configured with a restricted admin mode or credential guard that blocks pass-through authentication; also, the user account might be a member of a protected users group with stricter Kerberos settings. (Exam clue: MS-102 and CISSP questions test PAW configuration and protected users group as a mitigation for credential theft.)

## Memory tip

Think of the word AAA to remember the three core parts of access control: Authentication, Authorization, and Accounting. The first A proves who you are, the second A decides what you can do, and the third A records what you did.

## Summary

Access control is a fundamental security concept that governs who can access systems and data, and what actions they can perform. It is built on three pillars: identification, authentication, and authorization, with accounting providing visibility into who did what. Access control models like discretionary, mandatory, role-based, and attribute-based provide different ways to manage permissions, each suited to different environments. In real IT work, you will configure access control in operating systems, networks, applications, and cloud platforms. Misconfigurations in access control are a leading cause of data breaches, making it essential to apply the principle of least privilege and conduct regular access reviews. For certification exams, access control appears across many domains, from security fundamentals to cloud architecture. You must understand the differences between models, know how to read policy statements, and be able to apply access control concepts to realistic scenarios. Remember that authentication is not authorization, that access control applies to both people and machines, and that permissions should be scoped narrowly. Mastering access control will not only help you pass exams but also build secure and efficient systems in your IT career.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/access-control