Re: [Freeipa-users] 3 way IPA setup
Steven Jones wrote: > Hi, > > I have a 3 way IPA 4.2 setup running on Centos7.2 > > > So ipa2 and ipa3 are replicas from ipa1. > > > Is a replication agreement setup between 2 and 3 automatically by > default? (I suspect not) how do I see this is or is not the case? > > > This is what I have so far, > > > == > > [root@glusterp2 ~]# ipa-replica-manage -v list > Directory Manager password: > > glusterp2.ods.graywitch.co.nz: master > glusterp3.ods.graywitch.co.nz: master > glusterp1.ods.graywitch.co.nz: master > [root@glusterp2 ~]# > === > > [root@glusterp3 ~]# ipa-replica-manage -v list > Directory Manager password: > > glusterp2.ods.graywitch.co.nz: master > glusterp3.ods.graywitch.co.nz: master > glusterp1.ods.graywitch.co.nz: master > [root@glusterp3 ~]# > == > > > If not, how do I set this up as I cant find any documentation on how. Re-run those with `hostname` appended and you'll see the replication agreements and their status (though in your case you just want to see who is talking to who). rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] 3 way IPA setup
Hi, I have a 3 way IPA 4.2 setup running on Centos7.2 So ipa2 and ipa3 are replicas from ipa1. Is a replication agreement setup between 2 and 3 automatically by default? (I suspect not) how do I see this is or is not the case? This is what I have so far, == [root@glusterp2 ~]# ipa-replica-manage -v list Directory Manager password: glusterp2.ods.graywitch.co.nz: master glusterp3.ods.graywitch.co.nz: master glusterp1.ods.graywitch.co.nz: master [root@glusterp2 ~]# === [root@glusterp3 ~]# ipa-replica-manage -v list Directory Manager password: glusterp2.ods.graywitch.co.nz: master glusterp3.ods.graywitch.co.nz: master glusterp1.ods.graywitch.co.nz: master [root@glusterp3 ~]# == If not, how do I set this up as I cant find any documentation on how. thanks regards Steven -- 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] SSH as Root on CentOS 7 fails
Hello, I’m unable to ssh as ‘root’ onto any of my new CentOS 7 hosts. I’ve always been able to do so on CentOS6.x We normally have the file ‘/root/.k5login’ listing the designated system admins’ principals. Once on a CentOS 7, an admin can ‘ksu’ and become root as we expected. We are using puppet and Foreman to build our hosts so they are in every way we can think of, identical, except for the O/s version. I’ve confirmed forward and reverse DNS and that the ‘kvno’ number matches what’s reported by ‘klist -k’. I enabled "LogLevel DEBUG” in sshd_config and restarted sshd on a CentOS7 host: Oct 31 19:22:36 someserver sshd[12378]: debug1: userauth-request for user testuser service ssh-connection method none [preauth] Oct 31 19:22:36 someserver sshd[12378]: debug1: attempt 0 failures 0 [preauth] Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: initializing for "testuser" Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: setting PAM_RHOST to "someserver.test.com" Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: setting PAM_TTY to "ssh" Oct 31 19:22:36 someserver sshd[12378]: debug1: userauth-request for user testuser service ssh-connection method gssapi-with-mic [preauth] Oct 31 19:22:36 someserver sshd[12378]: debug1: attempt 1 failures 0 [preauth] Oct 31 19:22:36 someserver sshd[12378]: Postponed gssapi-with-mic for testuser from 10.0.0.55 port 36383 ssh2 [preauth] Oct 31 19:22:36 someserver sshd[12378]: debug1: Received some client credentials Oct 31 19:22:36 someserver sshd[12378]: Authorized to testuser, krb5 principal testu...@test.com (ssh_gssapi_krb5_cmdok) Oct 31 19:35:42 someserver sshd[12409]: debug1: userauth-request for user root service ssh-connection method none [preauth] Oct 31 19:35:42 someserver sshd[12409]: debug1: attempt 0 failures 0 [preauth] Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: initializing for "root" Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: setting PAM_RHOST to "someserver.test.com" Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: setting PAM_TTY to "ssh" Oct 31 19:35:42 someserver sshd[12409]: debug1: userauth-request for user root service ssh-connection method gssapi-with-mic [preauth] Oct 31 19:35:42 someserver sshd[12409]: debug1: attempt 1 failures 0 [preauth] Oct 31 19:35:42 someserver sshd[12409]: Postponed gssapi-with-mic for root from 10.0.0.55 port 36384 ssh2 [preauth] Oct 31 19:35:42 someserver sshd[12409]: debug1: Received some client credentials Oct 31 19:35:42 someserver sshd[12409]: Failed gssapi-with-mic for root from 10.0.0.55 port 36384 ssh2 ... Oct 31 19:35:42 someserver sshd[12577]: debug1: userauth-request for user root service ssh-connection method gssapi-with-mic [preauth] Oct 31 19:35:42 someserver sshd[12577]: debug1: attempt 4 failures 1 [preauth] Appreciate any thoughts or suggestions you have. Yours, Geordie Grindle -- 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] Setting "preserve" as default action when deleting in webUI
Hello Sebastien,
I tried your plugin and it works correctly. Default value is Preserve
with your plugin. Did you copy your plugin into
/var/share/ipa/ui/js/plugins/plugin_name/plugin_name.js ? That should be
enough.
On 10/28/2016 12:14 AM, Sebastien Julliot wrote:
Hello guys,
Thank you for your answers. First, I was able to modify the minified js
to change the default. Ugly solution, but it works for now.
I am trying to write a plugin but it seems that I missed something here
since, despite being executed, the default is not changed ..
Here is my code, freely inspired of what I think I understood of your
'association_search_fix.js' example:
define([
'freeipa/ipa',
'freeipa/user',
],
function(IPA, user) {
exp = {};
exp.orig_create_active_user_del_dialog = IPA.user.create_active_user_del_dialog;
IPA.user.create_active_user_del_dialog = function(dialog) {
dialog.deleter_dialog_create_content();
dialog.option_layout = IPA.fluid_layout({
label_cls: 'col-sm-3',
widget_cls: 'col-sm-9'
});
dialog.option_radio = IPA.radio_widget({
name: 'preserve',
label: '@i18n:objects.user.delete_mode',
options: [
{ label: '@i18n:objects.user.mode_delete', value: 'false' },
{ label: '@i18n:objects.user.mode_preserve', value: 'true' }
],
default_value: 'true'
});
var html = dialog.option_layout.create([dialog.option_radio]);
dialog.container.append(html);
dialog.option_radio.set_value(['']);
return dialog;
};
//exp.orig_create_active_user_del_dialog =
IPA.user.create_active_user_del_dialog;
console.log('PRESERVE.JS WAS EXECUTED');
return exp;
});
I checked that disabling the comment or not does not change anything.
Can you see what I missed here ?
Thanks a lot,
Sebastien Julliot.
--
Pavel^3 Vomacka
--
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] Allow external AD users on webui
On ma, 31 loka 2016, Troels Hansen wrote: - On Oct 31, 2016, at 8:33 AM, Alexander Bokovoy aboko...@redhat.com wrote: You make it sound as if it is a done deal. It is not, there is a number of changes that yet not figured out how to do in an efficient way. It is in our pipeline for 4.5. It is understandable that people ask for this feature. It is also should be clear to you had it been a simple thing, it would have been implemented already. If you want to see a progress, subscribe to the ticket. Hi Alexander It was in no way a critics of the FreeIPA team. I'm well aware of the work being out into this product from the core team, and appreciate every new release, but also not really able to help much with the development, only testing and feedback. That's why I asked you to subscribe to the ticket. Once the changes will be ready, you could help with testing them. -- / Alexander Bokovoy -- 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] Allow external AD users on webui
- On Oct 31, 2016, at 8:33 AM, Alexander Bokovoy aboko...@redhat.com wrote: > You make it sound as if it is a done deal. It is not, there is a number > of changes that yet not figured out how to do in an efficient way. > > It is in our pipeline for 4.5. It is understandable that people ask for > this feature. It is also should be clear to you had it been a simple > thing, it would have been implemented already. > > If you want to see a progress, subscribe to the ticket. Hi Alexander It was in no way a critics of the FreeIPA team. I'm well aware of the work being out into this product from the core team, and appreciate every new release, but also not really able to help much with the development, only testing and feedback. I'm aware that this request isn't a simple change of structure, and the complexity of the product. Also, at the same time, a big thumbs up to the whole IPA team! Keep up the good work... -- 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] freeipa 4.2.0 ipa-cacert-manage not generating CSR with CA:True for chaining
we currently have a IPA 4.2 servers working with a self-signed CA certificate with the REALM of xyz.local I’m trying chain our xyz.local CA cert with IT’s abc.local CA cert so that users on corp laptop(with the abc.local cert already in CA chain) would trust the xyz.local CA cert and not get the SSL cert warning when visiting sites with certs issued by the IPA installation. I followed the step in freeipa documentation and ran: ipa-cacert-manage renew --external-ca it generated the ca.scr, but the CA attribute was set to False: [root@xyz ipa]# openssl req -in ca.csr -noout -text | grep -B 2 X509 friendlyName :unable to print attribute Requested Extensions: X509v3 Key Usage: Digital Signature, Non Repudiation, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:FALSE Please let me know how to generate the CSR so that CA is set to True, or do I need to manually modify the CSR to make it True ? 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] Allow external AD users on webui
On ma, 31 loka 2016, Troels Hansen wrote: Hi there After trying to add external usergroups from AD to allow (admin) users to log in to IPA webUI, by tdding the groups to toe local admin group and discovering that it didn't work, I found that as far as I can see, its currently not possibly, and fount this rather old ticket on the case: https://fedorahosted.org/freeipa/ticket/3242 I can see that its currently pushed for IPA 4.5 and that the required patch seems to have been made, but also that the request have been pushed for some time now. Is there and active plan for pushing this into the 4.5 release as I too would like to have this implemented and see this as a BIG missing feature that everyone have to log in as admin, or create local IPA users, to be able to log in to webui. You make it sound as if it is a done deal. It is not, there is a number of changes that yet not figured out how to do in an efficient way. It is in our pipeline for 4.5. It is understandable that people ask for this feature. It is also should be clear to you had it been a simple thing, it would have been implemented already. If you want to see a progress, subscribe to the ticket. -- / Alexander Bokovoy -- 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 fix a broken PKI state?
Hello dear FreeIPA people, After weeks of unsuccessful attempts, I seems to run out of sane ideas of how to proceed. I have been using FreeIPA in Docker container https://github.com/ adelton/docker-freeipa for over half a year now, and everything was fine up until this August when after a subsequent update my FreeIPA couldn't boot. I was messing things around and broke some files permissions, and it seems that during that process my PKI got reinstalled, so CA certificate and other certificates were regenerated... But they only got updated in the PKI (according to `certutil -L -d /etc/pki/pki-tomcat/alias ...` information it has certificates from August while `/etc/dirsrv/sldap-*/` and `/etc/httpd/alias/` have certificates from March). Unfortunately, I don't have backups from the time before the issue... Currently, everything but `pki-tomcat` is running successfully, though I think I won't be able to add a new host into the setup. I use `ipactl start --force` to ignore the PKI failure, but I would love to recover FreeIPA. The most relevant log I have found is `/var/log/pki/pki-tomcat/ca/debug`, which reveals the following error: ``` [localhost-startStop-1]: LdapJssSSLSocket: set client auth cert nickname subsystemCert cert-pki-ca Could not connect to LDAP server host freeipa.xxx.yyy.com port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-8054) You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. (-1) at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205) at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:166) at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:130) at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:654) at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1169) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1075) at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:571) at com.netscape.certsrv.apps.CMS.init(CMS.java:187) at com.netscape.certsrv.apps.CMS.start(CMS.java:1616) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:293) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:290) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:325) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:176) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:124) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1226) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1151) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1038) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5027) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5337) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:131) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:153) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:143) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:699) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:587) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1798) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at
[Freeipa-users] freeipa 4.2.0 ipa-cacert-manage not generating CSR with CA:True for chaining
we currently have a IPA 4.2 servers working with a self-signed CA certificate with the REALM of xyz.local I’m trying chain our xyz.local CA cert with IT’s abc.local CA cert so that users on corp laptop(with the abc.local cert already in CA chain) would trust the xyz.local CA cert and not get the SSL cert warning when visiting sites with certs issued by the IPA installation. I followed the step in freeipa documentation and ran: ipa-cacert-manage renew --external-ca it generated the ca.scr, but the CA attribute was set to False: [root@xyz ipa]# openssl req -in ca.csr -noout -text | grep -B 2 X509 friendlyName :unable to print attribute Requested Extensions: X509v3 Key Usage: Digital Signature, Non Repudiation, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:FALSE Please let me know how to generate the CSR so that CA is set to True, or do I need to manually modify the CSR to make it True ? Thanks. -- Efficiency is Intelligent Laziness -- 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] Allow external AD users on webui
Hi there After trying to add external usergroups from AD to allow (admin) users to log in to IPA webUI, by tdding the groups to toe local admin group and discovering that it didn't work, I found that as far as I can see, its currently not possibly, and fount this rather old ticket on the case: https://fedorahosted.org/freeipa/ticket/3242 I can see that its currently pushed for IPA 4.5 and that the required patch seems to have been made, but also that the request have been pushed for some time now. Is there and active plan for pushing this into the 4.5 release as I too would like to have this implemented and see this as a BIG missing feature that everyone have to log in as admin, or create local IPA users, to be able to log in to webui. -- 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
