Access control with Active Directory and group based permissions

Troubleshooting
1

Hi Forum,

I have Rockstor connected to my Active Directory and as far as I can tell this worked as expected, because I can see the AD user and groups.
When I create a SMB share with a AD user, I can access it with the correct credentials.

(Image below - only one image allowed)

When I want to assign the share not to a user, but a group, I reset the user and give all rights to the AD group.

(Image below - only one image allowed)

But now no AD user can access the share. And I tripple checked group memberships and passwords.

I thought the owner of the share should not be relevant and I also tried with an owner from the AD (and also the group), but then only that user can access the share and other group members can not.

The samba export is configured like this.

(Image below - only one image allowed)

Bild_2023-09-05_142405603
Bild_2023-09-05_1424056031500Ă—500 86 KB

Do you have any ideas? Or any sources, that I could look into? I was not able to find meaningful help on the internet (maybe I did search for the wrong term?) and especially not in the samba wiki or forum.

Thanks in advance,

Ben

1 Like
2

@b_b Out of my area I’m afraid.
But I’ve upped your user level to hopefully enable pasting more than one pic. Let me know if this is enough to allow for the pics you wanted to put in this post. Tricky to have to merge them into a single pic every time.

Hope that helps.

3 Likes
3

Quick follow up:
it seems, as if all required AD information is available on Rockstor

admin@rockstor:~> id bb@domain
uid=1302401612(bb@domain)
  gid=1302400513(domain_users@domain)
  groups=
    1302400513(domain_users@domain),
    1302401186(s_intern@domain),
    1302401214(s_svn@domain),
    [...]

admin@rockstor:~> id sa_backupuser@domain
uid=1302401608(sa_backupuser@domain) 
  gid=1302400513(domain_users@domain) 
  groups=
    1302400513(domain_users@domain),
    1302401186(s_intern@domain),
    1302401214(s_svn@domain),
    [...]

admin@rockstor:~> id sa_svn@domain
uid=1302401298(sa_svn@domain) 
  gid=1302400513(domain_users@domain) 
  groups=
    1302400513(domain_users@domain),
    1302401214(s_svn@domain),
    [...]

The permissions for the shares (configured from Rockstor GUI) also seem to be correct and in line with the ids from the AD:

admin@rockstor:~> sudo stat -c "%n // %u (%U) // %g (%G)" /mnt2/*
<share>                 // <permission> // <user>                             // <group>
/mnt2/share-hdd         // drwxrwx---   // 0 (root)                           // 1302400513 (domain_users@domain)
/mnt2/share-hdd-backup  // drwxrwx---   // 1302401608 (sa_backupuser@domain)  // 0 (root)
/mnt2/share-nvme        // drwxrwx---   // 0 (root)                           // 1302401186 (s_intern@domain)
/mnt2/share-nvme-svn    // drwxrwx---   // 0 (root)                           // 1302401214 (s_svn@domain)
  • All users can access share-hdd (because they all have domain_user as primary group).
  • Only sa_backupuser can access share-hdd-backup (because the share is user specific).
  • While it is correct, that sa_svn cannot access share-nvme, the other users should be able to access it, because both are member of s_intern (but s_intern is not their primary group).
  • No user can connect to share-nvme-svn, even though sa_svn is member of group s_svn.

I also tested different constellations and access to shares that allow the users primary group seem to work, but all further groups do not work.
So my current conclusion is, that this is probably a problem of sambas handling of AD groups.
I only found one discussion (debian - Samba only sees first group of a user - Server Fault), that is not many years old (two or three discussions mention a similar issue, but they are 10-15 years old), but there is no solution. The wiki and documentation on the samba page do not mention any restrictions in handling of AD groups.

Other users in similar topics mention, that there may be a problem with the idmap parameter and the assigned ranges, but because primary groups with similar ids do work and all AD users and groups seem to be mapped correctly, I did not investigate on that path.

Has anybody smb shares in use that have their access control based on groups? Maybe in an linux-only environment? Does this work there? Any other ideas?

Best,
Ben

2 Likes
4

Hi @b_b ,

Thanks a lot for your excellent “quick” follow-up.

… and:

Great! That’s a big relief and excludes a big part of what could be wrong here.

Now:

A problem with id mapping was actually my first thought and relates to something that has been in the back of my head for a little while. That thought applies to Samba versions 4.8 and later, and directly concerns idmap. This actually could be further supported by the link you pasted: debian - Samba only sees first group of a user - Server Fault. In that link, they indeed started noticing that primary/others groups issue when updating from Samba 4.5 to Samba 4.9 (hence before and after Samba 4.8). In Samba 4.8, there indeed was important security changes on how Samba gets information from the AD server (from the information I could gather).

An example of idmap settings would be:

idmap config * : backend = tdb
idmap config * : range = 10000-19999
idmap config EXAMPLE : backend = nss
idmap config EXAMPLE : range = 200000-2000200000

Of course, replace EXAMPLE with your WORKGROUP.
As these need to be in the [global] section of smb.conf, you can use the customization field when configuring the Samba service in Rockstor (see Services — Rockstor documentation). Note that this would need a toggle OFF/ON of the Samba service for changes to take effect.

Note also that the range above are example and taken from SUSE’s support docs (Configure Samba File Server with AD Users | Support | SUSE) but they seem to fit the ranges you listed, for instance. There’s another setting for SSSD that would need adjusting to make that fix survive a restart but we can look at that once we know if that actually fixes your issue.

I’ll see if I can find a way to reproduce and test your situation on my end but that may take a bit of time as I need to refresh my Windows test client… You can test these settings above if you are game, but note that I’m unsure whether they pose a potential risk of altering your current AD server; my apologies for my shortcomings here.

A most likely unrelated note: do your user records on your AD server include a uidNumber and gidNumber?

3 Likes
5

Hi @Flox,
thanks a lot for your feedback!

I already searched for idmap with samba, but I think, even after your explanation and additional research I am not sure, if I understand what it does or what it is important for.

I am not sure, what to use for the domain (EXAMPLE in your example**), because it was not clear, when to use the workgroup (I think its the NETBIOS name) and when the realm (what I generally mean when I refer to the domain name), but your link had some examples and at first I thought it was clear, but on second look I am still irritated.

They use EXAMPLE as name in the idmap configuration, but below they show the workgroup configuration

[global]
workgroup = EXAMPLE
realm = EXAMPLE.COM
security = ADS
kerberos method = secrets and keytab

Because workgroup does not contain the domain (for the Active Directory) I assumed, I have to put the same string there as in the workgroup definition.
In my case (of an Windows Server Active Directory) the NETBIOS name (as verified by nbtstat -n on an windows machine in the domain) and the domain are:

NETBIOS: FD
Domain/Active Directory: full-domain.com
(in fact in my example above I simply used domain, but everywhere where @domain was used there really is full-domain.com used).

I use full-domain.com to setup the Active Directory and put FD in the samba workgroup field.
But using FD for idmap definition somehow does not make sense to me: samba should look the defined ids up for the Active Directory, so for full-domain.com. Anyway - I tried both versions with dis-/enable samba and reboots in between and nothing changed anything in the share access.
Because of General Information, Including Pros & Cons, And Examples, Of Various Identity Mapping (idmap) Options | Support | SUSE I also tried both versions with backend type ad. This is what samba config looks like:

####BEGIN: Rockstor SAMBA GLOBAL CUSTOM####                                                                     
   idmap config * : backend = tdb                                                                              
   idmap config * : range = 10000-19999                                                                        
   idmap config fd : backend = ad                                                              
   idmap config fd : range = 200000-2000200000                                                 
   workgroup = FD                                                                                              
####END: Rockstor SAMBA GLOBAL CUSTOM####

Is ad or idmap_ad the module/plugin, that Rockstor uses?

You ask

A most likely unrelated note: do your user records on your AD server include a uidNumber and gidNumber ?

probably because of that passage:

Mappings must be provided in advance by the administrator by adding the uidNumber attributes for users and gidNumber attributes for groups in the AD. Winbind will only map users that have a uidNumber and whose primary group have a gidNumber attribute set. It is however recommended that all groups in use have gidNumber attributes assigned, otherwise they are not working.

(also from the link above)

I can not say for certain if that is set, but this is what the internet told me to check:

PS C:\Users\Administrator> Get-ADGroup -Identity "s_intern" -properties GIDNumber

DistinguishedName : CN=s_Intern,OU=SecurityGroups,OU=Groups,OU=FullDomain,DC=full-domain,DC=com
GroupCategory     : Security
GroupScope        : Global
Name              : s_Intern
ObjectClass       : group
ObjectGUID        : b5b61c69-585d-4013-b89e-fexxxxxxxxx
SamAccountName    : s_Intern
SID               : S-1-5-21-639966690-3561479041-xxxxxxxxx-xxxx


PS C:\Users\Administrator> Get-ADUser -Identity "bb" -properties GIDNumber

DistinguishedName : CN=Benjamin Badel,OU=Office365_User,OU=User,OU=User,OU=FullDomain,DC=full-domain,DC=com
Enabled           : True
GivenName         : B
Name              : B B
ObjectClass       : user
ObjectGUID        : ce83ccd1-4e0f-43a0-aa64-xxxxxb45xxxx
SamAccountName    : bb
SID               : S-1-5-21-639966690-3561479041-xxxxxxxxx-xxxx
Surname           : B
UserPrincipalName : bb@full-domain.com

…and fields are not visible, so I would guess uidNumber and gidNumber are not set. But then again I found, that those ids are not required, when winbind is used in combination with samba (gidnumber im Active Directory | Mathom unfortunately in german).

You can test these settings above if you are game, but note that I’m unsure whether they pose a potential risk of altering your current AD server ; my apologies for my shortcomings here.

Is there really a risk of affecting the Active Directory (that runs on a different server under credentials not available to Rockstor)?
And please - no need to apologize, on the contrary: big thanks for the help so far!

**haha :wink:

3 Likes
6

Reading the german article you linked to, it seems that the only “risk” is to the Linux box (aka Rockstor in this case), as it might get some group ids imposed on it which might be in conflict with local groups already set up (e.g. existing “standard” groups that are generated during installation). But also, appears that this risk can be alleviated by picking a “higher” range (though if one has been using the AD server before, then that might not be an option). But @Flox might have had some other experience that he is referring to.

3 Likes
7

Hi @b_b,

Yeah, I found that trying to work with AD tends to have the same effect on me. My explanations are thus deliberately high-level (read “superficial”) to limit my chances of giving you inaccurate information.

In SMB/Active Directory, users/groups/machines are identified with a security identifier (SID) but that needs to be translated to UID/GIDs for them to work with Linux’s user/group permissions that you set on shares. In our case, this is what SSSD is doing. SSSD is doing this SID-to-UID/GID mapping using a specific algorithm (see sssd-ad(5) — sssd-ad, section “Mapping Algorithm” for details), and this process can be configured to some extent. You can, for instance, configure in sssd.conf the range for these translated IDs. The defaults are 200000-2000200000 (see sssd-ad(5) — sssd-ad, section “configuration”). This is how you see the UIDs/GIDs you reported for your AD users above. This is independent on whether or not you export shares via Samba.

Now, when you do use Samba to export a share to be accessible to AD users, Samba needs to also translate these SIDs to UID/GID for file permissions to work properly. This is where the idmap config settings in smb.conf come into play. There are different backends available: nss recommended in the SUSE support docs linked above, but sss (for SSSD) is also an option, I think. Note that the ad backend would not be recommended here, especially if you do not have the uidNumber/gidNumber set on your AD users (see Idmap config ad - SambaWiki).

Now, that part can also be configured with the range, and you will notice that in the example I pasted in my previous message (which was directly taken from SUSE’s support doc), the range was the same as the default range of ID mapping of SSSD:

idmap config EXAMPLE : backend = nss
idmap config EXAMPLE : range = 200000-2000200000

My fault… this is indeed very easily confusing so I should have been more explicit. You are correct that EXAMPLE should be replaced with the Netbios name. You will see that referred to as the <AD-DOMAIN_SHORTNAME> in the various docs to which I linked above.

If using the nss backend, Samba will get that information from NSS, which itself fetches it from SSSD if my understanding is correct. That being said, the principle is the same: smb.conf does possess both the realm and workgroup settings that tells it where to look for exactly.
In Rockstor, we already do part of that for you as when you configure and start the Active Directory service, we automatically set the workgroup setting for you. For instance:
For the domain/realm set as follows: samdom.example.com:

1011Ă—601 51.6 KB

… Rockstor will automatically set the Samba workgroup as SAMDOM:
1162Ă—731 57.3 KB

Following this example, the bit of customization you would place in the Samba “Custom global configuration” text area would be:

idmap config * : backend = tdb
idmap config * : range = 10000-19999
idmap config SAMDOM : backend = nss
idmap config SAMDOM : range = 200000-2000200000

With regards to:

You may have hit a cache issue here, preventing the new information generated by the new settings from being set. Samba caches that information and SSSD caches all of that as well. As a result, it may be that changing a setting that would affect the UID/GID of an AD user would generally need to have the cache wiped before seeing the new settings come into play. You could thus try the following (note that it would most likely kick out any AD user currently connected):

  • turn OFF Samba service
  • turn OFF Active Directly service
  • make changes in Samba service global settings customization as detailed just above.
  • clear SSSD cache:
sss_cache -E
rm -v /var/lib/sss/db/*
  • clear Samba cache:
net cache flush
rm -f /var/lib/samba/*.tdb
  • Turn ON the Active Directory service. SSSD and Samba should now be back ON and with their new settings.

I personally do not think so, but as I have never tried, I was just overly cautious and wanted to make it clear that I have indeed never tried that. I really don’t think it would affect your server, indeed, and @Hooverdan seems to think the same.

3 Likes
8

On another note, I think we should also explore the following once we have the idmap setup appropriately:
https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs#Setting_Share_Permissions_and_ACLs

I’ll give that a try once I’m done getting all my setup in order.

3 Likes
9

Hi @b_b ,

I got to trying this over the week-end and this morning and was able to control access to secondary groups using that approach. In particular, this is the setup I used (let me know if that indeed fits what you are trying to do):

Active Directory setup

Groups

Create 2 custom groups:

  • adgroup1
  • adgroup2

Users

Create 3 new users:

  • aduser1
  • aduser2
  • aduser3

Group memberships

Set up group memberships to add the following groups to these users:

  • adgroup1:
aduser2
aduser3
aduser1
  • adgroup2:
aduser2
aduser1

Rockstor setup

I made the idmap changes I described above (note that I have not tested whether they were indeed required but I think we should make them anyway), created a share named test_share01. Note that I changed the access to set the domain users@samdom.example.com group as owner but I do not think that matters.

Samba config

Create a Samba export of test_share01 using Rockstor’s webUI using default settings, nothing particular here. The resulting smb.conf is as follows:

buildvm155:~ # cat /etc/samba/smb.conf
[global]
    log file = /var/log/samba/log.%m
    log level = 10
    load printers = no
    cups options = raw
    printcap name = /dev/null
    map to guest = Bad User

####BEGIN: Rockstor SAMBA GLOBAL CUSTOM####
    vfs objects = acl_xattr
    map acl inherit = yes
    idmap config * : backend = tdb
    idmap config * : range = 10000-19999
    idmap config SAMDOM : backend = sss
    idmap config SAMDOM : range = 200000-2000200000
    workgroup = SAMDOM
####END: Rockstor SAMBA GLOBAL CUSTOM####

####BEGIN: Rockstor ACTIVE DIRECTORY CONFIG####
    security = ads
    realm = SAMDOM.EXAMPLE.COM
    kerberos method = secrets and keytab
    client signing = yes
    client use spnego = yes
####END: Rockstor ACTIVE DIRECTORY CONFIG####

####BEGIN: Rockstor SAMBA CONFIG####
[test_share01]
    root preexec = "/opt/rockstor/.venv/bin/mnt-share test_share01"
    root preexec close = yes
    comment = b'Samba-Export'
    path = /mnt2/test_share01
    browseable = yes
    read only = no
    guest ok = no
####END: Rockstor SAMBA CONFIG####

Set up ACL from windows

I followed the Samba wiki guide linked above to give:

  • on test_share01: Full Control to adgroup2.

This means:

  • users from adgroup2 should be able to access, read, write, and modify: aduser1 and aduser2
  • users that do NOT belong to adgroup2, such as aduser3 should not be able to access, read, write, and modify.

Test the end result

From Windows:

  • I first mapped the test_share01 as a new network drive as user SAMDOM\aduser1. It worked, and I could create a new file named test_file_from_aduser1.txt.
  • Disconnect the mapped network drive.
  • Create a new network drive mapping of test_share01 as user SAMDOM\aduser3. I get connection refused due to "You do not have permission access to \testserver\test_share01".

It thus all seems to work as expected.

For reference, the resulting permissions as seen from the Samba host (Rockstor machine):

buildvm155:~ # ls -lah /mnt2/test_share01
total 8.0K
drwxrwx---+ 1 root                             domain admins@samdom.example.com 98 Sep 11 10:43 .
drwxr-xr-x  1 root                             root                             90 Aug 30 15:28 ..
-rwxrwxr-x+ 1 aduser1@samdom.example.com       domain users@samdom.example.com  37 Sep 11 10:43 tesfile_from_aduser1.txt

Let me know if that fits what you need and I can give more details on whatever step(s) you would like.

3 Likes
10

For general information, note that thanks to this thread, I seem to have found:

So thanks a lot, @b_b for bringing this to light!

2 Likes