On to, 06 syys 2018, Pieter Baele wrote:
That was not an answer meant for me :-) - it dates from 13 may upon
release of the sssd release supporting those configurations.
And it doesn't solve the problem.
I also opende a ticket with RH Support (we tend to pay a lot of money for
that.... directly to developer is sometimes faster, isn't it....?)
If you are
using trust to AD with multiple domains, you are having users
which would be conflicting in non-FQDN format. Each AD domain has the
same set of predefined users (Administrator, group Administrators, etc),
so these ones will already be conflicting to each other.
As result, in general there is no way to make it working for non-FQDN
users in case of a trust to AD. Recent SSSD and IPA allow you to define
an order of domains to look up unqualified inputs against. A side-effect
is that such lookups might become slower and are prone to conflicts
where a first one from a list of the domains would take over the
response.
You need to explain a bit in more detail what this PAM-based
application is and what it is supposed to do. If the application does
getpwuid()-like requests it would get back qualified user name anyway.
SSSD in a configuration where an order of domains to query is defined
can accept non-qualified user/group names, indeed, but if an application is
using a UID to name or GID to name resolution it might be confused with
the FQDN response.
Finally, on IPA masters do not reconfigure SSSD to output non-FQDN
names. This breaks badly compat tree and if you'd use legacy clients
with trust to AD, there is no way to fix that.
Thx for any advice
On Thu, Sep 6, 2018 at 9:23 AM Alexander Bokovoy <abokovoy(a)redhat.com>
wrote:
> On to, 06 syys 2018, Pieter Baele via FreeIPA-users wrote:
> >Hi,
> >
> >I've one more application that doesn't behave very properly with FQDN
> users.
> >For LDAP, this is no longer a problem as we use AD directly for
> >applications now.
> >But this application uses PAM, so somehow I do need to present it a
> >shortname as described in
> >
>
https://docs.pagure.org/sssd.sssd/design_pages/subdomain_configuration.ht...
> >and
https://docs.pagure.org/sssd.sssd/design_pages/shortnames.html
> >
> >Adding use_fully_qualified_names = False indeed results in the possibility
> >of using <user> instead of <user>@<domain>
> >But the returned/displayed values are still <user>@<ad domain> or
> ><user>@<IPA domain>
> >
> >I could resolve that with full_name_format = %1$s, but this breaks logon
> >for trusted AD users....
> >
> >Which is confirmed on the sssd mailing by Jakub Hrozek
> >"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."
> >
> >Or is there a configuration which is a solution for this issue?
> Jakub gave you the answer. The client side is all in SSSD control.
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland