Hello!
I've got interesting problem, I have very simple hbac and sudo rules, one hbac for admins group and the same sudo rule for the same user group - all members of this group could do anything and everywhere. I cannot do sudo on some of machines, it's just doesn't accepting password, but initial login via ssh always successful. There is no different between hosts where sudo working and where is not, for freeIPA.
audit log tells me why it's happening:
========= type=USER_AUTH msg=audit(1512995488.051:15986): pid=30997 uid=50019 auid=50019 ses=2221 msg='op=PAM:authentication grantors=? acct="andreios" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' type=USER_AUTH msg=audit(1512995497.531:15987): pid=30997 uid=50019 auid=50019 ses=2221 msg='op=PAM:authentication grantors=? acct="andreios" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' type=USER_AUTH msg=audit(1512995500.247:15988): pid=30997 uid=50019 auid=50019 ses=2221 msg='op=PAM:authentication grantors=? acct="andreios" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' ==========
You see? op=PAM:authentication grantors=? On the other hosts it's following:
op=PAM:authentication grantors=pam_succeed_if,pam_succeed_if,pam_sss
Obviously, sudo for whatever reason doesn't try to auth via pam modules, it's just doesn't seeing them.
sudo debug doesn't tell anything useful:
============ Dec 11 16:22:28 sudo[31666] -> getln @ ./tgetpass.c:303 Dec 11 16:22:33 sudo[31666] <- getln @ ./tgetpass.c:346 := ********** Dec 11 16:22:33 sudo[31666] -> sudo_term_restore_v1 @ ./term.c:112 Dec 11 16:22:33 sudo[31666] <- sudo_term_restore_v1 @ ./term.c:120 := true Dec 11 16:22:33 sudo[31666] <- tgetpass @ ./tgetpass.c:231 := ********** Dec 11 16:22:35 sudo[31666] -> tgetpass @ ./tgetpass.c:93 Dec 11 16:22:35 sudo[31666] -> tty_present @ ./tgetpass.c:360 Dec 11 16:22:35 sudo[31666] <- tty_present @ ./tgetpass.c:361 := true Dec 11 16:22:35 sudo[31666] -> sudo_term_noecho_v1 @ ./term.c:130 Dec 11 16:22:35 sudo[31666] <- sudo_term_noecho_v1 @ ./term.c:141 := true Dec 11 16:22:35 sudo[31666] -> getln @ ./tgetpass.c:303 ============
freeipa client installed via ipa-client-install without any errors OS: Centos 7.3.1611 OS without problems: 7.4.1708, 7.2.1511
So, have anyone idea of what's going happening and why? Thanks!
Ahhh, never mind. It seems that wrong time on that system broke sudo. Can anybody explain this?
2017-12-11 15:50 GMT+03:00 Andrew Radygin randrewg@gmail.com:
Hello!
I've got interesting problem, I have very simple hbac and sudo rules, one hbac for admins group and the same sudo rule for the same user group - all members of this group could do anything and everywhere. I cannot do sudo on some of machines, it's just doesn't accepting password, but initial login via ssh always successful. There is no different between hosts where sudo working and where is not, for freeIPA.
audit log tells me why it's happening:
========= type=USER_AUTH msg=audit(1512995488.051:15986): pid=30997 uid=50019 auid=50019 ses=2221 msg='op=PAM:authentication grantors=? acct="andreios" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' type=USER_AUTH msg=audit(1512995497.531:15987): pid=30997 uid=50019 auid=50019 ses=2221 msg='op=PAM:authentication grantors=? acct="andreios" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' type=USER_AUTH msg=audit(1512995500.247:15988): pid=30997 uid=50019 auid=50019 ses=2221 msg='op=PAM:authentication grantors=? acct="andreios" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' ==========
You see? op=PAM:authentication grantors=? On the other hosts it's following:
op=PAM:authentication grantors=pam_succeed_if,pam_succeed_if,pam_sss
Obviously, sudo for whatever reason doesn't try to auth via pam modules, it's just doesn't seeing them.
sudo debug doesn't tell anything useful:
============ Dec 11 16:22:28 sudo[31666] -> getln @ ./tgetpass.c:303 Dec 11 16:22:33 sudo[31666] <- getln @ ./tgetpass.c:346 := ********** Dec 11 16:22:33 sudo[31666] -> sudo_term_restore_v1 @ ./term.c:112 Dec 11 16:22:33 sudo[31666] <- sudo_term_restore_v1 @ ./term.c:120 := true Dec 11 16:22:33 sudo[31666] <- tgetpass @ ./tgetpass.c:231 := ********** Dec 11 16:22:35 sudo[31666] -> tgetpass @ ./tgetpass.c:93 Dec 11 16:22:35 sudo[31666] -> tty_present @ ./tgetpass.c:360 Dec 11 16:22:35 sudo[31666] <- tty_present @ ./tgetpass.c:361 := true Dec 11 16:22:35 sudo[31666] -> sudo_term_noecho_v1 @ ./term.c:130 Dec 11 16:22:35 sudo[31666] <- sudo_term_noecho_v1 @ ./term.c:141 := true Dec 11 16:22:35 sudo[31666] -> getln @ ./tgetpass.c:303 ============
freeipa client installed via ipa-client-install without any errors OS: Centos 7.3.1611 OS without problems: 7.4.1708, 7.2.1511
So, have anyone idea of what's going happening and why? Thanks! -- Best regards, Andrew.
I encountered this problem once more. At this time I go further in debug and found out, that this problem may be the result of conflict with existing local user, that belong to group, described in sudoers file. After complete deleting the local user - problem seems to be fixed.
2017-12-11 18:03 GMT+03:00 Andrew Radygin randrewg@gmail.com:
Ahhh, never mind. It seems that wrong time on that system broke sudo. Can anybody explain this?
2017-12-11 15:50 GMT+03:00 Andrew Radygin randrewg@gmail.com:
Hello!
I've got interesting problem, I have very simple hbac and sudo rules, one hbac for admins group and the same sudo rule for the same user group - all members of this group could do anything and everywhere. I cannot do sudo on some of machines, it's just doesn't accepting password, but initial login via ssh always successful. There is no different between hosts where sudo working and where is not, for freeIPA.
audit log tells me why it's happening:
========= type=USER_AUTH msg=audit(1512995488.051:15986): pid=30997 uid=50019 auid=50019 ses=2221 msg='op=PAM:authentication grantors=? acct="andreios" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' type=USER_AUTH msg=audit(1512995497.531:15987): pid=30997 uid=50019 auid=50019 ses=2221 msg='op=PAM:authentication grantors=? acct="andreios" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' type=USER_AUTH msg=audit(1512995500.247:15988): pid=30997 uid=50019 auid=50019 ses=2221 msg='op=PAM:authentication grantors=? acct="andreios" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed' ==========
You see? op=PAM:authentication grantors=? On the other hosts it's following:
op=PAM:authentication grantors=pam_succeed_if,pam_succeed_if,pam_sss
Obviously, sudo for whatever reason doesn't try to auth via pam modules, it's just doesn't seeing them.
sudo debug doesn't tell anything useful:
============ Dec 11 16:22:28 sudo[31666] -> getln @ ./tgetpass.c:303 Dec 11 16:22:33 sudo[31666] <- getln @ ./tgetpass.c:346 := ********** Dec 11 16:22:33 sudo[31666] -> sudo_term_restore_v1 @ ./term.c:112 Dec 11 16:22:33 sudo[31666] <- sudo_term_restore_v1 @ ./term.c:120 := true Dec 11 16:22:33 sudo[31666] <- tgetpass @ ./tgetpass.c:231 := ********** Dec 11 16:22:35 sudo[31666] -> tgetpass @ ./tgetpass.c:93 Dec 11 16:22:35 sudo[31666] -> tty_present @ ./tgetpass.c:360 Dec 11 16:22:35 sudo[31666] <- tty_present @ ./tgetpass.c:361 := true Dec 11 16:22:35 sudo[31666] -> sudo_term_noecho_v1 @ ./term.c:130 Dec 11 16:22:35 sudo[31666] <- sudo_term_noecho_v1 @ ./term.c:141 := true Dec 11 16:22:35 sudo[31666] -> getln @ ./tgetpass.c:303 ============
freeipa client installed via ipa-client-install without any errors OS: Centos 7.3.1611 OS without problems: 7.4.1708, 7.2.1511
So, have anyone idea of what's going happening and why? Thanks! -- Best regards, Andrew.
-- Best regards, Andrew.
freeipa-users@lists.fedorahosted.org