Samba shares authenticated by Active Directory

I’ve joined linux systems running Debian and CentOS 7 to Active Directory and set up Samba shares based on that, but I have yet to get this to work on RockyOS 9.

From what I understand, RockyOS 9 is different in that it uses SSSD instead of Winbind.

I have joined my RockOS 9 server to the domain and can query users, groups, and passwords. I can assign AD users and groups to files and folders. Signed in to my Windows client machine, I can get to the server and see the network shared folder in File Manager using the Windows credentials of my logged in user (a.k.a. working normally). When I click on it, I get the error that \SERVER\share is unavailable.

The most relevant log message I can find is “check_account: Failed to find local account with UID [numbers redacted] for SID [more numbers redacted] (dom_user[SHORT_DOMAIN/])”.

That error message isn’t leading me to anything relevant with RockOS 9.

I’ve combed through /etc/nsswitch.conf /etc/krb5.conf /etc/samba/smb.conf and so forth, trying to verify my settings against working configurations on Debian and CentOS 7 servers (I know, they’re different but I’m grabbing at straws at this point).

Are there any hints to get this going? Has it been done with RockyOS 9? I’ve found how-tos for joining RockyOS 9 to AD (done) and file shares with RockyOS 9, but not file shares using AD for authentication.

Is Samba configured to use SSSD as backend?


idmap config * : backend =  sss

Here’s what I’ve got so far in smb.conf (redacted sensitive info, of course)

        client max protocol = SMB2
        client min protocol = SMB2
        domain master = No
        kerberos method = secrets and keytab
        local master = No
        log file = /var/log/samba/log.%m
        max log size = 50
        preferred master = No
        restrict anonymous = 2
        security = USER
        server max protocol = SMB2
        server min protocol = SMB2
        template shell = /bin/bash
        idmap config [short_domain] : range = 10000-99999
        idmap config [short_domain] : backend = sss
        idmap config * : range = 100000-19999999
        idmap config * : backend = sss
        access based share enum = Yes

        comment = Archive folder
        create mask = 0660
        delete veto files = Yes
        directory mask = 0770
        force create mode = 0660
        force directory mode = 0770
        force group = "[group]"
        hide unreadable = Yes
        path = /[zfs parent share]/[shared folder]
        read only = No
        valid users = @[short_domain]/[group]
        veto files = /.*/

I’m using ZFS but Samba to share; works fine on other setups.

Now I’m thinking something could be amiss with /etc/nsswitch.conf settings?

Well, this is in the log file…

smb_gss_krb5_import_cred failed with [No credentials were supplied, or the credentials were unavailable or inaccessible: Keytab MEMORY:cifs_srv_keytab is nonexistent or empty]

If I use klist I can see where I (the user trying to access the share) have a kerberos ticket on the server.

Default principal: [my user name]

Valid starting     Expires            Service principal
05/22/23 11:58:12  05/22/23 21:58:12  [krb]/[FQDN]@[FQDN]
        renew until 05/29/23 11:58:05```

Shouldn’t security be set to ads or domain if you want to use AD for authentication?

Not sure, but this is giving me things to try so thank you! Current errors upon running testparm:

ERROR: The 'security=ADS' mode requires 'realm' parameter to be set!

 ERROR: Do not use the 'sss' backend as the default idmap backend!


So I shouldn’t use sss as the default idmap backend?

Setting security to domain only gives the idmap error:

ERROR: Do not use the 'sss' backend as the default idmap backend!```

This guide looked the most promising, but when I join with realm it seems to break the wbinfo function (and I suppose winbind). So, are the two mutually exclusive?

It’s been a while since I configured a Samba/SSSD/AD connection, but you need to add the realm parameter to smb.conf with the name of the domain (e.g yourdomain.tld).

I think that you cannot have SSSD as the default backend (used a bad example in my previous answer) since it is read only. Just remove this line from smb.conf:

idmap config * : backend = sss

Well, I don’t know what’s going on exactly. Winbind can’t seem to pair the SID and GID. SSSD without winbind (or not using winbind) doesn’t seem to supply the credentials in the correct format (DOMAIN\ I did it on Debian (not using SSSD) not too long ago. Rocky OS 9 seems to be different from prior versions, like CentOS 6, 7, & 8. I’m re-reading the RHEL documentation on SSSD hoping I can figure something out. Thanks for your input and help.

We use a username map script to strip domain info, example:



case "${ACCOUNTNAME}" in

        # skip

        echo "${ACCOUNTNAME}" | sed -e 's/[^\\]*\\//'


exit 0

Added it to our config after CVE-2020-25717, based on (ignore the “local nt token” stuff). Left it in after the vulnerability was patched.

As I understand it, the username map script maps the domain user to a local account, which means that SSSD is used to identify the user. Should mean that if SSSD can look up the user in Active Directory, Samba is happy.

Ah, I see. That seems to be the main issue I’m facing. Thanks for this. I think it may help greatly.
Strange SSSD is giving such grief…I guess. I may just be inexperienced with it.
I appreciate all the advice.

Well, I still can’t get this to work. I think Samba shares authenticated via AD user accounts/groups wasn’t meant to be with Rocky OS 9.
From the Samba listserv, someone with my exact problem (and version of Samba) downgraded from RockyOS 8.8 to 8.7. There goes my idea of installing RockyOS 8 on the server to get around this problem.

check_account: Failed to convert SID S-1-5-21-… to a UID > (dom_user[DOMAIN\username] > Not bothered about the SID, but what was the RID ? S-1-5-21-847089129-1187572071-3330553849-1107 > Also, does the username end with a ‘$’ ? no > Network problem ? > What else changed ? Not a network problem and nothing else has changed. I just downgraded to Samba 4.16.4 from the Rocky Linux 8.7 repos, but left everything else as Rocky 8.8, and everything is working fine. Thanks, Dale

Ok, it could be an issue with Samba and RHEL/Rocky 8.8. I installed a Samba server on RHEL 8.6 EUS with SSSD this week and it works.

Very interesting and in keeping with what was in that other thread on the Samba listserv.

Do you know what version of Samba is running on RHEL 8.6? I’m thinking if I downgrade the package it may work.

Sorry, not off the top of my head. I’ll try to remember to check next week, but it’s a long weekend so I’m off until Wednesday.

No problem; I appreciate you continuing to look at this.

Now it seems that winbind is trying to authenticate “root” to AD when I try to access a regular file share with a windows user.
“name_to_sid [rpc] MYDOMAIN\ROOT for domain MYDOMAIN”

I don’t quite know what to make of that.

I’m trying to compare my working Samba shares (on the same network/AD) on CentOS 7 with what I’m trying to do in Rocky OS 9.
“net stat sessions” displayed connected users (or one user in the case of ROS9) so it must just not be resolving the SID/UIDs correctly.
I don’t know what has dramatically changed, but something major seems to.

Checked the Sambaserver I installed on RHEL 8.6 EUS and it is version 4.15.5-12.

Installed Samba on RHEL 8.8 EUS this week with Active Directory authentication using SSSD and it worked, I think it was Samba 4.17.x.