[SSSD-users] Re: Passwordless SUDO commands in AD

[Pavel Březina]

On 12/04/2017 09:15 PM, Max DiOrio wrote:

Hi,

We use Active Directory to manage our Linux access including SUDO
permissions.

We need to have a particular account run a passwordless command.  I
created a new sudoRule in AD, added the following:

sudoCommand  /bin/systemctl restart wildfly.service
sudoHost   +DevTestLinuxServer(our group of servers)
sudoOption!authenticate
sudoOrder  1
sudoUsersvc_Jenkins_DTS

From what I'm reading, sudoOrder should be 0 when not defined, which it
isn't in the other sudoRoles.  So with this having a sudoOrder 1, it
should take precedence when there's more than one match for the
command.  The other sudoRole is ALL:ALL, but requires a password, and
that one works fine.

On the client side, logged in as svc_Jenkins_DTS, I see the following in
the sudo log:

(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400):
Sorting rules with higher-wins logic
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400):
Returning 2 rules for
[svc_jenkins_...@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com
]
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response]
(0x2000): error: [0]
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response]
(0x2000): rules_num: [0]
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response]
(0x2000): rule [1]/[2]
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): cn:jenkins
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): objectClass:sudoRule
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoCommand:/bin/systemctl restart wildfly.service
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoHost:+DevTestLinuxServer
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoOption:!authenticate
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoOrder:1
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoRunAsUser:ALL
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoUser:#1002202276
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response]
(0x2000): rule [2]/[2]
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): cn:DevTest
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): objectClass:sudoRule
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoCommand:ALL
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoHost:+DevTestLinuxServers
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoRunAsUser:ALL
(Mon Dec  4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoUser:#1002202276


So it knows of both rules, and sorted them properly.

But doing a sudo -l showing the following:

[svc_jenkins_dts@la-1dglsesgap01 ~]$ sudo -l
[sudo] password for svc_jenkins_dts:
Matching Defaults entries for svc_jenkins_dts on la-1dglsesgap01:
!visiblepw, always_set_home, match_group_by_gid, env_reset,
env_keep="COLORS DISPLAY HOSTNAME
HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME
LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
LANGUAGE LINGUAS
_XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User svc_jenkins_dts may run the following commands on la-1dglsesgap01:
(ALL) ALL


So
1) why does it not show in the list it can run the command
2) why does it keep prompting for a password when I try to run the command

Thanks!




Hi Max,
what sssd version do you use? Also, can you send us sudo logs? [1] is a 
guide how to obtain them.


[1] https://pagure.io/SSSD/docs/blob/master/f/users/sudo_troubleshooting.rst


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: Multiple skel dir (one oer domain)

[Lukas Slebodnik]

On (08/12/17 06:02), Иван Мастренко wrote:
>Hello!
>I'm trying to implement system, where could be logged 3 types of ldap users 
>separated per groups.
>First type is full admin, another 2 is a very imited users, with rbash and 
>unical per group home dir, which defines which commands a allowed to this 
>groups of users.
>
>Can i set per-domain skel dir?
>
>My conf:
>
>[sssd]
>services = nss, pam, autofs
>config_file_version = 2
>domains = 01_HW_ADMINS_DOMAIN, 02_TERMINAL_RESCTRICTEC_ACCESSS_DOMAIN, 
>03_SECURITY_AUDIT_DOMAIN
>
>
>[domain/default]
>debug_level = 7
>
>
>[domain/01_HW_ADMINS_DOMAIN]
>autofs_provider = ldap
>cache_credentials = False
>id_provider = ldap
>auth_provider = ldap
>chpass_provider = ldap
>

The problem is that the option skel_dir is supported only with local provider
and not with ldap provider. As it is described in man sssd.conf.

Maybe you should try to solve your problem in different way.
I can image that host based access control (HBAC) could be a solution
but that is supported only with IPA (or GPO with Active directory)

With ldap provider you might try to use
https://docs.pagure.org/SSSD.sssd/design_pages/restrict_domains_in_pam.html
But I think it is a little bit different use-case then yours.

LS
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: fast cache corruption

[Lukas Slebodnik]

On (08/12/17 12:07), Sumit Bose wrote:
>On Fri, Dec 08, 2017 at 11:57:23AM +0100, Franky Van Liedekerke wrote:
>> Op Vrijdag, 08-12-2017 om 11:34 schreef Sumit Bose:
>> > On Fri, Dec 08, 2017 at 11:10:49AM +0100, Franky Van Liedekerke wrote:
>> > > Before opening a bug report, I wanted to discuss a new issue here. 
>> > > 
>> > > I have ldap users that are in 1500 groups (yeah, I know ... not my 
>> > > choice either), ldap is using rfc2307 scheme (openldap, redhat EL7).
>> > > Now, when connecting sssd to this ldap server, I've already set 
>> > > enumeration=false, and also ignore_group_members=true (performance ...).
>> > > However, with ignore_group_members=true, I'm getting this in the 
>> > > sssd_nss.log when doing a 'groups " command:
>> > > 
>> > > [sssd[nss]] [sss_mc_find_record] (0x0010): Corrupted fastcache. name_ptr 
>> > > value is 16
>> > > 
>> > > (once when the cache is empty, and after that once or twice per 
>> > > groups-request).
>> > > I also see this in /var/log/messages (related of course):
>> > > 
>> > > sssd[nss]: Stored copy of corrupted mmap cache in file 
>> > > '/var/lib/sss/mc/group_corrupted#012'
>> > > 
>> > > As a result, this prevents the use of the sssd fast cache, so group 
>> > > requests at best take 5.5 seconds.
>> > > Now this problem happens 95% of the cases (which leads me to believe it 
>> > > is a timing bug), but when I set ignore_group_members=false, this is not 
>> > > happening (and when groups are ok in the fast cache: 0,03 secs response 
>> > > time).
>> > > 
>> > > Ideas? Hints? Or should I just go and open a bug report? Is there a real 
>> > > performance drawback to setting ignore_group_members=false?
>> > 
>> > There is already a BZ
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1490120.
>> > 
>> > I think in your setup (plain LDAP with rfc2307) the performance loss
>> > when using ignore_group_members=false (the default) should be
>> > acceptable.
>> > 
>> > bye,
>> > Sumit
>> 
>> Unfortunately I can't view the content of that BZ (no access, I'm searching 
>> for an account at my current company that does), so any insight/summary on 
>> that one would be appreciated.
>
>Here is the related upstream ticket
>https://pagure.io/SSSD/sssd/issue/3571.
>

And it is fixed in copr and fedora 25+
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-15/

LS
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: fast cache corruption

[Sumit Bose]

On Fri, Dec 08, 2017 at 11:10:49AM +0100, Franky Van Liedekerke wrote:
> Before opening a bug report, I wanted to discuss a new issue here. 
> 
> I have ldap users that are in 1500 groups (yeah, I know ... not my choice 
> either), ldap is using rfc2307 scheme (openldap, redhat EL7).
> Now, when connecting sssd to this ldap server, I've already set 
> enumeration=false, and also ignore_group_members=true (performance ...).
> However, with ignore_group_members=true, I'm getting this in the sssd_nss.log 
> when doing a 'groups " command:
> 
> [sssd[nss]] [sss_mc_find_record] (0x0010): Corrupted fastcache. name_ptr 
> value is 16
> 
> (once when the cache is empty, and after that once or twice per 
> groups-request).
> I also see this in /var/log/messages (related of course):
> 
> sssd[nss]: Stored copy of corrupted mmap cache in file 
> '/var/lib/sss/mc/group_corrupted#012'
> 
> As a result, this prevents the use of the sssd fast cache, so group requests 
> at best take 5.5 seconds.
> Now this problem happens 95% of the cases (which leads me to believe it is a 
> timing bug), but when I set ignore_group_members=false, this is not happening 
> (and when groups are ok in the fast cache: 0,03 secs response time).
> 
> Ideas? Hints? Or should I just go and open a bug report? Is there a real 
> performance drawback to setting ignore_group_members=false?

There is already a BZ
https://bugzilla.redhat.com/show_bug.cgi?id=1490120.

I think in your setup (plain LDAP with rfc2307) the performance loss
when using ignore_group_members=false (the default) should be
acceptable.

bye,
Sumit

> 
> Thanks,
> 
> Franky
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: fast cache corruption

[Sumit Bose]

On Fri, Dec 08, 2017 at 11:57:23AM +0100, Franky Van Liedekerke wrote:
> Op Vrijdag, 08-12-2017 om 11:34 schreef Sumit Bose:
> > On Fri, Dec 08, 2017 at 11:10:49AM +0100, Franky Van Liedekerke wrote:
> > > Before opening a bug report, I wanted to discuss a new issue here. 
> > > 
> > > I have ldap users that are in 1500 groups (yeah, I know ... not my choice 
> > > either), ldap is using rfc2307 scheme (openldap, redhat EL7).
> > > Now, when connecting sssd to this ldap server, I've already set 
> > > enumeration=false, and also ignore_group_members=true (performance ...).
> > > However, with ignore_group_members=true, I'm getting this in the 
> > > sssd_nss.log when doing a 'groups " command:
> > > 
> > > [sssd[nss]] [sss_mc_find_record] (0x0010): Corrupted fastcache. name_ptr 
> > > value is 16
> > > 
> > > (once when the cache is empty, and after that once or twice per 
> > > groups-request).
> > > I also see this in /var/log/messages (related of course):
> > > 
> > > sssd[nss]: Stored copy of corrupted mmap cache in file 
> > > '/var/lib/sss/mc/group_corrupted#012'
> > > 
> > > As a result, this prevents the use of the sssd fast cache, so group 
> > > requests at best take 5.5 seconds.
> > > Now this problem happens 95% of the cases (which leads me to believe it 
> > > is a timing bug), but when I set ignore_group_members=false, this is not 
> > > happening (and when groups are ok in the fast cache: 0,03 secs response 
> > > time).
> > > 
> > > Ideas? Hints? Or should I just go and open a bug report? Is there a real 
> > > performance drawback to setting ignore_group_members=false?
> > 
> > There is already a BZ
> > https://bugzilla.redhat.com/show_bug.cgi?id=1490120.
> > 
> > I think in your setup (plain LDAP with rfc2307) the performance loss
> > when using ignore_group_members=false (the default) should be
> > acceptable.
> > 
> > bye,
> > Sumit
> 
> Unfortunately I can't view the content of that BZ (no access, I'm searching 
> for an account at my current company that does), so any insight/summary on 
> that one would be appreciated.

Here is the related upstream ticket
https://pagure.io/SSSD/sssd/issue/3571.

> Fun fact just for info: we had to switch to rfc2307 (from 2307bis) because of 
> another bug in sssd that ignores the setting to not do nested group searches, 
> which resulted in a huge amount of extra ldap searches per user (1 per group).

Did you open a ticket about this?

bye,
Sumit

> 
> Franky
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: fast cache corruption

[Franky Van Liedekerke]

Op Vrijdag, 08-12-2017 om 11:34 schreef Sumit Bose:
> On Fri, Dec 08, 2017 at 11:10:49AM +0100, Franky Van Liedekerke wrote:
> > Before opening a bug report, I wanted to discuss a new issue here. 
> > 
> > I have ldap users that are in 1500 groups (yeah, I know ... not my choice 
> > either), ldap is using rfc2307 scheme (openldap, redhat EL7).
> > Now, when connecting sssd to this ldap server, I've already set 
> > enumeration=false, and also ignore_group_members=true (performance ...).
> > However, with ignore_group_members=true, I'm getting this in the 
> > sssd_nss.log when doing a 'groups " command:
> > 
> > [sssd[nss]] [sss_mc_find_record] (0x0010): Corrupted fastcache. name_ptr 
> > value is 16
> > 
> > (once when the cache is empty, and after that once or twice per 
> > groups-request).
> > I also see this in /var/log/messages (related of course):
> > 
> > sssd[nss]: Stored copy of corrupted mmap cache in file 
> > '/var/lib/sss/mc/group_corrupted#012'
> > 
> > As a result, this prevents the use of the sssd fast cache, so group 
> > requests at best take 5.5 seconds.
> > Now this problem happens 95% of the cases (which leads me to believe it is 
> > a timing bug), but when I set ignore_group_members=false, this is not 
> > happening (and when groups are ok in the fast cache: 0,03 secs response 
> > time).
> > 
> > Ideas? Hints? Or should I just go and open a bug report? Is there a real 
> > performance drawback to setting ignore_group_members=false?
> 
> There is already a BZ
> https://bugzilla.redhat.com/show_bug.cgi?id=1490120.
> 
> I think in your setup (plain LDAP with rfc2307) the performance loss
> when using ignore_group_members=false (the default) should be
> acceptable.
> 
> bye,
> Sumit

Unfortunately I can't view the content of that BZ (no access, I'm searching for 
an account at my current company that does), so any insight/summary on that one 
would be appreciated.
Fun fact just for info: we had to switch to rfc2307 (from 2307bis) because of 
another bug in sssd that ignores the setting to not do nested group searches, 
which resulted in a huge amount of extra ldap searches per user (1 per group).

Franky
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org