Issues adding an ad trust

[Itinerary3543]

We have setup two test systems, a containerized FreeIPA and a VM running Active Directory. After running IPA server install with the below settings and then running ipa-adtrust-install in the container, we attempt to add the trust with

ipa trust-add --type=ad test.example.com --admin Administrator --password

The command prompts for the AD Admin password then errors out with the following error:

ipa: ERROR: CIFS server communication error: code "3221225996", message "The transport connection is now disconnected." (both may be "None")

If you check the SMB log this error is present:

[2024/02/10 02:30:06.234488,  0, pid=4751] ../../lib/util/fault.c:185(smb_panic_log)
  INTERNAL ERROR: sys_setgroups failed in smbd (smbd[172.17.0.2) (client [172.17.0.2]) pid 4751 (4.19.4)

Couple things stick out here:

1. I've seen that 3221225996 error mentioned in a Bug Zilla report referring to issues with selinux https://bugzilla.redhat.com/show_bug.cgi?id=2096521 and that supposedly was fixed in this patch https://access.redhat.com/errata/RHBA-2022:8283. However I've checked and neither the container nor the host is running selinux. Even though "SELINUX=enforcing" in /etc/selinux/config checking getenforce says "Disabled"
2. We've tried with the rocky-9 container and the centos-8-stream container with the same result.
3. I've seen several references to issues pertaining to id range exhaustion specifically related to samba and the sys_setgroups error. We checked the dnaRemainingValues: in ldap and it was 199998.

I'm unclear what actions Samba is taking during the trust-add step and the logging is somewhat vague. Below is the ipa install commands we're running

sudo docker run -ti -h test-idm01.test.isg.vision --read-only  \
   -e TZ=America/New_York  \
   -e IPA_SERVER_IP=192.168.10.13 \
   --restart=unless-stopped  \
   -v /var/lib/ipa-data:/data  \
   -v /etc/localtime:/etc/localtime:ro  \
   -v /dev/urandom:/dev/random:ro  \
   --tmpfs /run --tmpfs /tmp --tmpfs /run/lock  \
   --name freeipa-server  \
   --dns=127.0.0.1  \
   -p 192.168.10.13:53:53/udp -p 192.168.10.13:53:53/tcp  \
   -p 192.168.10.13:80:80/tcp -p 192.168.10.13:443:443/tcp  \
   -p 192.168.10.13:389:389/tcp -p 192.168.10.13:636:636/tcp  \
   -p 192.168.10.13:88:88/tcp -p 192.168.10.13:464:464/tcp  \
   -p 192.168.10.13:88:88/udp -p 192.168.10.13:464:464/udp  \
   -p 192.168.10.13:123:123/udp -p 192.168.10.13:135:135/tcp  \
   -p 192.168.10.13:138:138/tcp -p 192.168.10.13:139:139/tcp  \
   -p 192.168.10.13:445:445/tcp -p 192.168.10.13:1024-1300:1024-1300/tcp  \
   -p 192.168.10.13:3268:3268/tcp -p 192.168.10.13:138:138/udp  \
   -p 192.168.10.13:139:139/udp -p 192.168.10.13:389:389/udp  \
   -p 192.168.10.13:445:445/udp  \
   --add-host=test-idm01.test.example.com=192.168.10.13  \
   --add-host=addc01.test.addomain.com=192.168.10.14  \
   --sysctl net.ipv6.conf.all.disable_ipv6=0  \
   quay.io/freeipa/freeipa-server:centos-8-stream ipa-server-install

ipa-server-install-options

--ip-address=192.168.10.13
--domain=test.example.com
--realm=TEST.EXAMPLE.COM
--ds-password=verydifficultpassword
--admin-password=mypassword
--no-ntp
--setup-dns
--forwarder=8.8.8.8
--no-reverse
--netbios-name=TEST
--unattended

samba.log.172.17.0.2.txt

[abbra]

There are several errors in your execution.

Mostly you need to ensure your environment is providing correct set up to allow operations to run. Samba is expecting ability to switch between root and other users and set effective groups/users details on the processes it starts. This might be in conflict with docker configuration of the containerized namespaces. In particular, if this is about rootless container, your subid/subgid ranges need to be able to work with the IDs expected by Samba and FreeIPA, if you run them in containers. Using setgroups() also requires CAP_SETGID capability, it needs to be allowed for this container namespace, and also seccomp filter needs to allow those operations.

The default RPC server dynamic port range is in higher numbers, not 1024-1300. From smb.conf(5):

           Default: rpc server dynamic port range = 49152-65535

[Itinerary3543]

So we're definitely using the userns-remap = default value in the docker.json which means the root user in the container is not the same userid as the root on the host, but I don't know if that is the same as "rootless". What changes need to be made to subid and subgid to accommodate this? I had suspected this could have been a cause based on some searches and we tried adding 5000000 to the /etc/subid and /etc/subgid to the dockremap entry but continued seeing the same error. How can we determine how many ids to add to the range for this?

This is the first time I've seen any mention of the CAP_SETGID capability but we can try setting this.

For the ports, we were using this guide, Free IPA Active Directory Trust Setup where we gleaned the ports 1024-1300 from but we didn't notice the 49152-65535, we'll keep that in mind. Is this a better guide for this purpose? https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/installing_trust_between_idm_and_ad/index

[abbra]

Regarding documentation, you should be using RHEL IdM documentation as that is the primary source. FreeIPA wiki does not change over time.

I should make it clear: containerized FreeIPA setup was never tested with trust to Active Directory feature. Containerized FreeIPA setup is also not supported beyond what is written in the Readme document here. There is no production support for it. If things work, fine, if they break and that can be reproduced with non-containerized deployment, fine -- report a bug to FreeIPA upstream. Otherwise, there is no support for it.

[adelton]

@abbra, while I agree with your general description of the situation, @Itinerary3543's question "How can we determine how many ids to add to the range for this?" might we worth exploring though. Assuming the problem is really the uids being exhausted in the user namespace, what is the ultimate way to set the uid range Samba uses in this case, to keep it under whatever limits are set in /etc/subuid/subgid?

[abbra]

I don't think it is going to be a problem if you do not do 1:1 reuse of the host namespace in the container.

[adelton]

@Itinerary3543 Have you made some progress with the investigation, for example testing that CAP_SETGID?

[adelton]

We seem to have lost traction here.