2:03 a.m.
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?
2:23 a.m.
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
2:28 a.m.
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....?)
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
2:39 a.m.
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
2:58 a.m.
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 <abokovoy(a)redhat.com>
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 <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
2:30 p.m.
On Thu, Sep 06, 2018 at 09:58:20AM +0200, Pieter Baele via FreeIPA-users wrote:
@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)
Hmm, this might be caused by a number of reasons, so I really need to
see the logs from that machine. The most probably causes are that either
sssd goes offline for one reason or another (sssctl domain-status is a
good help in this respect) or that HBAC is kicking you out.
2059
days inactive
2059
days old
freeipa-users@lists.fedorahosted.org
6 comments
3 participants
participants (3)
-
Alexander Bokovoy -
Jakub Hrozek -
Pieter Baele