Comment 0 for bug 2054445

This is a regression from when we added support for multiple AD backends (see https://github.com/ubuntu/adsys/pull/467)

Previously adsys would use the first domain from `sssd.conf` and potentially override it if `ad_domain` is explicitly set for the domain, see: https://github.com/ubuntu/adsys/blob/32a830f2a8204cc8b896094bad512ed619fbf6b7/internal/adsysservice/adsysservice.go#L279-L280

The current implementation raises an error if we are not able to find an `ad_domain` setting in the domain section, even if we already have a domain (`sssdDomain`): https://github.com/ubuntu/adsys/blob/c68d2cc999d25b1cb408a9e31775a76d2af4c8c7/internal/ad/backends/sss/sss.go#L62-L65

Ideally we should set `domain` to `sssdDomain` if we cannot find a value for `ad_domain`, which will mimic the behavior previous to the refactor.

While by default joining a domain with `realm join` will set the appropriate configuration values in `sssd.conf` so this doesn't happen, this is a regression we should aim to fix.

### Steps to reproduce it

1. Join an AD domain with sssd (e.g. using `realm join`)
2. Install the latest version of adsys, run `adsysctl update -m -vv`, everything should work
3. Comment out the `ad_domain` line from `/etc/sssd/sssd.conf`
4. `adsysctl update -m -vv` now fails, and the adsysd service does not start anymore
5. (Optional) To confirm the functionality prior to the regression, re-attempt the steps above on Ubuntu 22.04 using the adsys version currently in the archive (0.9.2) -- adsys is able to correctly determine the domain even without the `ad_domain` setting.

GitHub issue: https://github.com/ubuntu/adsys/issues/910