I think I have found a better solution than the ones currently presented here. In part because as far as I can tell cgmanager is dead, in part because my solution doesn't feel like a hacky workaround, but mostly because this discussion still shows up when searching for a solution to the problem. It's pretty simple actually: use systemd user mode.

Granted if you don't use systemd this solution isn't going to help. In that case I'd advice you to figure out if your init system has some way of allowing unpriviliged users to run services at boot and use that as a starting point.

Using systemd user mode to autostart unprivileged lxc containers

I'm assuming you have unprivileged lxc containers working properly and that running lxc-autostart as the container's user works. If so, do the following:

1. Create the file ~/.config/systemd/user/lxc-autostart.service in the home of whatever user has the lxc containers:

[Unit]
Description="Lxc-autostart for lxc user"

[Service]
Type=oneshot
ExecStart=/usr/bin/lxc-autostart
ExecStop=/usr/bin/lxc-autostart -s
RemainAfterExit=1

[Install]
WantedBy=default.target

2. Then as that user run:

systemctl --user enable lxc-autostart

(Note, the --user option tells systemctl you're using it in user mode. All of the things I normally do with systemctl, start, stop, statuc, enable, etc, work with --user.)

3. Then run the following, where $user is the name of the user that has the lxc containers:

sudo loginctl enable-linger $user

This is necessary for systemd to start a systemd user instance for $user at boot. Otherwise it would only start one at the moment $user logs in.

For more information I'd recommend the archlinux wiki systemd/timer page and the systemd man pages.

Accessing a user's systemd instance as root

You can actually start/stop/whatever a user's systemd service as root, however this requires you to set the XDG_RUNTIME_DIR environment variable. Assume $user is the user whose instance you want to access and $uid it's uid, then this is how you'd start the lxc-autostart.service defined above:

sudo -u $user XDG_RUNTIME_DIR=/run/user/$uid systemctl --user start lxc-autostart

You can even use systemd-run to run arbitrary commands as that user in a way that doesn't break lxc. I'm using the following commands to stop/start my containers before/after backup, where $name is the name of the lxc container that's being backed up:

sudo -u $user XDG_RUNTIME_DIR=/run/user/$uid systemd-run --user --wait lxc-stop -n $name
sudo -u $user XDG_RUNTIME_DIR=/run/user/$uid systemd-run --user --scope lxc-start -n $name

(Note that without --wait systemd-run doesn't block until the container is stopped.)

Solved it! Sharing the solution, just in case somebody else with the same problem stumbles upon this thread.

In the default configuration, LXD / the Host-System does not allocate enough UIDs/GIDs to its containers, so that you cannot effectively become a user with an ID as high as picked by FreeIPA randomly.

The files /etc/subuid and /etc/subgid have entries that read root:100000:65536, which note the IDs that LXD will effectively use at the time of writing. Host UIDs/GIDs in the range of 100000-165536 get mapped to container IDs from 0-65536. The container, trying to use ID 161200001 in my case, is far over that boundary.

Based on this article https://insights.ubuntu.com/2015/10/30/nested-containers-in-lxd/ , I modified the mapped IDs, and specified which IDs FreeIPA may use. Changes to the sub*id-files might only work before initialising a container.

Specifically, this config worked:

LXD Host:

/etc/subuid: root:5000000:2500000

/etc/subgid: root:5000000:2500000

LXD Container with FreeIPA-Server:

initialise the server with ipa-server-install --idstart=1000000 --idmax=2000000

Here, the directory IDs range from 1.000.000 - 2.000.000, whereas the client has 2.500.000 IDs available. Due to the offset of 5.000.000, the host may also join that FreeIPA directory. Adjust the numbers as desired, YMMV.