(Regression) sssd backend fails if ad_domain is not set

[GabrielNagy]

Is there an existing issue for this?

• I have searched the existing issues and found none that matched mine

Describe the issue

This is a regression from when we added support for multiple AD backends (see #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:

adsys/internal/adsysservice/adsysservice.go

Lines 279 to 280 in 32a830f

	// domain is either domain section provided by the user or read in sssd.conf
	adDomain := cfg.Section(fmt.Sprintf("domain/%s", domain)).Key("ad_domain").String()

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

adsys/internal/ad/backends/sss/sss.go

Lines 62 to 65 in c68d2cc

	domain := cfg.Section(fmt.Sprintf("domain/%s", sssdDomain)).Key("ad_domain").String()
	if domain == "" {
	return SSS{}, errors.New(gotext.Get("could not find AD domain name corresponding to %q", sssdDomain))
	}

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.

Ubuntu users: System information

No response

Non Ubuntu users: System information

No response

Additional information

No response

Double check your logs

• I have redacted any sensitive information from the logs

[didrocks]

IIRC, we did that change on purpose so that it’s not implicit and random anymore. Can you check what sssd does in that configuration so that we align behaviour, which seems the most logical? (If sss fails in that case, we should fail too, if it’s taking the first, then we take the first)

[GabrielNagy]

I confirmed that sssd works properly without this setting, and their AD join documentation suggests these options aren't mandatory.