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/sssd-users@lists.fedorahosted.org/thread/WYGMGRMMUXL65YWWU7LI42JLZDLDXCBT/
We need to document this better by fixing:
https://pagure.io/SSSD/sssd/issue/3377
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
