Fwd: SSS sudoers and Ubuntu 16.04

[Clayton Daley]

Good Morning,

We're doing some tests on Ubuntu 16.04 before upgrading and I'm having an
issue with sss (ldap) sudoers.  On 14.04, everything works:

User clayton@<domain> may run the following commands on lin2:
>      (root) ALL
>      (root) NOPASSWD: /usr/bin/docker 

On 16.04, the user has no problem authenticating, but:

User clayton@<domain> is not allowed to run sudo on lin3.


This is the same AD server and we use deployment automation code so I know
both systems are getting the same treatment.  Here are the software
versions:

   - ubuntu 14.04 vs 16.04
   - sssd 1.11.8 vs 1.13.4
   - sudo 1.8.9p5 vs. 1.8.19p2 << this is a manual upgrade of the 16.04
   default in case a relevant bug was fixed
   - realm 0.15.0-1 vs. 0.16.2.-2 << these appear to be the only versions
   available through apt
   - adcli 0.7.5-1 vs. adcli 0.8.1-1 << same apt limitation

Some additional notes and troubleshooting:

   - Our AD server has an SSL certificate for the domain.  ldapsearch has
   been used to verify that it's functioning correctly.  Based on logs, I'm
   not clear if realm/sssd ever even uses the LDAPS port.
   - "realm join" only works on Ubuntu 16.04 with either
   "dns_canonicalize_hostname = false" (in krb5.conf) or
   "--membership-software=samba".  I've tested both of these options on
   Ubuntu 14.04 and neither affect sudoers (i.e. it works fine).
   - I've increased the debug_level and verified that sssd is loading both
   the user's groups and sudoRoles (visually verified contents) and that sssd
   is (correctly) resolving 2 rules that apply to the user when running sudo
   -l:

   [sudosrv_get_sudorules_from_cache] (0x0400): Returning 2 rules for
   [clayton@<domain>]

Is there any more testing I should do at the sssd level or is this where
sssd hands off the data and sudo picks it up?  Is there a specific line
that gives me more information on the handoff?

P.S. I'm also interested in resolving my "realm join" issue on 16.04. 
I've
done some digging on the (failing) adcli step of the failing realm join
command.  The kinit works fine, but it chokes on "SASL(-1): generic
failure: GSSAPI Error: An invalid name was supplied (Success)".  I've even
tried to complete the process passwordless (i.e. https://fedoraproject.
org/wiki/QA:Testcase_realmd_join_ccache) but I'm always prompted for a
password.

P.P.S. Is ldap_uri the right way to switch to LDAPS?  Does it even work
with the ad provider?

Thanks,

Clayton Daley

[Jakub Hrozek]

I'm sorry I didn't notice this mail in the moderation queue sooner..

On Mon, May 01, 2017 at 05:21:55PM -0500, Clayton Daley wrote:
>  Good Morning,
>  
>  We're doing some tests on Ubuntu 16.04 before upgrading and I'm having an
>  issue with sss (ldap) sudoers.  On 14.04, everything works:
>  
>  User clayton@<domain> may run the following commands on lin2:
>  >     (root) ALL
>  >     (root) NOPASSWD: /usr/bin/docker
>  
>  
>  On 16.04, the user has no problem authenticating, but:
>  
>  User clayton@<domain> is not allowed to run sudo on lin3. 
It looks like another user hit a similar issue as reported on the
freeipa-users list:
    https://www.redhat.com/archives/freeipa-users/2017-May/msg00033.html

>  
>  
>  This is the same AD server and we use deployment automation code so I know
>  both systems are getting the same treatment.  Here are the software
>  versions:
>  
>     - ubuntu 14.04 vs 16.04
>     - sssd 1.11.8 vs 1.13.4
>     - sudo 1.8.9p5 vs. 1.8.19p2 << this is a manual upgrade of the 16.04
>     default in case a relevant bug was fixed
>     - realm 0.15.0-1 vs. 0.16.2.-2 << these appear to be the only versions
>     available through apt
>     - adcli 0.7.5-1 vs. adcli 0.8.1-1 << same apt limitation
>  
>  Some additional notes and troubleshooting:
>  
>     - Our AD server has an SSL certificate for the domain.  ldapsearch has
>     been used to verify that it's functioning correctly.  Based on logs, I'm
>     not clear if realm/sssd ever even uses the LDAPS port.
>     - "realm join" only works on Ubuntu 16.04 with either
>     "dns_canonicalize_hostname = false" (in krb5.conf) or
>     "--membership-software=samba".  I've tested both of these options on
>     Ubuntu 14.04 and neither affect sudoers (i.e. it works fine).
>     - I've increased the debug_level and verified that sssd is loading both
>     the user's groups and sudoRoles (visually verified contents) and that sssd
>     is (correctly) resolving 2 rules that apply to the user when running sudo
>     -l:
>  
>     [sudosrv_get_sudorules_from_cache] (0x0400): Returning 2 rules for
>     [clayton@<domain>]
>  
>  Is there any more testing I should do at the sssd level or is this where
>  sssd hands off the data and sudo picks it up?  Is there a specific line
>  that gives me more information on the handoff?
>  
>  P.S. I'm also interested in resolving my "realm join" issue on 16.04. 
> I've
>  done some digging on the (failing) adcli step of the failing realm join
>  command.  The kinit works fine, but it chokes on "SASL(-1): generic
>  failure: GSSAPI Error: An invalid name was supplied (Success)".  I've even
>  tried to complete the process passwordless (i.e. https://fedoraproject.
>  org/wiki/QA:Testcase_realmd_join_ccache) but I'm always prompted for a
>  password. 
I'm sorry, I don't know about this one. You said suppressing the
hostname canonicalization helps, is the hostname set to a value expected
for the domain?

>  
>  P.P.S. Is ldap_uri the right way to switch to LDAPS?  Does it even work
>  with the ad provider? 
The AD provider uses GSSAPI which already provides confidentiality. See:
   
https://lists.fedorahosted.org/archives/list/[e-mail]...
We need to document this better by fixing:
    https://pagure.io/SSSD/sssd/issue/3377

same problem here: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1686544