Active Directory Samba configuration issues

I’ve joined Rockstor to my domain using the Active Directory service. Upon clicking “On” the toggle immediately switches off. Subsequent attempts at toggling this provides an error stating that it’s already joined to the domain.
“realm list” does show that it’s domain joined and a computer named “rockstor” is added to my DC.

In addition to this, I’ve ensured that my samba “workgroup” matches my domain name but, when connecting to my Samba shares from a domain joined Windows computer and choosing “Security”, the only location selectable is “rockstor” and not the users/groups in AD.

If anyone could assist with setting Windows ACL it would be greatly appreciated.


Hi @manxam! Currently, a bit of extra/manual samba configuration is needed for AD.

In the [global] section of /etc/samba/smb.conf, locate the security directive. It’s most likely security = user. Change it to security = ads. Also add a couple more directives to make the section as follows:

security = ads
encrypt passwords = yes
passdb backend = tdbsam
realm = YOUR_REALM

Save the file and restart samba: systemctl restart nmb smb

Let us know how that goes. @JBelthoff shared some information with me and I hope to make things work out of the box soon.

Thank you @suman and JBelthoff. I had actually tinkered with those settings shortly after posting my topic. While this does appear to allow windows administrator access to the share, it does so without allowing write/modify access.

If I change the unix directory permission to “administrator@mydomain.local” then the matching Windows administrator user has full access. Unfortunately, when attempting to change windows ACL permissions, it accepts the domain user name and, upon clicking apply, it immediately clears it out.


Allow : root (Unix User\root)
Allow : root (Unix Group\root)
Allow : Everyone

Add ACL:

Add -> Select Principal -> manxam@mydomain.local


Allow : root (Unix User\root)
Allow : root (Unix Group\root)
Allow : Everyone
Allow : manxam (manxam@mydomain.local)

Upon clicking apply it reverts to:

Allow : root (Unix User\root)
Allow : root (Unix Group\root)
Allow : Everyone

As a note, I also tested adding the following to no avail:

admin users = @mydomain\Domain, Admins, @mydomain\Enterprise, Admins

If you could assist further I’d greatly appreciate it. I really like the concept of Rockstor and would like to continue to use it but AD integration for file shares is a must in my home lab.


I am experiencing the same issue.

1 Like

This appears to be a limitation of sssd. I’ve searched every forum, search engine, whitepaper, etc that I could find on this subject and it seems that sssd is a simpler alternative to active directory USER authentication than winbind but doesn’t support the full subset of integration with samba.

While I’ve been able to “work around” the situation by creating write lists, read lists, admin users, etc inside of samba.conf and changing the permissions on the shares via the command line:
chown "administrator@mydomain.local":"domain users@mydomain.local" sharename

It’s a less than perfect solution as it doesn’t allow fine grained control like Windows ACLs do. I can likely get into linux facl extended ACL’s and bugger around with them but it’s just too much manual work.

Unfortunately, Rockstor also has it’s own limitation with Samba in that it only allows you to create “admin” users per share and doesn’t support R,W permissions/attributes.

As much as I love BTRFS and the basics of Rockstor, it’s really not ready as a NAS device as one cannot easily create users, assign user permissions per share, etc with OR without AD integration without editing configs, manually changing folder permissions, etc.

While I’m totally comfortable in the command line, I want a NAS device to be something where I can just click a few boxes.

I’ll be switching over to OmniOS with napp-it for the time being due to better CIFS implementation and AD integration. I really loathe doing this because ZFS limits my ability to grow my “RAID 10” array but I just can’t find an easy way to manage users and permissions within Rockstor :frowning:

I’ll continue to watch Rockstor’s progress and hope to see the day that I can return.


1 Like

Thanks for playing @manxam. I think you are right about sssd. I am a bit behind, but thanks to @JBelthoff, I have some pointers to try and compare sssd and winbind(our old approach). It would be great if someone can get everything working with sssd and report here, as that would be an easier fix compared to going back to winbind.

I know I am late to the game here, but have been evaluating Rockstor. So far I have been able to get sssd working and in the same manner as I have all my existing Linux boxes; I have it setup to assign UID/GID based on an internal sssd algorithm which provides consistency for UIS/GIDs accross all the Linux platforms we support. idmap_ranges and sizes. Once that was done, we have AD integration on our Linux machines; Red/Fed/Cent and Ubu14/16 LTS.

So I am willing to jump into this and see what we can come up with. On this install of Rockstor I had to add the packages that realm identified as missing (sssd, some samba components, odjob, etc…). Then I dropped in three config files:


Stopped winbind and disabled it. Enabled and started sssd and viola, I can now resolve UID/GIDs from AD with the same values they have on our installed systems (this bit saves me from having to copy from the old storage to the new storage and mapping the IDs around, which we did on our last migration to new storage).

After I established that the AD setup was working, I rebooted the storage and when it came back up, sssd started and everything seems to work.

I have started to read the docs on getting setup to start doing Rockstor dev work, any pointers would be helpful. If there is already an issue opened on sssd, shoot me that info too, please. (Now I will go search for myself :slight_smile:


@maz Hello again.

Chuffed your preparing to code contribute:

Linking to the pull requests that introduced sssd the last time around, prior to the winbind reversion as detailed in my post on your recent AD related forum thread:

Sssd was first added (by way of winbind replacement):
related dev log post:

and the associated pull request:

Later improvements / enhancements:
related dev log post:

and the related pr:

And finally the revert to winbind approach announcement:

and the related pr:

There may have been a number of other fixes additions related to sssd during this period but some git investigation on the related files should help there. But I think we have the major changes listed above.

Hope that helps.