There have been a good collection of fixes between glibc-2.17-55.el7_0.3 and glibc-2.17-78.el7.x86_64, but no single fix should have caused the problem you are seeing. If you are using netgroups, things should have gotten better not worse, as we have fixed several netgroup related problems. If you are runnning with nscd you may wish to try without nscd to see if that impacts the problem.

I'm passing this on to the sudo maintainer to see if they have seen anything like this in rhel-7.0.

Hello, could you please attach debug logs from sudo? You can configure debugging via /etc/sudo.conf, just put the following line in there:

Debug sudo /tmp/sudo_debug.log all@debug

and then attach the sudo_debug.log file here. And do this for both scenarios (working vs. non-working), please.

Thanks,
Dan K.

No response from the reporter. Closing for now, please reopen for rhel-7.3 if you think this is still an issue and attach the requested (see comment #3) logs.

I have a customer who is facing similar issue.

Cu has provided me logs for failed sudo attempt and successful attempt hence i am opening the case again.

Created attachment 1119483 [details]
Sudo failed attempt.

Sudo debug logs for failed attempt.

Created attachment 1119487 [details]
Sudo successful attempt

Sudo successful debug attempt

I have attached debug logs from 1 more customer that is possibly hitting the same bug, Please let us know if you required more information.

> Hello. Is this whole issue reproducible only with sudo? There are also some su
> logs in the comments, so is it possible to reproduce this issue with su also?

During testing I would login to the VM as root and make changes to /etc/passwd or other files and then su - to the user to quickly see the effect.  That is probably the su you are seeing in the logs.   su does not see the problem because you supply the root passwd, which is local.  

Interesting to note that even when sudo is failing, the user can login to the system without problems: 

# ssh testuser_100.122.39
testuser_100.122.39's password:
Last login: Tue Feb 16 06:34:02 2016
[testuser_100@localhost ~]$ sudo -l
[sudo] password for testuser_100:
Sorry, try again.
[sudo] password for testuser_100:
Sorry, try again.
[sudo] password for testuser_100:
Sorry, try again.
sudo: 3 incorrect password attempts

I verified that the connection is getting to the AD because it would trip the wrong passwd limit.   

I also turned on pam debugging with debug_sensitive and could verify that the 'correct' password was being generated. 

While: 

 ignore_k5login=true

in /etc/krb5.conf seems to 'correct' the problem,  I am unclear at all why this would be necessary and I don't see it listed in the man page for krb5.conf.  Oddly, the pam_krb5 man page mentions it: 

*       ignore_k5login
specifies that pam_krb5 should skip checking the user's .k5login file to  verify
that  the  principal  name  of  the  client being authenticated is authorized to
access the user account.  (Actually,  the  check  is  performed  by  a  function offered  by  the  Kerberos library, which controls which files it will consult.) The default is to perform the check.

This would suggest that the is something to do with processing k5login file.  
I attempted to populate that file and it had no effect on the behavior.

(In reply to rick.beldin from comment #20)
> > Hello. Is this whole issue reproducible only with sudo? There are also some su
> > logs in the comments, so is it possible to reproduce this issue with su also?
> 
> During testing I would login to the VM as root and make changes to
> /etc/passwd or other files and then su - to the user to quickly see the
> effect.  That is probably the su you are seeing in the logs.   su does not
> see the problem because you supply the root passwd, which is local.  

Could you test with 'su' by running:

$ su - baduser
vs.
$ su - gooduser

?

(assuming that pam is configured the same for su and sudo)

hmm.  Bugzilla email not going through: 


baduser = testuser_100 gooduser=testuser_1

# ssh root.122.39
Last login: Tue Feb 16 06:34:07 2016
[root@localhost ~]# su - testuser_100
Last login: Tue Feb 16 07:15:18 EST 2016 from 192.168.122.1 on pts/0
[testuser_100@localhost ~]$ exit
logout
[root@localhost ~]# su - testuser_1
Last login: Fri Feb 12 16:55:23 EST 2016 from 192.168.122.1 on pts/0
[testuser_1@localhost ~]$ exit
logout

/var/log/secure of this run shows that we don't hit krb for anything.  This is expected as they are only getting passwds, not uids from the AD:

Feb 16 07:15:44 localhost sshd[10968]: Accepted publickey for root from 192.168.122.1 port 47353 ssh2: RSA a5:f6:f3:54:2d:a8:16:53:f6:ec:02:cf:99:20:04:a9
Feb 16 07:15:44 localhost sshd[10968]: pam_unix(sshd:session): session opened for user root by (uid=0)
Feb 16 07:15:50 localhost su: pam_unix(su-l:session): session opened for user testuser_100 by root(uid=0)
Feb 16 07:15:54 localhost su: pam_unix(su-l:session): session closed for user testuser_100
Feb 16 07:15:57 localhost su: pam_unix(su-l:session): session opened for user testuser_1 by root(uid=0)
Feb 16 07:16:01 localhost su: pam_unix(su-l:session): session closed for user testuser_1

Most pam debugging is 'off' at this point as I was trying to see what was relevant.

If you have specific options you want enabled, please let me know.

The differences seem to be in execution paths that are outside sudo's code. Since sudo is using PAM for authentication (calling pam_authenticate) and doesn't treat it in any special way when pam_krb5 is present in the stack, I don't see how this bug could be lurking somewhere in sudo.

Moving to pam_krb5 to see whether they can add something useful to solve this issue and/or explain why the ignore_k5login setting is (now?) required when authentication via sudo.

Keep in mind that the catalyst for this behavior was the upgrade from glibc-2.17-55.el7_0.3 to glibc-2.17-78.el7, as I detailed when I opened this ticket.

The two most likely explanations are:

1) There was a bug introduced with glibc-2.17-78.el7 that pam_krb5 just so happens to trigger.

2) There is a (potentially long-standing) bug in pam_krb5 that so happens to be triggered by changes made in glibc-2.17-78.el7.

I wasn't able to provide any further debugging help, because we abandoned pam_krb5.so in our PAM stack (in favor of pam_sss.so). But I'm glad others are taking this issue and running with it.

We just deployed a RHEL 7 VM in our environment and are experiencing the same issue.  I can confirm that this issue still occurs after upgrading to glibc-2.17-106.el7_2.4.  Either downgrading to glibc-2.17-55 or adding the following to /etc/krb5.conf remain viable workarounds:

[appdefaults]
 pam = {
  debug = false
  EXAMPLE.COM = {
   ignore_k5login = true
  }
 }

This looks like a duplicate: 

https://bugzilla.redhat.com/show_bug.cgi?id=1263745