Clarification on Samba AD Security Model for Remote RPC Administration

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).

Context:
Our environment deliberately separates AD administration from 
Unix/file-server administration.
OpenLDAP is the source of truth for Unix users/groups.
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.

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.

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.
  * Note: The same account can perform admin operations on a domain 
controller.

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? Or is it just an implementation 
detail of the current smbd code?
  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?
  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."
  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.

Thanks in advance for any insights.
Best regards,



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