Active Directory Integration

Introduction

This guide explains how to configure Fusion File Share Server to use Active Directory for user authentication.

What You'll Learn in This Guide

By reading and following the instructions in this guide, you'll learn:

1. How to join your Fusion File Share Server to an Active Directory domain:

   You'll use industry-standard command ine utilities to join the server to your domain, and configure the server's computer account.

2. How to use Active Directory for user authentication in Fusion File Share Server:

   You'll configure Fusion File Share Server to authenticate users against Active Directory, so that users can access shares using their domain credentials.

3. How to test Active Directory integration:

   You'll test that Fusion File Share Server can communicate with the domain controller, and that users can authenticate against Active Directory.

Prerequisites

Before you begin, make sure you have the following:

1. A working Active Directory domain:

   You should have a working Active Directory domain with a domain controller that is reachable from the server you want to join to the domain.

2. An installation of Fusion File Share Server:

   You should have Fusion File Share Server installed on the same network as your Active Directory domain controller. If you haven't installed Fusion File Share Server, you can follow the instructions in the Quickstart and Evaluation Guide.

Joining the Domain and Adding UPN

We will begin by joining the domain using SSSD and adcli. (net from the Samba suite is also supported, but not covered in this guide.)

Perform the following the server you want to join to the domain

1. Install the necessary packages:

   sudo apt -y update && sudo apt upgrade -y
   sudo apt -y install sssd-ad sssd-tools realmd adcli krb5-user sssd-krb5

2. Set the hostname to the FQDN of the server (we will use fusion-srv.acme.local):

   sudo hostnamectl set-hostname fusion-srv.acme.local

3. Configure Kerberos by editing the /etc/krb5.conf file. Note that the default_realm should match the domain name in uppercase:

   [libdefaults]
       default_realm = ACME.LOCAL
       rdns = false

4. Confirm domain discovery by running the following command:

   sudo adcli info acme.local

   The output should be similar to:

   [domain]
   domain-name = acme.local 
   domain-short = ACME 
   domain-forest = acme.local 
   domain-controller = DC1.acme.local 
   domain-controller-site = Default-First-Site-Name 
   domain-controller-flags = pdc gc ldap ds kdc timeserv closest writable full-secret ads-web 
   domain-controller-usable = yes 
   domain-controllers = DC1.acme.local 
   [computer] 
   computer-site = Default-First-Site-Name 

5. Create SSSD configuration at /etc/sssd/sssd.conf, replacing acme.local with your domain name, with the krb5_realm parameter in uppercase:

   [sssd]
   domains = acme.local
   config_file_version = 2
   services = nss
   
   [domain/acme.local]
   ad_domain = acme.local
   krb5_realm = ACME.LOCAL
   cache_credentials = True
   id_provider = ad
   krb5_store_password_if_offline = True
   ldap_id_mapping = True
   use_fully_qualified_names = false
   access_provider = ad

6. Set the permissions on the SSSD configuration file:

   sudo chmod 600 /etc/sssd/sssd.conf

7. Create a computer account and a krb5.keytab file for the server. We will use fusion-srv (without a number) as the server's computer account name. The domain and the computer name must be in uppercase:

   sudo adcli join --domain ACME.LOCAL --service-name=cifs --computer-name FUSION-SRV --host-fqdn fusion-srv.ACME.LOCAL -v

8. Enable and restart the SSSD service:

   sudo systemctl enable sssd
   sudo systemctl restart sssd

9. Confirm that the computer is part of the domain and is albe to query the domain controller, by querying for information about a user (e.g., johndoe):

   id johndoe

   The output should be similar to:

   uid=1414601123(johndoe) gid=1414600513(domain users)
   groups=1414600513(domain users),1414601115(testgroup)

Perform the following the domain controller

1. Open the Active Directory Users and Computers console, right click on the FUSION-SRV  computer account, and click on Properties:

   

2. Open the Attribute Editor tab, and find the userPrincipalName attribute. Click on Edit:

   

   note

   If you don't see the Attribute Editor tab, you may need to enable it by clicking on View > Advanced Features in the Active Directory Users and Computers console.

3. Make sure the userPrincipalName attribute is set to the to cifs/[email protected] (replace the domain name and the computer name with your own), and click OK.

note

Alternatively, you can use PowerShell:

Set-ADComputer -Identity FUSION-SRV -UserPrincipalName cifs/[email protected]

Configuring Fusion File Share Server

Now that the server is configured to operate in the domain environment, we can proceed with the configuration of Fusion File Share Server.

1. Edit your configuration file (e.g., at /etc/tsmb.conf), and add/edit the following parameters:

   ### GLOBAL CONFIGURATION ###
   
   [global]
   . . .
   
   # Perform authentication with Active Directory
   userdb_type = ad
   
   # The domain name
   domain = acme.local
   
   # The computer account name that clients will use to connect to SMB shares
   server_name = fusion-srv
   
   # Configure logging (for testing and diagnostics)
   log_destination = file 
   log_level = 40 
   log_params = path=/var/log/tsmb.log,long,timestamp,time_usec=false,tid,trace,sensitive_data=strip 
   
   . . .
   [/global]

   In the annotated example above, we have configured the following:

   • The userdb_type parameter is set to ad:

     This indicates that we are using Active Directory for user authentication.

   • The domain parameter is set to acme.local:

     This indicates the domain name. Replace this with your own domain name.

   • The server_name parameter is set to fusion-srv:

     This is the computer account name we've chosen when joining the server to Active Directory. That is the name clients will use to connect to SMB shares.

[Optional] Testing Active Directory Integration

You can now check that the Fusion File Share Server server can communicate with the Active Directory domain controller. You can also test how Fusion File Share Server handles user authentication.

1. First, make sure that domain controller is discoverable via DNS.

   Check for the SRV record for _kerberos._tcp for your domain:

   nslookup -q=srv _kerberos._tcp.acme.local

   The output should be similar to:

   Server:         127.0.0.53
   Address:        127.0.0.53#53
   
   Non-authoritative answer:
   _kerberos._tcp.acme.local   service = 0 100 88 dc1.acme.local.
   
   Authoritative answers can be found from:

   Then, check for the SRV record for _kpasswd._tcp for your domain:

   nslookup -q=srv _kpasswd._tcp.acme.local

   The output should be similar to:

   Server:         127.0.0.53
   Address:        127.0.0.53#53
   
   Non-authoritative answer:
   _kpasswd._tcp.acme.local    service = 0 100 464 dc1.acme.local.
   
   Authoritative answers can be found from:

2. Check that you are able to obtain tickets for the cifs service:

   sudo kinit -k -V cifs/[email protected] -t /etc/krb5.keytab

   The output should be similar to:

   keytab specified, forcing -k
   Using default cache: /tmp/krb5cc_0
   Using principal: cifs/[email protected]
   Using keytab: /etc/krb5.keytab
   Authenticated to Kerberos v5

3. Check that the key version number (KVNO) for the cifs service matches between KDC and the keytab file:

   sudo klist -k -t /etc/krb5.keytab

   The output should be similar to:

   Keytab name: FILE:/etc/krb5.keytab
   KVNO Principal
   ---- --------------------------------------------------------------------------
      2 [email protected]
      2 [email protected]
      2 [email protected]
      2 [email protected]
      2 [email protected]
      2 [email protected]
      2 cifs/[email protected]
      2 cifs/[email protected]
      2 cifs/[email protected]
      2 cifs/[email protected]
      2 cifs/[email protected]
      2 cifs/[email protected]
   
   . . .

4. Check that you are able to obtain tickets for user accounts (e.g., johndoe):

   sudo kinit -V [email protected]

   The output should be similar to:

   Using default cache: /tmp/krb5cc_0
   Using principal: [email protected]:
   Authenticated to Kerberos v5

   Then, list the tickets:

   sudo klist

   The output should be similar to:

   Ticket cache: FILE:/tmp/krb5cc_0
   Default principal: [email protected]
   
   Valid starting       Expires              Service principal
   06/01/2024 14:42:22  06/02/2024 00:42:22  krbtgt/[email protected]
           renew until 06/08/2024 14:42:12

5. Now, you can temporarily start the Fusion File Share Server on the node, to validate domain authentication further.

   • First, start Fusion File Share Server on the node:

     sudo /usr/sbin/tsmb-server

   • Then, from a Windows client, try to access the share using the johndoe user account. You should be able to map the share to a drive letter, and read data from the share.

   • After testing, stop the Fusion File Share Server by pressing Ctrl-C in the terminal.

   • Examine the logs at /var/lib/tsmb/tsmb.log to see if there there was a successful LDAP connection to the domain controller. The log should contain lines similar to:

   Using principal [email protected] for AD client
   Resolving SRV RR _ldap._tcp.acme.local
   Found URI[0]: ldap://dc1.acme.local:389
   Resolving SRV RR _gc._tcp.acme.local
   Found URI[0]: ldap://dc1.acme.local:3268
   Trying ldap://dc1.acme.local:389
   Connected to ldap://dc1.acme.local:389
   Our domain SID S-1-5-21-788087510-3421900764-663072633
   Our domain NETBIOS-Name 'ACME'
   • You should also see a ticket inside Fusion File Share Server's ticket cache at /var/lib/tsmb/tsmb_ccache. You can examine it by running:

   sudo klist -c /var/lib/tsmb/tsmb_ccache

   The output should be similar to:

   Ticket cache: FILE:/var/lib/tsmb/tsmb_ccache
   Default principal: [email protected]
   
   Valid starting       Expires              Service principal
   06/01/2024 14:52:32  06/01/2024 15:52:32  krbtgt/[email protected]
   06/01/2024 14:52:32  06/01/2024 15:52:32  ldap/dc1.acme.local@
   06/01/2024 14:52:32  06/01/2024 15:52:32  ldap/[email protected]