6:50 a.m.
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.
9:03 a.m.
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(a)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.
4:45 a.m.
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(a)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(a)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.
--
Best regards, Andrew.
2316
days inactive
2327
days old
freeipa-users@lists.fedorahosted.org
2 comments
1 participants
participants (1)
-
Andrew Radygin