Re: [Freeipa-users] FreeIPA and LetsEncrypt Question

[Petr Spacek]

On 2.12.2015 15:25, Günther J. Niederwimmer wrote:
> Hello All,
> 
> Am Wednesday 02 December 2015, 21:10:31 schrieb Fraser Tweedale:
>> On Mon, Nov 30, 2015 at 02:46:13PM +0200, Alexander Bokovoy wrote:
>>> On Mon, 30 Nov 2015, Günther J. Niederwimmer wrote:
 Hello ,

 I have the question, know any from the FreeIPA "Gurus" ;-), are the new
 upcoming LetsEncrypt Certificates compatible and working with FreeIPA?
>>>
>>> We have plans to support issuing certificates via Let's Encrypt.
>>
>> Günther, what are your specific wishes - to automatically acquire LE
>> certs for FreeIPA server's HTTP and LDAP?  Arbitrary hosts or
>> services that are managed by FreeIPA?
> 
> My wishes :-)).
> 
> when I can have wishes, I mean all ;-) 
> 
> But I nice Integration for IMAP, SMTP, LDAP, HTTPS ... was a dream.
> 
> Now I make a test with FreeIPA and "DANE" I hope this is working ?.

IPA allows you to DNSSEC-sign the domain, the rest is up to you. You have to
create TLSA records for your certificates, put these into DNSSEC-signed domain
and then get *clients* to respect them.

In other words, IPA does nothing except DNSSEC-signing of DNS domains.

>>> However, right now Let's encrypt only issues server certificates, not
>>> CA roots, so you cannot use them to bootstrap IPA CA.
>>
>> This will probably always be the case.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system

[Petr Spacek]

On 2.12.2015 22:02, Alexander Bokovoy wrote:
> On Wed, 02 Dec 2015, Andy Thompson wrote:
>> Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the
>> system up after a period of time.  The directory becomes unresponsive
>> to searches or any connections.  After a restart I see
>>
>> [02/Dec/2015:15:27:41 -0500] - slapd started.  Listening on All Interfaces
>> port 389 for LDAP requests
>> [02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636 for
>> LDAPS requests
>> [02/Dec/2015:15:27:41 -0500] - Listening on /var/run/slapd-MHBENP-LIN.socket
>> for LDAPI requests
>> [02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin -
>> agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389): Replication bind
>> with GSSAPI auth resumed
>> [02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep alive
>> entry 

[Freeipa-users] compat tree refresh

[Winfried de Heiden]

  
  
Hi all,
  
  Using a RHEL or Centos 5.11 as a legacy client (using sssd) seems
  to work.
  
  I created an external group which is member of a posix group.
  Putting an AD user in the external group works, but it seems to
  take ages beofre it takes effect.
  Yesterday late, I remove some AD user from some group and did not
  see any effect only until this morning.
  
  What could case this delay?
  
  Oh yeah, during the night, IPA is stopped during the back-up... Is
  this causing the refresh?
  
  It is OK to wait some time for group modifications to take effect,
  that's the price of the sssd-cache but this looks strange and is
  far too long
  
  On both IPA-server and the EL5 client I set "entry_cache_timeout" 
  to 300.
  
  Kind regards,
  
  Winny
  
  

  


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Problem with ipa-csreplica reinitialize

[Łukasz Jaworski]

Hi,

We have strange problems in our environment.

After ipa-csreplica-manage re-initialize servers crash (it happens very often, 
after second or third try, all dc, and pki replication gone. I've reinstalled 
server and setup new replication).
There aren't any information in logs. It looks like process stops without any 
notice.

During ipa-csreplica-manage re-initialize server shows:

Update in progress, 3 seconds elapsed
Update succeeded

but dirsrv is gone. ps -ax |grep dirsrv shows nothing.

after start dirsrv, replication is broken:
The remote replica has a different database generation ID than the local 
database.  You may have to reinitialize the remote replica, or the local 
replica.

some information about our setup:
Fedora 23 (updated from 22)

freeipa-server-4.1.4-4.fc22.x86_64
389-ds-base-1.3.4.4-1.fc22.x86_64
389-ds-base-libs-1.3.4.4-1.fc22.x86_64
krb5-server-1.13.2-7.fc22.x86_64  
krb5-workstation-1.13.2-7.fc22.x86_64  
krb5-pkinit-1.13.2-7.fc22.x86_64  
krb5-libs-1.13.2-7.fc22.x86_64

Best regards,
Łukasz Jaworski
Ender

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Sudo question

[Rob Crittenden]

Sean Hogan wrote:
> Hi Rob,
> 
> Thanks for the suggestion. I think that is what I have though. The
> sudorule applied for this user does not have sudo as an avail command
> unless it picks up /usr/bin/sudo -u user -i which I was thinking would
> only allow sudoing to user.
> HBAC services I have for the user has sudo and no sudo -i.
> Services
> sshd
> login
> gdm
> gdm-password
> kdm
> su
> su-l
> vsftpd
> sudo
> 
> Sudo Rule
> *Sudo Allow Commands*: /sbin/iptables, /sbin/service,
> /bin/view,/bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat
> *Sudo Deny Commands*: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo
> -u root -i
> 
> Unfortunately I am really stumped on this one.

You probably have the allow_all HBAC rule enabled. If sudo-i isn't
allowed in HBAC then the pam service shouldn't be allowed at all. I'd
suggest you bump up the sssd debug level to better see what is happening.

rob

> 
> 
> 
> 
> 
> Inactive hide details for Rob Crittenden ---12/02/2015 04:26:24
> PM---Sean Hogan wrote: > Hi All,Rob Crittenden ---12/02/2015 04:26:24
> PM---Sean Hogan wrote: > Hi All,
> 
> From: Rob Crittenden 
> To: Sean Hogan/Durham/IBM@IBMUS, freeipa-users@redhat.com
> Date: 12/02/2015 04:26 PM
> Subject: Re: [Freeipa-users] Sudo question
> 
> 
> 
> 
> 
> Sean Hogan wrote:
>> Hi All,
>>
>> I have a significant amount of time on this and hoping some of you might
>> have an idea. I want to limit user bob from getting to a root prompt on
>> this test box.
>> It seems to work until bob is able to run a command he is allowed via
>> sudo such as cat. Sudo -i is on the deny command list in IPA and root is
>> local(not in IPA) with
>> nsswitch pointing to files first then sss.
>>
>> So logged on as user bob, first thing attempted was sudo -i which
>> produces wrong pw message even though it is the correct pw but it is
>> denying so fine. Then I issue sudo cat /etc/sysconfig/iptables
>> and it allows it after I enter bob's pw which is fine. However right
>> after that I try sudo -i again and get root prompt which is not good. I
>> am thinking since root is local and files first then once I sudo up root
>> is avail.
>> Any suggestions are welcome
> 
> I think you are better off using an HBAC rule to only grant sudo and not
> sudo -i.
> 
> rob
> 
>>
>>
>>
>> *[me@mine ~]$ ssh bob@server*
>> bob@servers password:
>> Last login: Time: from IP
>> Internal systems must only be used for conducting company business or
>> for purposes authorized by company management
>> Use is subject to audit at any time by company management
>> *[bob@server ~]$ sudo -i*
>> [sudo] password for bob:
>> Sorry, try again.
>> *[bob@server ~]$ sudo -i*
>> [sudo] password for bob:
>> Sorry, try again.
>> [sudo] password for bob:
>> Sorry, try again.
>> [sudo] password for bob:
>> sudo: 2 incorrect password attempts
>> *[bob@server ~]$ sudo cat /etc/sysconfig/iptables*
>> [sudo] password for bob:
>> # Firewall configuration written by system-config-firewall
>> # Manual customization of this file is not recommended.
>> *filter
>> *[bob@server ~]$ sudo -i*
>> *server.example.local:/root# cat /etc/sysconfig/iptables*
>> # Firewall configuration written by system-config-firewall
>> # Manual customization of this file is not recommended.
>> *filter
>>
>>
>>
>> ipa sudorule-show bob
>> Rule name: bob
>> Description: test sudo rule for user bob
>> Enabled: TRUE
>> Host category: all
>> Users: bob
>> Sudo Allow Commands: /sbin/iptables, /sbin/service, /bin/view,
>> /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat
>> Sudo Deny Commands: /usr/bin/sudo -i, /usr/bin/sudo-i, /usr/bin/sudo -u
>> root -i
>>
>> Is it just me or is white space ignored as well with sudo commands much
>> like the sudo options?
>>
>>
>>
>>
>>
>>
>> Sean Hogan
>> Security Engineer
>> Watson Security & Risk Assurance
>> Watson Cloud Technology and Support
>> email: scho...@us.ibm.com | Tel 919 486 1397
>>
>>
>>
>>
>>
>>
>>
> 
> 
> 
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system

[Andy Thompson]

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Petr Spacek
> Sent: Thursday, December 3, 2015 3:04 AM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system
> 
> On 2.12.2015 22:02, Alexander Bokovoy wrote:
> > On Wed, 02 Dec 2015, Andy Thompson wrote:
> >> Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the
> >> system up after a period of time.  The directory becomes unresponsive
> >> to searches or any connections.  After a restart I see
> >>
> >> [02/Dec/2015:15:27:41 -0500] - slapd started.  Listening on All
> >> Interfaces port 389 for LDAP requests
> >> [02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636
> >> for LDAPS requests
> >> [02/Dec/2015:15:27:41 -0500] - Listening on
> >> /var/run/slapd-MHBENP-LIN.socket for LDAPI requests
> >> [02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin -
> >> agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389):
> Replication
> >> bind with GSSAPI auth resumed
> >> [02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep
> >> alive entry 

Re: [Freeipa-users] Problem with ipa-csreplica reinitialize

[Rob Crittenden]

Łukasz Jaworski wrote:
> Hi,
> 
> We have strange problems in our environment.
> 
> After ipa-csreplica-manage re-initialize servers crash (it happens very
> often, after second or third try, all dc, and pki replication gone. I've
> reinstalled server and setup new replication). There aren't any
> information in logs. It looks like process stops without any notice.
> 
> During ipa-csreplica-manage re-initialize server shows:
> 
> Update in progress, 3 seconds elapsed Update succeeded
> 
> but dirsrv is gone. ps -ax |grep dirsrv shows nothing.
> 
> after start dirsrv, replication is broken: The remote replica has a
> different database generation ID than the local database. You may have
> to reinitialize the remote replica, or the local replica.
> 
> some information about our setup: Fedora 23 (updated from 22)
> 
> freeipa-server-4.1.4-4.fc22.x86_64 389-ds-base-1.3.4.4-1.fc22.x86_64
> 389-ds-base-libs-1.3.4.4-1.fc22.x86_64 krb5-server-1.13.2-7.fc22.x86_64
> krb5-workstation-1.13.2-7.fc22.x86_64 krb5-pkinit-1.13.2-7.fc22.x86_64
> krb5-libs-1.13.2-7.fc22.x86_64
> 
> Best regards, Łukasz Jaworski Ender
> 
> 
> 

Install debuginfo for 389-ds-base and do another reinitialize and get a
stack trace. See
http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-crashes

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Sudo question

[Sean Hogan]

Rob,

  Yes.. in our setup allow_all has to be explicitly applied to a
persons/group HBAC for it to be available to them.  This user has one
direct HBAC rule and its called Bob which only allows access to 2 servers
and the services I provided below and one indirect HBAC rule which allows
him access to our NFS server automouting home profiles and his own sudo
rule called bob.

I have removed /bin/bash from his sudo rule and it is working as expected
now however I am thinking this will affect app owners from being able to
sudo to app IDs so they will just have to su to them instead I am thinking.
Is probably a better approach anyways as the app owner should know the app
password and keep anyone else from sudoing to it with there own pw.

output of working as required:

[bob@server ~]$ sudo -i
Sorry, user bob is not allowed to execute '/bin/bash' as root on
server.example.local.
[bob@server ~]$ sudo cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
[bob@server ~]$ sudo -i
Sorry, user bob is not allowed to execute '/bin/bash' as root on
server.example.local.
[bob@server ~]$

Any comments or suggestions welcome



Sean Hogan
Security Engineer
Watson Security & Risk Assurance
Watson Cloud Technology and Support
email: scho...@us.ibm.com | Tel 919 486 1397









From:   Rob Crittenden 
To: Sean Hogan/Durham/IBM@IBMUS, "Freeipa-users@redhat.com"

Date:   12/03/2015 11:21 AM
Subject:Re: [Freeipa-users] Sudo question



Sean Hogan wrote:
> I had the log bumped to 8 and yes the allow_all HBAC rule is enabled
> however not associated with this user at all. This test only allows this
> user to hit 2 servers with individual HBAC rule to the 2 servers via the
> services I provided earlier.
>

allow_all applies to everyone unless you've changed it. HBAC is deny by
default so once allowed, always allowed.

I'm not well-versed in the sssd logs so maybe one of those guys will
chime in.

rob

> [bob@server ~]$ sudo -l
> [sudo] password for bob:
> Matching Defaults entries for bob on this host:
> requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
> DISPLAY HOSTNAME HISTSIZE INPUTRC 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, logfile=/var/log/sudo.log
>
> User bob may run the following commands on this host:
> (root) !/usr/local/bin/sudo, !/usr/bin/sudo, !/bin/sudo
> (root) /usr/bin/xclock
> (root) /sbin/iptables, /sbin/service, /bin/vi, /bin/view, /usr/bin/vim,
> /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat,
> !/usr/bin/sudo -i, !/usr/bin/sudo-i, !/usr/bin/sudo -u root -i
>
>
>
> sssd.conf
> server.example.local:/var/log# cat /etc/sssd/sssd.conf
> [domain/example.local]
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = example.local
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = server.example.local
> chpass_provider = ipa
> ipa_dyndns_update = True
> ipa_server = _srv_, mastersrv.example.local
> ldap_tls_cacert = /etc/ipa/ca.crt
> [sssd]
> services = nss, sudo, pam, ssh
> config_file_version = 2
> debug_level = 8
>
> domains = example.local
> [nss]
> homedir_substring = /home
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [ssh]
>
> [pac]
>
> [ifp]
>
>
> Ran thru the commands again:
> [me@mine ~]$ ssh bob@server
> bob@server password:
> Last login: Thu Dec 3 11:24:53 2015 from IP_ADDRESS
> [bob@server ~]$ sudo -i
> [sudo] password for bob:
> Sorry, try again.
> [sudo] password for bob:
> sudo: 1 incorrect password attempt
> [bob@server ~]$ sudo cat /etc/sysconfig/iptables
> [sudo] password for bob:
> # Firewall configuration written by system-config-firewall
> # Manual customization of this file is not recommended.
> *filter
> [bob@server ~]$ sudo -i
> server.example.local:/root# exit
>
> This is what the logs show for above conversations
> Dec 3 11:49:52 server sshd[61682]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS user=bob
> Dec 3 11:49:53 server sshd[61682]: pam_sss(sshd:auth): authentication
> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS user=bob
> Dec 3 11:49:53 server sshd[61682]: Accepted password for bob from
> IP_ADDRESS port 50273 ssh2
> Dec 3 11:49:53 server sshd[61682]: pam_unix(sshd:session): session
> opened for user bob by (uid=0)
> Dec 3 11:49:53 server sshd[61682]: User child is on pid 61687
>
> Attempt sudo -i which fails with bad pw but at least fails, PW is
correct.
> Dec 3 11:50:05 server sudo: pam_unix(sudo-i:auth): authentication
> failure; logname=bob uid=1091450500 

Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system

[Rich Megginson]

On 12/03/2015 08:33 AM, Andy Thompson wrote:



-Original Message-
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
boun...@redhat.com] On Behalf Of Petr Spacek
Sent: Thursday, December 3, 2015 3:04 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system

On 2.12.2015 22:02, Alexander Bokovoy wrote:

On Wed, 02 Dec 2015, Andy Thompson wrote:

Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the
system up after a period of time.  The directory becomes unresponsive
to searches or any connections.  After a restart I see

[02/Dec/2015:15:27:41 -0500] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636
for LDAPS requests
[02/Dec/2015:15:27:41 -0500] - Listening on
/var/run/slapd-MHBENP-LIN.socket for LDAPI requests
[02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin -
agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389):

Replication

bind with GSSAPI auth resumed
[02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep
alive entry 

Re: [Freeipa-users] Sudo question

[Rob Crittenden]

Sean Hogan wrote:
> I had the log bumped to 8 and yes the allow_all HBAC rule is enabled
> however not associated with this user at all. This test only allows this
> user to hit 2 servers with individual HBAC rule to the 2 servers via the
> services I provided earlier.
> 

allow_all applies to everyone unless you've changed it. HBAC is deny by
default so once allowed, always allowed.

I'm not well-versed in the sssd logs so maybe one of those guys will
chime in.

rob

> [bob@server ~]$ sudo -l
> [sudo] password for bob:
> Matching Defaults entries for bob on this host:
> requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
> DISPLAY HOSTNAME HISTSIZE INPUTRC 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, logfile=/var/log/sudo.log
> 
> User bob may run the following commands on this host:
> (root) !/usr/local/bin/sudo, !/usr/bin/sudo, !/bin/sudo
> (root) /usr/bin/xclock
> (root) /sbin/iptables, /sbin/service, /bin/vi, /bin/view, /usr/bin/vim,
> /bin/bash, /bin/netstat, /usr/bin/sudo -u user -i, /bin/cat,
> !/usr/bin/sudo -i, !/usr/bin/sudo-i, !/usr/bin/sudo -u root -i
> 
> 
> 
> sssd.conf
> server.example.local:/var/log# cat /etc/sssd/sssd.conf
> [domain/example.local]
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = example.local
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = server.example.local
> chpass_provider = ipa
> ipa_dyndns_update = True
> ipa_server = _srv_, mastersrv.example.local
> ldap_tls_cacert = /etc/ipa/ca.crt
> [sssd]
> services = nss, sudo, pam, ssh
> config_file_version = 2
> debug_level = 8
> 
> domains = example.local
> [nss]
> homedir_substring = /home
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> 
> 
> Ran thru the commands again:
> [me@mine ~]$ ssh bob@server
> bob@server password:
> Last login: Thu Dec 3 11:24:53 2015 from IP_ADDRESS
> [bob@server ~]$ sudo -i
> [sudo] password for bob:
> Sorry, try again.
> [sudo] password for bob:
> sudo: 1 incorrect password attempt
> [bob@server ~]$ sudo cat /etc/sysconfig/iptables
> [sudo] password for bob:
> # Firewall configuration written by system-config-firewall
> # Manual customization of this file is not recommended.
> *filter
> [bob@server ~]$ sudo -i
> server.example.local:/root# exit
> 
> This is what the logs show for above conversations
> Dec 3 11:49:52 server sshd[61682]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS user=bob
> Dec 3 11:49:53 server sshd[61682]: pam_sss(sshd:auth): authentication
> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=IP_ADDRESS user=bob
> Dec 3 11:49:53 server sshd[61682]: Accepted password for bob from
> IP_ADDRESS port 50273 ssh2
> Dec 3 11:49:53 server sshd[61682]: pam_unix(sshd:session): session
> opened for user bob by (uid=0)
> Dec 3 11:49:53 server sshd[61682]: User child is on pid 61687
> 
> Attempt sudo -i which fails with bad pw but at least fails, PW is correct.
> Dec 3 11:50:05 server sudo: pam_unix(sudo-i:auth): authentication
> failure; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob
> rhost= user=bob
> Dec 3 11:50:06 server sudo: pam_sss(sudo-i:auth): authentication
> success; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob
> rhost= user=bob
> Dec 3 11:50:06 server sudo: pam_sss(sudo-i:account): Access denied for
> user bob: 6 (Permission denied)
> Dec 3 11:50:11 server sudo: pam_unix(sudo-i:auth): conversation failed
> Dec 3 11:50:11 server sudo: pam_unix(sudo-i:auth): auth could not
> identify password for [bob]
> Dec 3 11:50:11 server sudo: pam_sss(sudo-i:auth): authentication
> failure; logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob
> rhost= user=bob
> Dec 3 11:50:11 server sudo: pam_sss(sudo-i:auth): received for user bob:
> 7 (Authentication failure)
> Dec 3 11:50:11 server sudo: bob : 1 incorrect password attempt ;
> TTY=pts/2 ; PWD=/home/rusers/bob ; USER=root ; COMMAND=/bin/bash
> 
> Cat /etc/syconfig/iptables which works after prompting for pw so good
> Dec 3 11:50:42 server sudo: pam_unix(sudo:auth): authentication failure;
> logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob rhost= user=bob
> Dec 3 11:50:43 server sudo: pam_sss(sudo:auth): authentication success;
> logname=bob uid=1091450500 euid=0 tty=/dev/pts/2 ruser=bob rhost= user=bob
> Dec 3 11:50:43 server sudo: bob : TTY=pts/2 ; PWD=/home/rusers/bob ;
> USER=root ; COMMAND=/bin/cat /etc/sysconfig/iptables
> 
> sudo -i now works even though it did not before
> Dec 3 11:50:52 server sudo: bob : TTY=pts/2 ; PWD=/home/rusers/bob ;
> USER=root ; COMMAND=/bin/bash
> 
> 
> I expect the pam_unix fails as the accounts are not