Re: [Freeipa-users] Replica Cert failed to renew ...
Hmmm so question here .. our domain was originally installed as a 2.x and upgraded to 3.x .. I installed the replicas using the ipa-replica-prepare etc but the CA dirsrv instance was never copied over or started on the replicas (ie no slapd-PKI-* around) .. yet /etc/ipa/defaults.conf points to the replica itself for certmonger - so not sure how that will work given there is no CA copy running on the replica .. In the end the process followed was to change the xmlrpc_uri to the original master and delete and resubit the cert request for Server-Cert for slapd httpd/alias we get an up to date cert ... not sure if anything else broken by doing that though ... I assume maybe the replcia install/mgmt under 2.x was slightly or perhaps majorly different ... rgds Matt On 31/07/2014 6:21 pm, Martin Kosek wrote: (Adding back the users list as this may be interesting for everyone) Ok, the steps suggested below should help. If the DS does not want to start at all because of the expired certificate, you can also edit /etc/dirsrv/slapd-YOUR-REALM/dse.ldif and edit it manually (only when dirsrv service is stopped). Martin On 07/31/2014 09:53 AM, Matt Bryant wrote: Martin, Correct in that the replica does not have a CA and the version being run is $ rpm -qa ipa-server ipa-server-3.0.0-25.el6.x86_64 restarted the services and get Starting dirsrv: SERVER-IPA...[31/Jul/2014:18:00:15 +1000] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) so I think it is just dealing with an expired cert ... so will try the other steps suggested .. rgds Matt Bryant On 31/07/14 17:33, Martin Kosek wrote: On 07/31/2014 07:49 AM, Matt Bryant wrote: All, Got an issue with an IPA replica in that the certs in /etc/httpd/alias /etc/dirsrv/slapd-IPA-REALM have expired. I assume that this replica does not have a CA and we are only dealing with service HTTPD and DIRSRV service certificates. Have tried setting date back before expiry on the replica and doing an 'ipa-getcert resubmit -i id' but that hasn't worked it looks like the CA master is actually rejecting it since the havent set the date back on that server. Error am getting on replica is ... Request ID '20120719044839': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). Isn't this rather a problem that the replica does not trust the master server HTTPD certificate because it's certificates are not valid from replica POV? is there any way of forcing a re-newel or manual process for updating these certs .. ??? If this is just a replica without PKI, I would suggest synchronizing the time back with the master CA server and restarting all the services. If the HTTPD service does not want to start, follow chapter 25.2.2. Starting IdM with Expired Certificates in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/cas.html and then try to resubmit the certificates so that they can be renewed on the master. Do not forget to revert the above configuration changes when you are done. Also, what version of FreeIPA are you running? HTH, Martin -- Matt Bryant Manager - SMB Services | Melbourne IT | Brisbane | Tel +617 3230 7422 | Mob +61431 496663 -- 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] Replica Cert failed to renew ...
All, Got an issue with an IPA replica in that the certs in /etc/httpd/alias /etc/dirsrv/slapd-IPA-REALM have expired. Have tried setting date back before expiry on the replica and doing an 'ipa-getcert resubmit -i id' but that hasn't worked it looks like the CA master is actually rejecting it since the havent set the date back on that server. Error am getting on replica is ... Request ID '20120719044839': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). is there any way of forcing a re-newel or manual process for updating these certs .. ??? thx rgds Matt Bryant -- 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] Trust between IPA and another MIT Kerberos Realm
Simo, Have added the following into bugzilla .. Bug 1035494 https://bugzilla.redhat.com/show_bug.cgi?id=1035494 has been added to the database seems strange but whilst listprincs/getprinc works getpols and the addprinc (at least in this use case) doesnt... ie kadmin.local: add_principal -pw XXX krbtgt/OLD-REALM@IPA-REALM WARNING: no policy specified for krbtgt/OLD-REALM@IPA-REALM; defaulting to no policy add_principal: Invalid argument while creating krbtgt/OLD-REALM@IPA-REALM. kadmin.local: listpols get_policies: Plugin does not support the operation while retrieving list. rgds Matt B. On 11/27/2013 11:05 PM, Simo Sorce wrote: On Wed, 2013-11-27 at 15:24 +1000, Matt Bryant wrote: Hmm just upgraded to 3 so thought I woudl give it a go ... but (aint there always one of those :() can't seem to add the principle .. kadmin.local: add_principal krbtgt/OLD-REALM@IPA-REALM WARNING: no policy specified for krbtgt/OLD-REALM@IPA-REALM; defaulting to no policy Enter password for principal krbtgt/OLD-REALM@IPA-REALM: Re-enter password for principal krbtgt/OLD-REALM@IPA-REALM: add_principal: Invalid argument while creating krbtgt/OLD-REALM@IPA-REALM. and nothing was placed in the kadmin log .. :( This is almost certainly a bug, can you open a ticket so we can investigate ? Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm
Simo, Thanks for that .. using that switch the principle is now created on to see it it works as expected .. rgds Matt B. On 11/28/2013 09:10 AM, Simo Sorce wrote: On Thu, 2013-11-28 at 08:29 +1000, Matt Bryant wrote: Simo, Have added the following into bugzilla .. Bug 1035494 has been added to the database seems strange but whilst listprincs/getprinc works getpols and the addprinc (at least in this use case) doesnt... addprinc not working for normal user principals is expected, we block it to prevent the creation of incomplete user accounts. I think getpols is also expected to fail as we use IPA specific policies. However it should allow you to create krbtgt/OLD-REALM@IPA-REALM to set up trusts until we provide an explicit command for it. This is why I wanted you to open a bug on that. ie kadmin.local: add_principal -pw XXX krbtgt/OLD-REALM@IPA-REALM WARNING: no policy specified for krbtgt/OLD-REALM@IPA-REALM; defaulting to no policy add_principal: Invalid argument while creating krbtgt/OLD-REALM@IPA-REALM. Now that I think of it, there is an undocumented switch that will allow you to create an arbitrary principal. This switch should NEVER be used to create user principals or normal host principals, however it should allow you to workaround the issue until we can fix the kadmin interface. Use kadmin.local -x ipa-setup-override-restrictions But please use it exclusively to create the krbtgt/REALM1@REALM2 principals and nothing else. Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts ..
=server-ipa krbLastSuccessfulAuth: 20131124214435Z krbLoginFailedCount: 0 krbLastFailedAuth: 20131014050743Z memberOf: cn=admins,cn=groups,cn=accounts,dc=server-ipa memberOf: cn=replication administrators,cn=privileges,cn=pbac,dc=server-ipa memberOf: cn=add replication agreements,cn=permissions,cn=pbac,dc=server-ipa memberOf: cn=modify replication agreements,cn=permissions,cn=pbac,dc=server-ip a memberOf: cn=remove replication agreements,cn=permissions,cn=pbac,dc=server-ip a memberOf: cn=host enrollment,cn=privileges,cn=pbac,dc=server-ipa memberOf: cn=manage host keytab,cn=permissions,cn=pbac,dc=server-ipa memberOf: cn=enroll a host,cn=permissions,cn=pbac,dc=server-ipa memberOf: cn=add krbprincipalname to a host,cn=permissions,cn=pbac,dc=server-i pa memberOf: cn=unlock user accounts,cn=permissions,cn=pbac,dc=server-ipa memberOf: cn=manage service keytab,cn=permissions,cn=pbac,dc=server-ipa memberOf: cn=trust admins,cn=groups,cn=accounts,dc=server-ipa krbPasswordExpiration: 20140108225426Z krbExtraData:: xx krbTicketFlags: 128 krbLastPwdChange: 20131010225426Z objectClass: top objectClass: person objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: inetuser objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys uid: admin krbPrincipalName: admin@SERVER-IPA cn: Administrator sn: Administrator uidNumber: gidNumber: homeDirectory: /home/admin loginShell: /bin/bash gecos: Administrator ipaUniqueID: xxx # search result search: 4 result: 0 Success # numResponses: 3 # numEntries: 2 End: .Wed Nov 27 07:55:08 EST 2013 the whole thing still takes 6secs but most are coming back within the same second .. and the point it seems to slow down around is the initial ldap_int_select ... ldap_int_select read1msg: ld 0xdbf4a0 msgid 1 all 1 ber_get_next rgds Matt B. On 11/26/2013 06:41 PM, Sumit Bose wrote: On Tue, Nov 26, 2013 at 03:07:30PM +1000, Matt Bryant wrote: OK so been running some tcpdumps on this issue and the wierd thing is .. can see the initial sasl bind request followed by ack from ldap ... then nothing ldap/gssapi related until the unbind request post the 6s timeout period ... so no friggin idea whats going on just a big resounding nothing ... 14:20:47.065606 IP tardis.ipa.server-noc.com.40953 tardis.ipa.server-noc.com.ldap: Flags [P.], seq 261:974, ack 1502, win 280, options [nop,nop,TS val 23677005 ecr 23676785], length 713 14:20:47.104816 IP tardis.ipa.server-noc.com.ldap tardis.ipa.server-noc.com.40953: Flags [.], ack 974, win 276, options [nop,nop,TS val 23677045 ecr 23677005], length 0 14:20:53.066009 IP tardis.ipa.server-noc.com.40953 tardis.ipa.server-noc.com.ldap: Flags [P.], seq 974:981, ack 1502, win 280, options [nop,nop,TS val 23683006 ecr 23677045], length 7 14:20:53.066021 IP tardis.ipa.server-noc.com.ldap tardis.ipa.server-noc.com.40953: Flags [.], ack 981, win 276, options [nop,nop,TS val 23683006 ecr 23683006], length 0 14:20:53.066100 IP tardis.ipa.server-noc.com.40953 tardis.ipa.server-noc.com.ldap: Flags [F.], seq 981, ack 1502, win 280, options [nop,nop,TS val 23683006 ecr 23683006], length 0 14:20:53.105731 IP tardis.ipa.server-noc.com.ldap tardis.ipa.server-noc.com.40953: Flags [.], ack 982, win 276, options [nop,nop,TS val 23683046 ecr 23683006], length 0 14:20:53.111470 IP tardis.ipa.server-noc.com.ldap tardis.ipa.server-noc.com.40953: Flags [F.], seq 1502, ack 982, win 276, options [nop,nop,TS val 23683051 ecr 23683006], length 0 14:20:53.111486 IP tardis.ipa.server-noc.com.40953 tardis.ipa.server-noc.com.ldap: Flags [.], ack 1503, win 280, options [nop,nop,TS val 23683051 ecr 23683051], length 0 Comparing that to a connection that works and brings the backend online .. 14:22:01.193809 IP tardis.ipa.server-noc.com.41031 tardis.ipa.server-noc.com.ldap: Flags [S], seq 3387425755, win 32792, options [mss 16396,sackOK,TS val 23751134 ecr 0,nop,wscale 7], length 0 14:22:01.193833 IP tardis.ipa.server-noc.com.ldap tardis.ipa.server-noc.com.41031: Flags [S.], seq 1024653772, ack 3387425756, win 32768, options [mss 16396,sackOK,TS val 23751134 ecr 23751134,nop,wscale 7], length 0 14:22:01.193848 IP tardis.ipa.server-noc.com.41031 tardis.ipa.server-noc.com.ldap: Flags [.], ack 1, win 257, options [nop,nop,TS val 23751134 ecr 23751134], length 0 14:22:01.194371 IP tardis.ipa.server-noc.com.41031 tardis.ipa.server-noc.com.ldap: Flags [P.], seq 1:261, ack 1, win 257, options [nop,nop,TS val 23751134 ecr 23751134], length 260 14:22:01.194385 IP tardis.ipa.server-noc.com.ldap tardis.ipa.server-noc.com.41031: Flags [.], ack 261, win 265, options [nop,nop,TS val 23751134 ecr 23751134], length 0 14:22:01.195187 IP tardis.ipa.server-noc.com.ldap tardis.ipa.server-noc.com.41031: Flags [P.], seq 1:1502, ack 261, win 265, options [nop,nop,TS val 23751135 ecr 23751134], length 1501 14:22:01.195201 IP tardis.ipa.server-noc.com.41031 tardis.ipa.server
[Freeipa-users] Trust between IPA and another MIT Kerberos Realm
All, Is there any documentation anywhere that describes whether this can be done and how to do it ?? Would like to set up a one way trust between a new IPA realm and a legacy kerberos realm. The doco explicitly says dont use kadmin/kadmin.local so not sure how to get the krbtgt/OLD_REALM@IPA-REALM principle into IPA that would facilitate such a trust. rgds Matt B. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trust between IPA and another MIT Kerberos Realm
Hmm just upgraded to 3 so thought I woudl give it a go ... but (aint there always one of those :() can't seem to add the principle .. kadmin.local: add_principal krbtgt/OLD-REALM@IPA-REALM WARNING: no policy specified for krbtgt/OLD-REALM@IPA-REALM; defaulting to no policy Enter password for principal krbtgt/OLD-REALM@IPA-REALM: Re-enter password for principal krbtgt/OLD-REALM@IPA-REALM: add_principal: Invalid argument while creating krbtgt/OLD-REALM@IPA-REALM. and nothing was placed in the kadmin log .. :( rgds Matt B. On 11/27/2013 01:57 PM, Rob Crittenden wrote: Matt Bryant wrote: All, Is there any documentation anywhere that describes whether this can be done and how to do it ?? Would like to set up a one way trust between a new IPA realm and a legacy kerberos realm. The doco explicitly says dont use kadmin/kadmin.local so not sure how to get the krbtgt/OLD_REALM@IPA-REALM principle into IPA that would facilitate such a trust. We haven't implemented (or tested) this yet. It is just MIT Kerberos under-the-hood so in theory creating the right principals should do the trick. If you have IPA 3.0+ then you can use kadmin to create the principals you need. IIRC the RHEL Kerberos documentation is fairly good in this regard. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts ..
) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 7 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTTrustedDomain][cn=trusts,dc=server-ipa]. (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 (Tue Nov 26 09:16:22 2013) [sssd[be[ipa.server-noc.com]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication. also seeing these errors ... Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_update_ranges] (0x0400): Adding range [SERVER-IPA_id_range]. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_range_create] (0x0040): Invalid range, expected that either the secondary base rid or the SID of the trusted domain is set, but not both or none of them. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_range_create] (0x0400): Error: 22 (Invalid argument) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [sysdb_update_ranges] (0x0040): sysdb_range_create failed. (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 0) (Tue Nov 26 09:42:02 2013) [sssd[be[ipa.server-noc.com]]] [ipa_subdomains_handler_ranges_done] (0x0040): sysdb_update_ranges failed. Have not setup any AD trusts etc ... rgds Matt B. On 11/25/2013 06:49 PM, Sumit Bose wrote: On Mon, Nov 25, 2013 at 09:23:22AM +1000, Matt Bryant wrote: All, Was wondering if anyone can help out or point us the in right direction. Ever since we updated from IPA v2.1 to IPA v3.0 have been seeing some intermittent errors when trying to change passwords etc. Getting the error cannot change password since system
[Freeipa-users] Intermittent Issues changing passwords since updating to ipa v3 and sasl_bind timeouts ..
All, Was wondering if anyone can help out or point us the in right direction. Ever since we updated from IPA v2.1 to IPA v3.0 have been seeing some intermittent errors when trying to change passwords etc. Getting the error cannot change password since system offline. Have increased the logging and found that quite frequently the sasl_bind using the host principle is timing out and failing ... (whether this is red herring or not dont know but cant be good anyhow) (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/tardis.ipa.server-noc.com, SERVER-IPA, 86400) (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [get_server_status] (0x1000): Status of server 'tardis.ipa.server-noc.com' is 'working' (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [be_resolve_server_process] (0x0200): Found address for server tardis.ipa.server-noc.com: [203.147.190.30] TTL 7200 (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [create_tgt_req_send_buffer] (0x1000): buffer size: 56 (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [3734] (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [child_handler_setup] (0x2000): Signal handler set up for pid [3734] (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: sh[0xa45960], connected[1], ops[(nil)], ldap[0xa12200] (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [child_sig_handler] (0x1000): Waiting for child [3734]. (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [child_sig_handler] (0x0100): child [3734] finished successfully. (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_SERVER-IPA], expired on [1385420045] (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1385334545 (Mon Nov 25 08:54:05 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/tardis.ipa.server-noc.com (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-5)[Timed out] (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] [sasl_bind_send] (0x0080): Extended failure message: [unknown error] (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'tardis.ipa.server-noc.com' as 'not working' (Mon Nov 25 08:54:11 2013) [sssd[be[ipa.server-noc.com]]] [sdap_handle_release] (0x2000): Trace: sh[0xa45960], connected[1], ops[(nil)], ldap[0xa12200], destructor_lock[0], release_memory[0] .. .. it then goes on to connect to fail over server and succeed and shortly after the master server is tested and marked as working again ... works for a couple of times then time out again .. any pointers gratefully received. packages used ... ipa-server-3.0.0-25.el6.x86_64 sssd-1.9.2-82.11.el6_4.x86_64 rgds Matt Bryant ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
