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 sudoUser svc_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_dts@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!
Max
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 sudoUser svc_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_dts@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com http://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
- why does it not show in the list it can run the command
- 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
Hi Pavel,
We're using 1.15.2 of sssd. Attached are the dubug logs.
Hopefully they show something useful.
Max
On Fri, Dec 8, 2017 at 5:59 AM, Pavel Březina pbrezina@redhat.com wrote:
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 sudoUser svc_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_dts@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com http://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
- why does it not show in the list it can run the command
- 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_trouble shooting.rst
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Hey guys? Any thoughts on this? It's impacting our production environment.
Thanks!
On Mon, Dec 11, 2017, 11:11 AM Max DiOrio mdiorio@gmail.com wrote:
Hi Pavel,
We're using 1.15.2 of sssd. Attached are the dubug logs.
Hopefully they show something useful.
Max
On Fri, Dec 8, 2017 at 5:59 AM, Pavel Březina pbrezina@redhat.com wrote:
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 sudoUser svc_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_dts@internal.ieeeglobalspec.com@internal.ieeeglobalspec.com http://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
- why does it not show in the list it can run the command
- 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-leave@lists.fedorahosted.org
On Mon, Dec 18, 2017 at 11:11:25PM +0000, Max DiOrio wrote:
Hey guys? Any thoughts on this? It's impacting our production environment.
Thanks!
I think Pavel's reply must have missed you, I think we still need the logs he requested: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Hey Jakub,
I sent a response almost immediately - which is why I followed up when I hadn't heard back. You guys normally respond quickly.
The log files are available here. I attached them last time - maybe that was the problem? https://drive.google.com/open?id=1ht1Hf0RxzoOMQPZUUTUARM3R_tYEEYA_
We're using 1.15.2 of sssd. Thanks!
Max
On Tue, Dec 19, 2017 at 5:16 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Mon, Dec 18, 2017 at 11:11:25PM +0000, Max DiOrio wrote:
Hey guys? Any thoughts on this? It's impacting our production
environment.
Thanks!
I think Pavel's reply must have missed you, I think we still need the logs he requested: https://lists.fedorahosted.org/archives/list/sssd-users@ lists.fedorahosted.org/message/4BMTOMUM4DNDFV3KSWSSPLLKLLM2IX7R/ _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On 12/19/2017 11:27 PM, Max DiOrio wrote:
Hey Jakub,
I sent a response almost immediately - which is why I followed up when I hadn't heard back. You guys normally respond quickly.
The log files are available here. I attached them last time - maybe that was the problem? https://drive.google.com/open?id=1ht1Hf0RxzoOMQPZUUTUARM3R_tYEEYA_
We're using 1.15.2 of sssd. Thanks!
I'm sorry for the delay, the reply have not reached us.
I believe you have a typo in the sudoHost attribute of your rule:
netgroup DevTestLinuxServer matches (la-1dglsesgap01.internal.ieeeglobalspec.com|la-1dglsesgap01, , ): false @ netgr_matches() ./match.c:1139
netgroup DevTestLinuxServers matches (la-1dglsesgap01.internal.ieeeglobalspec.com|la-1dglsesgap01, , ): true @ netgr_matches() ./match.c:1139
Shouldn't your netgroup name in the failing rule be also in plural -- DevTestLinuxServers?
Max
On Tue, Dec 19, 2017 at 5:16 AM, Jakub Hrozek <jhrozek@redhat.com mailto:jhrozek@redhat.com> wrote:
On Mon, Dec 18, 2017 at 11:11:25PM +0000, Max DiOrio wrote: > Hey guys? Any thoughts on this? It's impacting our production environment. > > Thanks! I think Pavel's reply must have missed you, I think we still need the logs he requested: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/4BMTOMUM4DNDFV3KSWSSPLLKLLM2IX7R/ <https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/4BMTOMUM4DNDFV3KSWSSPLLKLLM2IX7R/> _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org <mailto:sssd-users-leave@lists.fedorahosted.org>
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Tue, Dec 19, 2017 at 05:27:02PM -0500, Max DiOrio wrote:
Hey Jakub,
I sent a response almost immediately - which is why I followed up when I hadn't heard back. You guys normally respond quickly.
Ahh, sorry about that, it's my fault. The mail got stuck in the moderation queue and I didn't notice it over all the spam that got into the moderation lately.
I've let the mail through now.
sssd-users@lists.fedorahosted.org