© 2024 SkillPoint IT. All rights reserved.
Module 4: Setting Up and Administering Users and Groups in Active Directory
Managing users and groups is a fundamental task for network administrators in a Windows Server environment. Active Directory Domain Services (AD DS) simplifies identity and access management through centralized user and group administration.
- Create User Accounts for Each Person Who Regularly Uses the Network
Creating User Accounts in Active Directory
User accounts in AD are used for:
Logging into domain-joined computers
Accessing network resources (e.g., file shares, printers)
Applying group policies and permissions
How to Create a User Account:
Open Active Directory Users and Computers (ADUC).
Navigate to or create a specific Organizational Unit (OU).
Right-click → New > User.
Enter user details (Name, User Logon Name).
Set and confirm a password.
Choose account options (e.g., must change password at next logon).
- Create Multiple User Accounts for New Users in a Single Batch Operation
Understanding Groups in Active Directory
Groups simplify management by allowing administrators to assign permissions to multiple users at once.
Group Types:
Security Groups – Used to assign permissions to resources (most common).
Distribution Groups – Used for email distribution lists (not for permissions).
Group Scopes:
Domain Local – Access to resources in the same domain.
Global – Users from the same domain, usable across domains.
Universal – Cross-domain group membership and permissions.
- Group User Accounts to Manage User Access to Shared Resources
Creating and Managing Groups
How to Create a Group:
In ADUC, right-click the desired OU → New > Group.
Choose group name, type (Security or Distribution), and scope.
Add members by selecting Properties > Members > Add.
- Nest Groups Within Other Groups to Reduce Administration
Using Group Policy with Users and Groups
Link Group Policy Objects (GPOs) to OUs to apply policies to users and computers.
Example policies:
Password policies
Desktop restrictions
Software deployment
Understanding User Logon Names in Active Directory (UPN vs. SAMAccountName)
User Logon Names in Active Directory
In Active Directory environments, user logon names are essential for authenticating users across domain-joined systems and applications. Admins must understand the two main formats and best practices for naming and managing these logins.
Types of User Logon Names
1. User Principal Name (UPN)
Format:
username@domain.comUsed for logging in to Microsoft 365, cloud services, and newer Windows login screens.
More user-friendly (similar to an email address).
2. SAMAccountName (Pre–Windows 2000 Logon Name)
Format:
DOMAIN\usernameUsed by legacy systems and applications.
Limited to 20 characters maximum.
- Introduction to User Logon Names
- User Principal Name
- The suffix defaults to the name of the root domain, but it can be changed and others added
- User Logon Name (Pre-Windows 2012)
- A user selects the domain when logging on
- User Logon Name Uniqueness Rules
- Full name must be unique within the container
- User principal name is unique within the forest
- User logon name (pre-Windows 2012) is unique within the domain
- Creating a User Principal Name Suffix
How to Create Multiple User Accounts in Active Directory (Step-by-Step Guide)
Creating Multiple User Accounts in Active Directory
Adding users one at a time in Active Directory is inefficient for medium or large organizations. Instead, use bulk user creation techniques like PowerShell scripts and CSV imports to speed up the process.
Method 1: Manual Creation (Not Recommended for Large Environments)
For small environments:
Open Active Directory Users and Computers (ADUC).
Navigate to the correct Organizational Unit (OU).
Right-click → New > User.
Enter user details and repeat for each account.
Time-consuming and error-prone for more than a few users.
Method 2: Bulk User Creation with PowerShell and CSV
Step 1: Create a CSV File
Create a file called users.csv with this format:
- For Each User Object, the File:
- Must include the path to the user account’s OU, object type, and user logon name (pre-Windows 2012)
- Should include the user principal name and whether the user account is enabled or disabled
- Can include personal user information
- Cannot include a password
- Using CSVDE to Create Multiple User Accounts
FirstName,LastName,Username,Password,OU
John,Doe,jdoe,P@ssw0rd1,”OU=Sales,DC=yourdomain,DC=com”
Jane,Smith,jsmith,P@ssw0rd2,”OU=HR,DC=yourdomain,DC=com”
- Attribute line containing the names of the attributes:
- User account line containing values for attributes:
“cn=Suzan Fine,ou=Human Resources,dc=asia,dc=contoso,dc=msft”, user,suzanf,suzanf@contoso.msft,Suzan Fine,512
- Using LDIFDE to Create Multiple User Accounts
DN:CN=Suzan Fine,OU=Human Resources,DC=asia,DC=contoso,DC=msftobjectClass: user
samAccountName: suzanf
userPrincipalName: suzanf@contoso.msft
displayName: Suzan Fine
userAccountControl: 512
Administering User Accounts
- Performing Common Administrative Tasks
- Locating User Accounts
Using Groups in Active Directory
- Introduction to Groups in Active Directory
- Using Global Groups
| Membership | =>Mixed mode: User accounts from same domain =>Native mode: User accounts and global groups from same domain |
| Can Be a Member of | =>Mixed mode: Domain local groups =>Native mode: Universal and domain local groups in any domain, and global groups in the same domain |
| Scope | Visible in its own domain and all trusted domains |
| Permissions for | All domains in the forest |
- Using Domain Local Groups
| Membership | =>Mixed mode: User accounts and global groups from any domain Native mode: User accounts, global groups, and universal groups from any domain in the forest, and domain local groups from the same domain |
| Can Be a Member of | =>Mixed mode: Not a member of any group =>Native mode: Domain local groups in the same domain |
| Scope | Only visible in its own domain |
| Permissions for | Domain in which the domain local group exists |
- Using Universal Groups
| Membership | =>Mixed mode: Not applicable Native mode: User accounts, global groups, and other universal groups from any domain in the forest |
| Can Be a Member of | =>Mixed mode: Not applicable =>Native mode: Domain local and universal groups in any domain |
| Scope | Visible in all domains in a forest |
| Permissions for | All domains in a forest |
Top Strategies for Using Groups in an Active Directory Domain
Strategies for Using Groups in a Domain
In a Windows Server domain environment, Active Directory groups are powerful tools that help administrators manage permissions and policies more efficiently. By grouping users with similar access needs, you can implement security and administration at scale.
1. Use Role-Based Access Control (RBAC)
Assign users to groups based on their roles or job functions (e.g., Sales, HR, IT Support). Then grant access to resources based on group membership rather than individual users.
Example:
Sales Shared Folderpermission → granted toSales GroupAll Sales employees → added to
Sales Group
2. Prefer Security Groups over Distribution Groups
Security groups are used for assigning permissions to resources.
Distribution groups are only for email communication (Exchange/Outlook).
Use security groups even if you’re not assigning permissions yet — they’re more versatile.
3. Follow the AGDLP Model (Microsoft Best Practice)
AGDLP =
Accounts → into Global Groups → into Domain Local Groups → assigned to Permissions
This helps in managing access across domains in large environments.
Example:
Users →
HR_GlobalHR_Global→ member ofPayroll_Read_DLPayroll_Read_DL→ granted Read permissions on a folder
4. Use Nested Groups for Scalability
Instead of assigning users to multiple groups, nest groups:
Example:
Interns→ member ofMarketing_ReadOnlyMarketing_ReadOnly→ granted read-only permissions on shared drives
This simplifies permission management when departments grow.
5. Keep Group Scope in Mind
| Scope | Usage |
|---|---|
| Global | Add users from the same domain |
| Domain Local | Use to assign permissions to resources |
| Universal | Use across multiple domains (in forests) |
- Using Global and Domain Local Groups
- Add Domain User Accounts into Global Groups
- (Optional) Add Global Groups into Another Global Group
- Add Global Group into Domain Local Group
- Assign Resource Permissions to the Domain Local Group
- Class Discussion: Using Groups in a Single Domain
Troubleshooting Domain User Accounts and Groups in Active Directory
Troubleshooting Domain User Accounts and Groups in Active Directory
In a Windows Server environment, user and group issues can lead to login failures, access denials, or policy misapplications. Efficient troubleshooting is key to maintaining productivity and security.
Common Issues with Domain User Accounts
1. User Can’t Log In to the Domain
Causes:
Disabled account
Incorrect password or expired password
User locked out
Workstation not connected to the domain
Fix:
Open Active Directory Users and Computers (ADUC)
Right-click the user → Properties
Check:
Account status
Password settings
“Logon Hours” and “Log on to” restrictions
Use PowerShell:
Get-ADUser jdoe -Properties Enabled, LockedOut, PasswordExpired
2. Group Membership Not Applying Correctly
Causes:
User not added to correct security group
Replication delay between domain controllers
GPOs not linked or not applying to group
Fix:
Run
gpresult /ron the user’s machine to check applied group policiesUse ADUC or PowerShell to verify group membership:
Get-ADUser jdoe -Properties MemberOf
3. Access Denied to Resources
Causes:
User not part of group with proper permission
NTFS or Share permissions misconfigured
SIDHistory issues (after domain migrations)
Fix:
Use Effective Access tab on folder properties to test permissions
Re-add user to group and run:
gpupdate /force
Common Group Issues
1. Group Policy Not Applying
Causes:
Group is a distribution group (not security)
GPO not linked to the correct OU
Block Inheritance or conflicting GPOs
Fix:
Ensure group is a Security Group
Use Group Policy Management Console (GPMC) to trace GPO application
Run:
gpresult /h report.html
2. User Added to Group But No Immediate Effect
Causes:
Token refresh required (user not logged out/in)
AD replication delay
Fix:
Log user out and back in
Force replication:
repadmin /syncall /AdeP
- Cannot Create a User Account or a Group
- Cannot Update Attributes of a User Account
- User Cannot Access Resources
Add comment