Re: [Freeipa-users] freeipa / sudo
On 12/10/2014 04:54 PM, Chris Card wrote: On 12/10/2014 12:57 PM, Chris Card wrote: thanks Martin, I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine. I've set up a user with ssh keys, and can successfully ssh onto the client machine. I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run sudo su - on the client to become root. snip [root@fedora21-freeipa log]# ipa hostgroup-show Host-group: cog Host-group: cog Member hosts: ipaclient21.testdomain21.com Member of Sudo rule: All [root@fedora21-freeipa log]# ipa sudorule-show All Rule name: All Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: cog_rw Host Groups: cog Sudo Option: !authenticate but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something? Chris With FreeIPA 4.1.1, client sudo integration should be automatically configured, so it should just work, including hostgroups. In your case, I would start with investigating http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups If that does not help, I bet SSSD devs will ask for logs. I've done the troubleshooting steps: [root@ipaclient21 log]# nisdomainname testdomain21.com [root@ipaclient21 log]# getent netgroup cog cog (ipaclient21.testdomain21.com,-,testdomain21.com) I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before). I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages. I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line Debug sudo /var/log/sudo_debug all@debug and I saw this in the debug output: Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557 Dec 10 15:42:57 sudo[10046] val[0]=+cog Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked. The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :( So on the OpenStack instance, even hostname -f does not show the FQDN? If this is the case, I am not sure what we could do, sudo somehow needs to learn the FQDN. I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run hostname FQDN; unfortunately this doesn't survive a reboot. Chris -- 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] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally works! [How I did it...]
On 10.12.2014 20:20, Dmitri Pal wrote: On 12/10/2014 06:55 AM, Gianluca Cecchi wrote: On Tue, Dec 9, 2014 at 10:50 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 12/09/2014 12:50 AM, Gianluca Cecchi wrote: On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi gianluca.cec...@gmail.com mailto:gianluca.cec...@gmail.com wrote: OK. I will check requirements to write into The wiki Hello, now I was able to login and I created this draft page, you can check and feel free to review... http://www.freeipa.org/page/HowTo/vsphere5_integration I scanned the page. Looks good. Thanks a lot! I hope someone with the similar use case can verify the steps. Link to the how-to was added to: http://www.freeipa.org/page/HowTos#Virtualization -- 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] freeipa / sudo
On 12/11/2014 09:42 AM, Chris Card wrote: On 12/10/2014 04:54 PM, Chris Card wrote: On 12/10/2014 12:57 PM, Chris Card wrote: thanks Martin, I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine. I've set up a user with ssh keys, and can successfully ssh onto the client machine. I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run sudo su - on the client to become root. snip [root@fedora21-freeipa log]# ipa hostgroup-show Host-group: cog Host-group: cog Member hosts: ipaclient21.testdomain21.com Member of Sudo rule: All [root@fedora21-freeipa log]# ipa sudorule-show All Rule name: All Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: cog_rw Host Groups: cog Sudo Option: !authenticate but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something? Chris With FreeIPA 4.1.1, client sudo integration should be automatically configured, so it should just work, including hostgroups. In your case, I would start with investigating http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups If that does not help, I bet SSSD devs will ask for logs. I've done the troubleshooting steps: [root@ipaclient21 log]# nisdomainname testdomain21.com [root@ipaclient21 log]# getent netgroup cog cog (ipaclient21.testdomain21.com,-,testdomain21.com) I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before). I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages. I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line Debug sudo /var/log/sudo_debug all@debug and I saw this in the debug output: Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557 Dec 10 15:42:57 sudo[10046] val[0]=+cog Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked. The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :( So on the OpenStack instance, even hostname -f does not show the FQDN? If this is the case, I am not sure what we could do, sudo somehow needs to learn the FQDN. I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run hostname FQDN; unfortunately this doesn't survive a reboot. You should be able to just set the hostname to /etc/hostname (for older platforms, it may also be in /etc/sysconfig/network) and it should survive the reboot. I do not think that OpenStack really cares that much what hostname did you set up in the system after the VM is created. At least my OpenStack VM with the FreeIPA demo works this way. Martin -- 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] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally works! [How I did it...]
On Thu, Dec 11, 2014 at 10:19 AM, Petr Spacek pspa...@redhat.com wrote: Link to the how-to was added to: http://www.freeipa.org/page/HowTos#Virtualization -- Petr^2 Spacek thanks! Gianluca -- 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] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally works! [How I did it...]
On 12/10/2014 08:20 PM, Dmitri Pal wrote: On 12/10/2014 06:55 AM, Gianluca Cecchi wrote: On Tue, Dec 9, 2014 at 10:50 AM, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: On 12/09/2014 12:50 AM, Gianluca Cecchi wrote: On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi gianluca.cec...@gmail.com mailto:gianluca.cec...@gmail.com wrote: OK. I will check requirements to write into The wiki Hello, now I was able to login and I created this draft page, you can check and feel free to review... http://www.freeipa.org/page/HowTo/vsphere5_integration I scanned the page. Looks good. Thanks a lot! I hope someone with the similar use case can verify the steps. +1, thanks! I see the page is already linked from http://www.freeipa.org/page/HowTos#Virtualization so we are covered on that front. Martin -- 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] freeipa / sudo
On 12/11/2014 09:42 AM, Chris Card wrote: On 12/10/2014 04:54 PM, Chris Card wrote: On 12/10/2014 12:57 PM, Chris Card wrote: thanks Martin, I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine. I've set up a user with ssh keys, and can successfully ssh onto the client machine. I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run sudo su - on the client to become root. snip [root@fedora21-freeipa log]# ipa hostgroup-show Host-group: cog Host-group: cog Member hosts: ipaclient21.testdomain21.com Member of Sudo rule: All [root@fedora21-freeipa log]# ipa sudorule-show All Rule name: All Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: cog_rw Host Groups: cog Sudo Option: !authenticate but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something? Chris With FreeIPA 4.1.1, client sudo integration should be automatically configured, so it should just work, including hostgroups. In your case, I would start with investigating http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups If that does not help, I bet SSSD devs will ask for logs. I've done the troubleshooting steps: [root@ipaclient21 log]# nisdomainname testdomain21.com [root@ipaclient21 log]# getent netgroup cog cog (ipaclient21.testdomain21.com,-,testdomain21.com) I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before). I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages. I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line Debug sudo /var/log/sudo_debug all@debug and I saw this in the debug output: Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557 Dec 10 15:42:57 sudo[10046] val[0]=+cog Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked. The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :( So on the OpenStack instance, even hostname -f does not show the FQDN? If this is the case, I am not sure what we could do, sudo somehow needs to learn the FQDN. I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run hostname FQDN; unfortunately this doesn't survive a reboot. You should be able to just set the hostname to /etc/hostname (for older platforms, it may also be in /etc/sysconfig/network) and it should survive the reboot. I do not think that OpenStack really cares that much what hostname did you set up in the system after the VM is created. At least my OpenStack VM with the FreeIPA demo works this way. I found that simply editing /etc/hostname and rebooting didn't work, because cloud-init resets the hostname. But if I create the instance with a cloud-init script to set the hostname to the FQDN, and then reboot the instance after creation, /etc/hostname contains the FQDN and hostname returns the FQDN. Chris -- 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] freeipa / sudo
On 12/11/2014 01:57 PM, Chris Card wrote: On 12/11/2014 09:42 AM, Chris Card wrote: On 12/10/2014 04:54 PM, Chris Card wrote: On 12/10/2014 12:57 PM, Chris Card wrote: thanks Martin, I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine. I've set up a user with ssh keys, and can successfully ssh onto the client machine. I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run sudo su - on the client to become root. snip [root@fedora21-freeipa log]# ipa hostgroup-show Host-group: cog Host-group: cog Member hosts: ipaclient21.testdomain21.com Member of Sudo rule: All [root@fedora21-freeipa log]# ipa sudorule-show All Rule name: All Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: cog_rw Host Groups: cog Sudo Option: !authenticate but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something? Chris With FreeIPA 4.1.1, client sudo integration should be automatically configured, so it should just work, including hostgroups. In your case, I would start with investigating http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups If that does not help, I bet SSSD devs will ask for logs. I've done the troubleshooting steps: [root@ipaclient21 log]# nisdomainname testdomain21.com [root@ipaclient21 log]# getent netgroup cog cog (ipaclient21.testdomain21.com,-,testdomain21.com) I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before). I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages. I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line Debug sudo /var/log/sudo_debug all@debug and I saw this in the debug output: Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557 Dec 10 15:42:57 sudo[10046] val[0]=+cog Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked. The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :( So on the OpenStack instance, even hostname -f does not show the FQDN? If this is the case, I am not sure what we could do, sudo somehow needs to learn the FQDN. I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run hostname FQDN; unfortunately this doesn't survive a reboot. You should be able to just set the hostname to /etc/hostname (for older platforms, it may also be in /etc/sysconfig/network) and it should survive the reboot. I do not think that OpenStack really cares that much what hostname did you set up in the system after the VM is created. At least my OpenStack VM with the FreeIPA demo works this way. I found that simply editing /etc/hostname and rebooting didn't work, because cloud-init resets the hostname. But if I create the instance with a cloud-init script to set the hostname to the FQDN, and then reboot the instance after creation, /etc/hostname contains the FQDN and hostname returns the FQDN. Chris Ah, right. I just remembered I also need to set it up with cloud-init. This is the config I use for the FreeIPA demo: #cloud-config: FreeIPA cloud configuration hostname: ipa.demo1.freeipa.org fqdn: ipa.demo1.freeipa.org manage_etc_hosts: false -- 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] Unit pki-tomcatd@pki-tomcat.service entered failed state @ vanilla install on jessie – with log attached
Am Dienstag, 9. Dezember 2014, 23:52:08 schrieb chymian: Am Dienstag, 9. Dezember 2014, 09:49:04 schrieb Ade Lee: On Tue, 2014-12-09 at 13:54 +0100, chymian wrote: hey people, after a successful install of ipa 4.0.5-2 on jessie, the named services started flawless during setup. see attached log, Installation summary (line 3107) but after reboot, it refuses to start. (did this install a couple times, on vanilla jessie) I can reach work with Dogtag https://ipa.eb8.lan:8443/ca, but not the admin-services on https://ipa.eb8.lan/ca/ee/ca and https://ipa.eb8.lan/ca/agent/ca. $ systemctl status pki-tomcatd@pki-tomcat.service ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled) Active: failed (Result: resources) Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat... Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such file or directory Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd@pki-tomcat.service failed to run 'start-pre' task: No such file or directory Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server pki-tomcat. Dez 08 20:40:13 ipa systemd[1]: Unit pki-tomcatd@pki-tomcat.service entered failed state. Is dogtag actually running? ps -ef |grep java it shows: pkiuser676 1 0 13:25 ?00:00:26 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.proper ties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -DRESTEASY_LIB=/usr/share/java/ -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/var/lib/pki/pki-tomcat/bin/tomcat-jul i.jar -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp org.apache.catalina.startup.Bootstrap start is it ment to be, that the dogtag-pki package it’s self is not installed, just the dogtag-pki-server-theme is and a couple pki-packages… pki-base, pki-ca, pki-server, pki-tools? You could try restarting it - systemctl restart pki-tomcatd@pki-tomcat.service fails with same log-msg. The logs should be found in the journal -- journalctl -u pki-tomcatd@pki-tomcat.service same as above. Other debug logs should be found under /var/log/pki/pki-tomcat/. Please provide a tar of that directory. attached I am curious what the unit file looks like: On Fedora, its at /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@pki-tomcat.servi ce lrwxrwxrwx 1 pkiuser pkiuser 40 Dez 8 20:22 pki-tomcatd@pki-tomcat.service - /lib/systemd/system/pki-tomcatd@.service root@ipa /etc/systemd/system/pki-tomcatd.target.wants $ cat pki-tomcatd@pki-tomcat.service [Unit] Description=PKI Tomcat Server %i After=pki-tomcatd.target network.target PartOf=pki-tomcatd.target [Service] Type=simple EnvironmentFile=/etc/tomcat/tomcat.conf Environment=NAME=%i EnvironmentFile=-/etc/default/%i ExecStartPre=/usr/bin/pkidaemon start %i ExecStart=/usr/libexec/tomcat/server start ExecStop=/usr/libexec/tomcat/server stop SuccessExitStatus=143 User=pkiuser Group=pkiuser [Install] WantedBy=multi-user.target which points to an EnvironmentFile /etc/tomcat/tomcat.conf. Does that file exist? there is not even an dir. /etc/tomcat/, or rather a tomcat.conf in it. this is what was installed: ii libtomcat7-java 7.0.56-1 ii libtomcatjss-java7.1.1-2 ii tomcat7-common 7.0.56-1 ii tomcat7-user 7.0.56-1 and if I would install tomcat7, it would give me an /etc/tomcat7 – not a /etc/tomcat and, here on debian, there is no such dir. /usr/libexec. seems that the unitfile is more a centos one. but: systemctl status pki-tomcatd.service ● pki-tomcatd.service - LSB: Start pki-tomcatd at boot time Loaded: loaded (/etc/init.d/pki-tomcatd) Active: active (running) since Di 2014-12-09 13:25:12 CET; 10h ago CGroup: /user.slice/user-0.slice/session-5.scope/system.slice/pki-tomcatd.servic e └─676 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/log ging.properties -Djava.util.log... Dez 09 13:25:12 ipa pki-tomcatd[484]: . Dez 09 13:25:12 ipa systemd[1]: Started LSB: Start pki-tomcatd at boot time. which is started with a /etc/init.d/pki-tomcatd script, not systemd-unit-file – yet. Ade thx, guenter hello ade, what happens next? is there anything I can provide? should I open a bug with debian/freeIPA team? have a nice day, guenter -- 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] [Freeipa-interest] Announcing FreeIPA 4.1.2 - NEED HELP WITH 2FA/OTP!!!
On 12/11/2014 08:56 AM, Niranjan M.R wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/09/2014 11:14 PM, thierry bordaz wrote: On 12/09/2014 04:07 PM, thierry bordaz wrote: On 12/09/2014 11:15 AM, thierry bordaz wrote: On 12/09/2014 10:48 AM, Niranjan M.R wrote: On 12/09/2014 02:57 PM, thierry bordaz wrote: Hello, Niranjan, may I have access to your test machine. It's a vm on my laptop. I am trying to reproduce on another VM to which i can give access. I will provide the details of this VM as soon as possible. Mean while i am providing ns-slapd access logs, ipa-logs and pkispawn logs. Something curious is that the installer is waiting for DS to restart but it is looking like DS has not received the terminaison signal. 2014-12-09T09:37:49Z DEBUG Waiting for CA to start... ... 2014-12-09T09:42:45Z DEBUG Waiting for CA to start... [09/Dec/2014:04:37:41 -0500] - Warning: Adding configuration attribute nsslapd-security here we should expect a restart of DS First why DS did not receive the restart order and then as it is still running (DS looks idle) what does the install is waiting for. At the end of the CS configuration, the installer configure ssl DS, restart DS it and then reach the ldap to retrieve the CA status. It fails pki/pki-tomcat/localhost.2014-12-09.log Dec 09, 2014 4:37:49 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve. at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Its fails to reach DS because: 0.localhost-startStop-1 - [09/Dec/2014:04:37:49 EST] [8] [3] In Ldap (bound) connection pool to host port 636, Cannot connect to LDAP server. Error: netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) Having not been able to restart DS, the secure port is not enabled so the CA failure after 5min was normal. So the remaining question was why the DS service restart
Re: [Freeipa-users] freeipa / sudo
On 12/11/2014 08:08 AM, Martin Kosek wrote: On 12/11/2014 01:57 PM, Chris Card wrote: On 12/11/2014 09:42 AM, Chris Card wrote: On 12/10/2014 04:54 PM, Chris Card wrote: On 12/10/2014 12:57 PM, Chris Card wrote: thanks Martin, I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine. I've set up a user with ssh keys, and can successfully ssh onto the client machine. I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run sudo su - on the client to become root. snip [root@fedora21-freeipa log]# ipa hostgroup-show Host-group: cog Host-group: cog Member hosts: ipaclient21.testdomain21.com Member of Sudo rule: All [root@fedora21-freeipa log]# ipa sudorule-show All Rule name: All Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: cog_rw Host Groups: cog Sudo Option: !authenticate but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something? Chris With FreeIPA 4.1.1, client sudo integration should be automatically configured, so it should just work, including hostgroups. In your case, I would start with investigating http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups If that does not help, I bet SSSD devs will ask for logs. I've done the troubleshooting steps: [root@ipaclient21 log]# nisdomainname testdomain21.com [root@ipaclient21 log]# getent netgroup cog cog (ipaclient21.testdomain21.com,-,testdomain21.com) I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before). I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages. I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line Debug sudo /var/log/sudo_debug all@debug and I saw this in the debug output: Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557 Dec 10 15:42:57 sudo[10046] val[0]=+cog Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked. The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :( So on the OpenStack instance, even hostname -f does not show the FQDN? If this is the case, I am not sure what we could do, sudo somehow needs to learn the FQDN. I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run hostname FQDN; unfortunately this doesn't survive a reboot. You should be able to just set the hostname to /etc/hostname (for older platforms, it may also be in /etc/sysconfig/network) and it should survive the reboot. I do not think that OpenStack really cares that much what hostname did you set up in the system after the VM is created. At least my OpenStack VM with the FreeIPA demo works this way. I found that simply editing /etc/hostname and rebooting didn't work, because cloud-init resets the hostname. But if I create the instance with a cloud-init script to set the hostname to the FQDN, and then reboot the instance after creation, /etc/hostname contains the FQDN and hostname returns the FQDN. Chris Ah, right. I just remembered I also need to set it up with cloud-init. This is the config I use for the FreeIPA demo: #cloud-config: FreeIPA cloud configuration hostname: ipa.demo1.freeipa.org fqdn: ipa.demo1.freeipa.org manage_etc_hosts: false Is it worth a howto? Seems like a valuable piece of info... -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] Unit pki-tomcatd@pki-tomcat.service entered failed state @ vanilla install on jessie – with log attached
On Tue, 2014-12-09 at 23:52 +0100, chymian wrote: Am Dienstag, 9. Dezember 2014, 09:49:04 schrieb Ade Lee: On Tue, 2014-12-09 at 13:54 +0100, chymian wrote: hey people, after a successful install of ipa 4.0.5-2 on jessie, the named services started flawless during setup. see attached log, Installation summary (line 3107) but after reboot, it refuses to start. (did this install a couple times, on vanilla jessie) I can reach work with Dogtag https://ipa.eb8.lan:8443/ca, but not the admin-services on https://ipa.eb8.lan/ca/ee/ca and https://ipa.eb8.lan/ca/agent/ca. $ systemctl status pki-tomcatd@pki-tomcat.service ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled) Active: failed (Result: resources) Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat... Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such file or directory Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd@pki-tomcat.service failed to run 'start-pre' task: No such file or directory Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server pki-tomcat. Dez 08 20:40:13 ipa systemd[1]: Unit pki-tomcatd@pki-tomcat.service entered failed state. Is dogtag actually running? ps -ef |grep java it shows: pkiuser 676 1 0 13:25 ? 00:00:26 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -DRESTEASY_LIB=/usr/share/java/ -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/var/lib/pki/pki-tomcat/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp org.apache.catalina.startup.Bootstrap start is it ment to be, that the dogtag-pki package it’s self is not installed, just the dogtag-pki-server-theme is and a couple pki-packages… pki-base, pki-ca, pki-server, pki-tools? Ok, so as far as I can see, the dogtag CA is in fact up and operational. The systemctl error messages are probably a result of the systemd unit scripts not yet being used. We clearly see that the IPA RA and Jar signing certs are issued with no problems. I do notice a few attempts to reach the agent pages which result in failed authentication. My guess is that you are trying to access these pages using the browser and are not providing the agent cert. As you have the dogtag-pki-server-theme package installed, you should be able to reach the UI. But .. -- If you try to access the dogtag UI pages through port 80 and 443, then you are going through the apache instance for IPA. This instance talks to Dogtag on the back-end using AJP, and has a proxy configuration file that only permits certain URL paths to go through. -- If you want to access the Dogtag UI pages, you need to access https://host:8443/... or http://host:8080/... To access the agent pages, you need to import the IPA RA agent certificate into your browser (and trust the CA cert). That cert/key is in the IPA HTTP certdb. You will need to extract it from there as a p12 file and import it into your browser. Ade You could try restarting it - systemctl restart pki-tomcatd@pki-tomcat.service fails with same log-msg. The logs should be found in the journal -- journalctl -u pki-tomcatd@pki-tomcat.service same as above. Other debug logs should be found under /var/log/pki/pki-tomcat/. Please provide a tar of that directory. attached I am curious what the unit file looks like: On Fedora, its at /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@pki-tomcat.service lrwxrwxrwx 1 pkiuser pkiuser 40 Dez 8 20:22 pki-tomcatd@pki-tomcat.service - /lib/systemd/system/pki-tomcatd@.service root@ipa /etc/systemd/system/pki-tomcatd.target.wants $ cat pki-tomcatd@pki-tomcat.service [Unit] Description=PKI Tomcat Server %i After=pki-tomcatd.target network.target PartOf=pki-tomcatd.target [Service] Type=simple EnvironmentFile=/etc/tomcat/tomcat.conf Environment=NAME=%i EnvironmentFile=-/etc/default/%i ExecStartPre=/usr/bin/pkidaemon start %i ExecStart=/usr/libexec/tomcat/server start ExecStop=/usr/libexec/tomcat/server stop SuccessExitStatus=143 User=pkiuser Group=pkiuser [Install] WantedBy=multi-user.target which points to an EnvironmentFile /etc/tomcat/tomcat.conf. Does that file exist? there is not even an dir. /etc/tomcat/, or rather a tomcat.conf in it. this is what was installed: ii libtomcat7-java 7.0.56-1 ii libtomcatjss-java 7.1.1-2 ii tomcat7-common 7.0.56-1 ii
[Freeipa-users] Replica re-initialization
I have a cluster of four IPA masters that should be performing fully meshed replication. I discovered yesterday that a recently created user only existed on a single master. After looking through all four masters, it appears that several recent updates only exist on one of the masters. I do not see any replication errors in any of the logs, but I'm not 100% sure how far back this issue goes. I do believe the one master with up-to-date data is a reliable representation of what the LDAP directory should look like. I ran a reinitialize command (ipa-replica-manage re-initialize --from reliable-server.fqdn) on two of the out-of-date masters yesterday around 4pm EST. It's now a little after 12pm EST and the Update in progress message is still scrolling by once a second on both terminals. I'd greatly appreciate suggestions about a) how to determine the status of the reinitialize command and b) any other ideas about how to resolve this issue and monitor for it better in the future. Thanks in advance for your help! Thanks, Matt -- 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] Forest trust and AD child domain
Hello, We have been following the AD integration guide for IPAv3: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup Our setup is: • 2 domain controllers with Windows 2008 R2 AD DC - windows.com http://example.com/ as Forest Root Domain and acme.windows.com http://acme.example.com/ as transitive child domain • RHEL7 as IPA server with domain: linux.com http://linux.acme.example.com/ We have established a forest trust between windows.com and linux.com and everything seems OK from an IPA perspective. We can work with Kerberos tickets without any issue from “windows” domain or his child domain “acme”. (kinit, kvno…) When we use samba tools, the following command is working fine. *[root@support1 ]# wbinfo -n 'WINDOWS\Domain Admins'* *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)* But, the same command against the acme domain returns an error. *[root@support1 ]# wbinfo -n 'ACME\Domain Admins'* *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND* *Could not lookup name ACME\Domain Admins* Same problem with the following command: *[root@support1]# ipa group-add-member ad_users_external --external ACME\Domain Users* *[member user]:* *[member group]:* * Group name: ad_users_external* * Description: AD users external map* * External member: * * Member of groups: ad_users* * Failed members:* *member user:* *member group: ACME\Domain Users: Cannot find specified domain or server name* *-* *Number of members added 0* Any help would be appreciated Regards -- 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] Forest trust and AD child domain
On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote: Hello, We have been following the AD integration guide for IPAv3: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup Our setup is: • 2 domain controllers with Windows 2008 R2 AD DC - windows.com http://example.com/ as Forest Root Domain and acme.windows.com http://acme.example.com/ as transitive child domain • RHEL7 as IPA server with domain: linux.com http://linux.acme.example.com/ We have established a forest trust between windows.com and linux.com and everything seems OK from an IPA perspective. We can work with Kerberos tickets without any issue from “windows” domain or his child domain “acme”. (kinit, kvno…) When we use samba tools, the following command is working fine. *[root@support1 ]# wbinfo -n 'WINDOWS\Domain Admins'* *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)* But, the same command against the acme domain returns an error. *[root@support1 ]# wbinfo -n 'ACME\Domain Admins'* *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND* *Could not lookup name ACME\Domain Admins* Same problem with the following command: *[root@support1]# ipa group-add-member ad_users_external --external ACME\Domain Users* *[member user]:* *[member group]:* * Group name: ad_users_external* * Description: AD users external map* * External member: * * Member of groups: ad_users* * Failed members:* *member user:* *member group: ACME\Domain Users: Cannot find specified domain or server name* *-* *Number of members added 0* Any help would be appreciated Does ipa trustdomain-find windows.com show acme.windows.com as well ? Does ipa trust-fetch-domains ad.devel help to retrieve the child domain? Please note that if acme.windows.com now shows up you might have to wait 1-2 minutes until SSSD's negative caches are flushed and the new domains is discovered by SSSD, as an alternative you can just restart SSSD. HTH bye, Sumit Regards -- 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 -- 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] Host based 2FA ?
I'd like to be able to require 2FA on *certain* hosts and allow just passwords on others. It seems you can check both passwords and 2FA under the user. I was hoping I could create a HBAC such that certain hosts would only allow 2FA, but I can't see an obvious way to do that. Is it possible? Help on how would be great. If not, feature request? thanks, -t -- 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] Host based 2FA ?
On 12/11/2014 06:32 PM, free...@pettyvices.com wrote: I'd like to be able to require 2FA on *certain* hosts and allow just passwords on others. It seems you can check both passwords and 2FA under the user. I was hoping I could create a HBAC such that certain hosts would only allow 2FA, but I can't see an obvious way to do that. Is it possible? Help on how would be great. If not, feature request? thanks, -t We have several tickets: https://fedorahosted.org/freeipa/ticket/433 https://fedorahosted.org/freeipa/ticket/3659 https://fedorahosted.org/freeipa/ticket/4498 If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6 we discussed this use case. And I was about to fork it as said but then I realized that there is not good way on the KDC to determine the host you are coming from. So IMO it should be a policy decision on SSSD. There are two options: - short term solution: allow SSSD to have a local overwrite to require OTP if server offers different options. - longer term solution: actually have a per host policy that is centrally managed that is fetched per host and enforced by SSSD. Before filing tickets I would like to hear opinions on the matter. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] Forest trust and AD child domain
Hi Sumit, Thank you very much for the prompt reply [root@support1 ~]# ipa trustdomain-find windows.com Domain name: windows.com Domain NetBIOS name: WINDOWS Domain Security Identifier: S-1-5-21-1701591335-3855227394-3044674468 Domain enabled: True Domain name: acme.windows.com Domain NetBIOS name: ACME Domain Security Identifier: S-1-5-21-1215373191-1991333051-3772904882 Domain enabled: True Number of entries returned 2 [root@support1 ~]# ipa trust-fetch-domains windows.com --- No new trust domains were found --- Number of entries returned 0 Regards Le 11 déc. 2014 20:08, Sumit Bose sb...@redhat.com javascript:_e(%7B%7D,'cvml','sb...@redhat.com'); a écrit : On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote: Hello, We have been following the AD integration guide for IPAv3: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup Our setup is: • 2 domain controllers with Windows 2008 R2 AD DC - windows.com http://example.com/ as Forest Root Domain and acme.windows.com http://acme.example.com/ as transitive child domain • RHEL7 as IPA server with domain: linux.com http://linux.acme.example.com/ We have established a forest trust between windows.com and linux.com and everything seems OK from an IPA perspective. We can work with Kerberos tickets without any issue from “windows” domain or his child domain “acme”. (kinit, kvno…) When we use samba tools, the following command is working fine. *[root@support1 ]# wbinfo -n 'WINDOWS\Domain Admins'* *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)* But, the same command against the acme domain returns an error. *[root@support1 ]# wbinfo -n 'ACME\Domain Admins'* *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND* *Could not lookup name ACME\Domain Admins* Same problem with the following command: *[root@support1]# ipa group-add-member ad_users_external --external ACME\Domain Users* *[member user]:* *[member group]:* * Group name: ad_users_external* * Description: AD users external map* * External member: * * Member of groups: ad_users* * Failed members:* *member user:* *member group: ACME\Domain Users: Cannot find specified domain or server name* *-* *Number of members added 0* Any help would be appreciated Does ipa trustdomain-find windows.com show acme.windows.com as well ? Does ipa trust-fetch-domains ad.devel help to retrieve the child domain? Please note that if acme.windows.com now shows up you might have to wait 1-2 minutes until SSSD's negative caches are flushed and the new domains is discovered by SSSD, as an alternative you can just restart SSSD. HTH bye, Sumit Regards -- 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 -- 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 -- 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] Trusted Realm Across IPA Servers
Hi All, I have requirement to access the service under different IPA servers, can some one help me on this... IPA Servers are running on V3. -Eldo--- 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
