How to do cross-subdomain user authentication by short name (among trusted AD subdomains) since sssd-ad 1.15.3?

[Spike White]

Sssd aficionados,

It is with great interest that I read the announcement of SSSD version
1.15.3.

https://lists.fedorahosted.org/archives/list/[e-mail].o...

Among the new features is this:

In a setup where an IPA domain trusts an Active Directory domain, it is now
possible to define the domain resolution order (see
http://www.freeipa.org/page/Releases/4.5.0#AD_User_Short_Names). Starting
with this version, SSSD is able to read and honor the domain resolution
order, providing a way to resolve Active Directory users by just their
short name. SSSD also supports a new option "domain_resolution_order"
applicable in the "[sssd]" section that allows to configure short names for
AD users in setup with "id_provider=ad" or in a setup with an older IPA
server that doesn't support the "ipa config-mod --domain-resolution-order"
configuration option. Also, it is now possible to use
"use_fully_qualified_names=False" in a subdomain configuration, but please
note that the user and group output from trusted domains will always be
qualified to avoid conflicts.

This corresponds exactly to a use case we have.  In fact this design doc (
https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html)

has excellent verbiage describing our use case:

Use cases

Allow the Administrator of an IdM deployment in a trust relationship with
an AD forest to configure its IdM servers and associated IdM clients to
allow user & group resolution and user authentication in all domains (or a
subset of the domains) to be possible by using only the short names without
the domain component, as it’s done by some 3rd party solutions.

That’s our exact situation.  We have a parent AD domain – company.com.  We
have 3 AD subdomains:  amer.company.com, euro.company.com and
asia.company.com.    All 3 AD subdomains have a transitive trust with the
parent domain.  Meaning all 4 domains fully trust each other.   All user
and groups are in the 3 subdomains; none in the parent domain.

We do not have an IPA server, not would our company’s AD administrators
tolerate such – they don’t even allow trusts to Kerberos realms.  (They’re
very security-conscious – and windows-centric).

We are currently using a 3rd party software product for our Linux AD
integration.  (actually, 2 products -- in different parts of the
company).  They’re
currently doing user authentication from all 3 AD subdomains by short
account name.  They’re doing it by domain resolution order (always looking
in the local domain first).

In these products, I join the local AD sub-domain by creating a machine
account under my OU.

I have evaluated sssd-ad on RHEL7 as a potential replacement.  There are
some obscure dusty corners where sssd-ad may not be able to do what these 3
rd party products do.  But outside of that handful of use cases, sssd-ad (&
maybe a couple of companion PAM modules) seem like it’ll accomplish
everything we need for AD-based Linux authentication.

Except for cross-subdomain user authentication by short name.

I’m able to login by short name in the local subdomain.  Using:

[domain/amer.company.com]

use_fully_qualified_names = False

Starting with version 1.15.3, I’m supposed to be able to add:

domain_resolution_order = amer.company.com, euro.company.com,
asia.company.com

to the [sssd] section in /etc/sssd/sssd.conf.  Then I’m supposed to change
my current subdomain section:

[domain/amer.company.com]

use_fully_qualified_names = False

To:

[domain/amer.company.com/euro.company.com/asia.company.com]

use_fully_qualified_names = False

?

How does that work?

To join the amer.company.com subdomain, ‘realm join’ on my test server
created a machine account under my OU.   Namely,
[e-mail].   (Realm join also properly created the
Kerberos creds in the /etc/krb5.keytab file.)

Thus for [domain/amer.company.com], I had to set up ldap_sasl_authid as so:

ldap_sasl_authid = [e-mail]

And the other AD subdomains wouldn’t know about this machine account.

I actually tried this recommended syntax  (see
https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html ):

[domain/amer.company.com/euro.company.com/asia.company.com]

And I caught a syntax error in /var/log/sssd/sssd.log on startup:

(Sun May 13 15:11:07:070656 2018) [sssd] [sss_ini_call_validators]
(0x0020): [rule/allowed_sections]: Section [domain/
amer.company.com/euro.company.com/asia.company.com] is not allowed. Check
for typos.

(Sun May 13 15:11:07:083115 2018) [sssd] [confdb_get_domain_internal]
(0x0010): Unknown domain [amer.company.com]

(Sun May 13 15:11:07:083247 2018) [sssd] [confdb_get_domains] (0x0010):
Error (2 [No such file or directory]) retrieving domain [amer.company.com],
skipping!

Prior to sssd 1.15.3, in order to authenticate from the various AD
subdomains with sssd-ad even by fully-qualified name, you had to join each
subdomain.

Is that still the case?  I have to create a machine account in each
subdomain for a given computer?  Then create 3 separate sections in
/etc/sssd/sssd.conf file?  Like so:

[sssd]

…

domain_resolution_order = amer.company.com, euro.company.com,
asia.company.com

domains = amer.company.com, euro.company.com, asia.company.com

…

[domain/amer.company.com]

use_fully_qualified_names = False

…

ldap_sasl_authid = [e-mail]

[domain/euro.company.com]

use_fully_qualified_names = False

…

ldap_sasl_authid = [e-mail]

[domain/apac.company.com]

use_fully_qualified_names = False

…

ldap_sasl_authid = [e-mail]

and then I’d have to consolidate the 3 /etc/krb5.keytab files created by
'realm join' into one grand & glorious keytab file with all the above
principals?

After that, I'd be able to user authenticate from the various subdomains by
short name?

Spike White

PS Since I’m testing on RHEL7, actually I’m testing version
sssd-ad-1.16.0-19.el7.x86_64

[Jakub Hrozek]

> On 13 May 2018, at 22:44, Spike White  wrote:
>
> Sssd aficionados,
>
> It is with great interest that I read the announcement of SSSD version 1.15.3.
>
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
>
> Among the new features is this:
>
> In a setup where an IPA domain trusts an Active Directory domain, it is now possible to define the domain resolution order (see http://www.freeipa.org/page/Releases/4.5.0#AD_User_Short_Names). Starting with this version, SSSD is able to read and honor the domain resolution order, providing a way to resolve Active Directory users by just their short name. SSSD also supports a new option "domain_resolution_order" applicable in the "[sssd]" section that allows to configure short names for AD users in setup with "id_provider=ad" or in a setup with an older IPA server that doesn't support the "ipa config-mod --domain-resolution-order" configuration option. Also, it is now possible to use "use_fully_qualified_names=False" in a subdomain configuration, but please note that the user and group output from trusted domains will always be qualified to avoid conflicts.
>
> This corresponds exactly to a use case we have.  In fact this design doc (https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html)
>
> has excellent verbiage describing our use case:
>
> Use cases
>
> Allow the Administrator of an IdM deployment in a trust relationship with an AD forest to configure its IdM servers and associated IdM clients to allow user & group resolution and user authentication in all domains (or a subset of the domains) to be possible by using only the short names without the domain component, as it’s done by some 3rd party solutions.
>
> That’s our exact situation.  We have a parent AD domain – company.com.  We have 3 AD subdomains:  amer.company.com, euro.company.com and asia.company.com.    All 3 AD subdomains have a transitive trust with the parent domain.  Meaning all 4 domains fully trust each other.   All user and groups are in the 3 subdomains; none in the parent domain.
>
> We do not have an IPA server, not would our company’s AD administrators tolerate such – they don’t even allow trusts to Kerberos realms.  (They’re very security-conscious – and windows-centric).
>
> We are currently using a 3rd party software product for our Linux AD integration.  (actually, 2 products -- in different parts of the company).  They’re currently doing user authentication from all 3 AD subdomains by short account name.  They’re doing it by domain resolution order (always looking in the local domain first).
>
> In these products, I join the local AD sub-domain by creating a machine account under my OU.
>
> I have evaluated sssd-ad on RHEL7 as a potential replacement.  There are some obscure dusty corners where sssd-ad may not be able to do what these 3rd party products do.

I’m curious, what are the other shortcomings?
> But outside of that handful of use cases, sssd-ad (& maybe a couple of companion PAM modules) seem like it’ll accomplish everything we need for AD-based Linux authentication.
>
> Except for cross-subdomain user authentication by short name.
>
> I’m able to login by short name in the local subdomain.  Using:
>
> [domain/amer.company.com]
> use_fully_qualified_names = False
>
> Starting with version 1.15.3, I’m supposed to be able to add:
>
> domain_resolution_order = amer.company.com, euro.company.com, asia.company.com
>
> to the [sssd] section in /etc/sssd/sssd.conf.  Then I’m supposed to change my current subdomain section:

Yes.
> [domain/amer.company.com]
> use_fully_qualified_names = False
>
> To:
>
> [domain/amer.company.com/euro.company.com/asia.company.com]
> use_fully_qualified_names = False
>
> ?
>
> How does that work?

After startup, SSSD auto-discovers the domains in the forest. From SSSD’s point of view, the domain structure is always flat, so you’d configure:
[domain/amer.company.com]
use_fully_qualified_names = False

[domain/amer.company.com/euro.company.com]
use_fully_qualified_names = False

[domain/amer.company.com/asia.company.com]
use_fully_qualified_names = False

..etc

Keep in mind that by default, the names will still come back qualified from the child domains because that’s the only way to distinguish users from different domains during a multi-step authentication process (e.g. application receives a name to authenticate as, then calls getpwnam on that input and uses the output of getpwnam from then on..). You /can/ tune the full_name_format to only include the user name, but please be aware of the consequences.
> To join the amer.company.com subdomain, ‘realm join’ on my test server created a machine account under my OU.   Namely, [e-mail].   (Realm join also properly created the Kerberos creds in the /etc/krb5.keytab file.)
>
> Thus for [domain/amer.company.com], I had to set up ldap_sasl_authid as so:
>
> ldap_sasl_authid = [e-mail]

As long as the domains trust each other, you can use the account from the joined domain, right? So no configuration should be needed.
> And the other AD subdomains wouldn’t know about this machine account.
>
> I actually tried this recommended syntax  (see https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html ):
>
> [domain/amer.company.com/euro.company.com/asia.company.com]
>
> And I caught a syntax error in /var/log/sssd/sssd.log on startup:
>
> (Sun May 13 15:11:07:070656 2018) [sssd] [sss_ini_call_validators] (0x0020): [rule/allowed_sections]: Section [domain/amer.company.com/euro.company.com/asia.company.com] is not allowed. Check for typos.
> (Sun May 13 15:11:07:083115 2018) [sssd] [confdb_get_domain_internal] (0x0010): Unknown domain [amer.company.com]
> (Sun May 13 15:11:07:083247 2018) [sssd] [confdb_get_domains] (0x0010): Error (2 [No such file or directory]) retrieving domain [amer.company.com], skipping!
>
> Prior to sssd 1.15.3, in order to authenticate from the various AD subdomains with sssd-ad even by fully-qualified name, you had to join each subdomain.
>
> Is that still the case?  I have to create a machine account in each subdomain for a given computer?  Then create 3 separate sections in /etc/sssd/sssd.conf file?  Like so:
>
> [sssd]
> …
> domain_resolution_order = amer.company.com, euro.company.com, asia.company.com
> domains = amer.company.com, euro.company.com, asia.company.com
> …
>
> [domain/amer.company.com]
> use_fully_qualified_names = False
> …
> ldap_sasl_authid = [e-mail]
>
> [domain/euro.company.com]
> use_fully_qualified_names = False
> …
> ldap_sasl_authid = [e-mail]
>
> [domain/apac.company.com]
> use_fully_qualified_names = False
> …
> ldap_sasl_authid = [e-mail]
>
> and then I’d have to consolidate the 3 /etc/krb5.keytab files created by 'realm join' into one grand & glorious keytab file with all the above principals?
>
> After that, I'd be able to user authenticate from the various subdomains by short name?
>
> Spike White
>
> PS Since I’m testing on RHEL7, actually I’m testing version sssd-ad-1.16.0-19.el7.x86_64
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Spike White]

Jakub,

Thanks for the prompt response.  This seems to work great.  As you state:

Keep in mind that by default, the names will still come back qualified
from the child domains because that’s the only way to distinguish users
from different domains

that means 'id admspike_white' now returns:

$ id admspike_white
    uid=2025431([e-mail]) gid=2025431(
[e-mail])       groups=2025431(
[e-mail]),1002([e-mail])

That's a small price to pay.  That's ok.

Curiously, if I don't define:

ldap_sasl_authid = [e-mail]

in my local domain -- that's ok.

But if I don't define it in my non-local domains, when I do an 'id <user>'
(for a user in a remote domain) --  nd it doesn't retrieve user info  and I
get these errors in the /var/log/sssd/sssd*.log files:

(Mon May 14 11:17:04 2018) [[sssd[ldap_child[124579]]]]
[ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client
'host/[e-mail]' not found in Kerberos database

If I add that line in to all remote domain, all works as described above.

Much thanks!
full /etc/sssd/sssd.conf file below:

[sssd]
domains = amer.company.com, apac.company.com, emea.company.com,
japn.company.com
domain_resolution_order = amer.company.com, emea.company.com,
apac.company.com, japn.company.com
config_file_version = 2
services = nss, pam
#ldap_user_member_of = member

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
#entry_cache_timeout = 300
entry_cache_nowait_percentage = 75

[domain/amer.company.com]
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = amer.company.com
krb5_realm = AMER.COMPANY.COM
realmd_tags = joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = ad
ldap_schema = rfc2307bis
#ldap_sasl_authid = host/spikerealmd01.us.company.com
#ldap_sasl_authid = SPIKEREALMD01$@AMER.COMPANY.COM
#ldap_sasl_authid = [e-mail]
ad_enabled_domains = amer.company.com, apac.company.com, emea.company.com,
japn.company.com, company.com
dyndns_update = False
subdomains_provider = none
# also look at
https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648.htm...

[domain/apac.company.com]
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = apac.company.com
krb5_realm = APAC.COMPANY.COM
realmd_tags = joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = ad
ldap_schema = rfc2307bis
#ldap_sasl_authid = host/spikerealmd01.us.company.com
#ldap_sasl_authid = SPIKEREALMD01$@AMER.COMPANY.COM
ldap_sasl_authid = [e-mail]
ad_enabled_domains = amer.company.com, apac.company.com, emea.company.com,
japn.company.com, company.com
dyndns_update = False
subdomains_provider = none

[domain/emea.company.com]
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = emea.company.com
krb5_realm = EMEA.COMPANY.COM
realmd_tags = joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = ad
ldap_schema = rfc2307bis
#ldap_sasl_authid = host/spikerealmd01.us.company.com
#ldap_sasl_authid = SPIKEREALMD01$@AMER.COMPANY.COM
ldap_sasl_authid = [e-mail]
ad_enabled_domains = amer.company.com, apac.company.com, emea.company.com,
japn.company.com, company.com
dyndns_update = False
subdomains_provider = none

[domain/japn.company.com]
auto_private_groups = True
use_fully_qualified_names = False
ad_domain = japn.company.com
krb5_realm = JAPN.COMPANY.COM
realmd_tags = joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = ad
ldap_schema = rfc2307bis
#ldap_sasl_authid = host/spikerealmd01.us.company.com
#ldap_sasl_authid = SPIKEREALMD01$@AMER.COMPANY.COM
ldap_sasl_authid = [e-mail]
ad_enabled_domains = amer.company.com, apac.company.com, emea.company.com,
japn.company.com, company.com
dyndns_update = False
subdomains_provider = none

Spike

On Mon, May 14, 2018 at 3:23 AM, Jakub Hrozek  wrote:
> > On 13 May 2018, at 22:44, Spike White  wrote:
> >
> > Sssd aficionados,
> >
> > It is with great interest that I read the announcement of SSSD version
>
> 1.15.3.
> > https://lists.fedorahosted.org/archives/list/sssd-users@
>
> lists.fedorahosted.org/thread/6EPEUSAXXMS4WCI7PUR6PU7AQB7K5EAJ/
> > Among the new features is this:
> >
> > In a setup where an IPA domain trusts an Active Directory domain, it is
>
> now possible to define the domain resolution order (see
> http://www.freeipa.org/page/Releases/4.5.0#AD_User_Short_Names). Starting
> with this version, SSSD is able to read and honor the domain resolution
> order, providing a way to resolve Active Directory users by just their
> short name. SSSD also supports a new option "domain_resolution_order"
> applicable in the "[sssd]" section that allows to configure short names for
> AD users in setup with "id_provider=ad" or in a setup with an older IPA
> server that doesn't support the "ipa config-mod --domain-resolution-order"
> configuration option. Also, it is now possible to use
> "use_fully_qualified_names=False" in a subdomain configuration, but
> please note that the user and group output from trusted domains will always
> be qualified to avoid conflicts.
> > This corresponds exactly to a use case we have.  In fact this design doc
>
> (https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html)
> > has excellent verbiage describing our use case:
> >
> > Use cases
> >
> > Allow the Administrator of an IdM deployment in a trust relationship
>
> with an AD forest to configure its IdM servers and associated IdM clients
> to allow user & group resolution and user authentication in all domains (or
> a subset of the domains) to be possible by using only the short names
> without the domain component, as it’s done by some 3rd party solutions.
> > That’s our exact situation.  We have a parent AD domain – company.com.
>
> We have 3 AD subdomains:  amer.company.com, euro.company.com and
> asia.company.com.    All 3 AD subdomains have a transitive trust with the
> parent domain.  Meaning all 4 domains fully trust each other.   All user
> and groups are in the 3 subdomains; none in the parent domain.
> > We do not have an IPA server, not would our company’s AD administrators
>
> tolerate such – they don’t even allow trusts to Kerberos realms.  (They’re
> very security-conscious – and windows-centric).
> > We are currently using a 3rd party software product for our Linux AD
>
> integration.  (actually, 2 products -- in different parts of the company).
> They’re currently doing user authentication from all 3 AD subdomains by
> short account name.  They’re doing it by domain resolution order (always
> looking in the local domain first).
> > In these products, I join the local AD sub-domain by creating a machine
>
> account under my OU.
> > I have evaluated sssd-ad on RHEL7 as a potential replacement.  There are
>
> some obscure dusty corners where sssd-ad may not be able to do what these
> 3rd party products do.
>
> I’m curious, what are the other shortcomings?
> > But outside of that handful of use cases, sssd-ad (& maybe a couple of
>
> companion PAM modules) seem like it’ll accomplish everything we need for
> AD-based Linux authentication.
> > Except for cross-subdomain user authentication by short name.
> >
> > I’m able to login by short name in the local subdomain.  Using:
> >
> > [domain/amer.company.com]
> > use_fully_qualified_names = False
> >
> > Starting with version 1.15.3, I’m supposed to be able to add:
> >
> > domain_resolution_order = amer.company.com, euro.company.com,
>
> asia.company.com
> > to the [sssd] section in /etc/sssd/sssd.conf.  Then I’m supposed to
>
> change my current subdomain section:
>
> Yes.
> > [domain/amer.company.com]
> > use_fully_qualified_names = False
> >
> > To:
> >
> > [domain/amer.company.com/euro.company.com/asia.company.com]
> > use_fully_qualified_names = False
> >
> > ?
> >
> > How does that work?
>
> After startup, SSSD auto-discovers the domains in the forest. From SSSD’s
> point of view, the domain structure is always flat, so you’d configure:
> [domain/amer.company.com]
> use_fully_qualified_names = False
>
> [domain/amer.company.com/euro.company.com]
> use_fully_qualified_names = False
>
> [domain/amer.company.com/asia.company.com]
> use_fully_qualified_names = False
>
> ..etc
>
> Keep in mind that by default, the names will still come back qualified
> from the child domains because that’s the only way to distinguish users
> from different domains during a multi-step authentication process (e.g.
> application receives a name to authenticate as, then calls getpwnam on that
> input and uses the output of getpwnam from then on..). You /can/ tune the
> full_name_format to only include the user name, but please be aware of the
> consequences.
> > To join the amer.company.com subdomain, ‘realm join’ on my test server
>
> created a machine account under my OU.   Namely,
> [e-mail].   (Realm join also properly created the
> Kerberos creds in the /etc/krb5.keytab file.)
> > Thus for [domain/amer.company.com], I had to set up ldap_sasl_authid as
>
> so:
> > ldap_sasl_authid = [e-mail]
>
> As long as the domains trust each other, you can use the account from the
> joined domain, right? So no configuration should be needed.
> > And the other AD subdomains wouldn’t know about this machine account.
> >
> > I actually tried this recommended syntax  (see
>
> https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html ):
> > [domain/amer.company.com/euro.company.com/asia.company.com]
> >
> > And I caught a syntax error in /var/log/sssd/sssd.log on startup:
> >
> > (Sun May 13 15:11:07:070656 2018) [sssd] [sss_ini_call_validators]
>
> (0x0020): [rule/allowed_sections]: Section [domain/amer.company.com/euro.
> company.com/asia.company.com] is not allowed. Check for typos.
> > (Sun May 13 15:11:07:083115 2018) [sssd] [confdb_get_domain_internal]
>
> (0x0010): Unknown domain [amer.company.com]
> > (Sun May 13 15:11:07:083247 2018) [sssd] [confdb_get_domains] (0x0010):
>
> Error (2 [No such file or directory]) retrieving domain [amer.company.com],
> skipping!
> > Prior to sssd 1.15.3, in order to authenticate from the various AD
>
> subdomains with sssd-ad even by fully-qualified name, you had to join each
> subdomain.
> > Is that still the case?  I have to create a machine account in each
>
> subdomain for a given computer?  Then create 3 separate sections in
> /etc/sssd/sssd.conf file?  Like so:
> > [sssd]
> > …
> > domain_resolution_order = amer.company.com, euro.company.com,
>
> asia.company.com
> > domains = amer.company.com, euro.company.com, asia.company.com
> > …
> >
> > [domain/amer.company.com]
> > use_fully_qualified_names = False
> > …
> > ldap_sasl_authid = [e-mail]
> >
> > [domain/euro.company.com]
> > use_fully_qualified_names = False
> > …
> > ldap_sasl_authid = [e-mail]
> >
> > [domain/apac.company.com]
> > use_fully_qualified_names = False
> > …
> > ldap_sasl_authid = [e-mail]
> >
> > and then I’d have to consolidate the 3 /etc/krb5.keytab files created by
>
> 'realm join' into one grand & glorious keytab file with all the above
> principals?
> > After that, I'd be able to user authenticate from the various subdomains
>
> by short name?
> > Spike White
> >
> > PS Since I’m testing on RHEL7, actually I’m testing version
>
> sssd-ad-1.16.0-19.el7.x86_64
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Spike White]

BTW,

If I use your suggested syntax:

[domain/amer.company.com/asia.company.com]
use_fully_qualified_names = False

I catch an error.

That is, if I define this:

[sssd]
domains = amer.company.com, apac.company.com, emea.company.com,
japn.company.com
domain_resolution_order = amer.company.com, emea.company.com,
apac.company.com, japn.company.com

[domain/amer.company.com]
...

[domain/amer.company.com/apac.company.com]
...

I catch this error in /var/log/sssd/sssd.log file:

(Mon May 14 11:38:01:293985 2018) [sssd] [confdb_get_domain_internal]
(0x0010): Unknown domain [apac.company.com]
(Mon May 14 11:38:01:294090 2018) [sssd] [confdb_get_domains] (0x0010):
Error (2 [No such file or directory]) retrieving domain [apac.company.com],
skipping!

But if I use:

[domain/amer.company.com]
...

[domain/apac.company.com]
...

All works.  (as long as I add ldap_sasl_authid to each non-local domain).

Spike

On Mon, May 14, 2018 at 3:23 AM, Jakub Hrozek  wrote:
> > On 13 May 2018, at 22:44, Spike White  wrote:
> >
> > Sssd aficionados,
> >
> > It is with great interest that I read the announcement of SSSD version
>
> 1.15.3.
> > https://lists.fedorahosted.org/archives/list/sssd-users@
>
> lists.fedorahosted.org/thread/6EPEUSAXXMS4WCI7PUR6PU7AQB7K5EAJ/
> > Among the new features is this:
> >
> > In a setup where an IPA domain trusts an Active Directory domain, it is
>
> now possible to define the domain resolution order (see
> http://www.freeipa.org/page/Releases/4.5.0#AD_User_Short_Names). Starting
> with this version, SSSD is able to read and honor the domain resolution
> order, providing a way to resolve Active Directory users by just their
> short name. SSSD also supports a new option "domain_resolution_order"
> applicable in the "[sssd]" section that allows to configure short names for
> AD users in setup with "id_provider=ad" or in a setup with an older IPA
> server that doesn't support the "ipa config-mod --domain-resolution-order"
> configuration option. Also, it is now possible to use
> "use_fully_qualified_names=False" in a subdomain configuration, but
> please note that the user and group output from trusted domains will always
> be qualified to avoid conflicts.
> > This corresponds exactly to a use case we have.  In fact this design doc
>
> (https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html)
> > has excellent verbiage describing our use case:
> >
> > Use cases
> >
> > Allow the Administrator of an IdM deployment in a trust relationship
>
> with an AD forest to configure its IdM servers and associated IdM clients
> to allow user & group resolution and user authentication in all domains (or
> a subset of the domains) to be possible by using only the short names
> without the domain component, as it’s done by some 3rd party solutions.
> > That’s our exact situation.  We have a parent AD domain – company.com.
>
> We have 3 AD subdomains:  amer.company.com, euro.company.com and
> asia.company.com.    All 3 AD subdomains have a transitive trust with the
> parent domain.  Meaning all 4 domains fully trust each other.   All user
> and groups are in the 3 subdomains; none in the parent domain.
> > We do not have an IPA server, not would our company’s AD administrators
>
> tolerate such – they don’t even allow trusts to Kerberos realms.  (They’re
> very security-conscious – and windows-centric).
> > We are currently using a 3rd party software product for our Linux AD
>
> integration.  (actually, 2 products -- in different parts of the company).
> They’re currently doing user authentication from all 3 AD subdomains by
> short account name.  They’re doing it by domain resolution order (always
> looking in the local domain first).
> > In these products, I join the local AD sub-domain by creating a machine
>
> account under my OU.
> > I have evaluated sssd-ad on RHEL7 as a potential replacement.  There are
>
> some obscure dusty corners where sssd-ad may not be able to do what these
> 3rd party products do.
>
> I’m curious, what are the other shortcomings?
> > But outside of that handful of use cases, sssd-ad (& maybe a couple of
>
> companion PAM modules) seem like it’ll accomplish everything we need for
> AD-based Linux authentication.
> > Except for cross-subdomain user authentication by short name.
> >
> > I’m able to login by short name in the local subdomain.  Using:
> >
> > [domain/amer.company.com]
> > use_fully_qualified_names = False
> >
> > Starting with version 1.15.3, I’m supposed to be able to add:
> >
> > domain_resolution_order = amer.company.com, euro.company.com,
>
> asia.company.com
> > to the [sssd] section in /etc/sssd/sssd.conf.  Then I’m supposed to
>
> change my current subdomain section:
>
> Yes.
> > [domain/amer.company.com]
> > use_fully_qualified_names = False
> >
> > To:
> >
> > [domain/amer.company.com/euro.company.com/asia.company.com]
> > use_fully_qualified_names = False
> >
> > ?
> >
> > How does that work?
>
> After startup, SSSD auto-discovers the domains in the forest. From SSSD’s
> point of view, the domain structure is always flat, so you’d configure:
> [domain/amer.company.com]
> use_fully_qualified_names = False
>
> [domain/amer.company.com/euro.company.com]
> use_fully_qualified_names = False
>
> [domain/amer.company.com/asia.company.com]
> use_fully_qualified_names = False
>
> ..etc
>
> Keep in mind that by default, the names will still come back qualified
> from the child domains because that’s the only way to distinguish users
> from different domains during a multi-step authentication process (e.g.
> application receives a name to authenticate as, then calls getpwnam on that
> input and uses the output of getpwnam from then on..). You /can/ tune the
> full_name_format to only include the user name, but please be aware of the
> consequences.
> > To join the amer.company.com subdomain, ‘realm join’ on my test server
>
> created a machine account under my OU.   Namely,
> [e-mail].   (Realm join also properly created the
> Kerberos creds in the /etc/krb5.keytab file.)
> > Thus for [domain/amer.company.com], I had to set up ldap_sasl_authid as
>
> so:
> > ldap_sasl_authid = [e-mail]
>
> As long as the domains trust each other, you can use the account from the
> joined domain, right? So no configuration should be needed.
> > And the other AD subdomains wouldn’t know about this machine account.
> >
> > I actually tried this recommended syntax  (see
>
> https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html ):
> > [domain/amer.company.com/euro.company.com/asia.company.com]
> >
> > And I caught a syntax error in /var/log/sssd/sssd.log on startup:
> >
> > (Sun May 13 15:11:07:070656 2018) [sssd] [sss_ini_call_validators]
>
> (0x0020): [rule/allowed_sections]: Section [domain/amer.company.com/euro.
> company.com/asia.company.com] is not allowed. Check for typos.
> > (Sun May 13 15:11:07:083115 2018) [sssd] [confdb_get_domain_internal]
>
> (0x0010): Unknown domain [amer.company.com]
> > (Sun May 13 15:11:07:083247 2018) [sssd] [confdb_get_domains] (0x0010):
>
> Error (2 [No such file or directory]) retrieving domain [amer.company.com],
> skipping!
> > Prior to sssd 1.15.3, in order to authenticate from the various AD
>
> subdomains with sssd-ad even by fully-qualified name, you had to join each
> subdomain.
> > Is that still the case?  I have to create a machine account in each
>
> subdomain for a given computer?  Then create 3 separate sections in
> /etc/sssd/sssd.conf file?  Like so:
> > [sssd]
> > …
> > domain_resolution_order = amer.company.com, euro.company.com,
>
> asia.company.com
> > domains = amer.company.com, euro.company.com, asia.company.com
> > …
> >
> > [domain/amer.company.com]
> > use_fully_qualified_names = False
> > …
> > ldap_sasl_authid = [e-mail]
> >
> > [domain/euro.company.com]
> > use_fully_qualified_names = False
> > …
> > ldap_sasl_authid = [e-mail]
> >
> > [domain/apac.company.com]
> > use_fully_qualified_names = False
> > …
> > ldap_sasl_authid = [e-mail]
> >
> > and then I’d have to consolidate the 3 /etc/krb5.keytab files created by
>
> 'realm join' into one grand & glorious keytab file with all the above
> principals?
> > After that, I'd be able to user authenticate from the various subdomains
>
> by short name?
> > Spike White
> >
> > PS Since I’m testing on RHEL7, actually I’m testing version
>
> sssd-ad-1.16.0-19.el7.x86_64
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Jakub Hrozek]

Defining each domain as a standalone [domain] section means that each [domain] section will spawn its own sssd_be process and connect to the remote directory on its own. It’s a valid approach for some cases, especially if the domains don’t fully trust each other but you shouldn’t need it.

If you rely on sssd autodiscovering the forest, then you shouldn’t need to define the [domain] section but you shouldn’t also need to list them in the domains= directive in the [sssd] section — I think that’s why SSSD is complaining about the unknown domain, every name in the domains= list must match a [domain] section. The sub-sections don’t need a domains= name.
> On 14 May 2018, at 18:48, Spike White  wrote:
>
> BTW,
>
> If I use your suggested syntax:
>
> [domain/amer.company.com/asia.company.com]
> use_fully_qualified_names = False
>
> I catch an error.
>
> That is, if I define this:
>
> [sssd]
> domains = amer.company.com, apac.company.com, emea.company.com, japn.company.com
> domain_resolution_order = amer.company.com, emea.company.com, apac.company.com, japn.company.com
>
> [domain/amer.company.com]
> ...
>
> [domain/amer.company.com/apac.company.com]
> ...
>
> I catch this error in /var/log/sssd/sssd.log file:
>
> (Mon May 14 11:38:01:293985 2018) [sssd] [confdb_get_domain_internal] (0x0010): Unknown domain [apac.company.com]
> (Mon May 14 11:38:01:294090 2018) [sssd] [confdb_get_domains] (0x0010): Error (2 [No such file or directory]) retrieving domain [apac.company.com], skipping!
>
> But if I use:
>
> [domain/amer.company.com]
> ...
>
> [domain/apac.company.com]
> ...
>
> All works.  (as long as I add ldap_sasl_authid to each non-local domain).
>
> Spike
>
> On Mon, May 14, 2018 at 3:23 AM, Jakub Hrozek  wrote:
> > On 13 May 2018, at 22:44, Spike White  wrote:
> >
> > Sssd aficionados,
> >
> > It is with great interest that I read the announcement of SSSD version 1.15.3.
> >
> > https://lists.fedorahosted.org/archives/list/[e-mail].o...
> >
> > Among the new features is this:
> >
> > In a setup where an IPA domain trusts an Active Directory domain, it is now possible to define the domain resolution order (see http://www.freeipa.org/page/Releases/4.5.0#AD_User_Short_Names). Starting with this version, SSSD is able to read and honor the domain resolution order, providing a way to resolve Active Directory users by just their short name. SSSD also supports a new option "domain_resolution_order" applicable in the "[sssd]" section that allows to configure short names for AD users in setup with "id_provider=ad" or in a setup with an older IPA server that doesn't support the "ipa config-mod --domain-resolution-order" configuration option. Also, it is now possible to use "use_fully_qualified_names=False" in a subdomain configuration, but please note that the user and group output from trusted domains will always be qualified to avoid conflicts.
> >
> > This corresponds exactly to a use case we have.  In fact this design doc (https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html)
> >
> > has excellent verbiage describing our use case:
> >
> > Use cases
> >
> > Allow the Administrator of an IdM deployment in a trust relationship with an AD forest to configure its IdM servers and associated IdM clients to allow user & group resolution and user authentication in all domains (or a subset of the domains) to be possible by using only the short names without the domain component, as it’s done by some 3rd party solutions.
> >
> > That’s our exact situation.  We have a parent AD domain – company.com.  We have 3 AD subdomains:  amer.company.com, euro.company.com and asia.company.com.    All 3 AD subdomains have a transitive trust with the parent domain.  Meaning all 4 domains fully trust each other.   All user and groups are in the 3 subdomains; none in the parent domain.
> >
> > We do not have an IPA server, not would our company’s AD administrators tolerate such – they don’t even allow trusts to Kerberos realms.  (They’re very security-conscious – and windows-centric).
> >
> > We are currently using a 3rd party software product for our Linux AD integration.  (actually, 2 products -- in different parts of the company).  They’re currently doing user authentication from all 3 AD subdomains by short account name.  They’re doing it by domain resolution order (always looking in the local domain first).
> >
> > In these products, I join the local AD sub-domain by creating a machine account under my OU.
> >
> > I have evaluated sssd-ad on RHEL7 as a potential replacement.  There are some obscure dusty corners where sssd-ad may not be able to do what these 3rd party products do.
>
> I’m curious, what are the other shortcomings?
> > But outside of that handful of use cases, sssd-ad (& maybe a couple of companion PAM modules) seem like it’ll accomplish everything we need for AD-based Linux authentication.
> >
> > Except for cross-subdomain user authentication by short name.
> >
> > I’m able to login by short name in the local subdomain.  Using:
> >
> > [domain/amer.company.com]
> > use_fully_qualified_names = False
> >
> > Starting with version 1.15.3, I’m supposed to be able to add:
> >
> > domain_resolution_order = amer.company.com, euro.company.com, asia.company.com
> >
> > to the [sssd] section in /etc/sssd/sssd.conf.  Then I’m supposed to change my current subdomain section:
>
> Yes.
> > [domain/amer.company.com]
> > use_fully_qualified_names = False
> >
> > To:
> >
> > [domain/amer.company.com/euro.company.com/asia.company.com]
> > use_fully_qualified_names = False
> >
> > ?
> >
> > How does that work?
>
> After startup, SSSD auto-discovers the domains in the forest. From SSSD’s point of view, the domain structure is always flat, so you’d configure:
> [domain/amer.company.com]
> use_fully_qualified_names = False
>
> [domain/amer.company.com/euro.company.com]
> use_fully_qualified_names = False
>
> [domain/amer.company.com/asia.company.com]
> use_fully_qualified_names = False
>
> ..etc
>
> Keep in mind that by default, the names will still come back qualified from the child domains because that’s the only way to distinguish users from different domains during a multi-step authentication process (e.g. application receives a name to authenticate as, then calls getpwnam on that input and uses the output of getpwnam from then on..). You /can/ tune the full_name_format to only include the user name, but please be aware of the consequences.
> > To join the amer.company.com subdomain, ‘realm join’ on my test server created a machine account under my OU.   Namely, [e-mail].   (Realm join also properly created the Kerberos creds in the /etc/krb5.keytab file.)
> >
> > Thus for [domain/amer.company.com], I had to set up ldap_sasl_authid as so:
> >
> > ldap_sasl_authid = [e-mail]
>
> As long as the domains trust each other, you can use the account from the joined domain, right? So no configuration should be needed.
> > And the other AD subdomains wouldn’t know about this machine account.
> >
> > I actually tried this recommended syntax  (see https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html ):
> >
> > [domain/amer.company.com/euro.company.com/asia.company.com]
> >
> > And I caught a syntax error in /var/log/sssd/sssd.log on startup:
> >
> > (Sun May 13 15:11:07:070656 2018) [sssd] [sss_ini_call_validators] (0x0020): [rule/allowed_sections]: Section [domain/amer.company.com/euro.company.com/asia.company.com] is not allowed. Check for typos.
> > (Sun May 13 15:11:07:083115 2018) [sssd] [confdb_get_domain_internal] (0x0010): Unknown domain [amer.company.com]
> > (Sun May 13 15:11:07:083247 2018) [sssd] [confdb_get_domains] (0x0010): Error (2 [No such file or directory]) retrieving domain [amer.company.com], skipping!
> >
> > Prior to sssd 1.15.3, in order to authenticate from the various AD subdomains with sssd-ad even by fully-qualified name, you had to join each subdomain.
> >
> > Is that still the case?  I have to create a machine account in each subdomain for a given computer?  Then create 3 separate sections in /etc/sssd/sssd.conf file?  Like so:
> >
> > [sssd]
> > …
> > domain_resolution_order = amer.company.com, euro.company.com, asia.company.com
> > domains = amer.company.com, euro.company.com, asia.company.com
> > …
> >
> > [domain/amer.company.com]
> > use_fully_qualified_names = False
> > …
> > ldap_sasl_authid = [e-mail]
> >
> > [domain/euro.company.com]
> > use_fully_qualified_names = False
> > …
> > ldap_sasl_authid = [e-mail]
> >
> > [domain/apac.company.com]
> > use_fully_qualified_names = False
> > …
> > ldap_sasl_authid = [e-mail]
> >
> > and then I’d have to consolidate the 3 /etc/krb5.keytab files created by 'realm join' into one grand & glorious keytab file with all the above principals?
> >
> > After that, I'd be able to user authenticate from the various subdomains by short name?
> >
> > Spike White
> >
> > PS Since I’m testing on RHEL7, actually I’m testing version sssd-ad-1.16.0-19.el7.x86_64
> >
> > sssd-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]