Jakub, Alexander, I really appreciate your quick responses. This is about the SAS Viya product. I had to find out myself why their software doesn't want to create new session(s) from their 'CAS Session controller' It's only a guess, because I don't have access to the source obviously ;-) But they rely on the PAM stack and messages like “User <username> has name <username>@<AD domain> on machine …” point in a certain direction....
I always thought that using IPA for our Big Data platforms would be nice, because of the Kerberos features. But in the end I had to configure most services to go to AD directly only because of the FQDN issues and the way the trust iw working IPA goes a long way easing the maintenance of POSIX, HBAC, Kerberos on RHEL systems.... but still AuthZ/AuthN is a tedious subject if you also have to integrate it with the software itself and legacy systems such as AIX (!) Sorry for my rant, but IDM is only a part of my job, the Hortonworks platform takes preference above the OS which has to be stable ;-) Still I want Kerberos SSO for some services, but is that even possible for windows clients (browser) and keytabs generated in IDM.... the trust only goes one way? @Jakub: not planning to use full_name_format on IDM servers, only on the (SAS Viya) CAS Worker Nodes (if this is the problem....) Somehow I can no longer login directly using my AD user (which has an override in IPA) - once the db/mc/cache is cleared. Sep 6 09:54:25 iictyibcls012 sshd[30884]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x user=y Sep 6 09:54:25 iictyibcls012 sshd[30884]: pam_sss(sshd:auth): received for user x: 6 (Permission denied) Sep 6 09:54:27 iictyibcls012 sshd[30881]: error: PAM: Authentication failure for x from hostx Sep 6 09:54:27 iictyibcls012 sshd[30881]: Postponed keyboard-interactive for xfrom 10.249. @Alexander: I know the limitations and the impact / slow-down. Only one domain will be trusted - ever. Sincerely Pieter On Thu, Sep 6, 2018 at 9:39 AM Alexander Bokovoy <[email protected]> wrote: > 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 <[email protected]> > >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.html#test-short-names-for-trusted-domains > >> >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 >
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
