On 13 May 2018, at 22:44, Spike White <spikewhitetx(a)gmail.com>
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.fedorahoste...
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, spikerealmd01(a)AMER.COMPANY.COM. (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 = spikerealmd01(a)AMER.COMPANY.COM
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 = spikerealmd01(a)AMER.COMPANY.COM
[
domain/euro.company.com]
use_fully_qualified_names = False
…
ldap_sasl_authid = spikerealmd01(a)EURO.COMPANY.COM
[
domain/apac.company.com]
use_fully_qualified_names = False
…
ldap_sasl_authid = spikerealmd01(a)APAC.COMPANY.COM
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 -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org