[Authentication] When does 'realm discover' return two sections for the one realm, with one not configured?

[Richard Sharpe]

On Wed, Oct 16, 2019 at 12:07 AM Sumit Bose <sbose at redhat.com> wrote:
>
> On Tue, Oct 15, 2019 at 09:26:38AM -0700, Richard Sharpe wrote:
> > Hi folks,
> >
> > Today I saw the following when running 'realm discover -v <some-realm>'
> >  * Resoving: _ldap._tcp.<some-realm>
> >  * Performing LDAP DSE LOOKUP on: 10.x.y.z
> >  * Performing LDAP DSE LOOKUP on: 10.x.a.z
> >  * Successfully discovered: <some-realm>
> > SOME-REALM
> >   type: kerberos
> >   realm-name: SOME-REALM
> >   domain-name: some-realm
> >   configured: kerberos-member
> >   ...
> > some-realm
> >   type: kerberos
> >   realm-name: SOME-REALM
> >   domain-name: some-realm
> >   configured: no
> >
> > Why would a domain/realm have this second section?
>
> Hi,
>
> typically I see this double output with 'realm list' on systems where
> both SSSD and Samba/Winbind are configured. This is because realmd does
> not store its state in a specific file but collects to  state from the
> existing Samba, SSSD and Kerberos configuration.
>
> I haven't seen this with 'realm discover' so far. What is the
> 'client-software' for the two different realms? You have given one
> section name in upper-case and the other in lower-case, I guess this
> might be the reason why realmd thinks that there are two "different"
> realms. I'll try to reproduce.

As it turns out we are running winbindd and SSSD ... however, that is
not our problem, it seems.

The uppercase name of the domain, SOME-REALM, is getting into the
sssd.conf file in the [domain/SOME-REALM] section and that causes the
SSSDConfig utility to throw a NoDomainError exception like the
following (with some extra debugging):

      File "/usr/lib/python2.7/site-packages/SSSDConfig/__init__.py",
line 1913, in get_domain
        raise NoDomainError("domain {} not in {}".format(name,self.opts))
    NoDomainError: domain win.ad.test not in [{'type': 'empty',
'name': 'empty'}, {'type': 'section', 'name': 'sssd', 'value':
[{'type': 'option', 'name': 'services', 'value': 'nss, pac'}, {'type':
'option', 'name': 'domains', 'value': 'WIN.AD.TEST'}, {'type':
'option', 'name': 'config_file_version', 'value': '2'}, {'type':
'empty', 'value': 'empty'}]}, {'type': 'section', 'name':
'domain/WIN.AD.TEST', 'value': [{'type': 'option', 'name':
'ad_domain', 'value': 'win.ad.test'}, {'type': 'option', 'name':
'krb5_realm', 'value': 'WIN.AD.TEST'}, {'type': 'option', 'name':
'realmd_tags', 'value': 'manages-system joined-with-samba'}, {'type':
'option', 'name': 'cache_credentials', 'value': 'True'}, {'type':
'option', 'name': 'id_provider', 'value': 'ad'}, {'type': 'option',
'name': 'default_shell', 'value': '/bin/bash'}, {'type': 'option',
'name': 'ldap_sasl_authid', 'value': 'HS8005056AD377E$'}, {'type':
'option', 'name': 'ldap_id_mapping', 'value': 'False'}, {'type':
'option', 'name': 'use_fully_qualified_names', 'value': 'True'},
{'type': 'option', 'name': 'fallback_homedir', 'value':
'/home/%u@%d'}, {'type': 'option', 'name': 'access_provider', 'value':
'ad'}, {'type': 'option', 'name': 'ad_hostname', 'value':
'HS8005056AD377E.WIN.AD.TEST'}, {'type': 'option', 'name':
'ad_maximum_machine_account_password_age', 'value': '0'}, {'type':
'option', 'name': 'dyndns_update', 'value': 'False'}, {'type':
'option', 'name': 'ldap_schema', 'value': 'rfc2307bis'}]}]

We are using sssd 1.16.1 and have no changes in the realm code or the
SSSDConfig utility.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)