What to check before enabling ADSSO (Active Directory) on an EditShare System

What to Check before attempting to enable ADSSO:

• Check the hostnames of all nodes. Make sure they are not maxed out at the 15 character NETBIOS name limit.
  • For instance if all storages nodes are named es-efs-storage01 through es-efs-storage09, then when these are created as NETBIOS names they will all be truncated to es-efs-storage0. Make sure to rename all nodes with more than 14 characters in their names if there will be a conflict.
  • In an HA environment also check that the EFS Stack hostname is also not too long as this is what is used by both MDC's in that configuration.
• Check that each node (MDC or EFS Stack hostname and all Storage nodes) has a DNS HOST A record already created, this needs to be a static record as we do not leverage DHCP. The only exception to this is our Flex+ product which is a separate discussion.
  • To validate that they have an A record and not a CNAME or some other type of record you can use the following methods:

    • dig efs-master.example.com A
      or
      nslookup -type=A efs-master.example.com

    • As an example from lab this is what they should look like:

    • 13:05:39 es-mst:~$ dig es-mst.eslab.org A
      
      ; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> es-mst.eslab.org A
      ;; global options: +cmd
      ;; Got answer:
      ;; WARNING: .org is reserved for Multicast DNS
      ;; You are currently testing what happens when an mDNS query is leaked to DNS
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27060
      ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
      
      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 1232
      ;; QUESTION SECTION:
      ;es-mst.eslab.org.		IN	A
      
      ;; ANSWER SECTION:
      es-mst.eslab.org.	3600	IN	A	192.168.0.204
      
      ;; Query time: 6 msec
      ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
      ;; WHEN: Thu Jul 31 13:05:50 EDT 2025
      ;; MSG SIZE  rcvd: 63
      
      13:05:50 es-mst:~$ nslookup -type=A es-mst.eslab.org
      Server:		127.0.0.1
      Address:	127.0.0.1#53
      
      Non-authoritative answer:
      Name:	es-mst.eslab.org
      Address: 192.168.0.204

• As we are discussing DNS it is also good to confirm that the Domain has properly configured service SRV records as well as the correct number of DC's show up within an nslookup. You will also want to make sure that ALL EditShare Cluster nodes can reach all of the DC's that show up in the list.
  • There are a couple of ways that you can check these from the EditShare Servers themselves, and it is highly recommended to do this before any attempts to bind. If the system cannot resolve the domain or the SRV records before hand you will want to troubleshoot why systemd-resolve and DNSmasq cannot resolve properly.
  • This could be a problem with the DNS IPs they have configured on the NICs, and would be the first place to check when unable to resolve these:

  • 14:21:13 es-mst:~$ nslookup eslab.org
    Server:		127.0.0.1
    Address:	127.0.0.1#53
    
    Name:	eslab.org
    Address: 192.168.0.30
    14:21:52 es-mst:~$ dig eslab.org SRV
    
    ; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> eslab.org SRV
    ;; global options: +cmd
    ;; Got answer:
    ;; WARNING: .org is reserved for Multicast DNS
    ;; You are currently testing what happens when an mDNS query is leaked to DNS
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7373
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1232
    ;; QUESTION SECTION:
    ;eslab.org.			IN	SRV
    
    ;; AUTHORITY SECTION:
    eslab.org.		3561	IN	SOA	eslabdc.eslab.org. hostmaster.eslab.org. 63828 900 600 86400 3600
    
    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
    ;; WHEN: Thu Jul 31 14:22:19 EDT 2025
    ;; MSG SIZE  rcvd: 128
    
    14:21:40 es-mst:~$ nslookup -type=SRV  _ldap._tcp.eslab.org
    Server:		127.0.0.1
    Address:	127.0.0.1#53
    
    _ldap._tcp.eslab.org	service = 0 10 389 eslabdc.eslab.org.

  • You will want to make sure that the number of SRV (service) records should match the number of IPs that are configured as A records on the Domain. This can be a cause of a popup warning in EditShare Connect to leave and rejoin the Domain if they are not properly configured as well as other authentication issues.
  • If there is a DC that the customer notes the systems will not be able to connect to, or there are only a couple of DC's close to the EditShare System, then before attempting to add the system to the Domain you may want to add the following line, with at least 2 DC's minimum, to /etc/editshare/prefs.conf 

    • echo "adsso_dns_servers = dc1.example.com,dc2.example.com,etc..." >> /etc/editshare/prefs.conf

    • Then restart services with: sudo systemctl restart smbd winbind editshare-server
• Check that all systems are leveraging the same NTP as the Active Directory Domain Controllers or DNS servers.
  • This can cause kerberos issues if not properly configured.
  • This can be done easily where the Metadata Controllers(s) in the cluster point to the local NTP server, usually these are the DC's or DNS servers in the environment. And then setting the MDC Time to also be a server:

• Point all other servers in the cluster to the MDC(s)
• Some gateways can also provide NTP.
• If the system has Internet then you can use external NTP servers but it is always better to use something local to stay in sync.
• You can use the following to check servers and also see what the local EditShare servers look like:
  • For each EditShare server, once you have configured them you can have the customer verify or you can if needed with:

    • 13:21:40 es-mst:~$ sudo ntpq -p -n
           remote           refid      st t when poll reach   delay   offset  jitter
      ==============================================================================
       192.168.0.30    69.89.207.99     2 u   58   64  361    0.494  +13.300  14.891

• Once you know that NTP and DNS is configured properly the next step that has made enabling ADSSO successful is to have the customer create the Computer Objects (CO) for each Master or in an HA environment the EFS Stack hostname and all Storage nodes within the Default Computer Container.
  • Some admins might ask if they can put the Objects in a named OU first instead, but we have had better success with them adding it to the Default Computer Container and then moving them once the system is bound and AD Replication has completed in the environment.
  • This step is especially important since going to Ubuntu 20.04 and above, as when a Ubuntu Linux node adds the Computer Object during bind itself, it often will get some Restricted SPN's which prevents us from adding the EFS SPN's.

• Next make sure the below ports are open between the EditShare MetaData Controller(s) and Storage Servers to the Domain Controllers/DNS servers and NTP servers:

  • DNS (53 TCP/UDP): For domain name resolution.
  • Kerberos (88 TCP/UDP): For authentication. Both UDP and TCP are required, as Kerberos uses UDP for most traffic but falls back to TCP for larger tickets.
  • LDAP (389 TCP/UDP): For directory-based queries and communication with Active Directory.
  • SMB (445 TCP/UDP): For file and printer sharing services and other Windows-specific protocols.
  • RPC Endpoint Mapper (135 TCP/UDP): Required for many domain operations, including client-to-domain controller and domain controller-to-domain controller communication. 
  • LDAPS (636 TCP): For secure LDAP communication (LDAP over SSL/TLS).
  • Global Catalog LDAP (3268 TCP): For querying the global catalog in a multi-domain environment.
  • Global Catalog LDAPS (3269 TCP): For secure global catalog queries.
  • NTP (123 UDP): For time synchronization between the Ubuntu client and the domain controller. The next thing to check on is usually the hardest to get correct, which is the permissions needed to be able to add the system into the Domain.
• Due to the fact that we are leveraging Ubuntu and Samba as our OS platform and services to bind the system to the Domain some additional privileges are required, at least during the enablement of ADSSO process.
• Even with providing a Direct OU in the join command for Samba, it still requires that the EditShare AD user has Computer Object create and delete rights on the Default Computer Container. It will also need privileges to be able to update the Computer Objects Service Principal Names.
• If you would like to use an OU, the user still needs the above privileges but will also require Full Control on the OU that the Computer Objects reside in during the Binding due to how Samba interacts with AD and Object Units. Again this is why it is recommended to leave the Objects in the Default Computer Container during the binding process and move them after AD Replication has completed.
• We have had several very secure and locked down environments where even the above security rights and privileges were not enough. This is where another option can be used. The AD Admin can be present and assign the User to a Domain Admin or a much higher Privilege than a normal user while the cluster binds to the Domain. Then once it is complete and ready for reboot they can remove this group or set of privileges from the EditShare Admin user. This is always the toughest conversation, but usually having them on the zoom meeting with us and to have them type in the password for the user then clicking Enable can help with this. If needed feel free to reach out to EditShare Support AD SME's for assistance.
• Always note, that the system requires higher than "Windows Computer" permissions to join Windows Domains as it is limited by the requirements and use of Ubuntu and Samba.

Notes and troubleshooting:

• A huge note with this process, and it is tempting to not take this step but will save you actual time. Especially in large environments. Any time you attempt to bind to the domain and it fails partially through or because of missing permissions, ALWAYS reboot the MDC(s) and the Storage nodes (if the process got that far) before attempting to enable ADSSO again.
  • Along with this we have used the following script to do a more "automatic" restart of the storage nodes when doing reboots within ADSSO enablement. It will save you some headache when you need to do it multiple times if the customer is only giving some privileges to the user or some other problem occurs.

• Another thing to remember if an attempt to enable ADSSO fails, along with rebooting all nodes that were affected. It is also most likely that the Computer Objects for at least the MDC (or EFS Stack hostname ) have been deleted from the Default Computer Container or OU where they were previously created as the system attempts to remove them if it fails to bind correctly. Always make sure to Recreate the CO's.

  • If this problem does happen. I suggest waiting ~15 minutes or to have the AD Admin to force AD replication within a large geo-located AD environment as different DC's might still have the older stale CO's and could cause a problem.

   

If you can follow the above before enabling ADSSO on an EditShare system should work the first time. Remember it is all about preparation of all configuration before hand. Getting appropriate permissions within the Domain, even temporarily, rebooting the systems and recreating computer objects (if needed) between tries and understanding the customers environment.