Corentin 8e1b06e090 Initial lab release: Docker-based Active Directory lab

Complete Active Directory teaching environment based on dockurr/windows:
- Windows Server domain controller, Windows 11 client, Debian 12 client
- docker-compose orchestration, env-driven configuration
- Bilingual documentation (FR + EN) for students
- Dual approach (GUI + PowerShell) in every procedure
- Instructor course plan and reference scripts
- RDP launcher scripts for Linux, macOS and Windows

Made by AcadéNice - https://acadenice.fr/

2026-04-17 11:29:49 +02:00

3 KiB

Raw Blame History

SMB shares and NTFS permissions

Goal: expose three shares on DC01, secure them with the AD groups created earlier, and verify permissions behave as expected.

Note: in production, shares live on a dedicated file server, not on a DC. We simplify here.

Shares to create

Share	Path	Access
`Common`	`C:\Shares\Common`	read for everyone, write for Direction/Teaching/Admin
`Teaching`	`C:\Shares\Teaching`	restricted to GG_Teaching
`Direction`	`C:\Shares\Direction`	restricted to GG_Direction

AGDLP reminder

Permissions are never placed directly on global groups or users. They go on a domain local group, which contains the matching global groups.

Example for Common:

Global groups: GG_Teaching, GG_Students, ...
DL groups: DL_Share_Common_R (read), DL_Share_Common_RW (write)
NTFS ACLs: set on DL_Share_Common_R and DL_Share_Common_RW
Nesting:
- GG_Students member of DL_Share_Common_R
- GG_Teaching member of DL_Share_Common_RW

Create folders and shares

GUI

Create C:\Shares\Common in Explorer
Right-click > Properties > Sharing > Advanced Sharing
Tick Share this folder, name the share, click Permissions
Remove Everyone, add the relevant AD groups with appropriate rights
Security tab > Edit: define NTFS ACLs
Disable inheritance if you want an explicit ACL

PowerShell

Key cmdlets: New-SmbShare, Get-Acl, Set-Acl, FileSystemAccessRule.

New-Item -Path C:\Shares\Common -ItemType Directory -Force

New-SmbShare -Name "Common" -Path "C:\Shares\Common" `
    -FullAccess "CORP\Domain Admins" `
    -ReadAccess "CORP\DL_Share_Common_R" `
    -ChangeAccess "CORP\DL_Share_Common_RW"

NTFS permissions:

$acl = Get-Acl "C:\Shares\Common"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    "CORP\DL_Share_Common_R", "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($rule)
Set-Acl "C:\Shares\Common" $acl

Repeat per (DL, rights) pair.

Test from a Windows client

On PC01, logged in as an AD user:

\\DC01\Common

via Run (Win + R) or the Explorer address bar.

Tests:

as a GG_Students member: read OK, write denied
as a GG_Teaching member: read and write OK
attempt to access \\DC01\Teaching as a student: denied

Test from Linux

If linux01 is domain-joined (see 07-join-linux-client.md):

smbclient //DC01/Common -U pmartin%<password>
# then:
ls
put /etc/hostname

or mount via cifs-utils:

mkdir /mnt/common
mount -t cifs //DC01/Common /mnt/common -o username=pmartin,domain=CORP

Notes

Both layers (Share and NTFS) apply. The effective access is the intersection. Common practice: Full Control at share level, then refine via NTFS.
An already-connected user does not see group membership changes until relogon (or klist purge).
Never ACL a user directly. They leave, you are left with cleanup.

06-join-windows-client.md to join PC01 and test these shares from a client.

3 KiB Raw Blame History