Re: [Freeipa-users] RHEL 7 Upgrade experience so far
I have been following this thread with great interest, as I have
encountered similar problems with our migration from 3.0.0-37 on CentOS
6.5 to 3.3.3-28 on CentOS 7. I have been able to solve a few of them
with manual patching, but there is still something going on that will
make the CA replication to fail.
The following changes have been made to the environments:
- On the replica,
/usr/lib/python2.7/site-packages/ipaserver/install/replication.py has
been patched to handle multiple values of nsDS5ReplicaId on the master.
- /usr/share/ipa/html/ca.crt used to contain our local root certificate
as well as the IPA CA-certificate, which caused the replica installation
to fail. The root certificate was removed from this file, the replica
gpg-bundle recreated, and the installation would happily continue.
- /etc/httpd/conf.d/ipa-pki-proxy.conf has been patched to contain the
profileSubmit-patch to the ee port-line
LocationMatch
^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL|^/ca/ee/ca/profileSubmit
and have also tried with and without the additions to the admin port and
installer-line
LocationMatch
^/ca/admin/ca/getCertChain|^/ca/admin/ca/getConfigEntries|^/ca/admin/ca/getCookie|^/ca/admin/ca/getStatus|^/ca/admin/ca/securityDomainLogin|^/ca/admin/ca/getDomainXML|^/ca/rest/installer/installToken|^/ca/admin/ca/updateNumberRange|^/ca/rest/securityDomain/domainInfo|^/ca/rest/account/login|^/ca/admin/ca/tokenAuthenticate|^/ca/admin/ca/updateNumberRange|^/ca/admin/ca/updateDomainXML|^/ca/rest/account/logout|^/ca/rest/securityDomain/installToken
Checking the log files on the 3.3.3 replica, there are a few error
messages, which I am not sure how to resolve.
/var/log/ipareplica-install.log ends with the following lines:
2014-08-27T14:44:15Z DEBUG Starting external process
2014-08-27T14:44:15Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpxkixl8
2014-08-27T14:45:19Z DEBUG Process finished, return code=1
2014-08-27T14:45:19Z DEBUG stdout=Loading deployment configuration from
/tmp/tmpxkixl8.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.
2014-08-27T14:45:19Z DEBUG stderr=pkispawn: WARNING ... unable
to validate security domain user/password through REST interface.
Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: Error while updating security domain: java.io.IOException: 2
2014-08-27T14:45:19Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpxkixl8' returned non-zero exit status 1
2014-08-27T14:45:19Z DEBUG File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 638, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 667, in main
CA = cainstance.install_replica_ca(config)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
1678, in install_replica_ca
subject_base=config.subject_base)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
478, in configure_instance
self.start_creation(runtime=210)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 364, in start_creation
method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
2014-08-27T14:45:19Z DEBUG The ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed
/var/log/pki/pki-ca-spawn.20140827164415.log reveals these error messages:
2014-08-27 16:44:16 pkispawn: INFO ... executing 'systemctl
start pki-tomcatd@pki-tomcat.service'
2014-08-27 16:44:18 pkispawn: DEBUG... No connection -
server may still be down
2014-08-27 16:44:18 pkispawn: DEBUG... No connection -
exception thrown: [Errno 111] Connection refused
2014-08-27 16:44:26 pkispawn: DEBUG... ?xml
version=1.0 encoding=UTF-8
standalone=no?XMLResponseState0/StateTypeCA/TypeStatusrunning/StatusVersion10.0.5-3.el7/Version/XMLResponse
2014-08-27 16:44:27 pkispawn: INFO ... constructing PKI
configuration data.
2014-08-27 16:44:27 pkispawn: INFO ... configuring PKI
configuration data.
2014-08-27 16:45:19 pkispawn: ERROR... Exception from Java
Configuration Servlet: Error while updating security domain:
java.io.IOException: 2
2014-08-27 16:45:19 pkispawn: DEBUG... Error Type: HTTPError
2014-08-27 16:45:19 pkispawn: DEBUG... Error Message: 500
Server Error: Internal Server Error
2014-08-27 16:45:19 pkispawn: DEBUG... File
/usr/sbin/pkispawn, line 374, in main
rv = instance.spawn()
File
/usr/lib/python2.7/site-packages/pki/deployment/configuration.py, line
128, in
[Freeipa-users] ipa-server (v3.3.3) with sssd (v1.11.2) config
Hi, In a setup where FreeIPA + sssd act as an authentication for AD users (taking advantage of sssd's ability to act as an authentication client for AD users), why do we need to establish a (two-way) trust relationship? Ins't there a workaround for this, given that sssd is already able to authenticate users without having to do nothing on the DA-side (just need a read-only user to carry out the initial bind)? In a bit more detail: We'd like to use AD-based authentication on some Unix hosts (mostly Solaris 10) for which there's no sssd available (we're already using sssd on RHEL hosts); we were thinking of setting up a server with FreeIPA + sssd to act as sort of a proxy to the actual AD for authentication, for those hosts for which there's no sssd client available (based on this doc: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts). There reasons why we're doing this are basically: · there's no unix-compatibiliy available on the AD sever (and most likely there won't ever be) · we'd like to keep the same UID/GIDs for all users that already authenticate on the RHEL boxes (to be able to work on the same home directories, maintain homogenous file ownership accross shared ressources, etc.) So, we've set up: · a CentOS 7.0 host with ipa-server v3.3.3 and sssd v1.11.2 and configured (with domain: ipa-dom.com) · checked that sssd-based authenticacion to the AD server works on this box (AD-users in domain da-dom.com) · checked that the IPA server works for users created on the IPA server (domain e.g. u...@ipa-dom.com) Now, to set up what we really wanted, which is basically, on a Unix-box with no sssd client, be able to authentica a us...@da-dom.com via the FreeIPA-server, through sssd. But, the final step of the configuration process (cmd: ipa trust-add ...) requires to establish a two-way trust relationship between the IPA server and the AD DC, which requires AD administrator privileges (which we don't have, and I don't see why we should have them). The AD admins of the company are not willing to consider this trust relationship to be established because the regard this as a secury risk. My question is basically, isn't there a workaround for this situation? If sssd is already able to authenticate, and based on the explanations of the doc mentioned above, I can't see why for plaiin user authentication there must be a trust relationship established. We don't need that for any of our sssd-based hosts (and they haven't been added to the domain da-dom.com, no need to). Any suggestions? Maybe there are different setups and/or tool combinations for a this kind of scenario? Thanks a lot, -- *Gerardo Padierna*mailto:asl.gera...@gmail.com -- 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] ipa-server (v3.3.3) with sssd (v1.11.2) config
On 08/28/2014 12:08 PM, Gerardo Padierna wrote: Hi, In a setup where FreeIPA + sssd act as an authentication for AD users (taking advantage of sssd's ability to act as an authentication client for AD users), why do we need to establish a (two-way) trust relationship? Ins't there a workaround for this, given that sssd is already able to authenticate users without having to do nothing on the DA-side (just need a read-only user to carry out the initial bind)? In a bit more detail: We'd like to use AD-based authentication on some Unix hosts (mostly Solaris 10) for which there's no sssd available (we're already using sssd on RHEL hosts); we were thinking of setting up a server with FreeIPA + sssd to act as sort of a proxy to the actual AD for authentication, for those hosts for which there's no sssd client available (based on this doc: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts). There reasons why we're doing this are basically: · there's no unix-compatibiliy available on the AD sever (and most likely there won't ever be) · we'd like to keep the same UID/GIDs for all users that already authenticate on the RHEL boxes (to be able to work on the same home directories, maintain homogenous file ownership accross shared ressources, etc.) So, we've set up: · a CentOS 7.0 host with ipa-server v3.3.3 and sssd v1.11.2 and configured (with domain: ipa-dom.com) · checked that sssd-based authenticacion to the AD server works on this box (AD-users in domain da-dom.com) · checked that the IPA server works for users created on the IPA server (domain e.g. u...@ipa-dom.com) Now, to set up what we really wanted, which is basically, on a Unix-box with no sssd client, be able to authentica a us...@da-dom.com via the FreeIPA-server, through sssd. But, the final step of the configuration process (cmd: ipa trust-add ...) requires to establish a two-way trust relationship between the IPA server and the AD DC, which requires AD administrator privileges (which we don't have, and I don't see why we should have them). The AD admins of the company are not willing to consider this trust relationship to be established because the regard this as a secury risk. My question is basically, isn't there a workaround for this situation? If sssd is already able to authenticate, and based on the explanations of the doc mentioned above, I can't see why for plaiin user authentication there must be a trust relationship established. We don't need that for any of our sssd-based hosts (and they haven't been added to the domain da-dom.com, no need to). Any suggestions? Maybe there are different setups and/or tool combinations for a this kind of scenario? Thanks a lot, -- *Gerardo Padierna* Will one way trust be acceptable by AD admins? Is there more prejudice to IdM connecting to AD in general or one way trust when IPA trusts AD but not the other way around is OK? It will still require admin privileges to establish the trust. There is already work going on to make the trust be one way by default since there is some confusion about it. Trusts are needed for Kerberos to be able to forward tickets and do SSO. Without trusts you can do only basic proxy setup which can be done with a DS server and PAM proxy plugin - a non goal for IPA. -- 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] How to use sudo rules on ubuntu
Hi, I try to apply sudo policies on ubuntu client. Is there any examples how to apply it? Regards... -- br img src=http://www.yasar.com.tr/banner/yhbanner.jpg; /img brbr Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -- 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] How to use sudo rules on ubuntu
On Thu, Aug 28, 2014 at 02:15:43PM +0300, Tevfik Ceydeliler wrote: Hi, I try to apply sudo policies on ubuntu client. Is there any examples how to apply it? Regards... Depends on your sssd and sudo versions but in general I don't think there are any Ubuntu-specific issues. As long as you have sssd 1.9+ and sudo 1.8+ you should be good. -- 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] Password expiration dates are different when being resetted by the (primary) admin and a different admin
Hi, I'm trying to change a user password without reset. If I use the (primary) admin to change the password then it doesn't need a password reset, because the expire lifetime is 90 days. But if I create a second admin, then every password change made by the second admin needs a password reset, because the password is expired immediately. 1a) Does anyone knows how I can change the policy/privilege of the second admin so every password change doesn't require a reset? 1b) and is it possible to set a different expire lifetime like zero for unlimited lifetime? It's almost the same bugreport as https://fedorahosted.org/freeipa/ticket/2795 but the difference is there should be 2 policies: one for changing your own password and another for resetting other users password. 2) Are there more differences in policies between the first (primary) admin and the second admin you just created? Kind regards, Zip -- 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] Password expiration dates are different when being resetted by the (primary) admin and a different admin
On 08/28/2014 04:18 PM, Zip Ly wrote: Hi, I'm trying to change a user password without reset. If I use the (primary) admin to change the password then it doesn't need a password reset, because the expire lifetime is 90 days. This is strange. Did you by any chance added this admin's account DN to passSyncManagersDNs setting in ipa_pwd_extop plugin? http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/pass-sync.html#password-sync But if I create a second admin, then every password change made by the second admin needs a password reset, because the password is expired immediately. Right, this is done on purpose: http://www.freeipa.org/page/New_Passwords_Expired 1a) Does anyone knows how I can change the policy/privilege of the second admin so every password change doesn't require a reset? See docs link above. But note it is a hack and we discourage it for reasons written in the wiki link above. 1b) and is it possible to set a different expire lifetime like zero for unlimited lifetime? No (for security reasons). It's almost the same bugreport as https://fedorahosted.org/freeipa/ticket/2795 but the difference is there should be 2 policies: one for changing your own password and another for resetting other users password. Administrative password change is only subject to max password life time part of the password policy AFAIR. Thus it already uses 2 different standards for these password changes (e.g. password length is not enforced for administrative password change). 2) Are there more differences in policies between the first (primary) admin and the second admin you just created? There should not be. All members of admins groups should be equal in rights. 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] Password expiration dates are different when being resetted by the (primary) admin and a different admin
1a) has come up before: https://www.redhat.com/archives/freeipa-users/2014-February/msg00313.html 1b) We handled this by setting the expire lifetime to a very large value (20 years) for members of a certain group. 2) I’m not sure. Kind regards, Will Sheldon +1.778-689-1244 On August 28, 2014 at 7:26:03 AM, Zip Ly (zip...@gmail.com) wrote: Hi, I'm trying to change a user password without reset. If I use the (primary) admin to change the password then it doesn't need a password reset, because the expire lifetime is 90 days. But if I create a second admin, then every password change made by the second admin needs a password reset, because the password is expired immediately. 1a) Does anyone knows how I can change the policy/privilege of the second admin so every password change doesn't require a reset? 1b) and is it possible to set a different expire lifetime like zero for unlimited lifetime? It's almost the same bugreport as https://fedorahosted.org/freeipa/ticket/2795 but the difference is there should be 2 policies: one for changing your own password and another for resetting other users password. 2) Are there more differences in policies between the first (primary) admin and the second admin you just created? Kind regards, Zip -- 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] Disable Password Policy?
We are going to use a SSO provider like OneLogin to enforce a password policy how can we disable FreeIPA from doing it also? -- 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] Disable Password Policy?
On 08/28/2014 04:56 PM, Chris Whittle wrote: We are going to use a SSO provider like OneLogin to enforce a password policy how can we disable FreeIPA from doing it also? I do not think you can. You can make IPA policy less restrictive then it would just not apply. -- 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] Password expiration dates are different when being resetted by the (primary) admin and a different admin
On 08/28/2014 04:18 PM, Zip Ly wrote: Hi, I'm trying to change a user password without reset. If I use the (primary) admin to change the password then it doesn't need a password reset, because the expire lifetime is 90 days. But if I create a second admin, then every password change made by the second admin needs a password reset, because the password is expired immediately. 1a) Does anyone knows how I can change the policy/privilege of the second admin so every password change doesn't require a reset? 1b) and is it possible to set a different expire lifetime like zero for unlimited lifetime? You are probably changing password for the admin himself. Isn't there a different flow when admin changes his own password? It's almost the same bugreport as https://fedorahosted.org/freeipa/ticket/2795 but the difference is there should be 2 policies: one for changing your own password and another for resetting other users password. 2) Are there more differences in policies between the first (primary) admin and the second admin you just created? Kind regards, Zip -- 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
