En/3.2/File sharing and Domain Services
Configuring Zentyal as a Standalone Domain server
Enabling the File Sharing module has to be done carefully. The reason is that during module activation the Domain is provisioned. This means that the LDAP, DNS and Kerberos data is initialized, creating all the LDAP objects, Kerberos security principals, DNS zones and so on. The operation can be reverted but it's certainly more difficult than disabling and re-enabling other modules.
Before enabling the File Sharing module for the first time make sure that:
- You have configured the operation mode, by default Domain Controller, but you can also configure your server
to be an additional controller joined to another node. In the latter case, configure the server role and credentials to join the domain before enabling the module and look at the other instructions below. If this server is the first (or the only) Domain Controller, you don't have to modify anything. Check the operation mode from Domain ‣ Settings
- Your local domain and host name parameters are correct. You can check this from System ‣ General,
Hostname and Domain section. If you want to change these, save changes and reboot the machine before enabling the module.
- In the DNS module configuration, you will have a DNS "local" domain that matches the one you have configured in
System ‣ General, this domain has to contain the server Hostname as an A register (inside the Hostnames section) and this hostname has to have at least one local IP address. You have to associate all the internal IPs addresses where you want to provide Domain services to the server's DNS hostname.
- NTP module is installed and enabled, and your clients are receiving NTP information from the server, generally though DHCP.
Once you have enabled File Sharing you can provide File Sharing functionality, join Windows Clients to your Zentyal server, Configure and Link the Group Policy Objects and accept connections from additional controllers, either Windows Server or Zentyal.
Configuring a file server with Zentyal
Once the File Sharing module is enabled (either as a Domain Controller or as an Additional Domain Controller), your server can act as an SMB/CIFS File server.
By default each LDAP user has a personal /home/<username> directory on the server. If the File Sharing module is active this directory will be accessible to the specific user (and only to the user) through SMB/CIFS. Furthermore, if a Windows client host is joined to the domain this directory will be automounted as drive H:.
To create a shared directory, use File Sharing, Shares tab and click Add new.
Enabled:Leave it checked if this directory needs to be shared. Disable to stop sharing.
Share name:The name of the shared directory.
Share path:Directory path to be shared. You can create a sub-directory within the Zentyal specific directory /home/samba/shares, or use an existing file system pathway by selecting Filesystem path.
Comment:A more detailed description of the shared directory simplifies management of shared assets.
Guest access:Enabling this option allows a shared directory to be accessible without authentication. Any other access settings will be ignored.
Shared directories can be edited using Access control. By clicking on Add new, you can assign read, read/write or administration permissions to a user or group. If a user is a shared directory administrator, he/she can read, write and delete any user files within that directory.
If you want to store deleted files in a special directory called RecycleBin, you can check the Enable recycle bin box using File Sharing, Recycle bin tab. If you do not want to use this for all shared resources, add exceptions using Resources excluded from Recycle Bin. Other default settings for this feature, such as the directory name, can be modified using the file /etc/zentyal/samba.conf.
Using File Sharing, Antivirus tab, virus scanning of shared resources can be enabled and disabled. Exceptions can also be defined where virus scanning is not required. To use this feature the Zentyal antivirus module must be installed and enabled.
If a virus is detected in the configured shares, the file will be moved to an special quarantine folder /var/lib/zentyal/quarantine. This behavior blocks the spreading of the malware between the users, but the system administrator will still be able to inspect the file (sometimes the malware is embedded into to useful files, like spreadsheet macros)
SMB/CIFS is a really common protocol that can be used natively on any Windows Client, most flavors of Linux (Using the Nautilus file manager, for example), and using external applications, also on Android and iOS.
Furthermore, the File Sharing daemon is tightly integrated with the Kerberos subsytem (See Kerberos Authentication System below), meaning that if your client is joined to the domain or has acquired the Kerberos TGT by other means, the ACL explained above with be honored without any user intervention.
Joining a Windows client to the domain
The process of joining a Windows Client to your domain is identical to joining with a Windows Server.
First of all, you need to create a Domain Admin, not to be confused with Zentyal's admin account. The Domain Admin is any LDAP user that you add to the group Domain Admins
Now, accessing the Windows client:
- Make sure Zentyal server and the Windows client can reach each other though a local network
- Make sure the Windows client has Zentyal as its DNS server
- Make sure both Server and client are perfectly time sync'ed using NTP
After checking the preconditions, you can join the domain the usual way
You will then enter the Domain Admin user to join
After the process is complete, the Windows host will appear under the Computers OU and will apply the configured GPOs and obtain Kerberos tickets automatically (See sections below).
Now, you can log in your Windows client using the LDAP users created in Zentyal's LDAP.
Kerberos Authentication System
Kerberos is an automatic authentication service that integrates with Samba4/Active Directory and all the compatible services across your domain.
The client only needs to provide his/her credentials once to obtain the "main" ticket, Ticket Granting Ticket.
This is done automatically with a Windows client joined to the domain, login credentials are sent to the Domain Controller (any of them), and if the LDAP user is correct, the controller automatically provides the TGT along with other tickets needed for file sharing to the client.
You can list the tickets currently active in your client using the command 'klist'
In Debian/Ubuntu systems it also possible to obtain the Kerberos TGT installing the package heimdal-clients
Once the client has obtained the Kerberos TGT, all the other Kerberos-compatible services in your domain will accept Kerberos tickets, that are automatically issued on demand to authenticate the users.
This mechanism has two main advantages:
- Security: Passwords are secured while they travel through the local networks, the system is robust against sniffing or replay.
- Convenience: User just needs to provide credentials once, the other auth tickets are obtained transparently. For example, you
can use a non-transparent proxy without bugging your users with a login screen each time they start navigating.
Zentyal Services currently compatible with Kerberos authorization:
- Samba File Sharing (SMB/CIFS)
- HTTP Proxy
- Electronic mail
- Groupware (Zarafa)
It's important to note that all Domain Controllers are integrated in the same Kerberos context. For example, a Windows Server can provide the Kerberos TGT and then the client can use an HTTP Proxy offered by a Zentyal Server joined to the same domain, without having to enter credentials again.
Group Policy Objects
The Group Policy Objects are policies associated to containers of the Domain.
Using GPOs, you can autoconfigure and enforce policies, global policies for all the domain or specific policies for Organizational Units or Sites.
Typical uses of the GPOs include:
- Installing and upgrading software packages without user intervention
- Configuring the HTTP Proxy in the browsers or the Certification Authority of the domain
- Deploying scripts to be executed in the client at login or logoff time
- Restricting part of the configuration of the Windows client to the user
Zentyal can import and enforce any GPO when joined to a Window Server through SYSVOL(9) replication, which is done automatically. Using own Zentyal webadmin you can create new GPOs related to login and logoff scripts.
Going to Domain ‣ Group Policy Objects, you can see the Default Domain Policy that will be applied to all hosts in the domain and the Default Domain Controllers Policy, that will apply to the controller servers.
Clicking on the configuration icon of a GPO, you can configure the login and logoff scripts, that can be associated with the Computers or with the Users.
Once you have created a GPO, you have to link it to a container in order to apply it over a set of computers and/or users. You can do this from Domain ‣ Group Policy Links
Even if you don't have any Windows Server in your domain, it's still possible to create and enforce any GPO using a Windows client joined to the domain. Installing Microsoft RSAT tools and logging into the client using the Domain Administrator LDAP account, you will use RSAT interface to design the desired GPO.
The GPOs will be automatically added to the domain SYSVOL and enforced by the Zentyal server.
Joining Zentyal server to an existing domain
Integrating Samba4 technologies, Zentyal is able to become an Additional Controller of an existing domain, joining a Windows Server or any Samba4-based controller, like another Zentyal server.
After domain join, LDAP, the DNS domain associated with samba (local domain), Kerberos and SYSVOL information will be transparently replicated.
There are some points to verify before joining another controller:
- Zentyal's local LDAP data will be destroyed, since it will be overwritten with the domain LDAP information
- All the controllers have to be perfectly time synced, preferably using NTP
- When the users are synchronized from the other controller, Zentyal will create their associated /home/<username>
directories, check that these will not collide with pre-existing home directories
- All the controllers have to belong to the same domain
- DNS configuration is critical, other domain controllers will try to push the information to the IP provided
by your DNS system
If you have external IPs associated to your hostname (i.e. zentyal.zentyal-domain.lan), you may have synchronization problems if any of the controllers tries to use that IP to push data. Even if you have several internal IPs, you may have the same problem, because the DNS system performs round-robin when answering DNS queries. If that's your case, you may want to uncomment sortlist = yes on the /etc/zentyal/dns.conf file and restart the DNS server. This way, the DNS system will always put the IP that matches the query netmask first.
Once you have checked all the points, you can join the domain from Domain ‣ Settings
Saving the changes will take longer than usual, because Samba4 will be reprovisioned and all the domain information replicated.
Exploring the LDAP tree from the Windows server will also show the new domain controller
From now on, DNS, LDAP and Kerberos information will be synchronized both ways. You can manipulate the LDAP information (users, groups, OUs) in any of the controllers and the information will be replicated to the others.
The process of joining to another Zentyal server is exactly the same.
All the domain controllers have the mentioned domain information, however there are some specific roles that belong to an specific server host, these are called FSMO roles or Operations Masters.
Operation Masters are critical to the domain functioning, there are five FSMO roles:
- Schema master: LDAP schema master, defines and pushes updates of the LDAP format
- Domain naming master: Creates and Deletes the domains of the forests
- Infrastructure master: Provides domain-unique GUID, SID and DN IDs
- Relative ID Master: relative IDs assigned to the Security Principals
- PDC Emulator: Compatibility with Windows 2000/2003 hosts, root time server
Using the Total Migration script you can transfer all these roles to a Zentyal server joined to the domain.
From the /usr/share/zentyal-samba directory:
administrator@zentyal:/usr/share/zentyal-samba$ sudo ./ad-migrate WARNING: This script will transfer all FSMO roles from the current owners to
the local server. After all roles has been successfully transferred, you can shutdown the other domain controllers.
Do you want to continue [Y/n]? Y
Checking server mode...
Checking if server is provisioned...
Synchronizing sysvol share... syncing [SYSVOL] files and directories including ACLs, without DOS Attributes
Transferring FSMO roles... Transferring Schema Master role Transferring Domain Naming Master role Transferring PDC Emulation Master role Transferring RID Allocation Master role Transferring Infrastructure Master role
Migrated successfully!From now on, Zentyal is the only critical controller in the domain, and all the features should continue working even if you turn off the others controllers, save scalability and network considerations.
It's important to check the list of current known limitation of Samba4 before planning your domain:
- Only one domain in the forest, Samba doesn't support multiple domains
- Your hostname can not match your NETBIOS name, the NETBIOS name is generated using the
left part of the domain, for example, if your hostname is 'zentyal' your domain can not be 'zentyal.lan', but it could be 'zentyal-domain.lan'
- Functional Domain level min 2003, current max 2012 (not 2012R2)
- Trust relationships between domains and forests are not supported
- GPOs will be synced from Windows servers to Zentyal servers, but not the other way around
- It's not possible to combine Samba4 with master/slave synchronization
- Only ASCII names for the users (no tilde, starting by number, etc...)