Re: Clarification on Samba AD Security Model for Remote RPC Administration

On Tue, 11 Aug 2026 09:14:46 +0000
Havany via samba <[email protected]> wrote:

> Hi,
> I’d like to clarify the security implications of a specific Samba AD 
> architecture, focusing on remote Samba/RPC administration of 
> domain-member file servers (not SMB share access).

They are basically the same thing, administration and share access both
rely on a user being both a Unix user and a SMB user.

> 
> Context:
> Our environment deliberately separates AD administration from 
> Unix/file-server administration.

Why ? You are just duplicating things

> OpenLDAP is the source of truth for Unix users/groups.

Well yes, in your case, but you now have two sources of truth, your
openLDAP and AD and you need to keep them in sync.

> LSC syncs a filtered subset of these to our Samba 4 AD domain
> controllers. Our Linux file/print servers are Samba AD domain members
> but do not use winbind for Unix identities. Instead, we use idmap_nss
> with:
> 
> idmap config * : backend = tdb
> idmap config * : range = 1000000-1999999
> idmap config <DOMAIN> : backend = nss
> idmap config <DOMAIN> : range = ...
> 
> Thus, a domain user only gets a Unix UID/GID mapping on a file server
> if they also exist in OpenLDAP (resolvable via NSS).
> This is intentional: our AD admin accounts do not exist in OpenLDAP,
> so they have no Unix UID/GID mapping on file servers. The goal is to 
> prevent AD admins from automatically gaining remote Samba/file-server 
> admin access.
> 

Have you ever heard of ACLs ? You just deny access to things on the
Unix machines. Or you could use the rfc2307 attributes and not give
uidNumber or gidNumber attributes to anything you do not want visible
on Unix.

> Observed Behavior:
> There are two distinct authorization layers:
> 
>   1- An AD user must be resolvable via NSS/idmap to establish an SMB 
> session on the file server.
>   2- Even with an NSS/idmap identity, a user cannot perform
> privileged operations (e.g., net rpc rights grant) unless they also
> have the appropriate Samba/AD admin privileges.
> 

They are not both authorisation layers, the first is authentication,
the second is authorisation.

> For AD-only admin accounts (not in OpenLDAP):
> 
>   * Kerberos authentication works (kinit succeeds, TGT is valid,
> service tickets are obtained).
>   * But when these accounts attempt to use net rpc against the file 
> server, SMB session setup fails with: check_account: Failed to
> convert SID S-1-5-21-... to a UID (dom_user[DOMAIN\toto]). The client
> receives NT_STATUS_LOGON_FAILURE.

That is to be expected, Samba does not know who the user is.

>   * Note: The same account can perform admin operations on a domain 
> controller.
> 

Again expected, Samba AD DCs use a different idmap backend where all
users and groups are know to the OS.

> Key Questions:
> 
>   1- Is the requirement for successful SID-to-UID conversion during
> SMB session establishment an intentional and supported part of
> Samba’s security model for domain members?

Yes, Samba has to know who the user is and then needs a Unix user to
map the users SID to.

> Or is it just an
> implementation detail of the current smbd code?

Yes it is implemented in Samba, and always has been.

>   2- Long-term risk: Could a future Samba version change the SMB/RPC 
> auth path to allow an AD-authenticated identity with admin privileges
> to establish an SMB session and access remote administrative RPC
> operations without requiring a SID-to-UID mapping? In other words,
> could this requirement be bypassed?

Anything is possible, but I personally doubt it will be changed.

>   3- Official recommendation: If the current behavior is not
> guaranteed as part of the security model, what is the explicitly
> supported Samba mechanism to enforce this policy?
> "An AD admin account must not be able to remotely administer a Samba 
> domain member unless it also has a Unix identity on that member."

That, in my opinion, is the wrong question, it probably should be
something like:

An AD admin account must not be able to remotely administer a Samba
domain member unless it has permission to do so.

See ACLs.

>   4- Operation order: Could you clarify the exact sequence in this
> case? Kerberos auth -> SID/security-token construction -> SID-to-UID 
> resolution -> SMB session establishment -> SAMR/LSARPC operation 
> authorization.

Well no, not without diving into the code and working out the order.
What I can say is that it is very easy to deny users and groups access
to anything by using the correct ACLs, you just have to get out of the
Unix mindset where only 'ugo' permissions exist.

Rowland

-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba