I need some help with this. I am working with FreeIPA runnning on CentOS 7.4 verssion 4.5.0-22. I have 2 servers in my AWS VPC and 2 servers at my local office. For some reason I am not seeing replication happen (over ldaps?) from 1 server in my local office to the two servers up there. AWS servers: [centos@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa01.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:30:31+00:00[centos@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa03.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[centos@freeipa03 ~]$ [root@freeipa04 log]# ipa-replica-manage list -v freeipa03.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[root@freeipa04 log]# ipa-replica-manage list -v freeipa01.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:30:31+00:00[root@freeipa04 log]# Local office:server 1 [gatewayblend@freeipa01 ~]$ sudo ipa-replica-manage list -v freeipa04.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:24:41+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:24:32+00:00freeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa01 ~]$ sudo ipa-replica-manage list -v freeipa03.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:30:53+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:30:53+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa01 ~]$ [gatewayblend@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa04.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:08:00+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:07:54+00:00freeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa03 ~]$ sudo vim /etc/resolv.conf[gatewayblend@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa03.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:40:35+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:40:35+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa03 ~]$ The topologysegment shows we have 2-way connectivity all the way around:[root@freeipa04 log]# ipa topologysegment-find --allSuffix name: domain------------------6 segments matched------------------ dn: cn=freeipa01.stl1.gatewayblend.net-to-freeipa03.stl1.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa01.stl1.gatewayblend.net-to-freeipa03.stl1.gatewayblend.net Left node: freeipa01.stl1.gatewayblend.net Right node: freeipa03.stl1.gatewayblend.net Connectivity: both iparepltoposegmentstatus: autogen objectclass: iparepltoposegment, top dn: cn=freeipa01.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa01.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net Left node: freeipa01.stl1.gatewayblend.net Right node: freeipa04.east.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top dn: cn=freeipa03.east.gatewayblend.net-to-freeipa01.stl1.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.east.gatewayblend.net-to-freeipa01.stl1.gatewayblend.net Left node: freeipa03.east.gatewayblend.net Right node: freeipa01.stl1.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top dn: cn=freeipa03.east.gatewayblend.net-to-freeipa04.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.east.gatewayblend.net-to-freeipa04.east.gatewayblend.net Left node: freeipa03.east.gatewayblend.net Right node: freeipa04.east.gatewayblend.net Connectivity: both iparepltoposegmentstatus: autogen objectclass: iparepltoposegment, top dn: cn=freeipa03.stl1.gatewayblend.net-to-freeipa03.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.stl1.gatewayblend.net-to-freeipa03.east.gatewayblend.net Left node: freeipa03.stl1.gatewayblend.net Right node: freeipa03.east.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top dn: cn=freeipa03.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net Left node: freeipa03.stl1.gatewayblend.net Right node: freeipa04.east.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top----------------------------Number of entries returned 6----------------------------[root@freeipa04 log]# When I add a user everything gets sync'ed. When I add a DNS entry its gets sync'ed all the way around. Is the error i'm getting a false positive? It seems like it is. This is the error I'm getting in /var/log/messages. However I think this pertains to DNSSEC and can be ignored, correct? Mar 21 13:35:25 freeipa01 systemd: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILUREMar 21 13:35:25 freeipa01 systemd: Unit ipa-dnskeysyncd.service entered failed state.Mar 21 13:35:25 freeipa01 systemd: ipa-dnskeysyncd.service failed.Mar 21 13:36:25 freeipa01 systemd: ipa-dnskeysyncd.service holdoff time over, scheduling restart.Mar 21 13:36:25 freeipa01 systemd: Started IPA key daemon.Mar 21 13:36:25 freeipa01 systemd: Starting IPA key daemon...Mar 21 13:36:28 freeipa01 ipa-dnskeysyncd: ipa : INFO LDAP bind...Mar 21 13:36:28 freeipa01 ipa-dnskeysyncd: ipa : INFO Commencing sync processMar 21 13:36:29 freeipa01 ipa-dnskeysyncd: ipa.ipaserver.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BINDMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: Traceback (most recent call last):Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 114, in <module>Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_pollMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: self.syncrepl_refreshdone()Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 115, in syncrepl_refreshdoneMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: self.hsm_replica_sync()Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 181, in hsm_replica_syncMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 512, in runMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: raise CalledProcessError(p.returncode, arg_string, str(output))Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1Mar 21 13:36:33 freeipa01 systemd: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILUREMar 21 13:36:33 freeipa01 systemd: Unit ipa-dnskeysyncd.service entered failed state.Mar 21 13:36:33 freeipa01 systemd: ipa-dnskeysyncd.service failed.Mar 21 13:37:33 freeipa01 systemd: ipa-dnskeysyncd.service holdoff time over, scheduling restart.Mar 21 13:37:33 freeipa01 systemd: Started IPA key daemon.Mar 21 13:37:33 freeipa01 systemd: Starting IPA key daemon...Mar 21 13:37:36 freeipa01 ipa-dnskeysyncd: ipa : INFO LDAP bind...Mar 21 13:37:36 freeipa01 ipa-dnskeysyncd: ipa : INFO Commencing sync processMar 21 13:37:36 freeipa01 ipa-dnskeysyncd: ipa.ipaserver.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BINDMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: Traceback (most recent call last):Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 114, in <module>Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_pollMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: self.syncrepl_refreshdone()Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 115, in syncrepl_refreshdoneMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: self.hsm_replica_sync()Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 181, in hsm_replica_syncMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 512, in runMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: raise CalledProcessError(p.returncode, arg_string, str(output))Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1Mar 21 13:37:40 freeipa01 systemd: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILUREMar 21 13:37:40 freeipa01 systemd: Unit ipa-dnskeysyncd.service entered failed state.Mar 21 13:37:40 freeipa01 systemd: ipa-dnskeysyncd.service failed.[gatewayblend@freeipa01 ~]$ I'm not sure what the issue is. Any help is appreciated. Thank you,Andrew Meyer
Hello,
We are implementing OTP for a new deployment and we can log in with the otp codes however when trying to sudo it fails. We would like to use the 2fa to log in but single factor is ok for sudo escalation. Is OTP supposed to be getting involved when issuing sudo commands?
bob@ipa-client1$ sudo cat /etc/resolv.conf First Factor: Second Factor: Sorry, try again. First Factor: sudo: 1 incorrect password attempt
ipa-server-dns-4.5.0-21.el7_4.2.2.noarch python-libipa_hbac-1.15.2-50.el7_4.6.x86_64 python-ipaddress-1.0.16-2.el7.noarch ipa-common-4.5.0-21.el7_4.2.2.noarch ipa-client-common-4.5.0-21.el7_4.2.2.noarch python2-ipalib-4.5.0-21.el7_4.2.2.noarch ipa-server-common-4.5.0-21.el7_4.2.2.noarch ipa-client-4.5.0-21.el7_4.2.2.x86_64 libipa_hbac-1.15.2-50.el7_4.6.x86_64 python2-ipaclient-4.5.0-21.el7_4.2.2.noarch python2-ipaserver-4.5.0-21.el7_4.2.2.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 python-iniparse-0.4-9.el7.noarch ipa-server-4.5.0-21.el7_4.2.2.x86_64
Sean Hogan
On to, 22 maalis 2018, Sean Hogan via FreeIPA-users wrote:
Hello,
We are implementing OTP for a new deployment and we can log in with the otp codes however when trying to sudo it fails. We would like to use the 2fa to log in but single factor is ok for sudo escalation. Is OTP supposed to be getting involved when issuing sudo commands?
Yes, it should work.
Look at SSSD troubleshooting guide to produce SSSD logs when sudo tries PAM authentication. https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
On Thu, Mar 22, 2018 at 10:28:17AM -0700, Sean Hogan via FreeIPA-users wrote:
Hello,
We are implementing OTP for a new deployment and we can log in with theotp codes however when trying to sudo it fails. We would like to use the 2fa to log in but single factor is ok for sudo escalation. Is OTP supposed
You have to allow on the server that the user can use both 1FA (password) or 2FA, see --user-auth-type option of 'ipa user-add'.
To force 2FA at the log in you have to define on the server that the host requires the 'OTP' authentication indicator, see --auth-ind option of 'ipa host-mod'
HTH
bye, Sumit
to be getting involved when issuing sudo commands?
bob@ipa-client1$ sudo cat /etc/resolv.conf First Factor: Second Factor: Sorry, try again. First Factor: sudo: 1 incorrect password attempt
ipa-server-dns-4.5.0-21.el7_4.2.2.noarch python-libipa_hbac-1.15.2-50.el7_4.6.x86_64 python-ipaddress-1.0.16-2.el7.noarch ipa-common-4.5.0-21.el7_4.2.2.noarch ipa-client-common-4.5.0-21.el7_4.2.2.noarch python2-ipalib-4.5.0-21.el7_4.2.2.noarch ipa-server-common-4.5.0-21.el7_4.2.2.noarch ipa-client-4.5.0-21.el7_4.2.2.x86_64 libipa_hbac-1.15.2-50.el7_4.6.x86_64 python2-ipaclient-4.5.0-21.el7_4.2.2.noarch python2-ipaserver-4.5.0-21.el7_4.2.2.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 python-iniparse-0.4-9.el7.noarch ipa-server-4.5.0-21.el7_4.2.2.x86_64
Sean Hogan
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On Tue, Nov 27, 2018 at 01:34:25PM +0100, Winfried de Heiden wrote:
Hi all,
I tried this as well, created a user for which otp and password is both allowe to enforce OTP login on certain hosts but sudo without otp:
Enforcing 2FA for a host currently means enforcing it for all services which are handled by SSSD via PAM including sudo.
bye, Sumit
ipa user-show winfried User login: winfried First name: Winfried Last name: de Heiden Home directory: /home/winfried Login shell: /bin/bash Principal name: winfried@IPA.EXAMPLE.LOCAL Principal alias: winfried@IPA.EXAMPLE.LOCAL Email address: winfried@ipa.example.local UID: 100018 GID: 100018 User authentication types: password, otp Account disabled: False Password: True Member of groups: ipausers Member of Sudo rule: reboot Member of HBAC rule: freeipa-clientxx Kerberos keys available: True
The host indeed will force otp upon login:
[winfried@freeipa-client03 ~]$ ipa host-show $(hostname) Host name: freeipa-client03.ipa.example.local Principal name: host/freeipa-client03.ipa.example.local@IPA.EXAMPLE.LOCAL Principal alias: host/freeipa-client03.ipa.example.local@IPA.EXAMPLE.LOCAL SSH public key fingerprint: SHA256:a03P2T5BqumEXarmQlZxqD9VNIw6l9VTSXkhRp3wKo8 (ssh-rsa), SHA256:PlV7LeKRipRw5Fild77ENuazjUWhEIQbwxACegdj+34 (ecdsa-sha2-nistp256), SHA256:DiPQ/ EXr+w4ZSvCZBkdddGGYcJuITR64uIaMSbr0o0s (ssh-ed25519) Authentication Indicators: otp Password: False Member of Sudo rule: reboot Member of HBAC rule: freeipa-clientxx Keytab: True Managed by: freeipa-client03.ipa.example.local
However, leaving the second empty, sudo will fail:
sudo -l First Factor: Second Factor (optional): Sorry, try again. First Factor: Second Factor (optional): Sorry, try again. First Factor: Second Factor (optional): sudo: 3 incorrect password attempts
Both IPA-server and client are running on CentOS 7.5.
Op 23-03-18 om 09:32 schreef Sumit Bose via FreeIPA-users:
On Thu, Mar 22, 2018 at 10:28:17AM -0700, Sean Hogan via FreeIPA-users wrote: Hello, We are implementing OTP for a new deployment and we can log in with the otp codes however when trying to sudo it fails. We would like to use the 2fa to log in but single factor is ok for sudo escalation. Is OTP supposed You have to allow on the server that the user can use both 1FA (password) or 2FA, see --user-auth-type option of 'ipa user-add'. To force 2FA at the log in you have to define on the server that the host requires the 'OTP' authentication indicator, see --auth-ind option of 'ipa host-mod' HTH bye, Sumit to be getting involved when issuing sudo commands? bob@ipa-client1$ sudo cat /etc/resolv.conf First Factor: Second Factor: Sorry, try again. First Factor: sudo: 1 incorrect password attempt ipa-server-dns-4.5.0-21.el7_4.2.2.noarch python-libipa_hbac-1.15.2-50.el7_4.6.x86_64 python-ipaddress-1.0.16-2.el7.noarch ipa-common-4.5.0-21.el7_4.2.2.noarch ipa-client-common-4.5.0-21.el7_4.2.2.noarch python2-ipalib-4.5.0-21.el7_4.2.2.noarch ipa-server-common-4.5.0-21.el7_4.2.2.noarch ipa-client-4.5.0-21.el7_4.2.2.x86_64 libipa_hbac-1.15.2-50.el7_4.6.x86_64 python2-ipaclient-4.5.0-21.el7_4.2.2.noarch python2-ipaserver-4.5.0-21.el7_4.2.2.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 python-iniparse-0.4-9.el7.noarch ipa-server-4.5.0-21.el7_4.2.2.x86_64 Sean Hogan _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On Tue, Nov 27, 2018 at 02:09:43PM +0100, Winfried de Heiden wrote:
Hi all,
Mmmm, I was afraid so..... Any (nearby) plans for a "feature enhancement" on this :)
I'm not aware of any plans in this direction.
The original idea was that there might be hosts with have a higher requirement for security e.g. because they contain sensitive data. In this case I think it makes sense to require otp for all services especially services which can give you even higher privileges like sudo.
If you want to make is easy for a user to call specific commands with sudo you might want to add the '!authenticate' option to the related sudo rule to bypass all authentication?
bye, Sumit
Winfried
Op 27-11-18 om 13:47 schreef Sumit Bose:
On Tue, Nov 27, 2018 at 01:34:25PM +0100, Winfried de Heiden wrote: Hi all, I tried this as well, created a user for which otp and password is both allowe to enforce OTP login on certain hosts but sudo without otp: Enforcing 2FA for a host currently means enforcing it for all services which are handled by SSSD via PAM including sudo. bye, Sumit ipa user-show winfried User login: winfried First name: Winfried Last name: de Heiden Home directory: /home/winfried Login shell: /bin/bash Principal name: winfried@IPA.EXAMPLE.LOCAL Principal alias: winfried@IPA.EXAMPLE.LOCAL Email address: winfried@ipa.example.local UID: 100018 GID: 100018 User authentication types: password, otp Account disabled: False Password: True Member of groups: ipausers Member of Sudo rule: reboot Member of HBAC rule: freeipa-clientxx Kerberos keys available: True The host indeed will force otp upon login: [winfried@freeipa-client03 ~]$ ipa host-show $(hostname) Host name: freeipa-client03.ipa.example.local Principal name: host/freeipa-client03.ipa.example.local@IPA.EXAMPLE.LOCAL Principal alias: host/freeipa-client03.ipa.example.local@IPA.EXAMPLE.LOCAL SSH public key fingerprint: SHA256:a03P2T5BqumEXarmQlZxqD9VNIw6l9VTSXkhRp3wKo8 (ssh-rsa), SHA256:PlV7LeKRipRw5Fild77ENuazjUWhEIQbwxACegdj+34 (ecdsa-sha2-nistp256), SHA256:DiPQ/ EXr+w4ZSvCZBkdddGGYcJuITR64uIaMSbr0o0s (ssh-ed25519) Authentication Indicators: otp Password: False Member of Sudo rule: reboot Member of HBAC rule: freeipa-clientxx Keytab: True Managed by: freeipa-client03.ipa.example.local However, leaving the second empty, sudo will fail: sudo -l First Factor: Second Factor (optional): Sorry, try again. First Factor: Second Factor (optional): Sorry, try again. First Factor: Second Factor (optional): sudo: 3 incorrect password attempts Both IPA-server and client are running on CentOS 7.5. Op 23-03-18 om 09:32 schreef Sumit Bose via FreeIPA-users: On Thu, Mar 22, 2018 at 10:28:17AM -0700, Sean Hogan via FreeIPA-users wrote: Hello, We are implementing OTP for a new deployment and we can log in with the otp codes however when trying to sudo it fails. We would like to use the 2fa to log in but single factor is ok for sudo escalation. Is OTP supposed You have to allow on the server that the user can use both 1FA (password) or 2FA, see --user-auth-type option of 'ipa user-add'. To force 2FA at the log in you have to define on the server that the host requires the 'OTP' authentication indicator, see --auth-ind option of 'ipa host-mod' HTH bye, Sumit to be getting involved when issuing sudo commands? bob@ipa-client1$ sudo cat /etc/resolv.conf First Factor: Second Factor: Sorry, try again. First Factor: sudo: 1 incorrect password attempt ipa-server-dns-4.5.0-21.el7_4.2.2.noarch python-libipa_hbac-1.15.2-50.el7_4.6.x86_64 python-ipaddress-1.0.16-2.el7.noarch ipa-common-4.5.0-21.el7_4.2.2.noarch ipa-client-common-4.5.0-21.el7_4.2.2.noarch python2-ipalib-4.5.0-21.el7_4.2.2.noarch ipa-server-common-4.5.0-21.el7_4.2.2.noarch ipa-client-4.5.0-21.el7_4.2.2.x86_64 libipa_hbac-1.15.2-50.el7_4.6.x86_64 python2-ipaclient-4.5.0-21.el7_4.2.2.noarch python2-ipaserver-4.5.0-21.el7_4.2.2.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 python-iniparse-0.4-9.el7.noarch ipa-server-4.5.0-21.el7_4.2.2.x86_64 Sean Hogan _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Andrew Meyer -
Sean Hogan -
Sumit Bose -
Winfried de Heiden