#2527 sssd.conf(5) man page gives bad advice about domains parameter
Closed: Fixed None Opened 4 years ago by lslebodn.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1172865

Description of problem:

When I initially configured sssd.conf, I set up the following:

    [sssd]
    domains = example.org

    [domain/example.org]
    access_provider = ad
    auth_provider = ad

This worked perfectly, as sssd takes the default discover domain and AD domain,
from the name of the domain in the domains parameter.

But then I saw this advice in sssd.conf(5):

    domains
        A domain is a database containing user information. SSSD can use
        more domains at the same time, but at least one must be configured
        or SSSD won?t start. This parameter described the list of domains
        in the order you want them to be queried. A domain name should only
        consist of alphanumeric ASCII characters, dashes and underscores.

So I replaced what I had with:

    [sssd]
    domains = example_org

    [domain/example_org]
    access_provider = ad
    auth_provider = ad
    dns_discovery_domain = example.org
    ad_domain = example.org

This seemed to work? until I ran useradd to create a local system account,
which blocked forever on the sss nsswitch database provider. And while that
happened, sssd repeatedly logged this:

==> sssd_ad_example_org.log <==
(Wed Dec 10 18:13:28 2014) [sssd[be[ad_example_org]]]
[sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap:
Referral(10), 0000202B: RefErr: DSID-03100742, data 0, 1 access points
        ref 1: 'ad-root.example.org'

(Wed Dec 10 18:13:29 2014) [sssd[be[ad_example_org]]]
[sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap:
Referral(10), 0000202B: RefErr: DSID-03100742, data 0, 1 access points
        ref 1: 'ad-root.example.org'

(Wed Dec 10 18:13:29 2014) [sssd[be[ad_example_org]]]
[sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap:
Referral(10), 0000202B: RefErr: DSID-03100742, data 0, 1 access points
        ref 1: 'ad-root.example.org'

(Wed Dec 10 18:13:29 2014) [sssd[be[ad_example_org]]]
[sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap:
Referral(10), 0000202B: RefErr: DSID-03100742, data 0, 1 access points
        ref 1: 'ad-root.example.org'

(Wed Dec 10 18:13:29 2014) [sssd[be[ad_example_org]]]
[ad_account_info_complete] (0x0010): Bug: dp_error is OK on failed request

==> sssd_nss.log <==
(Wed Dec 10 18:13:29 2014) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040):
Unable to get information from Data Provider
Error: 3, 5, Internal Error (Memory buffer error)
Will try to return what we have in cache

Frustrated, I went back to what I had originally, even though it violates the
naming advice in sssd.conf(5). And it worked perfectly; useradd returned with
no errors, and sssd didn't log any errors.

So I assert that sssd.conf(5) is dispensing bad advice. It seems like the
easiest way to configure sssd is to make the [domain] section name the DNS
discovery and AD domain name, even though that means the argument to the
"domains =" parameter in the [sssd] section will contain dots, which the man
page forbids. Because specifying both dns_discovery_domain and ad_domain
manually in a [domain] section does NOT appear to have the same effect as just
naming the [domain] section with the correct domain in the first place.

And even if there is some combination of options in the [domain] section that
will have the same effect as simply naming the [domain] section with the domain
name in the first place, the latter is a lot easier and more intuitive to
configure.

Version-Release number of selected component (if applicable):

0:sssd-1.11.6-30.el6_6.3.x86_64

Fields changed

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
mark: no => 0
milestone: NEEDS_TRIAGE => SSSD 1.12.4
review: True => 0
selected: =>
testsupdated: => 0

Fields changed

owner: somebody => preichl

Fields changed

patch: 0 => 1

resolution: => fixed
status: new => closed

Metadata Update from @lslebodn:
- Issue assigned to preichl
- Issue set to the milestone: SSSD 1.12.4

2 years ago

Login to comment on this ticket.

Metadata