Re: [Freeipa-users] User AD can not Login Client Linux
On (23/08/15 17:53), alireza baghery wrote: Hi i install Centos 7.1 (IDM Server) and integrate with Windows SERVER 2008 R2 Trust USER AD can not Login on client (OLE 6.6) but User create idm can login name IDM SERVER= ipasrv.l.infotechpsp.net domain Windows = infotechpsp.net i execute [ kinit abagh...@infotechpsp.net] on IDM Server and klist and show keytab abagheri but execute kvno abag...@infotechpsp.net get ERROR kvno Server not found in kerberos database please help me and thank you KLIST Valid starting ExpiresService principal 08/23/15 17:09:53 08/24/15 03:11:34 krbtgt/infotechpsp@infotechpsp.net renew until 08/24/15 17:09:53 = Tail LOG /var/log/sssd/ssd_l.infotechpsp.net debug_level = 6 = [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/ussd7.l.infotechpsp.net, L.INFOTECHPSP.NET, 86400) (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [be_resolve_server_process] (0x0200): Found address for server ipasrv.l.infotechpsp.net: [10.30.160.19] TTL 1200 (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [write_pipe_handler] (0x0400): All data has been sent! (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [read_pipe_handler] (0x0400): EOF received, client finished (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ ccache_L.INFOTECHPSP.NET], expired on [1440420165] (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Sun Aug 23 17:12:45 2015) [sssd[be[l.infotechpsp.net]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/ ussd7.l.infotechpsp.net (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [child_sig_handler] (0x0100): child [13370] finished successfully. (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [fo_set_port_status] (0x0100): Marking port 389 of server ' ipasrv.l.infotechpsp.net' as 'working' (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [set_server_common_status] (0x0100): Marking server ' ipasrv.l.infotechpsp.net' as 'working' (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTTrustedDomain][cn=trusts,dc=l,dc=infotechpsp,dc=net]. (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaIDRange][cn=ranges,cn=etc,dc=l,dc=infotechpsp,dc=net]. (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTDomainAttrs][cn=ad,cn=etc,dc=l,dc=infotechpsp,dc=net]. (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [get_subdomains_callback] (0x0400): Backend returned: (0, 0, NULL) [Success] (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=abagheri] (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Sun Aug 23 17:12:46 2015) [sssd[be[l.infotechpsp.net]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Operations error(1), (null) There seems to be a problem on server side. It's is a very likely bug in sssd on FreeIPA server. Some AD related fixes are included in latest update in el7.1 (1.12.2-58.el7_1.14) If it does not help please try to upgrade to the latest upstream version of sssd[1]. I hope it will help otherwise we will need to see log files from IPA server. LS [1] https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12/ -- Manage your subscription for the Freeipa-users
Re: [Freeipa-users] stubborn old replicas
You could try this (RH recommended way). It works for me better than
cleanallruv.pl as this sometimes leads to ldap freeze)
unable to decode: {replica 30} 5548fa20001e 5548fa20001e
unable to decode: {replica 26} 5548a9a8001a 5548a9a8001a
for all of them, on-by-one:
ldapmodify -x -D cn=directory manager -w XXX dn:
cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype:
modify replace: nsds5task nsds5task: CLEANRUV30 enter + Ctrl + D
On Fri, Aug 28, 2015 at 4:55 PM, Guillermo Fuentes
guillermo.fuen...@modernizingmedicine.com wrote:
Hi Janelle,
Using the cleanallruv.pl tool was the only way I was able to get ride of
the unable to decode: {replica x} entries.
This is how I used it, cleaning a replica ID at a time:
# For replica id: 40
cleanallruv.pl -v -D cn=directory manager -w - -b 'dc=example,dc=com'
-r 40
Note that the -w - will make the tool prompt you for the directory
manager password.
Hope this helps,
Guillermo
On Thu, Aug 27, 2015 at 10:27 AM, Janelle janellenicol...@gmail.com
wrote:
On 8/27/15 1:05 AM, thierry bordaz wrote:
On 08/27/2015 09:41 AM, Ludwig Krispenz wrote:
On 08/27/2015 09:08 AM, Martin Kosek wrote:
On 08/26/2015 05:31 PM, Simo Sorce wrote:
On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:
Hello all,
My biggest problem is losing replicas and then trying to delete the
entries and rebuild them. Here is a perfect example, I simply can't get
rid of these (see below). I have tried (of course after the ORIGINAL
ipa-replica-manage del hostname --force --clean:
ipa-replica-manage clean-ruv 25
ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25
And yet nothing works. Any suggestions? This is perhaps the most
frustrating part about maintaining IPA.
~J
unable to decode: {replica 12} 5588dc2e000c 559f3de60004000c
unable to decode: {replica 14} 5587aa8d000e 5587aa8d0003000e
unable to decode: {replica 16} 5588f58f0010 55bb7b0800050010
unable to decode: {replica 25} 55a4887b0019 55a4924200040019
unable to decode: {replica 29} 55d199a50001001d 55d199a50001001d
unable to decode: {replica 3} 5587c5c30003 55b8a04900010003
unable to decode: {replica 5} 55cc82ab041d0005 55cc82ab041d0005
Have you tried restarting DS before trying to clean the ruv ?
I run in a similar problem in a test install recently, and I got better
results that way. The bug is known to the DS people and they are working
to get out patches that fix the root issue.
Simo.
CCing DS folks. Wasn't there a recent DS fix that was supposed to improve
the
RUV situation?
Looking at 389 DS Trac, I see some interesting RUV fixes in 1.3.4.x
releases:
https://fedorahosted.org/389/query?summary=~RUVstatus=closedorder=milestonecol=idcol=summarycol=statuscol=ownercol=typecol=prioritycol=milestone
I see that 389-ds-base-1.3.4.3 is already in Fedora 22+, does the RUV
issue
happen there?
it should not, and I think Thierry verified the fix.
The problem we resolved and which we think is the core of the corrupted
RUV was that the cleanallruv task did only purge the RUV, but dit not purge
the changelog. If cleanallruv was run and the server had a disorderly
shutdown (crash or abort when shutdown was hanging) then at restart the
changelog RUV was rebuilt from the data in the changelog and if it
contained a csn from cleaned RIDs this was added to the RUV (but the
reference to the server was lost and so the url part is missing from this
RUV.
The fix now does remove all references to the cleaned RID from the
changelog and the problem should not reoccur with RIDs cleaned with the
fix, of course th echangelog can still can contain references to RIDs
cleaned before the fix - and if no changelog trimming is configured this is
what will happen. So, even after the fix old RUVs could pop up and have to
be (finally) cleaned.
The other source is that these corrupted rivs can be imported from
another server by exchanging ruvs in the repl protocol. Cleanallruv tries
to address this and to propagate the cleanallruv tasks to all servers it
thinks are connected. If there are replication agreements to servers which
no longer exist or to servers which cannot be connetcted this will delay
the ruv cleaning
Hello,
I verified the fix in 1.3.4.2 F22 / 389-ds-base-1.3.4.0-6.el7 RHEL7, so
after those versions CLEANALLRUV do not create any longer corrupted ruv
elements.
According to the timestamp in the ruv (for example csn2date.py
5587aa8d0003000e -- 22/06/2015:06:26:21) this are old ruv elements. I
think Ludwig is right, these corrupted ruv-elements come from old
cleanallruv before the fix was applied.
The problem is that even a fixed server can get those corrupted
ruv-elements from others
Re: [Freeipa-users] Using IPA CA to sign SSL client certificates
On 08/28/2015 10:41 AM, Jan Pazdziora wrote: That's new feature in FreeIPA 4.2: http://www.freeipa.org/page/V4/User_Certificates I'm glad to see that's being added. I have IPA 3.0 on CentOS 6 (on a 32-bit system), so I won't be able to use that feature. I'm basically asking if there's a way to manually use the CA within my existing IPA install to manually create a certificate, in a way that is non-disruptive to IPA itself. I hope that makes sense. Thanks! -- Ian Pilcher arequip...@gmail.com I grew up before Mark Zuckerberg invented friendship -- 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] ssh_exchange_identification: Connection closed by remote host
On Fri, Aug 28, 2015 at 05:10:31PM +0200, Roberto Cornacchia wrote: Hi, I have two hosts, photon and hadron, and an LDAP user roberto. The user can login successfully on both machines. The SSH pub key is uploaded . Running sss_ssh_authorizedkeys roberto from both clients returns the same key. Port 22 is open on both clients, sshd is running on both clients. On both client, /etc/ssh/ssh_config is: Host * GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts PubkeyAuthentication yes ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h GSSAPIAuthentication yes On both clients, /etc/ssh/sshs_config is: KerberosAuthentication no PubkeyAuthentication yes UsePAM yes AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys GSSAPIAuthentication yes AuthorizedKeysCommandUser nobody However, ssh from hadron to photon works, the other way around doesn't: roberto@photon $ ssh -vv hadron OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 56: Applying options for * debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p 22 hadron debug1: permanently_drop_suid: 117206 debug1: identity file /home/roberto/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.9 *ssh_exchange_identification: Connection closed by remote host* If I include a few other cases, this is the summary: - photon to hadron FAILS - photon to photon SUCCEEDS - photon to ipa server SUCCEEDS - photon to (non-ipa-client) FAILS before asking password (no keypair suthentication expected here) - hadron to photon SUCCEEDS - hadron to hadron FAILS - hadron to ipa server SUCCEEDS - hadron to (non-ipa-client) FAILS before asking password (no keypair suthentication expected here) I know that the error above is quite generic, so I don't expect someone can point out the exact cause, but perhaps someone can help me debug this? What could I look at? Do you have any HBAC rules for hadron activated on the IPA server? If not, can you activate sshd debug logging on hadron by setting LogLevel to DEBUG3 in sshd_config and restarting sshd? Maybe they have some useful information. HTH bye, Sumit Thanks, Roberto -- 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
Re: [Freeipa-users] Using IPA CA to sign SSL client certificates
On 08/28/2015 10:35 AM, Alexander Bokovoy wrote: This is all explained in the official guide: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/service-certificates.html I guess I should have been more clear. I need to create certificates for users, not services. -- Ian Pilcher arequip...@gmail.com I grew up before Mark Zuckerberg invented friendship -- 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_exchange_identification: Connection closed by remote host
Hi, I have two hosts, photon and hadron, and an LDAP user roberto. The user can login successfully on both machines. The SSH pub key is uploaded . Running sss_ssh_authorizedkeys roberto from both clients returns the same key. Port 22 is open on both clients, sshd is running on both clients. On both client, /etc/ssh/ssh_config is: Host * GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts PubkeyAuthentication yes ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h GSSAPIAuthentication yes On both clients, /etc/ssh/sshs_config is: KerberosAuthentication no PubkeyAuthentication yes UsePAM yes AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys GSSAPIAuthentication yes AuthorizedKeysCommandUser nobody However, ssh from hadron to photon works, the other way around doesn't: roberto@photon $ ssh -vv hadron OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 56: Applying options for * debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p 22 hadron debug1: permanently_drop_suid: 117206 debug1: identity file /home/roberto/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.9 *ssh_exchange_identification: Connection closed by remote host* If I include a few other cases, this is the summary: - photon to hadron FAILS - photon to photon SUCCEEDS - photon to ipa server SUCCEEDS - photon to (non-ipa-client) FAILS before asking password (no keypair suthentication expected here) - hadron to photon SUCCEEDS - hadron to hadron FAILS - hadron to ipa server SUCCEEDS - hadron to (non-ipa-client) FAILS before asking password (no keypair suthentication expected here) I know that the error above is quite generic, so I don't expect someone can point out the exact cause, but perhaps someone can help me debug this? What could I look at? Thanks, Roberto -- 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] Using IPA CA to sign SSL client certificates
On Fri, 28 Aug 2015, Ian Pilcher wrote: On 08/28/2015 10:35 AM, Alexander Bokovoy wrote: This is all explained in the official guide: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/service-certificates.html I guess I should have been more clear. I need to create certificates for users, not services. User certificates is a feature we added in FreeIPA 4.2. It is coming to Red Hat Enterprise Linux 7 updates and Fedora 'soon'. -- / 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] Failed to start pki-tomcatd Service
Le 28 août 2015 à 17:41, Alexander Bokovoy aboko...@redhat.com a écrit : On Fri, 28 Aug 2015, Alexandre Ellert wrote: Le 28 août 2015 à 17:09, Alexander Bokovoy aboko...@redhat.com a écrit : On Wed, 26 Aug 2015, Alexandre Ellert wrote: Le 28 juil. 2015 à 05:59, Alexander Bokovoy aboko...@redhat.com a écrit : If the problem is too hard to solve, maybe I should try to deploy another replica ? You may try that. Sorry for not responding, I have some other tasks that occupy my time right now. Can you please tell me the procedure to decommission and re-create a new replica ? Are ipa-server-install —uninstall then ipa-server-install the only things to do ? No, you need also to remove the server from the replication topology. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html -- / Alexander Bokovoy I can’t remove the node on which I have problem with pki-tomcatd : # ipa-replica-manage del .example.com Deleting a master is irreversible. To reconnect to the remote master you will need to prepare a new replica file and re-install. Continue to delete? [no]: yes Deleting this server is not allowed as it would leave your installation without a CA I seem that it’s the only node where CA is installed. What should I do now ? Add a replica with CA using ipa-ca-install on existing replica. Read the guide, it has detailed coverage of these situations. -- / Alexander Bokovoy On the first node (which is working and without pki-tomcatd service) # ipa-ca-install Directory Manager (existing master) password: CA is already installed. How is it possible ? -- 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] Failed to start pki-tomcatd Service
On Wed, 26 Aug 2015, Alexandre Ellert wrote: Le 28 juil. 2015 à 05:59, Alexander Bokovoy aboko...@redhat.com a écrit : If the problem is too hard to solve, maybe I should try to deploy another replica ? You may try that. Sorry for not responding, I have some other tasks that occupy my time right now. Can you please tell me the procedure to decommission and re-create a new replica ? Are ipa-server-install —uninstall then ipa-server-install the only things to do ? No, you need also to remove the server from the replication topology. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html -- / 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] Using IPA CA to sign SSL client certificates
I need to create a few client certificates, and I'd like to use my pre- existing IPA CA. Is there a simple way to do this? Thanks! -- Ian Pilcher arequip...@gmail.com I grew up before Mark Zuckerberg invented friendship -- 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] Failed to start pki-tomcatd Service
Le 28 août 2015 à 17:09, Alexander Bokovoy aboko...@redhat.com a écrit : On Wed, 26 Aug 2015, Alexandre Ellert wrote: Le 28 juil. 2015 à 05:59, Alexander Bokovoy aboko...@redhat.com a écrit : If the problem is too hard to solve, maybe I should try to deploy another replica ? You may try that. Sorry for not responding, I have some other tasks that occupy my time right now. Can you please tell me the procedure to decommission and re-create a new replica ? Are ipa-server-install —uninstall then ipa-server-install the only things to do ? No, you need also to remove the server from the replication topology. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html -- / Alexander Bokovoy I can’t remove the node on which I have problem with pki-tomcatd : # ipa-replica-manage del .example.com Deleting a master is irreversible. To reconnect to the remote master you will need to prepare a new replica file and re-install. Continue to delete? [no]: yes Deleting this server is not allowed as it would leave your installation without a CA I seem that it’s the only node where CA is installed. What should I do now ? Thank you again for your support. -- 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] Using IPA CA to sign SSL client certificates
On Fri, 28 Aug 2015, Ian Pilcher wrote: I need to create a few client certificates, and I'd like to use my pre- existing IPA CA. Is there a simple way to do this? This is all explained in the official guide: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/service-certificates.html -- / 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] Using IPA CA to sign SSL client certificates
On Fri, Aug 28, 2015 at 10:38:46AM -0500, Ian Pilcher wrote: On 08/28/2015 10:35 AM, Alexander Bokovoy wrote: This is all explained in the official guide: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/service-certificates.html I guess I should have been more clear. I need to create certificates for users, not services. That's new feature in FreeIPA 4.2: http://www.freeipa.org/page/V4/User_Certificates -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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] Failed to start pki-tomcatd Service
On Fri, 28 Aug 2015, Alexandre Ellert wrote: Le 28 août 2015 à 17:09, Alexander Bokovoy aboko...@redhat.com a écrit : On Wed, 26 Aug 2015, Alexandre Ellert wrote: Le 28 juil. 2015 à 05:59, Alexander Bokovoy aboko...@redhat.com a écrit : If the problem is too hard to solve, maybe I should try to deploy another replica ? You may try that. Sorry for not responding, I have some other tasks that occupy my time right now. Can you please tell me the procedure to decommission and re-create a new replica ? Are ipa-server-install —uninstall then ipa-server-install the only things to do ? No, you need also to remove the server from the replication topology. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html -- / Alexander Bokovoy I can’t remove the node on which I have problem with pki-tomcatd : # ipa-replica-manage del .example.com Deleting a master is irreversible. To reconnect to the remote master you will need to prepare a new replica file and re-install. Continue to delete? [no]: yes Deleting this server is not allowed as it would leave your installation without a CA I seem that it’s the only node where CA is installed. What should I do now ? Add a replica with CA using ipa-ca-install on existing replica. Read the guide, it has detailed coverage of these situations. -- / 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] stubborn old replicas
Hi Janelle,
Using the cleanallruv.pl tool was the only way I was able to get ride of
the unable to decode: {replica x} entries.
This is how I used it, cleaning a replica ID at a time:
# For replica id: 40
cleanallruv.pl -v -D cn=directory manager -w - -b 'dc=example,dc=com' -r
40
Note that the -w - will make the tool prompt you for the directory
manager password.
Hope this helps,
Guillermo
On Thu, Aug 27, 2015 at 10:27 AM, Janelle janellenicol...@gmail.com wrote:
On 8/27/15 1:05 AM, thierry bordaz wrote:
On 08/27/2015 09:41 AM, Ludwig Krispenz wrote:
On 08/27/2015 09:08 AM, Martin Kosek wrote:
On 08/26/2015 05:31 PM, Simo Sorce wrote:
On Wed, 2015-08-26 at 06:36 -0700, Janelle wrote:
Hello all,
My biggest problem is losing replicas and then trying to delete the
entries and rebuild them. Here is a perfect example, I simply can't get
rid of these (see below). I have tried (of course after the ORIGINAL
ipa-replica-manage del hostname --force --clean:
ipa-replica-manage clean-ruv 25
ldapmodify... with:
dn: cn=clean 25, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
replica-id: 25
cn: clean 25
And yet nothing works. Any suggestions? This is perhaps the most
frustrating part about maintaining IPA.
~J
unable to decode: {replica 12} 5588dc2e000c 559f3de60004000c
unable to decode: {replica 14} 5587aa8d000e 5587aa8d0003000e
unable to decode: {replica 16} 5588f58f0010 55bb7b0800050010
unable to decode: {replica 25} 55a4887b0019 55a4924200040019
unable to decode: {replica 29} 55d199a50001001d 55d199a50001001d
unable to decode: {replica 3} 5587c5c30003 55b8a04900010003
unable to decode: {replica 5} 55cc82ab041d0005 55cc82ab041d0005
Have you tried restarting DS before trying to clean the ruv ?
I run in a similar problem in a test install recently, and I got better
results that way. The bug is known to the DS people and they are working
to get out patches that fix the root issue.
Simo.
CCing DS folks. Wasn't there a recent DS fix that was supposed to improve
the
RUV situation?
Looking at 389 DS Trac, I see some interesting RUV fixes in 1.3.4.x
releases:
https://fedorahosted.org/389/query?summary=~RUVstatus=closedorder=milestonecol=idcol=summarycol=statuscol=ownercol=typecol=prioritycol=milestone
I see that 389-ds-base-1.3.4.3 is already in Fedora 22+, does the RUV
issue
happen there?
it should not, and I think Thierry verified the fix.
The problem we resolved and which we think is the core of the corrupted
RUV was that the cleanallruv task did only purge the RUV, but dit not purge
the changelog. If cleanallruv was run and the server had a disorderly
shutdown (crash or abort when shutdown was hanging) then at restart the
changelog RUV was rebuilt from the data in the changelog and if it
contained a csn from cleaned RIDs this was added to the RUV (but the
reference to the server was lost and so the url part is missing from this
RUV.
The fix now does remove all references to the cleaned RID from the
changelog and the problem should not reoccur with RIDs cleaned with the
fix, of course th echangelog can still can contain references to RIDs
cleaned before the fix - and if no changelog trimming is configured this is
what will happen. So, even after the fix old RUVs could pop up and have to
be (finally) cleaned.
The other source is that these corrupted rivs can be imported from
another server by exchanging ruvs in the repl protocol. Cleanallruv tries
to address this and to propagate the cleanallruv tasks to all servers it
thinks are connected. If there are replication agreements to servers which
no longer exist or to servers which cannot be connetcted this will delay
the ruv cleaning
Hello,
I verified the fix in 1.3.4.2 F22 / 389-ds-base-1.3.4.0-6.el7 RHEL7, so
after those versions CLEANALLRUV do not create any longer corrupted ruv
elements.
According to the timestamp in the ruv (for example csn2date.py
5587aa8d0003000e -- 22/06/2015:06:26:21) this are old ruv elements. I
think Ludwig is right, these corrupted ruv-elements come from old
cleanallruv before the fix was applied.
The problem is that even a fixed server can get those corrupted
ruv-elements from others servers.
All servers in the topology should be updated with that fix, so that at
least they stop creating corrupted ruv-elements.
Now to get rid of the existing ones, I imagine only brute option of
recreating replica and reinit... I hope an other option is possible.
thanks
thierry
Simple question -- what if one is running RHEL 7.1?? Can this fix be
installed?? I see you mentioned it is in 1.3.4.0 for RHEL 7, but I don't
see it?
~J
--
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
Re: [Freeipa-users] ssh_exchange_identification: Connection closed by remote host
On Fri, 28 Aug 2015, Roberto Cornacchia wrote: Hi, I have two hosts, photon and hadron, and an LDAP user roberto. The user can login successfully on both machines. The SSH pub key is uploaded . Running sss_ssh_authorizedkeys roberto from both clients returns the same key. Port 22 is open on both clients, sshd is running on both clients. On both client, /etc/ssh/ssh_config is: Host * GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts PubkeyAuthentication yes ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h GSSAPIAuthentication yes On both clients, /etc/ssh/sshs_config is: KerberosAuthentication no PubkeyAuthentication yes UsePAM yes AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys GSSAPIAuthentication yes AuthorizedKeysCommandUser nobody However, ssh from hadron to photon works, the other way around doesn't: roberto@photon $ ssh -vv hadron OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 56: Applying options for * debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p 22 hadron debug1: permanently_drop_suid: 117206 debug1: identity file /home/roberto/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/roberto/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.9 *ssh_exchange_identification: Connection closed by remote host* If I include a few other cases, this is the summary: - photon to hadron FAILS - photon to photon SUCCEEDS - photon to ipa server SUCCEEDS - photon to (non-ipa-client) FAILS before asking password (no keypair suthentication expected here) - hadron to photon SUCCEEDS - hadron to hadron FAILS - hadron to ipa server SUCCEEDS - hadron to (non-ipa-client) FAILS before asking password (no keypair suthentication expected here) I know that the error above is quite generic, so I don't expect someone can point out the exact cause, but perhaps someone can help me debug this? What could I look at? Launch the following command under root: /usr/bin/sss_ssh_knownhostsproxy --debug 10 -p 22 hadron echo $? and see what it returns You also will get debug output from the run in syslog or journaldb, like: Aug 28 15:25:37 m1.example.com sss_ssh_knownhostsproxy[17049]: sss_ssh_get_ent() failed (2): No such file or directory Aug 28 15:25:37 m1.example.com sss_ssh_knownhostsproxy[17049]: connect() failed (113): No route to host -- / 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] certificate renewal stuck
Hey there - I¹m working a FreeIPA box (ipa-server-3.0.0-42) - Our original PKI ³master² was nuked a while ago and I have a suspicion that none of the other ³master² freeipa replicas were ³promoted² (sorry for the over-use of ³ ) So we went ahead and ran through these instructions and are currently in a weird state: http://www.freeipa.org/page/IPA_2x_Certificate_Renewal krb5 won¹t start and the getcert list command is returning CA_UNREACHABLE krb5kdc: Server error - while fetching master key K/M for realm status: CA_UNREACHABLE ca-error: Error setting up ccache for host service on client using default keytab: Cannot contact any KDC for realm So I don¹t think I can promote another master/replica ? Thanks, Mike smime.p7s Description: S/MIME cryptographic 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] certificate renewal stuck
I suspect that was the issue - Of course moved on to something else (hostname removed) Request ID '20140520151448': status: CA_UNREACHABLE ca-error: Server at https://ldapserver/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)). I assuming this new error is a result of my failed attempt at updating the certificates. Any idea if I was heading down the correct path? - I would have assumed these certs would have renewed themselves since I¹m +3.0. I see the Configure renewal section but its an odd situation where we have to renew and reconfigure Mike On 8/28/15, 7:45 PM, Rob Crittenden rcrit...@redhat.com wrote: Mike LoSapio wrote: Hey there - I¹m working a FreeIPA box (ipa-server-3.0.0-42) - Our original PKI ³master² was nuked a while ago and I have a suspicion that none of the other ³master² freeipa replicas were ³promoted² (sorry for the over-use of ³ ) So we went ahead and ran through these instructions and are currently in a weird state: krb5 won¹t start and the getcert list command is returning CA_UNREACHABLE krb5kdc: Server error - while fetching master key K/M for realm See if the LDAP server is running. status: CA_UNREACHABLE ca-error: Error setting up ccache for host service on client using default keytab: Cannot contact any KDC for realm This makes sense since the KDC isn't running. So I don¹t think I can promote another master/replica ? There really is no promotion, all IPA servers are masters. The only difference is what extra services (CA, DNS) may be running and who controls renewal and CRL generation. See rob smime.p7s Description: S/MIME cryptographic 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] Troubles with extending FreeIPA Web UI to fit my environment
W dniu 27.08.2015 o 15:18, Rob Crittenden pisze: Mateusz Małek wrote: We're trying to adjust FreeIPA to our environment... quite a bit. Here are some bullet points: (...) 3. Passwords need to be generated automatically, so user administrator won't be required to invent them for every single user. It should appear on-screen after user account creation. The ability is there on the CLI (don't know if it is exposed in UI): $ ipa user-add --first=random --last=user ruser --random -- Added user ruser -- User login: ruser First name: random ... Random password: Gu8VpULbb9xv ... Yeah, I've already found it ;) It isn't exposed in Web UI, but it wasn't extremely difficult to change these bits of code to send random: true with user_add request and then display dialog box with randompassword value sent in response (code is a bit ugly at the moment, as this is fair bit of copy-paste programming - but it works). I think the most problematic part of my struggles with adjusting IPA to my environment is point 4 of my list - it is easy to remove that single line responsible for creating default value of username, but I really want to avoid troubles with upgrades and that's why I'm trying to patch this in some pluggable, update-friendly way. Is there any interface to access definition of particular field from ipalib plugin code? At the moment I'm monkey-patching user object like that: from ipalib.plugins import user def patch(params): for param in params: if param.name == 'uid': yield param.clone(default_from=None) else: yield param user.user.takes_params = tuple(patch(user.user.takes_params)) It works, but is there any better (or more appropriate) way to replace one specific parameter definition? Best regards Mateusz Małek -- 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
