Setting Share Permissions & ACL's remotely to ubuntu 16.04 Samba file server via Windows Server 2012 r2


Recommended Posts

OpSupport

Hi all, 

 

I've been looking around the forums and trying to find an answer via search but I have been unable to thus far. I'm hoping someone can give me a hand. I'm very new to Linux and Samba but my bosses wanted me to set up a new file server on Ubuntu that can integrate with AD and have users be able to authenticate with their AD credentials. So far I have managed to get Ubuntu 16.04 installed, Kerberos configured and the system added to my AD domain. Everything is working fine. I am able to see my new file server in AD users and computers and DNS is working correctly, things are pingable and resolving right. 

 

My issue is that I am trying to use the instructions in the Samba wiki to set the share permissions and ACL on a share which I have created on my Samba server as it indicates that I shouldn't use the smb.conf to add the parameters, but instead use the Windows utilities ( https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs ) Unfortunately, despite everything else working correctly when I try to connect via my 2012 r2 server to the remote Samba I get an error " Computer <new server> cannot be managed. Verify hat the network path is correct, the computer is available on the network, and that the appropriate Windows Firewall rules are enabled on the target computer" Sadly, there are NO "Windows Firewall rules" since its a Ubuntu box and considering that the computer IS perfectly visible in the AD, the snap-in can find it when I 'browse', it can be ping'd and the UFW is off, I am at a loss as to what could possibly be the issue.

 

Anyone out there who has integrated a Ubuntu file server using Samba onto AD can point me in the right direction?

 

Thanks!

 

Link to post
Share on other sites
Mindovermaster

I think  that only applies to Windows systems. You are on Linux, use the smb.conf.

 

I am very shady on this, but I THINK that is what you're trying to get accross... If I'm wrong, shoot me in the foot...

Link to post
Share on other sites
OpSupport

@Mindovermaster I have tried both ways. Unfortunately I can't seem to get a windows user to be able to map to the samba share using only the AD credentials - which is what should be happening.  I can set up a share without the system being on the domain or using kerberos to authenticate but this is not what I am wanting. I need a ubuntu server to join my windows domain, to have users be able to map their shares using only their windows AD credentials. According to the article that I linked and the Samba wiki, this setup is completely possible - but I can't manage it. I was hoping someone had done it - and documented all the steps.

 

Thanks for trying. I think I am just going to have to set it up as a stand alone server , assign everyone their own samba passwords and have them map locally without it being a domain member.

Link to post
Share on other sites
Mindovermaster

@BudManmight be able to help...

Link to post
Share on other sites
+BudMan

did you validate your samba has extended ACLs enabled

 

smbd -b | grep HAVE_LIBACL

 

Does that come back that you HAVE_LIBACL?

 

If so and you joined it to the domain correctly, then yes you should be able to access via the windows tools..

 

What schema are you running you mention 2012r2 but are you actually running the 2012r2 schema -- you can check with dsquery or powershell.  Also what version of samba are you running?

 

What I can tell you off the top of my head, is yes this is very possible.. Problem is I have not done this in quite some time.. I would have to fire up some vms and run through it.

  • Like 1
Link to post
Share on other sites
This topic is now closed to further replies.
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By +BudMan
      So I have recently fired up a synology ds918+ running DSM 6.2-23648 (beta)
       
      So when I was running windows I got full speed both up and down from shares 113MBps.. With smb3 multichannel I was seeing 220 up and down.. I have a thread showing this.
       
      Well my move to the nas vs windows running on a esxi host has pushed me to move my main desktop to linux.. I will prob only run windows as VM to help users with stuff, etc.  Just because I am stuck with it at work doesn't mean I have to run it at home any more.
       
      So running linux mint 18.3.. All was going good until tried to mount my shares..  Seems something odd with latest kern or something and since not using smbv1 had to mount via cmd line, will add to fstab once all working as it should.  So no problem I got my shares mounted and working..
       
      sudo mount -t cifs //192.168.9.10/share /home/budman/nas/share -o username=budman,vers=3,uid=budman
       
      Copy a large file down and speeds look fine...
       

       
      But when pushing a file to the share.. it max out at like 14MBps
       
      While I can find all kinds of info about slow speeds, nothing that makes much sense for tweaks to smb.conf and such..  Or specific on changes in how mounting it?

       
      I don't use samba much.. Any suggestions here?  Anyone seen this sort of thing - seems very odd.. Its sure not a disk issue this is running off 860 EVO brand new SSD.. If I boot back to my windows SSD I get full speeds..
       
      I move a lot of files back and forth between my nas and pc.. So if can not work this out have to go back to running windows until I do.  I can give NFS a try vs smb... But seems odd linux mint doesn't come with nfs out of the box?
       
      edit:  Using file station to upload the file gives me 72MBps... So clearly its something in the in the samba on linux..
       
      edit2:  Guess just use NFS... because with that seeing full speed.. WTF??/
       
    • By +MJK
      A flaw in Intel AMT can leave your laptop exposed to attackers
      by Muhammad Jarir Kanji



      Following on the heels of the revelations of the Meltdown and Spectre vulnerabilities plaguing decades of Intel's processors, a new flaw in the Active Management Technology (AMT) has left Intel in even more hot water among the cybersecurity community.

      The new flaw targets laptops, especially those powered by Intel's enterprise-focused vPro processors, and exploits the remote access monitoring and maintenance tools provided by AMT to gain total control over the machine. Relatively easy to implement, the attack is also not impeded in any way by BIOS or BitLocker passwords, TPM pins, or login credentials.

      In order to carry out the attack, an individual would need physical access to the machine. The way it works is by rebooting the machine and entering the boot menu. While you would normally need the BIOS password in order to perform any hijinks at this point, using Intel's Managment Engine BIOS Extension (MEBx) can allow an attacker to login in with a simple 'admin' login that is the default.

      The attacker can then proceed by, "changing the default password, enabling remote access and setting AMT’s user opt-in to 'None'" to effectively compromise the machine, according to F-Security researcher Harry Sintonen. He continues, "Now the attacker can gain access to the system remotely, as long as they’re able to insert themselves onto the same network segment with the victim (enabling wireless access requires a few extra steps)."

      The ease with which the attack can be carried out is of particular concern, with Sintonen warning users,

      That physical access to the system is required is also not a large hindrance since the target of the attack are laptops, which are mobile by their nature and therefore easily accessible outside of secure environments. The process also takes under a minute, meaning the shortest of distractions could be enough for someone to tamper with your laptop.

      As of now, the only ways of mitigating the danger is to change the AMT password from its default 'admin' setting to something harder to guess - or to just disable the feature entirely.

      Source: F-Secure via PC Gamer

    • By vishal1082
      Google finally updates its Samba client for Android; disables SMBv1, adds support for SMBv3
      by Vishal Laul



      Just over two weeks ago, Google released a Samba client for Android out of the blue and without much fuss, bringing users the ability to mount Windows shares and conveniently move files. Unfortunately, it wasn't quite an ideal solution due to the perplexingly exclusive support for SMBv1.

      The SMBv1 protocol is vulnerable to exploits discovered by the NSA and released by The Shadow Brokers earlier this year; the WannaCry ransomware abused the protocol to propagate through networks in over seventy countries a few months ago and was followed by the Petya/NotPetya ransomware – using the same exploit – soon after.



      Today, Google has released an update for the Samba client, disabling support for SMBv1 by default and enabling support for SMBv2 and SMBv3 protocols.

      The SMBv2 and SMBv3 versions of the protocol offer a few extra security features and do not share the same vulnerabilities as SMBv1.

      Since the client is open-source, we can see that the change, in fact, happened more than a week ago, and was brought upon due to an “urge from users” – it just took Google this long to push an update for the app on the Play Store.

      However, it seems Google still has some work to do; of the 154 total reviews on the Play Store, the Samba client has received 60 one-star reviews, with only 45 five-star reviews, giving it a score of a mere 2.8. The most common complaint seems to be about a clunky interface, limited features, and the inability to unmount a share.

      The client may not be very feature-rich, but with the fatal vulnerability fixed, it is at least more secure.

      Source: Github, Google Play Store (Android Samba Client)

    • By vishal1082
      Google releases a Samba client for Android, only supports the vulnerable SMBv1 protocol
      by Vishal Laul



      A couple of days ago, out of the blue, Google released an open-source Samba client for Android, bringing users the convenience of being able to easily mount and access files over a network using the SMB protocol.

      In its description, Google states that the app is a “direct port of the Samba client,” and thus supports its entire feature set. Unfortunately, Google fails to mention that the app only supports the extremely vulnerable SMBv1 networking protocol.

      As tested by Android Police’s Corbin Davenport, the app simply refuses to connect if a Samba share has SMBv1 disabled.

      Microsoft’s Ned Pyle also chimes in to put emphasis on the risk SMBv1 possesses for users on Android:

      The ‘WannaCry’ ransomware that propagated through networks in over 70 countries a couple of months ago abused the SMBv1 protocol; this was followed by Petya/NotPetya ransomware just last week, which brought several organizations in Ukraine and the rest of Europe to a halt.

      SMBv2 and SMBv3 versions of the protocol do not share these same vulnerabilities and offer quite a few extra (and perhaps necessary) security features as well.

      While Google has been quite enthusiastic about pointing out “crazy bad” flaws and vulnerabilities in software other than its own, it seems that the company has neglected its own software. This comes at a time when organizations are moving away from SMBv1, with Microsoft going as far as creating a list of old and new software that still relies on the vulnerable protocol.

      Source: Google Play Store (Android Samba Client) via Android Police

    • By neoamigo
      Hello,
      To help others in my university Litemanagerfree used for monitoring and control, and you?