Forums

Share this post:
Responses (26)
  • Accepted Answer

    Sunday, September 30 2018, 06:39 PM - #Permalink
    Resolved
    0 votes
    I've made substantial edits to the first post so it now carries the latest information as we know it.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 25 2018, 07:46 PM - #Permalink
    Resolved
    0 votes
    I've done a little testing with ClearOS 6.x and, as it has not had the Samba update, you still need to enable "Windows 10 Domain Logons" in Windows Networking (Samba) and therefore enable SMB1 in Win10. Do not set "max protocol = SMB2"
    The reply is currently minimized Show
  • Accepted Answer

    Monday, September 24 2018, 05:35 PM - #Permalink
    Resolved
    0 votes
    It looks like we are back in business with the old ClearOS Domains and better than before.

    In Windows 10 there is an update coming through, KB4458469, which fixes the Domain Join issue. If you can't wait, you can install it directly from the Microsoft Update Catalog. Once installed your Windows OS Build version should be 17134.319 (Windows Key > Gear Wheel > System > About)

    At the same time there has been an update to Samba in ClearOS7. I received mine on 11 Sep and it updated to v4.7.1-9.v7. With this update there is no need to enable SMB1 in Windows 10 1803 or later and there is no need to Enable "Windows 10 Domain Logons" in Windows Networking (Samba).

    In ClearOS6, Samba defaults to SMB1 so I'd still expect you to need to enable SMB1 in Windows 10 1803. You can try enabling SMB2.0 in samba by setting:
    max protocol = SMB2
    in /etc/samba/smb.conf and seeing if you can join a domain without enabling SMB1 in Windows 10 1803. I ran with this set up for years in Simple Fileserver mode but I never used domains.

    I'd love it if people can independently confirm what I've found in ClearOS7 and also test ClearOS6 with domains if they able to, then post back to this thread with the results.

    Note, when testing, please remember to do the registry change. I overlooked it on a new PC and it failed ......

    [edit]
    If you postponed the 1803 update, possibly the fastest way of installing it is to upgrade from Microsoft's Upgrade Link. You can upgrade directly from there or download the ISO if you want to upgrade more than one machine. If you download the ISO onto your Win 10 machine, double clicking on it will open the ISO. From there, double-clicking on setup.exe will launch the update.
    [/edit]
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 14 2018, 03:35 PM - #Permalink
    Resolved
    0 votes
    I don't think editing the hosts file will help as it won't resolve SRV records. Also, because of your zone record, dnsmasq probably ignores the hosts file and tries to hand off to the container. You need to get the domain resolving correctly. Double check the firewall rules, especially the last one in 11-docker-samba (it is probably better to use the longer complex form of the rule), the "server" record in your dnsmasq file, and that the bindings are working ("netstat -npl | grep :53)" where you should see dnsmasq binding to most interfaces and docker to the one virtual IP you set up.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 14 2018, 03:15 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:
    /etc/resolv-peerdns.conf should have been correct all along and refers to your upstream resolver.


    The search domain was incorrect, as it pulled it must have from the DHCP server when I originally installed.

    Nick Howitt wrote:
    Have you checked you can resolve correctly the DC's FQDN both from inside and outside the container? Unfortunately for me, my set up has suddenly started resolving the DC's FQDN into 2 IP's, the container's internal and external IP. This has only been happening today, I think, or possibly yesterday after I did the domain join.


    The DC FQDN was only resolving from inside the container. I manually added it to /etc/hosts outside of the container to match the /etc/hosts that was inside the container. Both resolve to the container's external IP.

    Same error trying to connect though. I've been looking through as many log files as I can, but can't find any entry that is even remotely similar to the error message. Am I correct in assuming it's being generated by the Active Directory Connector app?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 14 2018, 02:54 PM - #Permalink
    Resolved
    0 votes
    /etc/resolv-peerdns.conf should have been correct all along and refers to your upstream resolver.

    I have been concerned about DNS recursion because sometimes my load averages go have been going haywire. In order to break any possible circle, I've made the following changes from the docker run command:
    1 - remove the line:
    -e "DNSFORWARDER=172.22.22.1" \
    Manually you can comment out the "dns forwarder" lines in /var/clearos/samba/config/smb.conf. This will stop the Samba resolver resolving anything except domain FQDN's
    2 - remove the first "--dns 172.22.22.2 \" line. This will stop the container resolving back into itself. It may be OK but I don't see it is needed. The other line is needed to set the external resolver for the container, I think, otherwise it falls back to the default external resolver (OpenDNS?)

    Have you checked you can resolve correctly the DC's FQDN both from inside and outside the container? Unfortunately for me, my set up has suddenly started resolving the DC's FQDN into 2 IP's, the container's internal and external IP. This has only been happening today, I think, or possibly yesterday after I did the domain join.

    Unfortunately I need to cut back the time I've been putting back into this, especially as my next step is possibly a full re-installation.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 14 2018, 12:35 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    @Cameron,
    I think I have found the issue. Please make sure the Default Domain in Webconfig > Network > Settings > IP Settings is the same as the domain you are joining. Then /etc/resolv.conf and /etc/resolv-peerdns.conf get set as I'd expect.


    I checked the webconfig IP settings page, but the domain was already set correctly, so /etc/resolv.conf is correct.

    I manually edited /etc/resolv-peerdns.conf and restarted dnsmasq, but still getting the same error when trying to connect using the Active Directory Connector.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 14 2018, 08:54 AM - #Permalink
    Resolved
    0 votes
    @Cameron,
    I think I have found the issue. Please make sure the Default Domain in Webconfig > Network > Settings > IP Settings is the same as the domain you are joining. Then /etc/resolv.conf and /etc/resolv-peerdns.conf get set as I'd expect.

    Please can you post back with your findings and I'll update the HowTo.

    [edit]
    BTW, during yesterday I noticed a couple of typo's in the 11-docker-samba file. Lines should begin with "$IPTABLES" and not "iptables" when run from a firewall file. "iptables" should only be used from the command line. Depending on when you did your set up, you may or may not have picked up the corrected version.
    [/edit]
    The reply is currently minimized Show
  • Accepted Answer

    Monday, August 13 2018, 09:38 PM - #Permalink
    Resolved
    0 votes
    I am in discussion with the dev's now as I hit the same or a similar issue. Please can you check your /etc/resolv.conf. In an LDAP system it should show something like (from my production box):
    # Please do not edit this file.
    # See http://www.clearcenter.com/support/documentation/clearos_guides/dns_and_resolver
    domain howitts.co.uk
    nameserver 127.0.0.1
    After installing the AD connector on my test box, mine read:
    ; generated by /usr/sbin/dhclient-script
    search howitts.co.uk test.lan
    nameserver 172.17.2.1
    For some reason dhclient-script has taken over it.

    Please let me know if you're in the same boat. You can fix it by changing the nameserver to 127.0.0.1 and restarting dnsmasq, but it reverts on every boot.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, August 13 2018, 09:21 PM - #Permalink
    Resolved
    0 votes
    I set up a new install using your ClearOS with Docker/Samba guide and it went well.

    Docker is up and running, however I'm having trouble connecting the Active Directory Connector to it.

    I'm getting the following:
    Failed to join domain: failed to lookup DC info for domain 'DOMAIN' over rpc: {Not Enough Quota} Not enough virtual memory or paging file quota is available to complete the specified operation.


    The system has plenty of RAM and HDD space available. Any suggestions?
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, August 11 2018, 02:05 PM - #Permalink
    Resolved
    2 votes
    HowTo set up ClearOS with Docker/Samba as an Active Directory Domain Controller

    If you follow this guide you should end up with a fully functioning Active Directory Domain Controller running in ClearOS. On a new installation of ClearOS you should be able to use the Active Directory Connector instead of OpenLDAP for you directory server. Dave Loper is working on a migration path for existing installations.

    1. Decide on a LAN IP for your Docker/Samba installation. This should be a fixed IP on your LAN, so outside if DHCP scope. My ClearOS LAN interface is 172.17.2.1/24 and I am going to use 172.17.2.2 for my Docker/Samba installation. Wherever you see 172.17.2.2 in this guide substitute it for your chosen LAN IP and 172.17.2.1 for your ClearOS LAN interface IP.

    2. In Webconfig > Network > Settings > IP Settings > Add Virtual button set up your Docker LAN IP as a virtual IP, attached your LAN interface with the same Netmask as your LAN. Note the name of the name if the interface it creates.

    3. Add a file /etc/sysconfig/network-scripts/ifcfg-docker0 and in it put:
    4. DEVICE=docker0
      TYPE="Bridge"
      ONBOOT="yes"
      USERCTL="no"
      BOOTPROTO="none"

    5. Note, if you're doing a fresh install with Community, do not install Windows Networking before you activate the AD Conector.
    6. Change the ClearOS Samba port bindings to bind so it does not bind to the virtual interface. Edit /etc/samba/smb.conf and set:
      bind interfaces only = yes
      interfaces = lo enp2s0f1
      nmbd bind explicit broadcast = yes
      socket address = 172.22.22.1
      In the "interfaces" section, list all your normal LAN interfaces and possibly the tun interfaces and docker0 interface. If you do an "ifconfig" you'll see a full list from which to make your choice. Do not add the virtual interface. For the "socket address", just set it to one of your LAN interface IP's. this is a bit of a kludge. Then restart Windows Networking from the webconfig (or the smb, nmb and winbind services).

      [edit]
      Note that the Gateway Management/DNSThingy manager, dnsthingymgr, must not be running before you start the docker samba container as that also binds to udp:137 and will stop the docker samba container from starting. To disable it, disable Gateway Manager/DNSThingy. If they are already disabled, enable them and disable them again. Gateway Manager/DNSThingy can be started after docker/samba starts. Alternatively, for a permanent fix you can:
      echo "disable-neighbour-discovery" > /etc/dnsthingy/dnsthingymgr.conf

      or change the netbios ports in dnsthingymgr to something silly. In /etc/dnsthingy/dnsthingymgr.conf:
      netbios-listen-port=54321
      netbios-reply-port=54322

      [/edit]

    7. Change the port bindings in dnsmasq not to bind on the virtual interface and, jumping ahead of ourselves set up a split DNS. Create a file /etc/dnsmasq.d/docker-samba (you can call it what you want as long as it is in this folder) and add the lines:
    8. bind-dynamic
      except-interface=enp2s0f1:0
      server=/howitts.local/172.22.22.2
      enp2s0f1:0 is my virtual interface and howitts.local is my domain. Instead of "except-interfaces=" you can do "interfaces=" and list all your interfaces, including docker0. Restart dnsmasq with a:
      systemctl restart dnsmasq.service

    9. Install app-docker, set it to start on boot and start it, then restart the firewall and dnsmasq:
    10. yum install app-docker
      systemctl enable docker.service
      systemctl start docker.service
      systemctl restart firewall.service
      systemctl restart dnsmasq.service
      Note that if you already had docker installed and running, you'll need to restart it after creating your virtual interface

      Also note that Docker tries to choose a free /16 network for its docker0 interface. It may be worth at this point doing an "ifconfig" and checking it has chosen a subnet which does not clash with any of yours. It does not seem to spot VLAN subnets in use and can have other issues (mine, obscurely, is a VM running with natted interfaces on my desktop which has a local IP in the 172.17.2.0/24 subnet). If this is the case, see the "Configure the default bridge network" section of this doc and add a line between the braces:
      "bip": "your_manual_subnet"
      in /etc/docker/daemon.json and restart the docker service and dnsmasq. A /24 subnet should be big enough for just a domain controller docker container.

    11. Now install the docker container from https://github.com/Fmstrat/samba-domain:
    12. docker pull nowsci/samba-domain

    13. Prep your data folders:
    14. mkdir -p /var/clearos/samba/data
      mkdir -p /var/clearos/samba/config

    15. Start your Docker/Samba container which will be called "samba":
    16. docker run -t -i -d \
      -e "DOMAIN=HOWITTS.LOCAL" \
      -e "DOMAINPASS=SomeC0mplexPassword" \
      -e "DNSFORWARDER=172.22.22.1" \
      -e "HOSTIP=172.22.22.2" \
      -e "NOCOMPLEXITY=true" \
      -p 172.22.22.2:53:53 \
      -p 172.22.22.2:53:53/udp \
      -p 172.22.22.2:88:88 \
      -p 172.22.22.2:88:88/udp \
      -p 172.22.22.2:135:135 \
      -p 172.22.22.2:137-138:137-138/udp \
      -p 172.22.22.2:139:139 \
      -p 172.22.22.2:389:389 \
      -p 172.22.22.2:389:389/udp \
      -p 172.22.22.2:445:445 \
      -p 172.22.22.2:464:464 \
      -p 172.22.22.2:464:464/udp \
      -p 172.22.22.2:636:636 \
      -p 172.22.22.2:1024-1044:1024-1044 \
      -p 172.22.22.2:3268-3269:3268-3269 \
      -v /etc/localtime:/etc/localtime:ro \
      -v /var/clearos/samba/data:/var/lib/samba \
      -v /var/clearos/samba/config:/etc/samba/external \
      --dns-search howitts.local \
      --dns 172.22.22.2 \
      --dns 172.22.22.1 \
      --add-host localdc.howitts.local:172.22.22.2 \
      -h localdc \
      --name samba \
      --privileged \
      --restart unless-stopped \
      nowsci/samba-domain
      Notes:
      DOMAIN is the name of your domain. Best practice says to use a subdomain of your proper external domain which does not resolve externally. As an example, my proper domain is howitts.co.uk so a best practice AD domain could be ad.howitts.co.uk and not howitts.local as in my example. This domain name should also be the one you put into your /etc/dnsmasq.d/samba-domain.
      Change all occurrences of howitts.local to your domain name.
      I have set password complexity off but the start script only changes the settings after the administrator password is set so you must use a complex administrator password. You can leave complexity on by removing the "COMPLEXITY" line. You can also change the administrator password to something else (non-complex) later on.
      localdc is the name given to the domain controller (not very imaginative. I've just used their example for now)
      Compared to the example, I've added "--restart unless-stopped \" to enable the container to start automatically when docker starts.

      [edit]
      It may be worth leaving out:
      	-e "DNSFORWARDER=172.22.22.1" \
      from the start up command. This will remove the ability of samba to resolve IP's externally, but is should not have to as the normal ClearOS dnsmasq DNS server looks after everything except domain lookups which must be handled by Docker/Samba. The container itself can still resolve externally because of the "--dns" lines.
      I have noticed high loads at times and it may be because of DNS lookups going round and round between ClearOS/dnamasq and Docker/Samba.
      [/edit]

    17. After a few seconds check the container is running with a:
    18. docker ps
      If you have just a number of capitalised headers wrapped over a couple of lines, it is not running. You should see some output where you can match a lot of it to the start up command. If it fails, for me it was due to lack of password complexity and you'll see the error in /var/log/messages. If that is the case, the best thing to do is to do a:
      docker rm samba
      Then remove everything in /var/clearos/samba/data and /var/clearos/samba/config and try again with a different password.

    19. You now need to make a final adjustment to the firewall. For this you need to know Docker/Samba's internal IP, so run the command:
    20. docker inspect --format '{{ .NetworkSettings.IPAddress }}' "samba"
      This will return the internal IP. In my case it is 172.18.0.2. Then add three firewall rules adjusting the IP's as necessary (probably only the last rule is really necessary):
      iptables -I DOCKER ! -i docker0 -o docker0 -d 172.18.0.2 -j ACCEPT
      iptables -A POSTROUTING -t nat -s 172.18.0.2 -d 172.18.0.2 -j MASQUERADE
      iptables -A DOCKER -t nat ! -i docker0 -d 172.22.22.2 -j DNAT --to-destination 172.18.0.2

    21. To make these rules survive a firewall restart, create a file /etc/clearos/firewall.d/11-docker-samba (the name is unimportant but must begin with a number greater than 10) and in it put:
    22. if [ "$FW_PROTO" == "ipv4" ]; then true
      $IPTABLES -I DOCKER ! -i docker0 -o docker0 -d 172.18.0.2 -j ACCEPT
      $IPTABLES -A POSTROUTING -t nat -s 172.18.0.2 -d 172.18.0.2 -j MASQUERADE
      $IPTABLES -A DOCKER -t nat ! -i docker0 -d 172.22.22.2 -j DNAT --to-destination 172.18.0.2
      fi
      or you could be clever and script the Docker/Samba internal IP:
      if [ "$FW_PROTO" == "ipv4" ]; then true
      $IPTABLES -I DOCKER ! -i docker0 -o docker0 -d `docker inspect --format '{{ .NetworkSettings.IPAddress }}' "samba"` -j ACCEPT
      $IPTABLES -A POSTROUTING -t nat -s `docker inspect --format '{{ .NetworkSettings.IPAddress }}' "samba"` -d `docker inspect --format '{{ .NetworkSettings.IPAddress }}' "samba"` -j MASQUERADE
      $IPTABLES -A DOCKER -t nat ! -i docker0 -d 172.22.22.2 -j DNAT --to-destination `docker inspect --format '{{ .NetworkSettings.IPAddress }}' "samba"`
      fi

    At this point you should have a fully functioning AD Domain controller which will start every time ClearOS starts. You should be able to use the ClearOS Active Directory Connector to connect to it from a new ClearOS installation (instead of using the OpenLDAP Directory Server).

    You can administer the domain using Microsoft's publicly available RSAT tool or the the Samba utility "samba-tool".

    To use samba-tool you have to get to a command line within docker. To do this, you can issue the command:
    docker exec -it samba /bin/bash
    Type "exit" to quit.
    I suggest you use the docker command line to set up all the default groups you may need from Active Directory User Guide by doing:
    samba-tool group add ftp_plugin
    samba-tool group add imap_plugin
    samba-tool group add openvpn_plugin
    samba-tool group add pptpd_plugin
    samba-tool group add print_server_plugin
    samba-tool group add smtp_plugin
    samba-tool group add user_certificates_plugin
    samba-tool group add web_proxy_plugin

    You can check password policies with:
    samba-tool domain passwordsettings show
    and change them with commands like:
    samba-tool domain passwordsettings set --complexity=off
    samba-tool domain passwordsettings set --max-pwd-age=0
    samba-tool domain passwordsettings set --history-length=0
    samba-tool domain passwordsettings set --min-pwd-age=0
    samba-tool domain passwordsettings set --min-pwd-length=4
    You were forced into setting a complex administrator password when initialising the docker container. You can change it here with:
    samba-tool user setpassword administrator
    and so on. RSAT may be the better tool to add users and add them to groups but that is down to you.

    Note that if you mess up you can blow everything away by doing a:
    docker stop samba
    docker rm samba
    Then remove everything in /var/clearos/samba/data and /var/clearos/samba/config and starting again from step 9 (or step 8 if changing store locations).
    You can change some startup settings (I added "--restart unless-stopped \" much later), but only those related to the docker container and not to samba, just by doing:
    docker stop samba
    docker rm samba
    then changing my "docker run" command but you can only change some things like that. Anything which as been written to the samba databases will not change (password complexity, the administrator password and so on)

    [edit]
    If you run this on a production system it is **very strongly** recommended to regularly back up the contents of the two folders:
    /var/clearos/samba/data
    /var/clearos/samba/config
    [/edit]
    The reply is currently minimized Show
  • Accepted Answer

    tomas
    tomas
    Offline
    Wednesday, August 08 2018, 09:16 AM - #Permalink
    Resolved
    0 votes
    tomas wrote:

    Hi

    Anyone tried to share a printer on domain members running W10 1803 (1507 domain joined then upgraded to 1803)?.The client is visible, but can't be accessed most of the time...


    I have managed to sort it out -> the client used static IP config (with WINS), I switched to DHCP and the client can be accessed now.

    Update: it works if you are logged in on other clients with the same username e.g. "tom" on W10 1803 client sharing a printer and "tom" on another client accessing that client via "Network", it doesn't work if you login using different credentials e.g. "adam"..Ehh...

    Update 2: So far I have manged to access that shared printer (and some test files shared by that client) only on 1 client (logged using the same user name), on any other clients I try I get "Windows cannot access \\client-name" message even when I login using that the same username; firewalls are disabled on both sides; I'm feeling silly now - how does one share a USB printer nowadays? It just doesn't seem to work - and it used to be just few clicks?

    Update 3: Netlogon service was down on the sharing client -> starting and setting it to Automatic solved the issue.
    The reply is currently minimized Show
  • Accepted Answer

    tomas
    tomas
    Offline
    Tuesday, August 07 2018, 06:19 PM - #Permalink
    Resolved
    0 votes
    Hi

    Anyone tried to share a printer on domain members running W10 1803 (1507 domain joined then upgraded to 1803)? I have one Zebra label printer connected to a client via USB and then shared to others.

    I tried many things but couldn't get it to work reliably...3rd party firewall uninstalled, Windows firewall disabled and I get 95 times out of 100 "Could connect to \\client-name" message when accessed under Network. SMB1 added via Add/Remove Windows features....I have "Function Discovery Provider Host" and "Function Discovery Resource Publication" services enabled and set to Automatic (Delayed Start), but that for some reason doesn't solve the issue completely...The client is visible, but can't be accessed most of the time...
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, August 04 2018, 08:52 PM - #Permalink
    Resolved
    0 votes
    Minor Update

    To anyone following this, we are probably going to change docker containers to Fmstrat/samba-domain as it seems more geared to running as an AD Domain Controller. The other image mentioned earlier looks more suitable just for a NAS/File Server.

    We've had a few issues to tackle and there is more info in https://docs.google.com/document/d/1-qH3pIcVKxO2Qf43jzfJV5LIPaqLkM7qGoWpmRxZBL8. The current ClearOS implementations of Samba and dnsmasq need to be changed to bind on specific interfaces or interface IP's. Details are in the doc and in issue trackers 20991 and 21001. For anyone using the Directory Server with Publish Policy = All Networks there is a further issue, but longer term may not be a required change as the AD Domain Controller will become the master LDAP server.

    I've used the instructions in the container link to get the image starting up, but I've used different file locations. My start up command is:
    docker run -t -i -d \
    -e "DOMAIN=SAMDOM.LOCAL" \
    -e "DOMAINPASS=SomeComplexPassword" \
    -e "DNSFORWARDER=172.22.22.1" \
    -e "HOSTIP=172.22.22.2" \
    -p 172.22.22.2:53:53 \
    -p 172.22.22.2:53:53/udp \
    -p 172.22.22.2:88:88 \
    -p 172.22.22.2:88:88/udp \
    -p 172.22.22.2:135:135 \
    -p 172.22.22.2:137-138:137-138/udp \
    -p 172.22.22.2:139:139 \
    -p 172.22.22.2:445:445 \
    -p 172.22.22.2:464:464 \
    -p 172.22.22.2:464:464/udp \
    -p 172.22.22.2:636:636 \
    -p 172.22.22.2:1024-1044:1024-1044 \
    -p 172.22.22.2:3268-3269:3268-3269 \
    -v /var/lib/docker/containers/samba/data:/var/lib/samba \
    -v /var/lib/docker/containers/samba/config/samba:/etc/samba/external \
    --dns-search samdom.local \
    --dns 172.22.22.2 \
    --dns 172.22.22.1 \
    --add-host localdc.samdom.local:172.22.22.2 \
    -h localdc \
    --name samba \
    --privileged \
    nowsci/samba-domain
    As you can see, I have not given it a proper domain yet and it is unlikely I will want to use any DNS forwarder (both parameters set to 172.17.2.1) and instead, on a fresh installation, will set up an explicit subdomain for the AD DC and in the ClearOS set dnsmasq to forward queries for the domain only to Docker. Dnsmasq can handle the rest of the queries.

    Dave is looking at how to implement this as a migration out of the current LDAP directory controller.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 03 2018, 01:26 PM - #Permalink
    Resolved
    1 votes
    @tomas,
    It is currently quite easy to get hold of Win10 iso's, for example from here and I don't believe there is anything wrong in that. They can only be used if you have a licence. I'd suggest you get yourself a copy of 1703 and 1709, but remember in 1709 you will have to enable SMB1. There will be a bit less updating to do compared to the 15xx build.

    Master/Slave is not going to work either because both are using NT4 domains. The solution is to use Samba as an AD Domain Controller. For the moment This has to be either on a standalone machine (because it will break various ClearOS functions) or on a docker image or VM in ClearOS. Once you have Samba AD running, you can change you ClearOS installation from using LDAP to using the AD Connector and join ClearOS to your AD Instance.

    There are issues with these solutions:
    - A migration path is needed to get the users and domain info out of ClearOS into Samba AD then switch off LDAP and switch on the AD Connector
    - If Samba AD is hosted in docker or a VM in ClearOS, a number of bindings need to change in ClearOS. As an example, by default UDP port 53 (DNS) currently binds to all interfaces in ClearOS. Samba AD also needs to act as a DNS server for the domain. This means that dnsmasq (the ClearOS DNS forwarder) needs to be changed to just bind to the ClearOS LAN IP's and not to the docker/VM IP. The same goes for the Samba ports (UDP 137/8 and TCP 139/445). There may be other services affected by this as well (thinking LDAP when the policy is published globally)
    - Other changes may be needed to the DNS set up to enable a split DNS.

    We have been making some progress particularly with getting Samba to run in Docker with its own LAN IP. Dave. is working on the migration into Samba AD (Samba publish a guide and have some tools to help) on a separate machine and has ideas on how to get it into the Docker image
    The reply is currently minimized Show
  • Accepted Answer

    tomas
    tomas
    Offline
    Friday, August 03 2018, 10:17 AM - #Permalink
    Resolved
    0 votes
    Hi

    Just started tracking this...We tried to join W10 1803 to our domain and got an error...Still have 15xx build .iso so will go with that for now, but future is uncertain....One day this possibly won't work anymore meaning after upgrading domain logons won't be possible...

    How would any possible solutions work for paid 7.x customers using master server and slave server (PDC and BDC)?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 02 2018, 02:25 PM - #Permalink
    Resolved
    0 votes
    UPDATE:

    Nick and I have found a method for doing the IP addressing on the docker image that might work. While I was working on other things inside the samba migration path, Nick was working on how to get the addressing compatible between ClearOS and the docker image. He hit a brick wall after exhausting some methods and even exhausting and proving that some of the items I thought might work were untenable. In the end, this left a limited set of options and I tried the stupid and simple one, which failed initially but then found that it would work with a restart of the docker daemon itself.

    So with that daemon defeated, we are ready to put it together. The big thing that is left is the Samba Directory to Samba Directory artifacts migration. I've got a busy day today but will hit try and put some end to end testing together tonight and see if we can't come up with a comprehensive howto by the end of the weekend.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, July 30 2018, 03:02 PM - #Permalink
    Resolved
    0 votes
    That would require a highly customized docker. I'll look into whether or not this is possible to do the inline restore with existing docker images but I kind of doubt it. Typically those docker images are preloaded with "The NEW Install" paradigm. Essentially the following things have to happen on the 'staging' VM/image:

    1) Validate that it has the samba and samba-dc packages in addition to the typical samba packages
    2) Setup OpenLDAP (which you would want removed from your eventual docker image
    3) Configure, import, and validate that it is running in a similar manner in order to be accessible by your current smb.ldap.conf
    4) Run the samba-tool classic upgrade against the running slapd and flattened smb.conf.old config

    When I did this I still ran into errors but my directory seems intact. But the fact that OpenLDAP is required for the migration is a big 'showstopper' for an elegant transition since you wouldn't want it at ALL running in your ideal endpoint. That being said, there is no need to torture everyone by making them jump through this hoop solo. The ideal thing to do here is to:

    a) provide the VM via FTP to everyone to use with simple instructions.
    b) provide individuals access to a hosted and snapshot version so that they can use the image like a time share.
    c) provide individuals with a method in support where they simply send their configuration backups and we provide them with the outcomes.
    d) provide individuals with the exact steps in the 'open source' model so they can do it all themselves if they so desire.

    But the correct answer here is likely...

    e) all of the above. Let them decide.

    SIDE NOTES: I'm having trouble with the group import currently. I failed to import any group memberships even though it imported all the group names. The failure was with the 'flexshare' group name and I believe it fails because it is the same name as the flexshare users which is strictly prohibited. When I refine the steps, I'll contend with this and see if I get different results. Secondly, my workstation (previously joined to the old domain) can log in using cached credentials but cannot complete the login with another user ('no logon servers'). It can also use the RSAT tools to see the domain but since group membership import was broken, is not able to manipulate things.

    For those of you following along at home, our evolving steps (distilling old, failed methods and current paradigms) are located here:

    https://docs.google.com/document/d/1-qH3pIcVKxO2Qf43jzfJV5LIPaqLkM7qGoWpmRxZBL8

    Lastly, the reason for Fedora and not ClearOS is because I cannot traverse Kerberos mismatch properly due to upstream inadequacies in support for DC mode for Samba Directory. The samba-tool, for example, doesn't exist properly which prompted me to go the Fedora route.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, July 30 2018, 07:05 AM - #Permalink
    Resolved
    0 votes
    Hi Dave,
    As an alternative to the VM route, would it be possible to do an in-place migration of Samba to Samba Directory, back up the migrated Samba set up and restore it into docker then do a config restore of the original Samba? Higher risk in case your last restore fails.
    Or, rather than use a Fedora VM, use a ClearOS VM or spare machine created by a config restore which will probably be much easier to set up initially.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, July 30 2018, 04:17 AM - #Permalink
    Resolved
    0 votes
    Hey,

    I wanted to give you all an update of where we are with creating a workaround for the Samba/Windows 10 issue. One of the difficult barriers is the total lack of upstream mechanisms. There are various reasons for this but the short answer is that there isn't good support upstream for Samba Directory (which solves the issue totally). Redhat has their reasons for this but it may be until RHEL 8 that there is domain controller support upstream. For example, you can follow this guide:

    https://wiki.samba.org/index.php/Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)#LDAP

    But you will get stuck with the fact that there isn't a samba-tool program in upstream which will require you to build Samba from source and then you will have a host of incompatibility problems. So that represents several development tracks that we have worked on and attempted. In the end, it isn't elegant.

    My next attempts will focus on getting an existing directory to a docker container. The idea is this, since Samba Directory cannot be made to work well because of upstream, we will containerize the Samba Directory and then use the very stable AD Connector method. This means that that there are two development tracks...

    1) The NEW install.

    This install looks like this. Install ClearOS, fire up a docker image of a Samba Directory. Install the AD Connector module and connect it to the docker image. The dev that has to happen here is:

    - Docker Samba Directory running on its OWN IP address
    - If we can get this docker to work, it is preferred: (https://github.com/dperson/samba)

    2) The migration

    This is tricky. We want to end up in the same state as the 'NEW install' paradigm. To get there we have a full list of problems

    - Exploring the migration of the domain off of ClearOS and then onto a Fedora VM with working Samba Directory
    - From there either 1) create a way to backup the Samba Directory domain for use by the docker, or 2) join the docker image domain to the migrated domain then decommission the Fedora VM.
    - Validate the domain
    - Uninstall the DC from ClearOS and move to AD Connector.

    If anyone wants to assist here. I will be focusing on the Samba elements so if you know docker and can point me to making the dperson image work on an alias LAN IP address in ClearOS, that would be very useful to me.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 28 2018, 08:00 AM - #Permalink
    Resolved
    0 votes
    Mansoor wrote:

    I'm trying to access clearOS shares from Windows 10 but without success! The SMBv1 is enabled in Windows 10. The clearOS server is 7.5 beta and running Samba in "Simple Server" mode with "Windows 10 Domain Logons" disabled.

    The server appears in the Windows file manager and in "nbtstat -A 192.168.0.1" output. When I double click on the server's icon, Windows asks for username and password. All usernames and passwords I enter are rejected! I tried to login with "winadmin" and with normal users, but always the same result.

    EDIT: Just after posting this reply I was abel to login from Windows by entering "WORKGROUP\username" instead of just username :)

    I've always found Win10 to be very picky. I use the same account name on the PC as in the server, but the PC has no password whereas the server has a strong one. Map Network Drive, connecting with different credentials was not reliable. I think a batch file with "net use" was better, but in the end I used the Credentials Manager to store the server credentials and this is 100% reliable. I also found that the drives would map on boot but stay in a disconnected state until you clicked on them. This was fine in a GUI environment but I used a batch file to do backups and if it tried to access the network drive it would not force a reconnect and the batch file failed. Trawling the internet I found a program which will automatically connect the drives using stored credentials which I run on boot.

    At the end of the day the recommendation is to use the same credentials in the PC as in ClearOS, but I've never got round to testing it as the family works without logins to the PC's.
    The reply is currently minimized Show
  • Accepted Answer

    Mansoor
    Mansoor
    Offline
    Wednesday, June 27 2018, 09:06 PM - #Permalink
    Resolved
    0 votes
    I'm trying to access clearOS shares from Windows 10 but without success! The SMBv1 is enabled in Windows 10. The clearOS server is 7.5 beta and running Samba in "Simple Server" mode with "Windows 10 Domain Logons" disabled.

    The server appears in the Windows file manager and in "nbtstat -A 192.168.0.1" output. When I double click on the server's icon, Windows asks for username and password. All usernames and passwords I enter are rejected! I tried to login with "winadmin" and with normal users, but always the same result.

    EDIT: Just after posting this reply I was abel to login from Windows by entering "WORKGROUP\username" instead of just username :)
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, June 20 2018, 07:49 PM - #Permalink
    Resolved
    0 votes
    ClearOS 6.x update added to the first post.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 07 2018, 12:12 AM - #Permalink
    Resolved
    0 votes
    One of my team got the following response from Support at Clearcenter today...

    "We just had a Innovation conference in Toronto with the ClearOS development team there and the new direction that was decided is with a docker-based method for Samba directory. There are a couple of reasons for that; one of them being security isolation and the other is being able to partition the directory in a way that is more scalable. We will have further guidance by Monday, June 11."


    Light at the end of the tunnel hopefully...... Dev's, how can we assist with this?....
    Cheers..... Andy
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 02 2018, 07:59 AM - #Permalink
    Resolved
    0 votes
    No word for the moment from the devs.

    From what I've read, it would be more than just installing Samba 4. If Samba is running as AD Domain Controller it takes over LDAP completely and also insists on using its own DNS or BIND. This could mess with any programs using LDAP extensions. The DNS bit would mean changes to the Webconfig and I don't know how it would play with products like Gateway Management which are DNS based services. There is a Samba Directory (beta) app out there, but it is very much a beta and does not support a lot of apps. I think it also became a little unstable towards the end of last year as well.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, June 01 2018, 09:35 PM - #Permalink
    Resolved
    0 votes
    Hi Nick,

    Thanks for the "heads-up" .... it saved me a lot of time this week when I ran into issues joining some new Windows 10 clients to one of my customers domains. Luckily, we were able to roll these back (remotely) to an earlier build (they'd been diligently updated prior to joining the domain), but this is going to be a major headache when PC's ship with an 1803 build pre-installed, and the only option will be to send someone to site to flatten and rebuild with a 1709 ISO.

    Any word from the Dev's on moving forward with Samba 4 AD...... ?

    Cheers.... Andy
    The reply is currently minimized Show
Your Reply