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 <[email protected]> wrote: > > > > On 13 May 2018, at 22:44, Spike White <[email protected]> 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, > [email protected]. (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 = [email protected] > > 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 = [email protected] > > > > > > [domain/euro.company.com] > > use_fully_qualified_names = False > > … > > ldap_sasl_authid = [email protected] > > > > > > [domain/apac.company.com] > > use_fully_qualified_names = False > > … > > ldap_sasl_authid = [email protected] > > > > > > 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 -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
