I couldn't find any report of success on running a Samba AD DC in an
unprivileged container.
The problem seems to be rooted in the acl_xattr vfs-module that is required
to store the NT ACLs.
The full support of the latter is essential for the operation of the AD DC
but the acl_xattr module
unfortunately stores them in an extended attribute of the security
namespace, which is only accessible
by privileged processes and therefore not usable for a Samba installation
inside an unprivileged container.
Now there is another vfs module that fully supports NT ACLs and stores them
in an extended attribute but also
provides the possibility to specify the namespace and name of the extended
attribute that holds the ACLs.
The nfs4acl_xattr vfs module can store the ACLs in the extended attribute
user namespace.
After some experimenting I was successful to provision a Samba AD DC in an
unprivileged lxc on OpenZFS with the following command:
samba-tool domain provision --domain=${DOMAIN} --realm=${REALM}
--dns-backend=SAMBA_INTERNAL --server-role='dc'
--host-name=${SAMBA_ADDC_HOSTNAME} --host-ip=${ADDC_HOST_IP} --use-rfc2307
--adminpass=${INIT_PASSWD} --option="vfs objects = dfs_samba4 posixacl
nfs4acl_xattr acl_xattr" --option="nfs4acl_xattr:encoding = nfs"
--option="nfs4acl_xattr:version = 41"
--option="nfs4acl_xattr:default acl
style = windows" --option="nfs4acl_xattr:xattr_name =
user.nfs4_acl"
This does store the ACLs in the user.nfs4_acl extended attribute which is
accessible from inside the unprivileged container.
The "vfs objects" option in the above command requires some further
explanation.
Initially I started with just --option="vfs objects = nfs4acl_xattr"
which
failed because the provisioning script requires the support of POSIX ACLs at
some point.
I still don't exactly understand why. Skimming through the source code
revealed that the acl_xattr vfs module does not only implement the NT ACL
functions but also the required POSIX ACL vfs functions. However, the
nfs4acl_xattr vfs module does not implement those functions but explicitely
fails calls to the POSIX ACL functions.
This means it does also not pass the call down to another vfs module in the
stack that might potentially implement these functions.
On the other hand the posixacl vfs module, which as its name says implements
the POSIX ACL vfs functions, does pass calls to the NT ACL functions down
the stack.
So you have to put this module in front of the nfs4acl_xattr module in the
vfs objects option, i.e. with --option="vfs objects = posixacl
nfs4acl_xattr" the provisioning completes.
Next was to also include the dfs_samba4 vfs module which is required to get
a full featured Samba AD DC.
The reason why there is also the acl_xattr at the end of the vfs objects
option of the provision command is simply to silence some commands like
smbclient, which where complaining: "vfs objects specified without required
AD DC module: acl_xattr", but nevertheless worked. As far as I can tell,
none of the functions implemented by the acl_xattr vfs module ever get
called with this module configuration because all calls are processed by one
of the vfs functions higher in the stack.
There is also a difference in the implementation of the POSIX ACL vfs
functions between the posixacl module and the acl_xattr module.
The latter does not only set the POSIX ACL but also remove a NT ACL in case
one existed. My understanding is that this is not important for a Samba AD
DC that is built fresh
with the above provisioning command.
As far a I can tell from running the initial standard test commands and
investigating the logs, the Samba AD DC installed this way inside an
unprivileged lxc on OpenZFS does work.
Nevertheless, because this is some kind of a hack I would like to ask which
pitfalls I might have overlooked.
The only difference to a similar installation of a Samba AC DC in a
privileged container are these "Unknown gid" messages in the output of
the
provisioning command:
INFO 2021-02-02 19:51:42,853 pid:942
/usr/local/samba/lib/python3.7/site-packages/samba/provision/__init__.py
#1592: Setting up self join
Repacking database from v1 to v2 format (first record
CN=dhcp-Properties,CN=Schema,CN=Configuration,DC=....,DC=....,DC=....)
Repack: re-packed 10000 records so far
Repacking database from v1 to v2 format (first record
CN=mSMQMigratedUser-Display,CN=405,CN=DisplaySpecifiers,CN=Configuration,DC....,DC=....,DC=....)
Repacking database from v1 to v2 format (first record
CN=ipsecNegotiationPolicy{72385233-70FA-11D1-864C-14A300000000},CN=IP
Security,CN=System,DC=.....,DC=....,DC=....)
map_smb4_to_nfs4_id: Unknown gid [30000]
map_smb4_to_nfs4_id: Unknown gid [30001]
map_smb4_to_nfs4_id: Unknown gid [30002]
....
map_smb4_to_nfs4_id: Unknown gid [30005]
map_smb4_to_nfs4_id: Unknown gid [30006]
map_smb4_to_nfs4_id: Unknown gid [30002]
map_smb4_to_nfs4_id: Unknown gid [30003]
map_smb4_to_nfs4_id: Unknown gid [30007]
INFO 2021-02-02 19:51:45,498 pid:942
/usr/local/samba/lib/python3.7/site-packages/samba/provision/sambadns.py
#1143: Adding DNS accounts
INFO 2021-02-02 19:51:45,517 pid:942
/usr/local/samba/lib/python3.7/site-packages/samba/provision/sambadns.py
#1177: Creating CN=MicrosoftDNS,CN=System,DC=....,DC=....,DC=....
I have no idea what implications they have and if it means that I might see
some problems later during the daily operation of the Samba AD DC.
And finally, all would be much easier if the acl_xattr module would provide
a similar configuration option for the extended attribute namespace and name
like the nfs4_acl module.