[SSSD-users] Re: Ability to auth sudo against a different back end using sssd.

[Erinn Looney-Triggs]

Correction they are full AD objects. So any ideas for a workaround are welcome.

-Erinn
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Ability to auth sudo against a different back end using sssd.

[Erinn Looney-Triggs]

So yes I saw krb5_map_user, problem is we have hundreds of these users and that 
list grows and shrinks dynamically as people come and go. I could do some 
really terrible hack to pull the data from wherever and stick it into 
krb5_map_user but that's just awful. Ultimately regex support here would solve 
everything.

I can't fully answer your second question yet, I am digging into it and I don't 
know this area of auth well enough. It appears for the moment that user/sudo is 
NOT a separate object. I know we don't have any other kerb other than the AD so 
perhaps we are injecting principles directly into the krb database in AD, which 
I realize is just backed into LDAP etc. etc. 

I'll pass along more info when I have it.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Ability to auth sudo against a different back end using sssd.

[Sumit Bose]

On Thu, Oct 24, 2019 at 11:52:56AM +0200, Pavel Březina wrote:
> On 10/23/19 11:31 PM, Erinn Looney-Triggs wrote:
> > Folks I am in the process of working through this but I thought I would
> > throw it out just in case there were other thoughts or I was chasing
> > down the wrong lane.
> > 
> > We have a requirement for sudo to use a different password than the user
> > password where I work. Now in RHEL 7 we implemented this requirement by
> > modifying the pam stack for sudo to use the pam_krb5 module like the
> > following:
> > 
> > auth required pam_env.so
> > auth requisite pam_succeed_if.so uid >= 500 quiet
> > auth sufficient pam_krb5.so try_first_pass no_user_check
> > auth required pam_deny.so
> > account sufficient pam_localuser.so
> > account sufficient pam_succeed_if.so uid < 500 quiet
> > account [default=bad success=ok user_unknown=ignore] pam_krb5.so
> > account required pam_permit.so
> > password requisite pam_cracklib.so try_first_pass retry=3 type=
> > password sufficient pam_krb5.so try_first_pass use_authtok
> > password required pam_deny.so
> > session optional pam_keyinit.so revoke
> > session required pam_limits.so
> > 
> > Now pam_krb5 is configured to auth against a username/sudo principal in
> > /etc/krb5.conf like the following (the mappings is the important part):
> > 
> > [appdefaults]
> >   pam = {
> >     debug = false
> >     forwardable = true
> >     renew_lifetime = 24h
> >     ticket_lifetime = 24h
> >     krb4_convert = false
> >     mappings = ^(.*)$ $1/sudo
> >   }
> > 
> > pam_krb5 has for better or worse gone the way of the dodo in RHEL 8 and
> > so I am looking to implement something similar using sssd. Our systems
> > are already joined to an AD, and it appears to me for the moment that
> > the 'application domain' using pam_sss might be the right approach here.
> > I understand that it is best tested with LDAP, but well, here we go. So
> > thus far I have:
> > 
> > [application/appdom]
> > inherit_from = ad.example.com
> > 
> > and the /etc/pam.d/sudo has the following inserted:
> > 
> > auth    sufficient pam_sss.so forward_pass domains=appdom
> > 
> > Great it seems to work. Now I need to remap the name to username/sudo
> > and auth it against kerb. I don't even know if this is possible at this
> > point, but again I thought I would write it up and ask just in case
> > someone knew.
> 
> No, this is AFAIK not possible at the moment, as you already found out.
> 
> Sumit, given the mapping only appends /sudo to the username, would it make
> sense to open an RFE to support such thing?

Hi,

we already have krb5_map_user, but if there are many users it might be
cumbersome to add a mapping for each. So some pattern/regex based
approach might be a good extension.

However, I'd like to understand the setup here a bit better to see if
there might be an alternative solution as well.

Erinn, are the 'user/sudo' principals are handled by AD as well? If yes,
can you send an example of the LDAP object which is used for this? Since
you said this is about a different password I assume there must be a
separate object. This object should either have 'user/sudo' as
samAccountName or 'user/sudo@REALM' as userPrincipalName. With this is
should be possible to configure [application/appdom] so that the "right"
principal is used.

bye.
Sumit

> 
> > 
> > Thanks,
> > 
> > -Erinn
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > 
> 
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Ability to auth sudo against a different back end using sssd.

[Pavel Březina]

On 10/23/19 11:31 PM, Erinn Looney-Triggs wrote:
Folks I am in the process of working through this but I thought I would 
throw it out just in case there were other thoughts or I was chasing 
down the wrong lane.


We have a requirement for sudo to use a different password than the user 
password where I work. Now in RHEL 7 we implemented this requirement by 
modifying the pam stack for sudo to use the pam_krb5 module like the 
following:


auth required pam_env.so
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_krb5.so try_first_pass no_user_check
auth required pam_deny.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_krb5.so try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so

Now pam_krb5 is configured to auth against a username/sudo principal in 
/etc/krb5.conf like the following (the mappings is the important part):


[appdefaults]
  pam = {
    debug = false
    forwardable = true
    renew_lifetime = 24h
    ticket_lifetime = 24h
    krb4_convert = false
    mappings = ^(.*)$ $1/sudo
  }

pam_krb5 has for better or worse gone the way of the dodo in RHEL 8 and 
so I am looking to implement something similar using sssd. Our systems 
are already joined to an AD, and it appears to me for the moment that 
the 'application domain' using pam_sss might be the right approach here. 
I understand that it is best tested with LDAP, but well, here we go. So 
thus far I have:


[application/appdom]
inherit_from = ad.example.com

and the /etc/pam.d/sudo has the following inserted:

auth    sufficient pam_sss.so forward_pass domains=appdom

Great it seems to work. Now I need to remap the name to username/sudo 
and auth it against kerb. I don't even know if this is possible at this 
point, but again I thought I would write it up and ask just in case 
someone knew.


No, this is AFAIK not possible at the moment, as you already found out.

Sumit, given the mapping only appends /sudo to the username, would it 
make sense to open an RFE to support such thing?




Thanks,

-Erinn
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org 


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: Double-check that I have this sssd.conf right....

[Pavel Březina]

On 10/24/19 6:32 AM, Spike White wrote:

sssd experts,

I think this is proper and expected sssd behavior.    Since I'm using 
short names for all lookups, that is called a "domain-less search".


Yes, if you are using short names the domain_resolution_order is required.



Look at https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html, 
where the implementation of  the "shortnames in trusted domains" feature 
is discussed.


The author explicitly says:


Overview of the

solution

In order to have it implemented a few internal changes have to be done 
in order to use the shared |cache_req| module for responder look-ups, 
allowing then SSSD to perform the domain-less look-ups when not 
explicitly set up in the domain to use only fully-qualified names for 
those operations.


Once domain-less searches are allowed, SSSD will have to support 
receiving an ordered list of domains which will be looked-up first so 
the Administrator can have a better control and avoid a bunch of 
unnecessary look-ups. The list of the ordered domains can be provided in 
three different ways and those are described below according to their 
precedence order:


  * sssd.conf: the admin can set up the |domain_resolution_order| option
in the |[sssd]| section;
  * |ipaDomainResolutionOrder| set by IPA ID-view: the admin can set up
the attribute per views on IPA server;
  * |ipaDomainResolutionOrder| set globally: the admin can set up the
attribute globally on IPA server;


Without setting the list of ordered domains (via any of those 3 methods 
above), I'm thinking that SSSD should do domain-less searches in the 
local domain only.   Which is exactly what happens.


Spike

On Fri, Oct 18, 2019 at 1:23 PM Spike White > wrote:


Pavel and sssd mailing list team members,

OK -- I have reproduced this behaviour as requested.  I set 
debug_level = 0x3ff0? for both cases - when the option is set and

when it is not.

I have done this for both a RHEL7 server and a RHEL8 server.  (Same
behavior on both OS versions.)

Here is the dropbox URL with the tarballs of the logs:

https://www.dropbox.com/sh/yqb4poh9ny9hypg/AAA71mXPDFvZcIThXKofOmVRa?dl=0

That dropbox URL contains two tarballs.

RHEL7_good_and_bad.tgz
RHEL8_good_and_bad.tgz

In each tarball, there's a "good" folder (with
domain_resolution_order set in sssd.conf file) and a "bad" folder
(without domain_resolution_order set in sssd.conf file).

Spike


On Wed, Oct 16, 2019 at 2:57 AM Pavel Březina mailto:pbrez...@redhat.com>> wrote:

On 10/11/19 6:28 PM, Spike White wrote:
 > Without domain_resolution_order set, it does not search the
non-local
 > domain and find any non-local accounts.  (This is on RHEL7
and RHEL8).
 >
 > So -- domain_resolution_order is required.

Can you send us sssd_nss.log and sssd_$domain.log logs generated
with
debug_level = 0x3ff0? Ideally for both cases - when the option
is set
and when it is not.

 > I suspected ldap_search_base would be auto-discovered. 
However, I got

 > lost when parsing the default setting of ldap_search_base in the
 > sssd.conf man page:
 >
 >             Default: If not set, the value of the
defaultNamingContext
 > or namingContexts attribute from the RootDSE of the LDAP
 >
 > server is used. If defaultNamingContext does not exist or has
an empty
 > value namingContexts is used. The
 >
 > namingContexts attribute must have a single value with the DN
of the
 > search base of the LDAP server to make this work.
 >
 > Multiple values are are not supported.
 >
 >
 > Spike
 >
 > PS Thanks for responding.
 >
 >
 > On Wed, Oct 9, 2019 at 11:47 AM Sumit Bose mailto:sb...@redhat.com>
 > >> wrote:
 >
 >     On Mon, Oct 07, 2019 at 09:53:35AM -0500, Spike White wrote:
 >      > All,
 >      >
 >      > I worked an sssd configuration case with my OS vendor
in the last
 >     3 weeks.
 >      > I have resolution and it's working 100% correctly.
 >      >
 >      > Just wanted to double-check.  A second set of eyes to
verify this
 >     solution
 >      > is all above board.
 >      >
 >      > The problem manifested itself in our multi-domain AD
forest with
 >     Posix
 >      > Attributes.  One parent domain that has a transitive
trust with 4
 >      > (regional) child domains.
 >      >
 >      > Thus all 4 chil