Problems faced
- User identities were managed separately on each system, with duplicated local accounts that were hard to disable.
- Linux clients had no uniform way to authenticate against the domain and apply access policies.
- The lab had to be isolated and recoverable, to try out changes to GPOs and domain structure without risk.
- DNS and time synchronization, prerequisites for Kerberos, were a frequent source of errors when joining clients.
Implemented solution
On Proxmox VE, in an isolated network, a Windows Server domain controller hosts Active Directory with integrated DNS. Separate organizational units divide users, groups, Windows computers, and Linux computers, and groups follow the principle of least privilege. Windows clients receive policies through GPOs, while Debian clients join the domain with realmd and use SSSD for authentication, identity resolution, and access control. Domain group membership determines who can log in and who can use sudo on the Linux systems.
Results
- A single domain account gives consistent access to Windows and Linux clients, with centralized deactivation.
- Access and security policies are defined in one place and applied to every system in the lab.
- Snapshots bring the lab back to a known state, making it safe to try out changes to policies and structure.
- The procedure for joining Linux clients is documented and repeatable.
Technical description
The lab reproduces a mixed domain environment in miniature: a Windows Server domain controller and both Windows and Linux clients that authenticate with the same identities. It is used to try out policies, access, and integration procedures before applying them in more sensitive contexts.
Lab architecture
On Proxmox VE, in an isolated network dedicated to the lab, there is a Windows Server domain controller with Active Directory and integrated DNS, a Windows client, and one or more Debian clients. The domain uses a subdomain of a DNS name I control; the examples use ad.example.com. Before any significant change to policies or structure, I take a snapshot of the VMs, so I can return to a known state. The lab documentation records the OU structure, the groups, and the client join procedure.
Components and choices
- Organizational units and groups: users, groups, Windows computers, and Linux computers sit in separate OUs. Access to systems depends on group membership, following the principle of least privilege.
- GPOs: Windows client policies (security, screen lock, resource mapping) are defined centrally and applied per OU.
- DNS and time: clients use the domain controller as their DNS, so they can locate the domain services, and time is synchronized because Kerberos tolerates only a few minutes of skew.
- SSSD and realmd on the Debian clients: realmd automates the join, SSSD handles identity, authentication, and access control. The Linux administrators group gets
sudothrough a rule based on the domain group.
realm discover ad.example.com
realm join --user=amministratore ad.example.com
id [email protected]Note
Joining requires the credentials of an authorized account: enter them interactively and never write them into scripts or versioned files.
Testing and acceptance
After joining, I check identity resolution (id, getent), obtaining a Kerberos ticket (kinit, klist), logging in with a domain account, and home directory creation on first login. On the Windows side, I verify policy application (gpresult) and domain health (dcdiag). I also test disabling an account centrally, confirming that access is denied on all systems. SSSD keeps a credential cache so that login still works when the domain controller is unreachable: the maximum lifetime of this cache is a configurable parameter, to be chosen based on the acceptable risk.
Possible next steps
A second domain controller with replication checks, automatic management of the local administrator credentials, SSH access with Kerberos without typing credentials, and client joins automated with Ansible. A deeper look is in Active Directory in the lab.