[Freeipa-users] AUTO: Christoph Kaminski is out of the office (Rückkehr am 03.08.2015)
Ich kehre zurück am 03.08.2015. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht Re: [Freeipa-users] Another Migration from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1) gesendet am 29.07.2015 17:25:15. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. -- 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] Another Migration from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1)
On (29/07/15 10:52), Guillermo Fuentes wrote: Thanks so much for the info David! We're using the latest version available via EPEL, which is 10.1.2. pki-core is not available in epel7 https://admin.fedoraproject.org/pkgdb/package/pki-core/ So you have the latest version from base CentOS 7.1 CentOS rebuild rhel packages. So you will need to wait for CentOS 7.2 for update. List, any idea where to grab pki 10.2.6 for CentOS 7? Source or binary would be fine. Or, if it isn't available, where can I start contributing to the port of pki 10.2.6 to CentOS 7? You might try to backport pki-core from Fedora. Good luck. LS -- 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] Is there any delay after applied rules to user?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! Thanks for the hints both of you, yes the sssd_cache is in play. I've set the cache to false, is it have any impact to ipa server/client (performance, security or another issue)? On 7/29/2015 21:39, Jakub Hrozek wrote: On Wed, Jul 29, 2015 at 04:32:42PM +0200, Martin Kosek wrote: On 07/29/2015 03:22 PM, Dewangga Bachrul Alam wrote: Hello! I'm using FreeIPA 4.1.x on CentOS 7, Is there any delay after applied some rules to specified user? [root@ipa ~]# ipa sudorule-show Rule name: wheel Rule name: Wheel Enabled: TRUE Host category: all Command category: all RunAs User category: all RunAs Group category: all Sudo order: 1 Users: dewangga User Groups: wheel Sudo Option: !authenticate On ipa-client, user `dewangga` asking for password when execute command `sudo -l` [dewangga@sherief-repository ~]$ sudo -l [sudo] password for dewangga: Here is `ipa user-show dewangga` result : $ ipa user-show dewangga User login: dewangga First name: Dewangga Last name: Alam Home directory: /home/dewangga Login shell: /bin/bash Email address: [removed] UID: 64201 GID: 64201 Account disabled: False Password: False Member of groups: wheel Member of Sudo rule: Wheel Kerberos keys available: False SSH public key fingerprint: [removed] mahaesa-key (ssh-rsa) Any helps are appreciated. Thanks I suspect that SSSD cache is in play. You can try to remove it (man sss_cache or remove it manually stop sssd, remove /var/lib/sss/db/* and start sssd again). I think restarting SSSD should help here. You can read the type of sudo refreshes sssd does in man sssd-sudo. If it doesn't, we need sssd logs. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVuOsyAAoJEF1+odKB6YIxN8YH+gLezNhWVzS8UDipFM7cBR5b xxj7M0rnkemHlvTVx5tzDkibTDzc3zLlcqX36EtdFWCp4N4uTvchnEbhzilcYW/T kRCAbLtHndhknx8U+eNrKw3EtrErSaDYjADboqqjyuiUfG7xaHwsomqje2F0PvFf c8wOkLxg1eLAZH3zTnZpHxW1PVx4Tdb+7RjwAEr4YFHoDhpe/k422H74ji2wPe3X 5MYJSbtxEra5qfDGsFN9nRKZkVPf/useSlBVH/mtonpT2YYTkdOIJqRaZw1xAG2V Dmuo4dIeZseKDg79easC2AeRtjckvjBo1NPJ4zfBtL8TJ9MZmpScOSh/zCF5miM= =cKjO -END PGP SIGNATURE- -- 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] ipa-dnskeysyncd exited on failure state
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I got many error message from ipa-dnskeysyncd. Here is the snippet from syslog http://fpaste.org/249594/20746714/raw Is it normal? I just restart the ipa server and its going back to normal again, but it come error on random times. Any debug log for this? I assume the error appears when I update to 4.1.4 from 4.1.0. IPA Environment: $ uname -a Linux ipa.mydomain.co.id 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ ipa --version VERSION: 4.1.4, API_VERSION: 2.114 [1] Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1229430 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVuVE3AAoJEF1+odKB6YIxBkYIALEqaRmaLvIrjMxVDejlnLIh +agqF9xVsAzBtA6ppJd5HZLNoS5QSicb0/ymi3jdH/qNnPO8OB/Id66/4FOYT1co D8gkNRheUOIjuQU834J5Gyuc5IMTOakfo4/gF5Zjp2wogmj3I4aCTLdJhG6TRDqs g2+rTIPQWs6GtbDS/vfuAYmJx8cz+Wt6NBgseGFshId3d6mEmUEv16XiSKulxeZs 2uqaGc967/XLQ7CXT8O8kfjDPFGejpqwQc9WNRLRqRbmLUy7Oz8h04QuBTdZLGwE Q4Wn2IPAyCGQ2nEOp/3jbl6OiJK9OBWiW3r9tmX3ZExndpTXJI5YQAW6etvHjsY= =OTU3 -END PGP SIGNATURE- -- 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] bind-dynamicdb TKEY update
Hello Jorgen,
Given you ask on this list, I assume you are asking if this CVE is fixed in
FreeIPA DNS feature which utilizes BIND.
The answer is - it depends :-) As the bug itself is in BIND, it depends if
the patch made it for given downstream platform. As for Fedora and/or RHEL, I
checked with the BIND maintainer and the fix is there, live.
You can check the tracking bug, which is now public:
https://bugzilla.redhat.com/show_bug.cgi?id=1247361
HTH,
Martin
On 07/29/2015 06:41 AM, Jorgen Lundman wrote:
Took a look at the diff while I was waiting:
diff -rub bind-9.9.7-P1/lib/dns/tkey.c bind-9.9.7-P2/lib/dns/tkey.c
--- bind-9.9.7-P1/lib/dns/tkey.c2015-06-18 07:48:03.0 +0900
+++ bind-9.9.7-P2/lib/dns/tkey.c2015-07-15 08:50:22.0 +0900
@@ -650,6 +650,7 @@
* Try the answer section, since that's where Win2000
* puts it.
*/
+ name = NULL;
if (dns_message_findname(msg, DNS_SECTION_ANSWER, qname,
dns_rdatatype_tkey, 0, name,
tkeyset) != ISC_R_SUCCESS) {
Sigh. All that work for one line. :)
Lund
Jorgen Lundman wrote:
Hola!
So with todays advisory: https://kb.isc.org/article/AA-01272
we finally get to test the procedure to patch and update here :)
Are there any plans for the dynamic_db github to pull in the fix, or should
I proceed with that step?
Sincerely,
Lund
--
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] Another Migration from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1)
Hi all,
We're also trying to migrate from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1).
Starting with FreeIPA 3.0 and to avoid the SSL certificate warning
when accessing the GUI, we installed a 3rd part certificate for https:
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
We're ready to migrate to FreeIPA 4.1 and we already have two 4.1
replicas but we're having problems cloning the CA from the 3.0 master.
This is our current environment:
master1 and master2:
CentOS 6.6 (up to date)
ipa-admintools-3.0.0-42.el6.centos.x86_64
ipa-server-3.0.0-42.el6.centos.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
libipa_hbac-1.11.6-30.el6_6.4.x86_64
device-mapper-multipath-0.4.9-80.el6_6.3.x86_64
ipa-client-3.0.0-42.el6.centos.x86_64
ipa-server-selinux-3.0.0-42.el6.centos.x86_64
ipa-python-3.0.0-42.el6.centos.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
sssd-ipa-1.11.6-30.el6_6.4.x86_64
pki-selinux-9.0.3-39.el6_6.noarch
pki-common-9.0.3-39.el6_6.noarch
pki-native-tools-9.0.3-39.el6_6.x86_64
pki-setup-9.0.3-39.el6_6.noarch
pki-util-9.0.3-39.el6_6.noarch
pki-symkey-9.0.3-39.el6_6.x86_64
pki-ca-9.0.3-39.el6_6.noarch
pki-java-tools-9.0.3-39.el6_6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
pki-silent-9.0.3-39.el6_6.noarch
replica1 and replica2:
CentOS 7.1 (up to date)
ipa-client-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-python-1.12.2-58.el7_1.6.x86_64
sssd-ipa-1.12.2-58.el7_1.6.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.1.0-18.el7.centos.3.x86_64
ipa-server-4.1.0-18.el7.centos.3.x86_64
ipa-python-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-1.12.2-58.el7_1.6.x86_64
pki-server-10.1.2-7.el7.noarch
krb5-pkinit-1.12.2-14.el7.x86_64
pki-base-10.1.2-7.el7.noarch
pki-ca-10.1.2-7.el7.noarch
pki-symkey-10.1.2-7.el7.x86_64
pki-tools-10.1.2-7.el7.x86_64
# ipa-replica-manage list
master1.example.com: master
master2.example.com: master
replica1.example.com: master
replica2.example.com.com: master
# ipa-csreplica-manage list
Directory Manager password:
replica1.example.com: CA not configured
master1.example.com: master
master2.example.com: master
replica2.example.com: CA not configured
When trying to install the CA on replica1 to do the migration:
ipa-ca-install --skip-conncheck --skip-schema-check
/var/lib/ipa/replica-info-replica1.example.com.gpg
we're getting the following error in the
/var/log/ipareplica-ca-install.log file:
...
2015-07-28T21:25:14Z DEBUG Saving StateFile to
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-07-28T21:25:14Z DEBUG Starting external process
2015-07-28T21:25:14Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
'/tmp/tmp2ON_ql'
2015-07-28T21:25:51Z DEBUG Process finished, return code=1
2015-07-28T21:25:51Z DEBUG stdout=Loading deployment configuration
from /tmp/tmp2ON_ql.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.
2015-07-28T21:25:51Z DEBUG
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:771:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
https://urllib3.readthedocs.org/en/latest/security.html
InsecureRequestWarning)
pkispawn: WARNING ... unable to validate security domain
user/password through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: Failed to obtain configuration entries from the master for
cloning java.io.IOException: Error: Not authorized
2015-07-28T21:25:51Z CRITICAL failed to configure ca instance Command
''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp2ON_ql'' returned
non-zero exit status 1
2015-07-28T21:25:51Z DEBUG Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 382, in start_creation
run_step(full_msg, method)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 372, in run_step
method()
File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 673, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
RuntimeError: Configuration of CA failed
...
From /var/log/pki/pki-ca-spawn.20150728172515.log:
...
2015-07-28 17:25:16 pkispawn: INFO ... executing 'certutil
-N -d /tmp/tmp-eUbMVB -f /root/.dogtag/pki-tomcat/ca/password.conf'
2015-07-28 17:25:16 pkispawn: INFO ... executing
'systemctl daemon-reload'
2015-07-28 17:25:16 pkispawn: INFO ... executing
'systemctl start pki-tomcatd@pki-tomcat.service'
2015-07-28 17:25:16 pkispawn: DEBUG... No connection -
server may still be down
2015-07-28 17:25:16 pkispawn: DEBUG... No connection -
exception thrown: ('Connection aborted.', error(111, 'Connection
refused'))
2015-07-28 17:25:17 pkispawn: DEBUG... No connection -
server may still be down
2015-07-28 17:25:17 pkispawn: DEBUG
Re: [Freeipa-users] Another Migration from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1)
On 29/07/15 01:47, Guillermo Fuentes wrote:
Hi all,
We're also trying to migrate from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1).
Starting with FreeIPA 3.0 and to avoid the SSL certificate warning
when accessing the GUI, we installed a 3rd part certificate for https:
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
We're ready to migrate to FreeIPA 4.1 and we already have two 4.1
replicas but we're having problems cloning the CA from the 3.0 master.
This is our current environment:
master1 and master2:
CentOS 6.6 (up to date)
ipa-admintools-3.0.0-42.el6.centos.x86_64
ipa-server-3.0.0-42.el6.centos.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
libipa_hbac-1.11.6-30.el6_6.4.x86_64
device-mapper-multipath-0.4.9-80.el6_6.3.x86_64
ipa-client-3.0.0-42.el6.centos.x86_64
ipa-server-selinux-3.0.0-42.el6.centos.x86_64
ipa-python-3.0.0-42.el6.centos.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
sssd-ipa-1.11.6-30.el6_6.4.x86_64
pki-selinux-9.0.3-39.el6_6.noarch
pki-common-9.0.3-39.el6_6.noarch
pki-native-tools-9.0.3-39.el6_6.x86_64
pki-setup-9.0.3-39.el6_6.noarch
pki-util-9.0.3-39.el6_6.noarch
pki-symkey-9.0.3-39.el6_6.x86_64
pki-ca-9.0.3-39.el6_6.noarch
pki-java-tools-9.0.3-39.el6_6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
pki-silent-9.0.3-39.el6_6.noarch
replica1 and replica2:
CentOS 7.1 (up to date)
ipa-client-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-python-1.12.2-58.el7_1.6.x86_64
sssd-ipa-1.12.2-58.el7_1.6.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.1.0-18.el7.centos.3.x86_64
ipa-server-4.1.0-18.el7.centos.3.x86_64
ipa-python-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-1.12.2-58.el7_1.6.x86_64
pki-server-10.1.2-7.el7.noarch
krb5-pkinit-1.12.2-14.el7.x86_64
pki-base-10.1.2-7.el7.noarch
pki-ca-10.1.2-7.el7.noarch
pki-symkey-10.1.2-7.el7.x86_64
pki-tools-10.1.2-7.el7.x86_64
# ipa-replica-manage list
master1.example.com: master
master2.example.com: master
replica1.example.com: master
replica2.example.com.com: master
# ipa-csreplica-manage list
Directory Manager password:
replica1.example.com: CA not configured
master1.example.com: master
master2.example.com: master
replica2.example.com: CA not configured
When trying to install the CA on replica1 to do the migration:
ipa-ca-install --skip-conncheck --skip-schema-check
/var/lib/ipa/replica-info-replica1.example.com.gpg
we're getting the following error in the
/var/log/ipareplica-ca-install.log file:
...
2015-07-28T21:25:14Z DEBUG Saving StateFile to
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-07-28T21:25:14Z DEBUG Starting external process
2015-07-28T21:25:14Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
'/tmp/tmp2ON_ql'
2015-07-28T21:25:51Z DEBUG Process finished, return code=1
2015-07-28T21:25:51Z DEBUG stdout=Loading deployment configuration
from /tmp/tmp2ON_ql.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.
2015-07-28T21:25:51Z DEBUG
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:771:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
https://urllib3.readthedocs.org/en/latest/security.html
InsecureRequestWarning)
pkispawn: WARNING ... unable to validate security domain
user/password through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: Failed to obtain configuration entries from the master for
cloning java.io.IOException: Error: Not authorized
2015-07-28T21:25:51Z CRITICAL failed to configure ca instance Command
''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp2ON_ql'' returned
non-zero exit status 1
2015-07-28T21:25:51Z DEBUG Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 382, in start_creation
run_step(full_msg, method)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 372, in run_step
method()
File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 673, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
RuntimeError: Configuration of CA failed
...
From /var/log/pki/pki-ca-spawn.20150728172515.log:
...
2015-07-28 17:25:16 pkispawn: INFO ... executing 'certutil
-N -d /tmp/tmp-eUbMVB -f /root/.dogtag/pki-tomcat/ca/password.conf'
2015-07-28 17:25:16 pkispawn: INFO ... executing
'systemctl daemon-reload'
2015-07-28 17:25:16 pkispawn: INFO ... executing
'systemctl start pki-tomcatd@pki-tomcat.service'
2015-07-28 17:25:16 pkispawn: DEBUG... No connection -
server may still be down
2015-07-28 17:25:16 pkispawn: DEBUG... No connection -
exception thrown: ('Connection aborted.', error(111, 'Connection
refused'))
2015-07-28 17:25:17 pkispawn: DEBUG... No connection -
server may
[Freeipa-users] Is there any delay after applied rules to user?
Hello! I'm using FreeIPA 4.1.x on CentOS 7, Is there any delay after applied some rules to specified user? [root@ipa ~]# ipa sudorule-show Rule name: wheel Rule name: Wheel Enabled: TRUE Host category: all Command category: all RunAs User category: all RunAs Group category: all Sudo order: 1 Users: dewangga User Groups: wheel Sudo Option: !authenticate On ipa-client, user `dewangga` asking for password when execute command `sudo -l` [dewangga@sherief-repository ~]$ sudo -l [sudo] password for dewangga: Here is `ipa user-show dewangga` result : $ ipa user-show dewangga User login: dewangga First name: Dewangga Last name: Alam Home directory: /home/dewangga Login shell: /bin/bash Email address: [removed] UID: 64201 GID: 64201 Account disabled: False Password: False Member of groups: wheel Member of Sudo rule: Wheel Kerberos keys available: False SSH public key fingerprint: [removed] mahaesa-key (ssh-rsa) Any helps are appreciated. Thanks -- 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] Another Migration from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1)
Thanks so much for the info David!
We're using the latest version available via EPEL, which is 10.1.2.
List, any idea where to grab pki 10.2.6 for CentOS 7? Source or binary
would be fine. Or, if it isn't available, where can I start
contributing to the port of pki 10.2.6 to CentOS 7?
Thanks!
Guillermo
On Wed, Jul 29, 2015 at 9:13 AM, David Kupka dku...@redhat.com wrote:
On 29/07/15 01:47, Guillermo Fuentes wrote:
Hi all,
We're also trying to migrate from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1).
Starting with FreeIPA 3.0 and to avoid the SSL certificate warning
when accessing the GUI, we installed a 3rd part certificate for https:
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
We're ready to migrate to FreeIPA 4.1 and we already have two 4.1
replicas but we're having problems cloning the CA from the 3.0 master.
This is our current environment:
master1 and master2:
CentOS 6.6 (up to date)
ipa-admintools-3.0.0-42.el6.centos.x86_64
ipa-server-3.0.0-42.el6.centos.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
libipa_hbac-1.11.6-30.el6_6.4.x86_64
device-mapper-multipath-0.4.9-80.el6_6.3.x86_64
ipa-client-3.0.0-42.el6.centos.x86_64
ipa-server-selinux-3.0.0-42.el6.centos.x86_64
ipa-python-3.0.0-42.el6.centos.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
sssd-ipa-1.11.6-30.el6_6.4.x86_64
pki-selinux-9.0.3-39.el6_6.noarch
pki-common-9.0.3-39.el6_6.noarch
pki-native-tools-9.0.3-39.el6_6.x86_64
pki-setup-9.0.3-39.el6_6.noarch
pki-util-9.0.3-39.el6_6.noarch
pki-symkey-9.0.3-39.el6_6.x86_64
pki-ca-9.0.3-39.el6_6.noarch
pki-java-tools-9.0.3-39.el6_6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
pki-silent-9.0.3-39.el6_6.noarch
replica1 and replica2:
CentOS 7.1 (up to date)
ipa-client-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-python-1.12.2-58.el7_1.6.x86_64
sssd-ipa-1.12.2-58.el7_1.6.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.1.0-18.el7.centos.3.x86_64
ipa-server-4.1.0-18.el7.centos.3.x86_64
ipa-python-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-1.12.2-58.el7_1.6.x86_64
pki-server-10.1.2-7.el7.noarch
krb5-pkinit-1.12.2-14.el7.x86_64
pki-base-10.1.2-7.el7.noarch
pki-ca-10.1.2-7.el7.noarch
pki-symkey-10.1.2-7.el7.x86_64
pki-tools-10.1.2-7.el7.x86_64
# ipa-replica-manage list
master1.example.com: master
master2.example.com: master
replica1.example.com: master
replica2.example.com.com: master
# ipa-csreplica-manage list
Directory Manager password:
replica1.example.com: CA not configured
master1.example.com: master
master2.example.com: master
replica2.example.com: CA not configured
When trying to install the CA on replica1 to do the migration:
ipa-ca-install --skip-conncheck --skip-schema-check
/var/lib/ipa/replica-info-replica1.example.com.gpg
we're getting the following error in the
/var/log/ipareplica-ca-install.log file:
...
2015-07-28T21:25:14Z DEBUG Saving StateFile to
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-07-28T21:25:14Z DEBUG Starting external process
2015-07-28T21:25:14Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
'/tmp/tmp2ON_ql'
2015-07-28T21:25:51Z DEBUG Process finished, return code=1
2015-07-28T21:25:51Z DEBUG stdout=Loading deployment configuration
from /tmp/tmp2ON_ql.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.
2015-07-28T21:25:51Z DEBUG
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:771:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
https://urllib3.readthedocs.org/en/latest/security.html
InsecureRequestWarning)
pkispawn: WARNING ... unable to validate security domain
user/password through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: Failed to obtain configuration entries from the master for
cloning java.io.IOException: Error: Not authorized
2015-07-28T21:25:51Z CRITICAL failed to configure ca instance Command
''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp2ON_ql'' returned
non-zero exit status 1
2015-07-28T21:25:51Z DEBUG Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 382, in start_creation
run_step(full_msg, method)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 372, in run_step
method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 673, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
RuntimeError: Configuration of CA failed
...
From /var/log/pki/pki-ca-spawn.20150728172515.log:
...
2015-07-28 17:25:16 pkispawn: INFO ... executing 'certutil
-N -d /tmp/tmp-eUbMVB -f /root/.dogtag/pki-tomcat/ca/password.conf'
2015-07-28 17:25:16 pkispawn: INFO
Re: [Freeipa-users] Is there any delay after applied rules to user?
On 07/29/2015 03:22 PM, Dewangga Bachrul Alam wrote: Hello! I'm using FreeIPA 4.1.x on CentOS 7, Is there any delay after applied some rules to specified user? [root@ipa ~]# ipa sudorule-show Rule name: wheel Rule name: Wheel Enabled: TRUE Host category: all Command category: all RunAs User category: all RunAs Group category: all Sudo order: 1 Users: dewangga User Groups: wheel Sudo Option: !authenticate On ipa-client, user `dewangga` asking for password when execute command `sudo -l` [dewangga@sherief-repository ~]$ sudo -l [sudo] password for dewangga: Here is `ipa user-show dewangga` result : $ ipa user-show dewangga User login: dewangga First name: Dewangga Last name: Alam Home directory: /home/dewangga Login shell: /bin/bash Email address: [removed] UID: 64201 GID: 64201 Account disabled: False Password: False Member of groups: wheel Member of Sudo rule: Wheel Kerberos keys available: False SSH public key fingerprint: [removed] mahaesa-key (ssh-rsa) Any helps are appreciated. Thanks I suspect that SSSD cache is in play. You can try to remove it (man sss_cache or remove it manually stop sssd, remove /var/lib/sss/db/* and start sssd again). -- 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] Is there any delay after applied rules to user?
On Wed, Jul 29, 2015 at 04:32:42PM +0200, Martin Kosek wrote: On 07/29/2015 03:22 PM, Dewangga Bachrul Alam wrote: Hello! I'm using FreeIPA 4.1.x on CentOS 7, Is there any delay after applied some rules to specified user? [root@ipa ~]# ipa sudorule-show Rule name: wheel Rule name: Wheel Enabled: TRUE Host category: all Command category: all RunAs User category: all RunAs Group category: all Sudo order: 1 Users: dewangga User Groups: wheel Sudo Option: !authenticate On ipa-client, user `dewangga` asking for password when execute command `sudo -l` [dewangga@sherief-repository ~]$ sudo -l [sudo] password for dewangga: Here is `ipa user-show dewangga` result : $ ipa user-show dewangga User login: dewangga First name: Dewangga Last name: Alam Home directory: /home/dewangga Login shell: /bin/bash Email address: [removed] UID: 64201 GID: 64201 Account disabled: False Password: False Member of groups: wheel Member of Sudo rule: Wheel Kerberos keys available: False SSH public key fingerprint: [removed] mahaesa-key (ssh-rsa) Any helps are appreciated. Thanks I suspect that SSSD cache is in play. You can try to remove it (man sss_cache or remove it manually stop sssd, remove /var/lib/sss/db/* and start sssd again). I think restarting SSSD should help here. You can read the type of sudo refreshes sssd does in man sssd-sudo. If it doesn't, we need sssd logs. -- 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] expired password reset issue
Hey All, Apologies in advance for the long email. I am having an issue with password resets via sshd and usermin. I think if I can get the sshd working again the usermin side will fall into place again. This used to work about a week or two ago, but I'm not sure what changed to break it. A new kernel update from RH was applied but even if I boot to the old kernel the issue persists. Attempts to connect over ssh (or anywhere else allowed by HBAC policy) works great except for users with expired passwords. When the client server tries to reset the password it fails. I was able to get the password change to succeed by setting the sshd to ChallengeResponse yes which seems very strange to me. Everything was run with setenforce 0 to make sure there was no issues from selinux. If anyone has any ideas on what I could try as a next step it would be greatly appreciated! V/r, David auth is the freeipa server while webserver is the server acting as the client, both are RHEL6.6 Client Server versions: ipa-client.x86_64 3.0.0-42.el6 ipa-python.x86_64 3.0.0-42.el6 libipa_hbac.x86_641.11.6-30.el6_6.4 libipa_hbac-python.x86_64 1.11.6-30.el6_6.4 python-iniparse.noarch0.3.1-2.1.el6 sssd-ipa.x86_64 1.11.6-30.el6_6.4 IPA Server versions: ipa-admintools.x86_64 3.0.0-42.el6 ipa-client.x86_64 3.0.0-42.el6 ipa-pki-ca-theme.noarch 9.0.3-7.el6 ipa-pki-common-theme.noarch 9.0.3-7.el6 ipa-python.x86_64 3.0.0-42.el6 ipa-server.x86_64 3.0.0-42.el6 ipa-server-selinux.x86_64 3.0.0-42.el6 libipa_hbac.x86_641.11.6-30.el6_6.4 libipa_hbac-python.x86_64 1.11.6-30.el6_6.4 python-iniparse.noarch0.3.1-2.1.el6 sssd-ipa.x86_64 1.11.6-30.el6_6.4 My sshd pam file on the client server: [root@webserver pam.d]# cat sshd | grep -v ^# auth requiredpam_sepermit.so auth include password-auth accountrequired pam_nologin.so accountinclude password-auth password include password-auth sessionrequired pam_selinux.so close sessionrequired pam_loginuid.so sessionrequired pam_selinux.so open env_params sessionoptional pam_keyinit.so force revoke sessioninclude password-auth My password-auth on the client server: [root@webserver pam.d]# cat password-auth | grep -v ^# auth required pam_env.so auth sufficient pam_sss.so auth sufficient pam_unix.so try_first_pass auth required pam_deny.so account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_unix.so account required pam_permit.so password required pam_cracklib.so retry=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=3 maxrepeat=3 password sufficient pam_sss.so use_authtok password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok remember=24 password required pam_deny.so session optional pam_sss.so session required pam_unix.so Attempting to ssh in first with ChallengeResponse set to no, then yes [root@auth /]# ssh dummy@192.168.1.6 dummy@192.168.1.6's password: Password expired. Change your password now. Last login: Wed Jul 29 09:08:13 2015 from auth.mydomain.com WARNING: Your password has expired. You must change your password now and login again! Changing password for user dummy. Current Password: New password: Retype new password: passwd: Authentication token manipulation error Connection to 192.168.1.6 closed. [root@auth /]# ssh dummy@192.168.1.6 Password: Password expired. Change your password now. Current Password: New password: Retype new password: Last login: Wed Jul 29 09:11:19 2015 from auth.mydomain.com [dummy@webserver ~]$ /var/log/secure record of the activity: Jul 29 09:11:19 webserver sshd[26823]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=auth.mydomain.com user=dummy Jul 29 09:11:19 webserver sshd[26823]: pam_sss(sshd:auth): received for user dummy: 12 (Authentication token is no longer valid; new one required) Jul 29 09:11:19 webserver sshd[26823]: pam_sss(sshd:account): User info message: Password expired. Change your password now. Jul 29 09:11:19 webserver sshd[26823]: Accepted password for dummy from 192.168.1.5 port 43656 ssh2 Jul 29 09:11:19 webserver sshd[26823]: pam_unix(sshd:session): session opened for user dummy by (uid=0) Jul 29 09:11:28 webserver passwd: pam_sss(passwd:chauthtok): Password change failed for user dummy: 15 (Authentication service cannot retrieve user credentials) Jul 29 09:11:38 webserver passwd: pam_unix(passwd:chauthtok): user dummy does not exist in /etc/passwd Jul 29 09:11:39 webserver sshd[26823]: pam_unix(sshd:session): session closed for user dummy Jul 29 09:12:01 webserver crond[26836]: pam_unix(crond:session): session opened for user root by (uid=0) Jul 29 09:12:01
