Short answer: NetSmart 1.0.7 can deploy an optional Samba Active Directory Domain Controller (AD DC) for Windows domain join and centralized user, computer, DNS, Kerberos, LDAP, SMB/RPC, and Global Catalog services. Organizations that do not need a Windows domain can continue using NetSmart's lighter built-in Directory service.
This release gives small companies, labs, branch offices, and self-hosted environments a clearer choice. Use the Samba AD DC when Windows computers must join a domain and use AD-compatible discovery and authentication. Use the built-in Directory service when applications need a lightweight LDAP directory without the operational scope of a complete Windows domain.
What is a Samba Active Directory Domain Controller?
Samba is open-source software that can provide Active Directory-compatible domain controller services. A domain controller stores directory objects, authenticates users and computers, publishes services through DNS, and supports the protocols Windows clients expect when joining and operating inside a domain.
According to the official Samba AD DC documentation, domain members use DNS to locate services such as LDAP and Kerberos. This means DNS is part of the identity system, not an optional convenience.
What NetSmart 1.0.7 adds
- An optional Samba Active Directory Domain Controller deployment
- Windows domain join support
- Integrated AD DNS for domain and service discovery
- Kerberos authentication for users, computers, and services
- LDAP directory access and AD-compatible object discovery
- SMB/RPC services used by Windows domain administration and policy workflows
- Global Catalog services for broader directory searches and discovery
- Docker port and configuration support, health status, and deployment documentation
The deployment is optional. Enabling it is an architectural decision because an AD domain controller becomes a central dependency for sign-in, name resolution, and service discovery.
How Windows domain join works
- DNS discovery: the Windows client queries the domain's DNS service for records that identify available domain controllers and services.
- Controller contact: the client reaches the selected controller through the required AD protocols.
- Computer identity: the domain creates or validates a computer account and establishes trust material for that machine.
- User authentication: domain users can authenticate through Kerberos, with supporting directory and Windows protocols available when required.
- Ongoing discovery: the client continues using domain DNS to find controllers, Kerberos, LDAP, Global Catalog, and related services.
A common cause of failed domain joins is incorrect client DNS. A Windows client intended to join the domain must query DNS that can resolve the AD zone and its service records. Pointing the client only at a public resolver prevents it from discovering the private domain correctly.
Services provided by the optional AD deployment
| Service | Role in the Windows domain |
|---|---|
| DNS | Publishes the records clients use to locate domain controllers, Kerberos, LDAP, and Global Catalog services. |
| Kerberos | Provides ticket-based authentication for domain users, computers, and compatible services. |
| LDAP | Exposes directory objects, attributes, groups, computers, and searchable identity data. |
| SMB/RPC | Supports Windows domain communication, administration, and file-based domain resources. |
| Global Catalog | Supports directory-wide discovery and searches expected by AD-aware clients and tools. |
Expanded built-in Directory service
NetSmart 1.0.7 also expands its built-in Directory service. It adds AD-compatible discovery, attributes, searches, and administrator operations while retaining the original lightweight LDAP mode.
This does not make every LDAP deployment a Windows domain. It means applications and administrators can use a broader set of familiar directory behaviors without being forced to deploy Samba AD. Windows domain join still requires the optional AD DC deployment and its complete protocol set.
Samba AD DC or lightweight LDAP?
| Requirement | Recommended NetSmart option |
|---|---|
| Join Windows PCs to a domain | Optional Samba Active Directory Domain Controller |
| Kerberos-backed Windows domain authentication | Samba AD DC |
| AD DNS, SMB/RPC, and Global Catalog | Samba AD DC |
| LDAP authentication for an internal application | Built-in Directory service may be sufficient |
| Simple users, groups, attributes, and searches | Built-in lightweight LDAP mode |
| Lower operational complexity without Windows domain join | Built-in Directory service |
Deployment planning checklist
- Choose a stable internal DNS domain and Kerberos realm before provisioning.
- Assign the NetSmart host a stable address and hostname.
- Configure domain clients to use the AD-capable DNS service.
- Publish only the required Docker ports on trusted networks.
- Keep host and client clocks synchronized because Kerberos is time-sensitive.
- Back up directory data, DNS data, configuration, and recovery credentials.
- Test user sign-in, computer join, DNS discovery, and administrator recovery before production use.
- Plan a second domain controller when the domain must survive one controller becoming unavailable.
The Samba project recommends two or more domain controllers for production failover. A single controller can be practical in a lab or small non-critical installation, but it remains a single point of failure for domain authentication and discovery.
Security practices for a self-hosted Windows domain
- Do not expose AD, LDAP, SMB/RPC, Kerberos, or Global Catalog ports directly to the public internet.
- Place the domain controller on trusted network segments and restrict management access.
- Use named administrator accounts for routine work and protect emergency credentials separately.
- Apply operating-system and NetSmart updates after reviewing release notes and backups.
- Monitor DNS, directory, Kerberos, and container health rather than relying only on successful sign-in.
- Document the realm, domain, DNS configuration, backup process, and recovery procedure.
Frequently asked questions
Can Windows computers join the NetSmart domain?
Yes. NetSmart 1.0.7 adds an optional Samba AD DC deployment intended for Windows domain join and the associated AD-compatible services.
Does Samba AD require its own DNS?
Domain clients must use DNS that can resolve the AD zone and service records. NetSmart's optional deployment includes integrated DNS for this purpose.
Is the built-in Directory service the same as Active Directory?
No. The expanded Directory service provides lightweight LDAP plus more AD-compatible discovery, attributes, searches, and administrative operations. A full Windows domain uses the optional Samba AD DC deployment.
Can one domain controller be used in production?
It can operate, but it creates a single point of failure. Environments that depend on domain availability should plan multiple domain controllers, tested backups, and documented recovery.
Why is time synchronization important?
Kerberos validates time-sensitive tickets. Excessive clock differences between clients, services, and the controller can cause authentication failures.
One panel, two directory strategies
NetSmart 1.0.7 does not force every environment into Active Directory. It adds a complete optional Samba AD path for Windows domains while continuing to improve the lightweight built-in Directory service. That separation lets administrators choose the smallest identity architecture that satisfies their actual requirements.
Explore NetSmart features and deployment information or review the NetSmartApp image on Docker Hub.